A top down approach would attempt to document databases, data flows, business rules, data quality, transformations, and application integration. While some of this is clearly needed and important for IT organizations to develop, the task of developing and maintaining rigorous documentation is daunting. In my experience, I seldom find IT organizations with this documentation and practice in place.
I'm an advocate of bottoms up, business driven discovery efforts. So if you're successful and have found people in the organization who have asked good data driven questions, what's next? How do you start answering questions with a limited enterprise guide to your data?
Who are your Data Explorers?
Eventually, this team will want to explore the data which is where technical skills will be needed. Don't immediately assume that this is your DBA - it depends. If your DBA largely keeps the databases humming, provides access, and occasionally creates views or data reports, then this person might not be skilled at data discovery tools and practices. You'll need someone who can develop entity relationship diagrams, use visualization tools to provide top-down access to data, and is skilled in data quality tools to perform a dimensional data quality analysis. She will also have to know how to quickly research ETLs, stored procedures, and application access to identify the ones most relevant and to provide sufficient business insight. In my experience, few DBAs possess these skills. A very technical data scientist should have these skills. A database architect or advanced developer will also be able to help, but they are often dedicated to projects and hard to assign to data exploration projects.
Iterative Data Discovery
The combination of these three steps describe who should perform discovery efforts, what is their process, and what are their deliverables. Create milestones for this team to do read outs and provide direction. Decide when you've achieved a "good enough" exploration.