The DBA is dead. Again.

Mark Twain never said, “Reports of my death are greatly exaggerated.”  Instead, his comment in 1897 was less tongue-in-cheek than matter-of-fact.  Confronted with news reports that he was gravely ill he responded, “James Ross Clemens, a cousin of mine, was seriously ill two or three weeks ago in London, but is well now.  The report of my illness grew out of his illness; the report of my death was an exaggeration.”  I can only hope that, while being equally matter of fact, in the retelling my comments will also grow wittier than they were written.  It is a lot for which to hope, as past experience is that my comments generally provoke unintended offense.

Every few years, when wondrous new automation appears imminent, reports surface about the long-anticipated death of the role of the database administrator.  Sometimes it seems these reports arise out of sheer frustration that DBAs and databases still exist, as seemed to have happened in 2008 during a conversation on the Oak Table email list, which closely followed a similar discussion on the ORACLE-L list.  To whit:  the war is over, and we lost.

Alex Gorbachev commented succinctly at the time:

We have already “lost” the war many times, haven’t we?  We lost it to object-oriented databases (8i?)  We lost to XML databases (9i?)  We lost to grid databases (10g?)  And we are losing to what now with 11g?  The “fusion” will save us all with or *without* databases in the first place?  Yeah right … the end is close.

The focus of discussion on both email lists was a thought-provoking blog post in March 2008 by Dom Brooks entitled “The dea(r)th of Oracle RDBMS and contracting?” He commented that the tide of history had finally turned against the Oracle database and the highly-visible role of database administrator.  Stiff competition from open-source competitors, emerging scalable technologies, absurd license fees, and belt-tightening by many IT shops were the overwhelming trend.  Poor database design exacerbated by immature implementation; if you’re going to produce a disaster, probably best that it not cost as much as Oracle.

My response on both email threads on ORACLE-L and the Oak Table was this…

Back in the 1980s, I worked for a company that had built some really cool applications in the area of travel reservations.  Eventually, the travel providers (i.e. airlines, hotels, car rental agencies, etc) caught on to what we were doing and did it themselves, effectively putting us out of business overnight.  So, it came time to sell the company off in pieces.  We tried to sell the applications, but nobody wanted them — they had their own, or could buy or build better.  We sold the hardware and facilities, but for pennies on the dollar.  Then, when we tried to sell the data, we hit the jackpot — everybody wanted the data, and we were able to sell it over and over again, to multiple buyers.

I never forgot that lesson, and several years later traded being a programmer for being a DBA because (as Michael just said, below) I like working with data.  Data, not programs, is the only thing that matters — applications are transient and have no value except to acquire, manipulate, and display data.  Data is the only thing with value.  The long-term value of data is the reason I’ve moved toward data warehousing and business intelligence, too.

Data is important.  Databases manage data.  DBAs architect, configure, and manage databases.  So, being a skilled database administrator will always be necessary as long as data exists.  If the state of the art ceases advancing, then automation will finally catch up to extinguish the DBA role/job.  But until then, being a DBA is a career.

That’s my story.  And I’m stickin’ to it.

Doug Burns was following both threads and was kind enough to lend his support in a post to his blog entitled “There’s Hope For Us All“, in which he stated “although it doesn’t reflect my personal experience in the slightest, there was something about what he had to say and the way he said it that rung very true to me.”  Kinder words are rarely spoken, and thank you, Doug.  And thank you too Dom, for your follow-up comment to Doug’s post, “Solidarity Brother!  I’m sure Tim’s right and will continue to be right.  I was having an emotional moment… the flat earth society are everywhere!

We all have those moments.

And here we are again, having another moment.

Once again, the topic of discussion on the Oak Table list was a blog post from Kenny Gorman (no relation) entitled “The Database Administrator Is Dead.”  My father, who was a police officer for 25 years, worked in a profession much more dangerous, and certainly several people had wished him harmed or dead over his career and even acted in that direction, but in a general way my chosen profession has received more death threats, it seems.

Now, the forces opposing the DBA are not necessarily cheaper, different, or disruptive technology, but better automation and provisioning.  The role of the DBA will literally be smothered out of existence, as highly-automated management consoles extend to the ultimate capability.  “Database As A Service” or “DBaaS“, cloud provisioning for databases, is the next development to obsolesce the database administrator.

The synchronicity of these discussions is spooky.  During the week previous to the discussion of Mr. [Kenny] Gorman’s blog post, I had related another particular story 4-5 separate times to 4-5 separate people, and now I found that I was relating it yet again, this time to the Oak Table email list.  It was something of a continuation from my earlier story…

In the 1990s, when I chose to move from being a developer to a DBA, the trend of out-sourcing was quite abundantly evident, not quite augmented by the trend of offshoring yet.  In 1999 I did my first ever keynote address at a conference in Portland, Maine to the Maine’S Oracle Users Group (MSOUG) on the topic of being a DBA in a world of out-sourcing.  I described a visualization of one of those water-holes in the Sahara.  A water-hole that is brimming and supporting a lush oasis during the rainy season, but that dries up and shrinks to a small muddy puddle during the dry season, surrounded by dead vegetation and dead animals that didn’t quite make it to the water-hole or another.

