We need to rid the world of “DBAs”

This may come as a complete shock based on the title of my website… but I have come to the conclusion that all DBA’s should be eliminated from all companies hierarchies. WHAT? Yep I do not think any company should employ a “DBA” ever again.

Before the mob comes and beats me up for heresy, Let me explain. The term and more specifically the job title “Database Administrator” is way to broad. More so then most titles in my opinion. In fact I feel it is an ancient description that does a disservice to most modern database professionals. I have seen titled DBA’s responsible for entire infrastructure stacks, and I have seen DBA’s who only know how to run SQL and perform backups. It hardly seems fair that all these folks end up lumped in together. I think we need better definitions and a somewhat common vocabulary to truly tell what sorts of tasks and responsibilities people have.

I was a “DBA” for several years. During that time I interviewed for a lot of open “DBA” positions, I also interviewed people for “DBA” positions I had open, and Lately I have been working with a lot of other companies “DBA’s”. On a resume or to a perspective employer, Joe the “DBA” who has 12 years of experience, looks like Andy the “DBA” who also has 12 years of experience. Because a resume is a short statement of your work… both resumes will look similar. I mean Joe and Andy would have to put their 10 years of MySQL, and 12 Years of Oracle, and tout their fat Linux skills right? But what if Andy was completely operational, and Joe was completely development and design? They would fit into two different worlds, certainly they could cross over, but that may hurt what they are really good at. Wouldn’t it be easier to know up front what each of these guys do?

Another problem is the overly broad definition of a DBA falsely inflates and also detracts from the true value of a professional. Lets say for instance Joe the “DBA” spends his days watching graphs and charts on database performance, he gets alerts, expands his Oracle tablespace, moves data from his prod MySQL instance to his dev MySQL instance, sets up new databases, and runs SQL scripts for deployments into QA and Prod. Joe is a solid employee at what he does. Meanwhile Steve the “DBA” is responsible for spec’ing out the DB server hardware, the architecture and designing of the underlying infrastructure (I.e. deciding on how many spindles his SAN needs), setting up an maintaining Various OS clustering solutions, walking through code looking for performance issue, and ultimately deciding which RDBMS needs to be deployed where. I would classify Steve as more then a DBA, I mean he is doing so much more, but he is only a “DBA” in the eyes of management and HR. So when Steve moves on its going to be hard for him to stand out versus the Joes. Equally importantly the company replacing Steve is going to have a hard time finding the right skillset, and if past experience serves will hire someone with less then the needed skills.

Before you get your knickers in a knot, I am not a DBA now, and I am not just blasting my current management. I feel the plight of the Super Stud Database Folks out their. I have been their in the past and really think that for companies to be successful they need to reevaluate what talent they really need internally. The fact is both Steve and Joe are needed. Someone needs to do the day to day items, but someone also needs to do the big stuff. The Steve’s of the world need to differentiate themselves. Also I run into a lot of companies that end up hiring the wrong guy for their needs, because they look so similar on paper.

Let me share with you three different “DBA” related jobs I have had in the past.

Position #1 you would call the Classic DBA. I was a Senior DBA and I had a few other DBA’s under me who I mentored and directed. My Job was primarily to ensure that all the database systems were up and running. So we did the 24×7 pager. We adjusted space, ensured backups ran, moved data from box a to b. I also got involved in projects to answer questions where the databases should go, whether we would need additional servers, or answer any questions. Here performance tuning was also key, so I spent a great deal of time learning and understanding how the database internals worked.

Postion #2 I would definitely call something more then a DBA, but with the DBA title. Here I actually did Linux administration, installed and configured HBA’s, configured SAN’s, setup windows clustering, managed a budget, hired consultants, etc… and of course had to make sure everything was up and running by assigning resources.

Position #3 This was an odd one. While the other jobs had different components that jumped DBA bounds, this was a pure task oriented DBA. My job was to run SQL scripts for deployments, carry a pager 24×7, and to ensure backups were completed. Any mojo or skills outside of that were worthless.

Three vary different positions, all the same “job”. Hiring a guy who works well in position 3, does not mean success in position 2… and so on. I know that the argument is that the interview process is their to weed out the candidates who are not good fits, but in my experience many companies are not effective at this. While this is good for consultants ( especially when we are asked to fix the issues ) its bad for the companies and costing them lots of money and productivity. The morale here just because a guy has DBA, or database’s listed on his Resume does not make him a a good fit to replace who you consider a DBA.

Lets look at some of the specific areas today’s database professionals end up working in. The big one is still operations. When I talk about operations I am talking about the basic day-to-day task oriented work. This work has been the target of several tools over the years to eliminate the day to day monatany that old school DBA’s had. Who remembers popping in a Tape for a backup before leaving? Adding space by hand? Yep automation is great. While automating these tasks has freed up a lot of time, there is still a ton for an operational database professional to do. The larger the company, the more so. Large companies tend to have a lot more red tape and hoops to jump through and generally require more of these guys. Smaller companies tend to be a lot more agile and while some of these skills are valuable the database professional can not only do this.

