There was a a time when DBAs (Database Administrators) were gods among mortals.  As the keepers of the companies most valuable IT asset, the data, they held the keys to the kingdom.  Their role took prominence throughout the 1990's as the wave of open systems databases emerged.  That would be Oracle, Sybase, SQL Server, etc.  These databases ran on servers instead of the mainframe, and the DBAs ruled those servers on which that database existed.

Over time, the sysadmins (systems administrators) started to take a more prominent role over the physical server, but the relationship was always one of mutual respect and equality.  And when it came to final decisions, the sysadmin almost always deferred to the DBA in matters of disagreement.  There was very little that the DBAs wanted that they didn't get.

Their sphere of influence even extended into the application code.  During this same era, there was a massive push to write code in such a way that it would live in, and execute from, the database itself.  These came in the form of stored procedures and triggers, but was broadly classified as "database procedural code".  Developers usually wrote it, but the DBAs had the authority to accept, change, or reject it.  As I said, there was precious little that the DBA couldn't veto.

In exchange for this power, they also carried an awful lot of responsibility.  They had to ensure availability, performance, change control, and disaster recovery.  Pretty much everything in the eyes of the end users, and as a result, they almost always were one of the first contacted when an application had a problem.  ANY problem.  They would investigate, and often have the troubleshooting skills to make a quick and accurate assessment of the situation, and subsequently call the right people to fix it.

All of this meant that the DBAs had respect, power, and compensation above their IT counterparts in development, support, and operations.  In the late 90's, DBAs (especially Oracle DBAs) were paid 15-25% higher than developers.  I can remember when developers were making around $50-65K as a national average.  DBAs with the same experience levels were making $65-90K.

Being a DBA was where it was at in terms of power, prestige, and paychecks.  But in the 2000's... that would start to change, and that's where we'll pick it up next.

Part 2
Part 3

I was recently doing some investigation into VCE, the 3-way alliance between EMC, VMWare, and Cisco.  If you watch the quick video by the three CEO's, the basic value propositions sound eerily similar to the same benefits being espoused by Oracle regarding Exadata.  In both cases, there is an acknowledgement of the unavoidable complexity that occurs when you mix and match pieces of the stack.

By "stack" I mean the various layers that make up a computing environment.  Network, Hardware, Storage, Operating System, Application Servers, Web Servers, etc.  Oracle's early successes with Exadata have occurred on the marketing, performance, and sales fronts.  This push by the already dominant database vendor has forced others to respond in kind.  Whereas Oracle acquired hardware to add to their dominant software position, HP and EMC moved to acquire software to supplement their hardware strongholds, with the purchases of specialized databases Vertica and Greenplum, respectively.  And last year, IBM led the way with it's acquisition of Neteeza.

