Before we go any further, let me briefly answer the question posed in the title of this blog entry: "No Way!" OK... with that out of the way, let's discuss the issue...
Every so often some industry pundit makes news by declaring that DBAs 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 of database systems. And yes, DBMS software is becoming easier to
use and some of the things that used to require manual effort are now
automated. But that does not obviate the need for DBAs!
It is not possible for all of the duties of the DBA to become obsolete. For
example, how can a DBMS make changes to its database structures (for example,
adding new columns to support a new business requirement)? How would it know
what to add - and what data type to choose? Database design, both logical and
physical, will be needed (along with knowledge of the business) to create and
maintain properly running database systems.
Additionally, what about backup and recovery? Would you trust a DBMS that
had a corrupted database to recover itself? If it was that darn smart why did
it become corrupted in the first place?
The job of the DBA will morph and change — as it has already during its 30+
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 would be focused on
prevention first, cure second. This requires a set of best practices for
database implementation and management to be designed and followed. But I’m
getting ahead of myself a bit here. Let me back up.
There are really several layers of misunderstanding and poor DBA practices
running rampant across the industry — and they need to be addressed. The most
pervasive these days, I think, is the situation facing DBAs working for
organizations where the Internet rules. As companies move from traditional
development to e-business development there is the inevitable change in mindset
that creates mad rushes. This is the "get it done NOW!" mentality.
This is bad for the DBA because this approach is bad for database design. Why?
Applications are temporary, but the data is permanent. Organizations are
forever coding and re-coding their applications — sometimes the next
incarnation of an application is being developed before the last one even has been
moved into production. But when did you ever throw away data? Oh, sure, you may
redesign a database or move from one DBMS to another. But what did you do?
Chances are, you saved the data and migrated it from the old database to the
new one. Some changes had to be made, maybe some external data was purchased to
combine with the existing data, and most likely some parts of the database were
not completely populated. But data lives forever — and as such we need data
architects and DBAs to design things and implement databases properly each and
every time.
So, the Internet causes rapid delivery schedules which can cause database
administration to be an afterthought. Sometimes smaller organizations are
trying to implement database applications with no DBAs. Well, not really — an
application developer 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 a system being built and managed
without a DBA I can guarantee that the system will be riddled with problems.
And this is just one of the many problems — another 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
cubicle 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 desk.
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 (e.g.
database design) and can also be freed up to tackle bigger problems… such as,
business problems, data quality issues, metadata management, and so on.