Every organization that manages data using a DBMS requires a database administration 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 on-going 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 work day.
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 probably 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.
Often, 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 desireable, 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 ever 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 on the modern DBA role because each organization may impose different requirements on it. At some, 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. 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.
Maybe we should just stick with DBA ... after all, most of us know that means, even if it is not truly an accurate descriptor of the job any more.