Every organization that manages data using a database management system (DBMS) requires a database administration (DBA) group to ensure the effective use and deployment of the company’s databases. And since most modern organizations of every size use a DBMS, most organizations have DBAs or at least people who perform the ongoing maintenance and optimization of the database infrastructure.
The DBA, traditionally, is the information technician responsible for ensuring the ongoing operational functionality and efficiency of an organization’s databases and the applications that access that data. A day in the life of a DBA is usually quite hectic. The DBA is required to maintain production and test environments while at the same time keeping an eye on active application development projects, attending strategy and design meetings, helping to select and evaluate new products, and connecting legacy systems to the web. And Joe in Accounting, he just submitted that “query from hell” again that is bringing the system to a halt, can you do something about that? All of these things can occur within a single DBA workday.
When application problems occur, the database environment is frequently the first thing blamed. The database is “guilty until proven innocent” instead of the other way around. It is rare that a DBA is approached with a question like “I’ve got some really bad SQL here, can you help me fix it?” Instead, the DBA is charged with seeking out the true culprit when the DBMS is blamed. Because DBAs are frequently forced to prove that the database is not the source of problems, s/he must know enough about all aspects of IT to track down the root cause of problems – and help to ensure corrections are made.
For this reason (and many more), DBAs are usually relied upon to do far more than just stoke the fires to keep database systems performing. Most DBAs have years of IT experience and are asked to share their expertise on related technologies (such as application development, middleware implementation, transaction processing, and networking) with project teams. In some small to medium-sized shops, an experienced full-time developer may be tasked with performing DBA duties “on the side.” Couple all of this with the fact that the discipline of database administration is not well understood or universally practiced in a coherent and easily replicated manner, and you get where I am headed with this. A DBA is not always just a DBA.
Oftentimes, DBAs are expected to know everything about everything. From technical and business jargon to the latest management and technology fads, the DBA is expected to be “in the know.” And don’t expect any private time. A DBA must always be prepared to be interrupted at any time to answer any type of question – and not just about databases, either.
Some of this is less than desirable, but some of it is actually a good thing. At least, that is, from the perspective of DBAs. By expanding the role of the DBA to include other technologies and even business issues, the DBA can become a more well-rounded and valuable employee. Yes, it is a great thing to have experienced techies who can delve into and solve complex problems. But it is an even greater thing for these techies to be able to communicate, to understand the business, and to extend their abilities more diversely than just on database tactics and issues.
So are today’s DBAs really DBAs? Or has the job grown into something more? And, if so, just what?
Perhaps it is not possible to peg a true definition of the modern DBA role because each organization may impose different requirements on it. At some shops, DBAs need to remain very technical but embrace new technologies. At others, DBAs need to adopt a data governance hat, becoming better versed on the meaning of the data. And at others, DBAs are mandated to become more active in the application development lifecycle, especially with the growth of DevOps. And who gets involved in evaluating and implementing all the new NoSQL and big data management platforms? Yup, DBAs. And then there are always those organizations that lump all of this onto the DBA.
With all of this in mind, might there be a more descriptive title for the modern DBA? Data Czar? Too imperial. Data Generalissimo? Too militaristic. Data Conductor? Too directorial (or musical). Data Analyst? There are already people with that title, but let’s not open that particular Pandora’s Box to try to define exactly what they do!
Maybe we should just stick with DBA… after all, most of us know what that means, even if it is not truly an accurate descriptor of the job anymore.
Long live the DBA!