Repeating the comments in Doug’s blog, code comes and goes but data is the only thing with lasting value.  I visualized that the dead vegetation and dead animals surrounding the muddy remainders of the water-hole were developers and DBAs whose jobs were outsourced.  Right in the middle of the muddy water were two eyes above the surface, and this was the skilled DBA, guarding the remainder of the water-hole, containing only the most important stuff that couldn’t be outsourced or offshored.  I had long decided that I would be that DBA, and stay as close to the data as I could, and especially the most strategic data (i.e. data warehousing).

I figure y’all might have as much fun as the good folks at MSOUG did with that visualization, especially when subjected to Freudian and Jungian dream analysis.

Though it has nothing to do with why I’ve related this story 4-5 times previously this week, in this context, the author of the article (we’re not related) talks about having been an Oracle DBA 15 years ago, which is about the time I did my keynote for MSOUG.

Perhaps he left the field too early too early?  :-)

I completely agree with his “automate or die” comment, and I might add “keeping learning or die”, and of course the job’s roles are changing, but besides DBaaS being a long way from the pointy-and-clicky utopia that this post implies, the question remains: who sets up the DBaaS environments?  DBaaS isn’t the end of the DBA role, it is more automation.

Who will set up DBaaS environments, if not DBAs?  Don’t get me wrong:  I agree that DBaaS is here.  And I think DBAs will set it up, use it, and improve on it.

That’s my story.  And I’m stickin’ to it.

6 thoughts on “The DBA is dead. Again.”

  1. Hey Tim,

    Nicely put yet again.
    Nearly six years after writing my blog post, I’m still doing what I do so maybe that shows it was just an emotional moment.

    My perspective is not as an orthodox DBA but from that of a database specialist working with development teams. In that sense, I’m still battling the same frustrations I was six years ago but that is expected.
    It is the nature of the role that people who understand data and how to work efficiently with data will be constantly trying to educate those that don’t, fix the subsequent app performance problems and fight the constant battle against things like the seemingly magical EAV table design or your bad CaRMa design.

    The role of the production DBA, in a large corporation at least, definitely seems to have evolved – we’re in IT, of course things evolve). Now it is all about the tickets – pick up new ticket, resolve issue, move on to next ticket and make it snappy. It must be very difficult to add value in this service model as it’s all about the metrics – cheapest and fastest – and not about the quality.

    Both from the perspective of the development team, from the perspective of the DBA support service model, from the bean counter’s perspective, the prospect of more automation, DBaaS, self-service provisioning, faster turnarounds, doing more with less – these are all very interesting prospects.

    For example, for me, the prospect of combining thin-clone database provisioning in conjunction with 12c multitenancy is very exciting – all can be very easily automated and suddenly my request to spin up a new test environment requires no DBA intervention, needs no immediate new resources/storage/instances, and should take just a few minutes – wow!

    But as you say, you want to be the person doing the automating, defining the DBaaS model, not the person whose job is under threat because of it.

    There will always be roles where the data/database specialist can add value and make a difference.
    The challenge is to find / keep / keep finding these minority roles.

    Dominic

  2. Not that long after I started with Oracle in 1991/2 (my memory isn’t that good), Oralce 7 came out.
    I recall an seasoned Oracle 5/6 veteran telling me that he was geting out of the DBA game as it was all just getting too automated and easy. Look, he said, “SHARED_POOL_SIZE”. One parameter. It replaces so many GC_ settings. The DBA is dead! 1992.

    I recall Mogen proclaiming it the day after the BAARF party was formed at a UKOUG Unix SIG in 2003 (looks like the BAARF war was lost too).

    The job just evolves. As a DBA, I simply don’t do what I did in 1992 – extent management and reorgs. The fundamental underpinnings are the same but that’s all. Everything has evolved (and like evolution, it’s not always for the best overall reasons, but sometimes for a niche). We just need to evolve with it. Or go get a job flipping burgers.

  3. The idea of Database Administrators to become not needed anymore is indeed just a Myth to my opinion. Over time when the “auto tuning ” database features surfaced i had managers who said you will have to start look for a new job cause DBA is an extincting race. That was way back with Oracle 10G if i am correct. Today in 2014 lot of the Dbas gear up to deal with 11G, 12C environments and i think we are still a proud and existing species!

    Often read the comparison to pilots .. Automate as much as you like but when it really comes to it , it is nice to know that the pilot is able to land the plane by hand in stead of just automated . I still know this is case with Dbas as well . No matter how matter tools – Guis – Wizards are offered there will be still a spider called a DBA in the web/grid/cloud able to use them and to optimize and implement those tools.

    #Proud2BaDba and Happy reading,

    Mathijs Bruggink

  4. Huh, Kenny touched on something I point out with respect to DBAAS or successors for rdbms: Telephones used to “just work” – but the replacement technology doesn’t.

Leave a Reply

Your email address will not be published. Required fields are marked *


8 − = four

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>