The second area I still see a number of “DBA’s” playing in is development. Some companies have DBA’s only to create new tables and objects. Others use their’s for creating stored procedures and database design. This area is fuzzy, because many other companies rely on developers to fill this role. I think in smaller companies this makes sense, but the larger the company I think dedicated database development professionals can add a lot of value. While some code developers make excellent database developers, at a large company with lets say 50 developers you maybe lucky to get 3 or 4 developers who you could trust with database development tasks. That means a lot of bad database design ends up getting into the system. The difficult part is balancing out the red tape, a separate database development group has to be structured so it does not interfere with the overall development process ( more groups = more overhead = slow generally).

The third area that I see “DBA’s” filling is the role of an infrastructure architect. Some of the things this database professional ends up doing include the planning of database systems ( how much capacity, whats our growth rate), the designing of the systems ( we need 4 nic cards, 2 crossovers in each server, dual hba cards connected to a RAID 10 SAN, etc ), the architecture of data flow ( using replication from A to B we can build an operational data store, etc ), determining how applications will connect to the database ( connection pooling), etc. This database professional out of necessity has to understand the big picture how does data flow through the system to his database. Some companies have filled this role with a solid infrastructure architect, however too few companies realize the benefit. How many DBA’s out their can relate to this statement:: “the database always ends up getting the blame until I can prove the problem is not database related”. In my role as a consultant many times I am engaged to help the DBA simply prove its not the database. I think a solid infrastructure architect can help deflect this, quickly bypassing the finger pointing, and ensuring infrastructure happiness by understanding all the peices instead of just a single component.

This may spill over to other infrastructure related positions as well. I mean, not all Unix Admins or Web Managers are created equally either. But I am selfish and only focusing on the database side.

So what would I do If I were in charge? Well off the very top of my head:

First every company should have an infrastructure group. At its head technically is an infrastructure architect. His job would be to know all the pieces of the infrastructure and how they all fit together. He would need to understand storage, networking, security, database, and system administration. To many companies in my opinion put a non-technical resource in charge here, but this only ends up breeding confusion and animosity amongst the various groups under him/her. It turns into the Unix guys vying for their agenda, vs the dba’s vying for theirs, and the network guys vying for theirs. The result in many cases is a half baked solution. Someone needs to have the respect of his team and the vision of how all the pieces fit together. TOO MANY times I end up seeing companies who do not understand how all the pieces fit together, and how one piece can effect the other.

The database group in my opinion would then fall under the infrastructure architect. I am going to list lots of titles, certainly these may not all be used in every environment, but bear with me. The most Junior members would end up being Operational Database Professionals ( SQL and task monkeys). These guys are going to building db’s, run scripts, adjust parameters. The step up from ODP’s could be Operational Database Masters ( people would love being called a master ). These guys would do the tough operational stuff, I.e. setup clustering, implement advanced features, doing performance tuning , etc. The Development Database Professional would be what most would consider a development DBA or even a SQL developer. They are really charged with creating relational diagrams, building schemas, some data administration tasks, etc. The Architectural Database Professional ADP would know the others jobs but, he is really their to help fit database technology into the overall architecture. His job includes the designing of how the systems will achieve high availability, how replication would be deployed, testing new features, ensuring optimal performance through design, etc.

How would you change things?

This entry was posted in mysql, oracle, rant, sql server. Bookmark the permalink.

3 Responses to We need to rid the world of “DBAs”

  1. Agreed…

    In the meantime, I think we have started to grow organically (and very slowly) into a DBA title regime over the years, and although we obviously can go further, we have started with these titles…

    Production vs. Development DBAs (similar to areas 1 and 2). Often production DBAs are called to deal with issues that most people think are a database issue, when it could be a number of things (area 3).

    With these two basic types of DBAs defined, the additional status of “guru” is often attached, for example: Production DBA guru – meaning, the level of expertise goes well beyond the database itself and this type of person must take into account a myriad of possibilities not considered by most people, including Linux admins and CIOs.

    Also note that often companies can only hire one DBA to do the range of operations you mention in the last paragraph (ODP, ODM, ADP, etc.) – so what would that title be called?

    What about other fields? I am sure that there are many flavors of bookkeepers, CPAs, Controllers, CMAs and CFOs just as there are different sub-types of musical genres.

    In the meantime, I am intrigued with what titles will be commonplace as the organic hum of DBA title differentiation increases.

  2. Dave Stokes says:

    I remember when ‘programmer’ was the generic term for the guy who pushed bits and ‘operator’ was the name of the guy (yup, 99.9999% guys) who kept the system running. Then systems and application programmers split and it has been down hill from there! 🙂

    So what skills make a DBA, or, what skills do you need to make yourself a DBA?

  3. Antony Curtis says:

    I guess without strict controls, job titles can suffer from severe dilution.

    Based upon past jobs and how they titled employees, this is a summary I’d go by:

    Engineer – suffix, someone with an engineering degree/qualification.
    Analyst – someone who writes requirements.
    Programmer – someone who writes code.
    Administrator – someone who writes policy.
    SysAdmin – superset of Administrator role but in addition: responsible for the machines the software is running on.
    Assistant – Runs backup scripts, writes simple scripts, changes tapes.

    So, one of my previous jobs, I would be “Analyst/Programmer Engineer, SysAdmin” – which is pretty similar to the actual job title I had at the time.

    From the article…
    Position #1 would be: Database Administrator.
    Position #2 would be: Database Systems Admin.
    Position #3 would be: Database Assistant.

    Not too complicated.

Comments are closed.