"Know the Data"

I received the other day a very interesting e-mail from Vijay Sitaram, a friend of mine who is a DB2 DBA (or not -- more on this later) at an organization that operates (no pun intended) in the health-care industry. Vijay's note contained some illuminating insights regarding the role of database professionals within a modern, strategically focused enterprise, and via this post I want to share some of these insights with you (my thanks to Vijay for permission to do so).

Recently, Vijay had found that traditional DB2 DBA work was becoming less satisfying for him, for reasons well-known to many DB2 people:

1. DB2 is becoming, more and more, a self-managing DBMS. This is a cross-platform truism. DB2 for z/OS people have for years benefited from advanced file-management features available on that platform (DB2-managed objects are the norm in mainframe environments), and DB2-managed storage capabilities have advanced in a major way via the "Viper" releases of DB2 (Versions 9.1 and 9.5) for Linux, UNIX, and Windows (aka LUW) servers. Similarly, self-tuning memory management -- a technology found now in DB2 9.1 and 9.5 for LUW, providing automated (and dynamic) sizing for things such as the database monitor heap, the agent pool, the package cache, the sort heap, and buffer pools -- is starting to show up in DB2 for z/OS (auto-adjustment of buffer pool sizes is an option available in DB2 9 for z/OS, and I expect to see more developments in this area in future releases).
2. While no vendor is giving server hardware away, the continuing decline in the price of compute power (and server memory) has more and more organizations asking DB2 DBAs to spend proportionally more time on work that is NOT directly related to boosting the CPU- and memory-efficiency of a DB2 workload. Sure, performance tuning is still important, but the value of saving X% of a server's CPU capacity, or reducing DB2's virtual storage footprint by Y megabytes, is not what it was a few years ago.
3. A lot of the DBA work related to DB2 system performance is front-loaded with respect to the life of a system. In other words, once a DB2 system has been effectively tuned and stabilized, over time it tends to require less DBA effort to keep it running well.

So, Vijay was thinking about how he could deliver greater value to his organization as a database professional. His manager provided the opportunity to do just that with this simple directive (paraphrasing a bit here, but this is the gist of what the manager said): "Know the data." What Vijay's manager wanted him to do was deepen his understanding of the data in the DB2 database that he administered (in this case, we're talking about medical billing data). The manager was NOT asking Vijay to know things like the number of rows in a table, or the length of a row in a table, or the cardinality of a column value. That's data about data. The manager was asking Vijay to know the data itself, and to appreciate "the value [that] is in the data." Vijay had already done a lot for his company in looking after an important database. Now he was being told that he could do more for the company if he could answer this question: what is the nature of the data in the database, and why and in what ways is it important to the organization?

Not being one to drop a ball, Vijay took this one and ran with it. He immersed himself in learning about the data elements in the database and the relationships between these elements. He built up his knowledge of how medical billing works (no easy task that -- I've worked with medical billing data, and it is very complex stuff), getting a lot of help from the senior programmer who developed the company's medical billing application. Vijay found that his deeper understanding of the data had some immediate payoffs, in that he was able to improve the performance of the ETL (extract/transform/load) processes used to update the database. He also found that his data knowledge made it much easier for him to successfully address database design issues.

Now, Vijay is helping his company with the implementation and deployment of data integration and data cleansing tools, and he's about to get into advanced data analysis software in a big way, focusing on cubing capabilities that will enable data users to drill into data structures to uncover actionable intelligence. In short, knowing how his organization values the data he administers, Vijay is working to grow that value by making it easier for users to access and analyze the data to improve decision making. In doing that, Vijay is increasing his value to his company. A side benefit: he's having more fun on the job.

Is Vijay still a DBA? He's not so sure that the "DBA" title reflects the kind of work he's doing now (and it's not as though he no longer does traditional DBA work -- it's more like "DBA-plus" these days). Vijay has asked that his job title be changed to Architect. If that decision were mine to make, I'd give it a thumbs-up. Drive on, Vijay.