I think today in most organizations, the answer to the above question lies at the two extremes. Either you have organizations that are understaffed and overworking their DBAs or you have organizations double counting their DBAs just because they have the money. So how does one arrive at some commonsensical staffing levels for DBAs? If you are a small organization then the chances are that if you can afford a DBA, you would expect him to be the coder, tester, performance guru, system admin and a DBA. And you can drive the DBA all day long, keeping him super busy with no life to speak of. In this case it obvious at some point he is going to get fed up and quit, and then you are SOL!
On the other hand if you are a big company, then there is a good chance that in the name of specialization or separation of duties you may have the luxury to staff a centralized team of systems or operational DBAs (ODBAs) and then have each application or Line of Business staff their own DBAs called application DBAs. This is what I call double counting and a waste of money. And here is why.
Companies in the name of wanting to ensure imposition of DB standards, security, separation of duties and for specialization create a bank of centralized ODBAs. The functions carried out by this group are usually:
Install the DB softwareCreate DB instances and databasesMaintain patching schedulesExecute backups and restoreManage the physical attributes of the DB which are mainly adding space or doing a re-org as needed.In essence they create a DB shell and then spend time managing the shell. They are not concerned about the application that uses the database, performance of the DB or application SQLs, don't interact with the application team to help with best practices in writing code for the databases, have no input in design changes that impact the DB, they don't help control growth of data by implementing purging or partitioning strategies, and so on. In essence though they may be qualified they do nothing that really helps the application do better with the database. They don't care about instance consolidation or rationalization. All of this is because they have been put in a box called "Systems DBA or Operational DBA". And more excruciating is the fact that these highly skilled people are reduced to mere gophers whose sole job is to give you a DB and they are done. How much more boring can this get? If you are a DBA worth anything you would wanna get outta there, pronto! The duties assigned to ODBAs DON'T consume a hell of a lot of time because DB creation is a one time event, and you move on to the next, managing patches is at best a quarterly event, adding space etc and managing the physical attributes are not a daily affair, backups are usually automated, restores are few and far in between (thanks to the resiliency in the new hardware these days). So most of the time there is nothing much to do except surf the internet and every once in a while look at the health monitors of the DB to make sure all are green. Most of the heavy lifting like performance of the DB, SQL, interaction with application teams to help with best practices, assisting the application teams through the SDLC, all fall to the application DBA.
So why create two tiers of DBAs? The notion that ODBAs provide better security is not true, since the DB by itself has no value, it is the data that the application uses that is of value and that is being entrusted to the ADBA anyway. Similarly, the ODBA with his system privileges can always look at stuff you may not want him to. Coming to imposing standards, I'd say create a corporate standard, and enforce it through automation and training so that every DBA knows how to install, manage and administer databases a certain way. In today's age of Cloud computing, all provisioning is automated, they all install the same way, same version, same patches, same structure, so automate and let's get this off the speciality list. Coming to separation of duties, if the ADBA is the guy who is closest to the data and the ODBAs have no clue what is in the database, enough harm can be done without the ADBA really needing system privileges that ODBAs are entrusted with. So this whole separation buying something unique is again a folly. Now, arguments have been made that having the ODBAs and ADBAs separate helps them focus on their jobs better and hence better outcomes. Wrong! In fact it is the opposite. A DBA who manages a DB has to know what goes into his DB and has to be application aware. He is the one who can decide if a performance issue is because of a bad SQL or if a DB parameter needs to be adjusted or if the I/O is bad because of poor placement of DB files. Having the duties of the DBA split just aggravates the situation where ADBA blames ODBA for bad I/O and ODBA blames the ADBA that it is the application issue. This is not a better outcome, it is the opposite. The time to fix also is elongated because of the dual structure of the DBA organization. All in all more people costing more money end up making the situation worse for the end customer.
The solution then is to get rid of the ODBA organization, you can still create a centralized DBA organization but each DBA is an ODBA & ADBA combined. They are loaned out to individual applications, let the application teams or lines of business pay for a DBA or multiple DBAs or a fraction of a DBA based on the needs. And once the DBA is assigned he does everything, similar to a full service shop, creates DBs, manages DBs, helps application team, resolves performance issues, works with storage for the best file layout of DB files ensuring best I/O performance, and so on. Give the DBA full ownership of everything from the cradle to the grave, he in the end is accountable for not only the DB but also for how it provides service to the application. It is not just enough to say DB is up and running and that means everything is fine with world and walk away. If he cannot immerse himself in helping the application run the best that it can on the DB and make sure application teams use the DB in the best manner, then I have no use for a DBA just to provide me a shell called DB, I can get it from Amazon for pennies!!
Comments