©  2021  Mullins Consulting, Inc.   All Rights Reserved   Privacy Policy   Contact Us

Are DBAs Obsolete?

by Craig S. Mullins

Before we go any further, let me briefly answer the question posed in this column's title:

       No Way!

OK ... with that out of the way, let's discuss the issue ...

Every so often, some industry pundit gets his opinions published by declaring that "Database administrators are obsolete" or that "we no longer need DBAs." Every time I hear this, it makes me shake my head sadly as I regard just how gullible IT publications can be.

These types of proclamations are typically based on the increasing autonomics within database systems. And yes, database management system (DMBS) software is becoming easier to use; some of the things that used to require manual effort are now automated. But that does not eliminate the need for DBAs!

It is not possible to entirely automate all of the duties performed by DBAs. For example, how can a DBMS make changes to its database structures (such as adding new columns to support a new business requirement)? How would it know what to add-and what data types to choose? Just as importantly, how would it know where to add the new columns?

Database design, both logical and physical, will always be needed (along with knowledge of the business) to create and maintain properly running database systems-and that is the domain of the DBA.

What about backup and recovery? Would you trust a DBMS that had corrupted data to recover itself? If it was that darn smart, why did it become corrupted in the first place? Yes, the job of the DBA will morph and change-as it has already during its 30-plus years of existence. But that doesn't mean it will become obsolete ... just different.

Database administration needs to be practiced in a more rigorous manner. Too often the DBA is viewed as a fireman. This is not meant to disparage firemen, of course, but the fireman is called after the fire has started. Database administration practiced as a management discipline should be focused on prevention first, cure second. This requires a set of best practices for database implementation and management to be designed and followed.

There are several layers of misunderstanding and poor DBA practices running rampant across the industry that need to be addressed. The most pervasive is probably faced by DBAs working for organizations predominantly focused on the Internet. As companies move from traditional development to web development, there is the inevitable change in mindset that creates "mad rushes." This "get it done NOW!" mentality is bad news for DBAs because it is detrimental to good database design practices. Poorly planned or unplanned changes get made to the database in order to speed development. These mistakes persist for years and can cause poor performance, data integrity problems, and make future changes more difficult.

Another problem is the "we don't need no stinking DBAs" attitude. Sometimes smaller organizations attempt to implement database applications without DBAs. Well, not really-usually one of the application developers acts as a pseudo-DBA and performs just the basics to get the application delivered. Meaning, database design, performance, availability, and maintenance will suffer. Whenever you hear of an enterprise application being built and managed without a DBA, I can guarantee that the system will be riddled with problems.

Perhaps the greatest issue facing DBAs these days is the whole "proactive versus reactive" argument. Many so-called mature organizations approach database administration only as a "reactive" chore. This gets back to my fireman metaphor. Oh yes, everyone says they are "proactive" but that is usually a great big lie. Many DBAs are up to their ears in paperwork, design tasks, and performance tuning-with a line of folks out the door of their cubicles looking for help. Now, how many of these DBAs do you think are being proactive and looking for more "potential" problems so they can fix them before they occur? None! They are all trying to put out the fires that are on their desks.

The bottom line is this: As portions of the DBA job are automated, the DBA can focus on those things that have been ignored or poorly addressed. They can better implement practices and procedures for the things that cannot become autonomic: backup/recovery and change management, to name two.  And, they can begin to tackle bigger problems ... such as business issues, compliance and governance, data quality issues, metadata management, and so on.

Long live the DBA!  

From Database Trends and Applications, June 2010.

© 2012 Craig S. Mullins,  

June 2010