In all of the cases noted above, what we see is a massive push for convergence into a single solution.  The promises are that while the initial cost is not cheap (for all of these "big boxes" you're looking at close to $500K as an entry point) the claim is that the long-term benefits make it well worth it.  What are those benefits?  How about these as a starting point:

• Availability
• Reliability
• Security
• Capacity on Demand
• Specialty Engines [for different workloads]
• I/O [optimized] Connectivity
• Networking
• Clustering [Scale]
• Performance 
• Management [Ease, Centralized, Flexible]

In part 1 we briefly looked at the historical power wielded by DBAs that began with the rise of the client/server databases of the late 1980's and early 1990's.  I ended with the thought that in the 2000's, something began to change.  I'm going to list what I see as the top 5 trends that changed the role of the DBA.

1. Better tooling.  Several third-party ISV's emerged, creating software that made solving complex database problems significantly easier.  At the same time, database vendors were in a race to lower total cost of ownership as they competed against each other.  The result was more extensive and easier-to-use tooling delivered right out of the box.  All of these products demystified some of the more intricate things once performed by only top-flight DBAs.

2. Virtualization.  With the emergence of virtualized systems, many non-mission-critical databases were consolidated into virtual machines.  Two things happened as a result.  First, the backup and recovery of these databases fell into someone else's hands for the first time.  Second, the DBA lost a significant amount of visibility into performance related issues as the hardware layer became obfuscated and only the system (virtualization) administrator could see the details under the covers.  Because they were non-mission-critical databases at first, the DBA's didn't raise much of a fuss.  Nevertheless, this is where we first saw a power shift away from the DBA.

3. Advanced SANs.  I still remember the first time I heard about this one.  I was talking to a DBA whose company just finished a consolidation/migration to SAP costing more than $100M.  As we talked, the subject of recovery was raised.  He told me, "Oh, I don't have anything to do with that."  WHAT?  I was shocked.  I asked how that could be and he said, "They're using an advanced partitioning system on the SAN that has mirroring for continuos availability and also a third partition that goes offline for the backup process.  So if it needs restored, the SAN team will handle it.  I'm completely out of it.  How bout that?"

4. Outsourcing.  One customer rather bluntly told me, "When we have problems, we just throw a lot of bodies at it.  It costs us way less than keeping tons of experts on staff.  We just don't need that many experts anymore."

5. SOA.  While SOA in its pure form arguably didn't take hold as fast as the preceding hype, one thing that did stick as part of this wave was taking code out of the database (procedures and triggers) and putting it into the application.  By doing so, the complexity of database change management was considerably reduced.  Developer teams now just wanted the shell (or database "instance") and they would handle the rest themselves inside the application.

DBAs who read this will be tempted to argue against each point, and at a granular level, many objections  could be fairly raised.  But my point here is to say that collectively these trends led the DBAs to a place of lesser prominence in the 2000's than they had seen in the previous decade.

In the next post, we'll look at a few more data points, then start to analyze where the DBA goes from here.

Part 3
Part 1

Last time I looked at some of the technology issues that affected the DBA.  Today I want to wrap up my contention that their role has changed over the last decade.  One objective way to look analyze this is by comparing salaries.  While my historical salaries were a guess from my personal memory, we can get an idea of what the market pays today.

According to PayScale.com...

An average DBA total compensation is now between $47-$85K.
An average Java Developer's total compensation is between $54-$85K.
And a .NET Developer's average total compensation is between $49-$74K.

Remember, these are averages, so obviously your pay might be higher or lower based on geography, years experience, etc.  But the relative differences are what I am after here, and as you can see, they are non-existent with Java developers and not horribly different for .NET developers.

OK, so the world is changing for DBAs... is it all doom and gloom?  It doesn't have to be.  Experienced DBAs are often some of the best problem solvers in an IT organization because, in the past, they had to touch so many different areas of an application stack.  I wasn't just the database they needed to understand, it was also the operating system, storage, and network layers.  Many have become very wise thanks to all their varied experiences, and that wisdom can translate to today.  While new trends seem new and revolutionary, often the underlying principles are not.

DBAs need to step up and take ownership of (or at least involvement in) projects outside of their comfort zone.  This could be virtualization, cloud, NoSQL, Hadoop, or any agent of change on the IT landscape that ultimately affects (or replaces) the traditional relational database.

The worst thing to do is nothing but the status quo and long for the days when DBAs ruled the data center.  That's not a good place to be in times of rapid change.

Part 1
Part 2

Like most, I don't really think NoSQL is a great name for some of the specialized databases that are on the market today, but sometimes you just have to go with the momentum of the masses and run with it.  But given that we have basically labeled something by what it is *not*, then we should at least understand what it *is* that we are discussing.

When I talk about NoSQL databases, I'm talking about those databases that were built for scalability and availability, with flexible schemas, and yes, as of today, they do not have a SQL interface.  I do not generally place Hadoop into this same general bucket because Hadoop is more of a stack consisting of multiple components, some of which can be leveraged independently.  So it would be more logical (to me) to speak of HBase in the NoSQL crowd, rather than "Hadoop" in general.

OK, so these databases are here.  So what?  Why should anyone who doesn't have a very specific problem solved by one of these NoSQL databases?  Frankly, this is a question I have seen asked many times over by customers.

Fortunately, I get to work with some very smart folks who discuss all things new and interesting, and recently the topic of the day was Platforms as a Service  (PaaS) and/or Infrastructure as a Service, depending again on your definition.  Here is a quote from one of the emails:

We have painted ourselves as an industry into a monolithic application architecture world of single apps tied to RDBMSs, one which is not ideally suited for cloud computing, hence why we need to re-architect most things to take advantage of new technologies

I have spent so much time thinking about the specific use cases around these technologies, that I too often brush aside a critically important aspect of the big picture, which is the flexibility to leverage things that are not yet here, but are continuing to emerge and evolve at stunning rates.  Thinks like PaaS and IaaS are going to become common and so it is worth a great deal of consideration whether your next new app (and underlying database) should be built in a way to potentially leverage them.