Another grey area in an age where everything and anything is obsessively analyzed and measured, is the question regarding how one can measure productivity of IT staff who are in the realm of administration like DBAs or System Admins or Network Admins, etc. While measurement of output productivity of developers has many acceptable methods these days like lines of codes per unit time or number of function points per unit time, etc measuring the output of admin guys has remained a guessing game.
One of the challenges presented by IT admin people is the fact that they don't produce anything tangible directly like a program or functionality. All the bean counters know is that they are spending a bunch of money on a set of guys who spend time doing things some time but seem idle most of the time and there is no way of telling what their value is. But we all know how crucial a good DBA or a System admin guy is to the project and to the enterprise. Without their work in securing a good foundation we can all run afoul of performance, availability, reliability in our production applications. The analogy I give to people is that of an army, many people may question why anyone has to spend money feeding and maintaining an army during peace time, it is the same with IT admin guys, why pay for these guys when there are no problems. Just like one cannot instantly create an army just before a war, it is impossible to have IT guys manifest just when you have an outage. So we all know we need these guys around, outage or not. The question then is how many do we need? And my answer is that it depends....
Let me consider the example of the DBA role. While DBAs can come in all flavors and colors from champions who can cover not just the database but also application design, storage, network, etc to the very vanilla guy who just does basic DB creation, user maintenance, etc, it is most always the case that they all get bundled into just one label. So the question of how much a DBA can support depends on two things, (1) the scope of a DBA's work and (2) the complexity of the application that runs on top of the database. If the DBA is doing plain vanilla DBA support that involve simple tasks like DB creation, backup & recovery, DB & User maintenance, some data movement, etc and if he is insulated to a large extent from application related issues then then such a DBA's scope is limited. I call such DBAs System DBAs or Operational DBAs, and the number of databases these guys can support are relatively large. A general rule of thumb is between 35-45 production databases or about 4-6 terabytes worth of allocated storage to databases, not counting development instances. And when I say databases I actually mean instances since a database is different in Oracle vs. Sybase or MS SQL Server.
On the other hand if your DBAs are doing more than just operational support and are involved heavily in application support, performance tuning of SQLs, schema design, etc then by definition of their scope they will not be able to support 35-45 database, it will more be in the range of about 15-20 production databases. Size of DB is usually not that material since a poorly written application on database the size of 25GB can take a lot of DBA's time compared to 1TB database with a well behaved application.
In the end while there are no well defined DB to DBA ratios, the key is to take the time to see what the defined scope of your DBAs are, see how well your organization manages changes and releases and how aware your applications are with DB 101, and then you can make a call on how much databases your DBAs should be supporting. This approach holds true to all other admin roles like System admins, Network admins, etc., almost always change is usually what introduces risk. Risk introduced governs the amount of unplanned work that your people will have to do. The more mature your organization is in managing change related risk, the more automation you have, the less likely you will ruin someone's weekend and reap the benefits of a high asset to personnel ratio, be it DB to DBAs or servers to System admins.
Comments