I have been working as a DBA for sometime now, and have been exposed to various database environments and with various tasks. Somehow, I can tell that for each environment, there is difference in terms of  challenges, difficulities and skillset requirments, and this brings me to think whether I can come up with a set of quantifiable criteria to gauge the database administration complexity, which amounts to workload in someway, just as the famous SLOC (soure line of code) model was once used to determine the workload / price of a project.

There are two realistic usages if such a database administration complexity model can be set up:

1. From employer side, an employer can make a reasonable budget to hire a DBA or outsource the dba work depending on the evaluation result of the model. If the budget is too low, the employer may end up with finding no DBA or getting not-so-qualified DBA, who does work in low quality and the employer suffers at the end.

2. From employee / consultant side,  the employee / consultant can make reasonable salary / rate requirements based on the model. For example, even if you are an expert (say SQL Server MVP), but the work only requires you to do the daily backup and occasional login creation / deletion, and you are not required to work offtime, then to me, there is no reason you charge the employer a premium simply because you are an MVP.

I'd like to set the complexity model by factoring in the following elements:

1.  Database support domain: Is the system need to be supported 24 x 7 x 365? What is the tolerance threshold for downtime? What is the rotation frequency to do the off-time support? What is the response time required during off-time support? Is on-site support needed during off-time? Any critical business activies that requires a DBA onsite on a regular base?

Database support domain usually decide your stress level and your work-life balance level.

I once supported systems used only by the company's accounting, HR department and development team. So in those good old days, the downtime is nothing critical, in holidays/weekends, I never need to worry about being called. However, I also worked on systems that need to be supported 24 x 7 x 365, and the stress in such an environment is far more high.

 2. Database function domain: What is the database system used for, OLAP or OLTP? How many databases are there? How many user-created database objects are there? Any communication interface with other systems? Maximum concurrent users and the trend down the road?

Database function domain usually decides your time dedicated to system tuning, monitoring and trouble-shooting. In a OLTP environment, when something happens, usually it means fire-fighting while in OLAP, it means "I will make it better later"

3. Database capacity domain:  What are the database size(s)? Largest tables in terms of rows / size? Growth rate of tables in terms of rows / database in terms of space? Transactions in terms of (both logical / physical) reads / writes to databases?

Database capacity domain usually decides the time when you do internal support. For example, with huge dbs, you may spend more time to do backup / restore, and very high-volume transactions may mean you will be more likely be reported that "The system is slow, can you take a look?"

4. Database technology domain: Is log-shipping used? replication used ?  table partitioned? system-clustered? database-mirrored? service-broker used? 

Database technology domain decides how much you need to invest (or already have invested  and need a reasonable ROI) in sharpening your skills and knowledge.

5. Business domain: Is auditing requried for database administration? Any business specific requirements on DBA?

Business domain may put additional workload on DBA. For example, if auditing is a business requirements, DBA work will involve lots of additional steps to meet the auditing requirements, like filling various forms, attending lots of meetings, requesting lots of approvals before something can be implemented. There is nothing wrong here, it is just additional work overhead and may raise your stress level.

All what I have said above is still not quantifiable, but based on this, we can design a matrics and assign some weight to each factor to make it quantifiable. Since we are DBAs, we can come up with a solution using tables and T-SQLs, cannot we?

PS: I always feel "sad/bad" that database administration as a field of subject has never caught the attentions of the academic world, while on the other hand, we see tons of articles / books / conference papers dedicated to software engineering, I hope I can make a little contribution to promote database administration more academic. That's why I want to write this blog (and some future blogs) to address the academic side of database administration.

Your comments are welcome.