If you are a working DBA, the actual work you do these days is probably significantly different than it was when you first began work as a DBA. Well, unless you’ve only been working as a DBA for a couple years or so. The core of the job remains, but a lot more is expected of the modern DBA.
For those who don’t know, DBA is an acronym for database administrator. 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 Traditional Role of the DBA
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, he or she must know enough about all aspects of IT to track down the root-cause of problems – and help to ensure corrections are made.
More Than a Database Administrator
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 the general idea. 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.” Folks stop by to ask about NoSQL and JSON, big data and analytics, networking, programming, and anything to do with data even if it isn’t in a database system. A DBA must always be prepared to be interrupted at any time to answer any type of question – and not just about databases, either.
You might think that this situation is less than desirable, but it can be 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.
Is the Title of “DBA” Accurate Today?
So is the term DBA really accurate any longer? 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 what that means, at least superficially … even if it is not truly an accurate descriptor of the job any more.