I hope the title of this column helped draw you in. You might be asking yourself, “What could he mean by that?” So, let me first explain the question.

For those who don’t know, DBA is an acronym for Database Administrator. Every organization that manages data using a Database Management System (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 ongoing maintenance and optimization of the database infrastructure.

So, to answer the basic question here, a 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 simultaneously keeping an eye on active application development projects, attending strategy and design meetings, helping 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’s bringing the system to a halt; can you do something about that? All these things can occur within a single DBA’s 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’s rare that a DBA is approached with a question such as, “I have 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 frequently are forced to prove the database isn’t 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 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-size shops, an experienced, full-time developer may be tasked with performing DBA duties “on the side.” Couple all this with the fact the discipline of database administration isn’t well-understood or universally practiced in a coherent and easily replicated manner, and you get where I’m headed with this. A DBA isn’t 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’s a great thing to have experienced techies who can delve into and solve complex problems. But it’s an even greater thing for these techies to be able to communicate, understand the business, and extend their abilities more diversely than just on database tactics and issues.

So, I ask again, are DBAs really DBAs today? Or, has the job grown into something more? And, if so, just what? Perhaps it isn’t possible to peg a true definition on the modern DBA role because each organization may impose different requirements. At some sites, DBAs need to remain very technical but embrace new technologies. At other sites, DBAs need to adopt a data governance hat, becoming better versed on the meaning of the data. And at other sites, DBAs are mandated to become more active in the application development lifecycle. Finally, there are always those organizations that lump all this onto the DBA.

With all 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, even if it isn’t truly an accurate descriptor of the job any more.