On Firemen, Web Time, and Service Levels

There are really several layers of misunderstanding and poor DBA practices running rampant across the industry – and they need to be addressed. The most pervasive these days, I think, is the situation facing DBAs working for organizations where the Internet rules. As companies move from traditional development to e-business development there is the inevitable change in mindset that creates mad rushes. This is the "get it done NOW!" mentality -- industry pundits have even coined the phrase "Internet time" or web time to describe this phenomenon. Basically, when a business starts operating on "Internet time" things move faster. One "Web month" is said to be equivalent to about three standard months. This is mostly just baloney. Now there may be a nugget of truth there in that Web projects move very fast because business executives want to conduct more and more business over the Web to save costs and to connect better with their clients. But just as frequently projects are forced to move fast because someone read an article in an airline magazine saying that Web projects should move fast and, well, everyone else is moving fast so you'd better move fast, too, or risk losing business.

This is bad for the DBA because this approach is bad for database design. Why? Applications are temporary, but the data is permanent. Organizations are forever coding and re-coding their applications -- sometimes the next incarnation of an application is being developed before the last one even has been moved into production. But when did you ever throw away data? Oh, sure, you may redesign a database or move from one DBMS to another. But what did you do? Chances are, you saved the data and migrated it from the old database to the new one. Some changes had to be made, maybe some external data was purchased to combine with the existing data, and most likely some parts of the database were not completely populated. But data lives forever.

So, the Internet causes rapid delivery schedules which causes database administration to be an afterthought. This means many organizations are trying to implement database applications with no DBAs – instead, the application developer acts as a pseudo-DBA and performs just the basics to get the application delivered. Meaning, database design, performance, availability, and maintenance will suffer.

And this is just one of the many problems -- things are worse than that. Let's think about the whole proactive versus reactive argument. Many so-called mature organizations approach database administration only as a “reactive” chore. This gets back to my fireman metaphor. Oh, yes, everyone says they are “proactive” but that is usually a great big lie. Many DBAs are up to their ears in paperwork, design tasks, and performance tuning – with a line of folks out the door of their cubicle looking for help. Now, how many of these DBAs do you think are being proactive and looking for more “potential” problems so they can fix them before they occur? None! They are all trying to put out the fires that are on their desk.

So what can be done? A big step in the right direction would be to implement service level management (SLM) and service level agreements (SLAs). Service level management is the disciplined, proactive methodology and procedures used to ensure that adequate levels of service are delivered to all IT users in accordance with business priorities and at acceptable cost. So, in order to effectively manage service levels, the business needs to prioritize application and identify the amount of time, effort, and capital that can be expended delivering service for those applications. When DBA is practiced as a management discipline every database application will have an SLA attached to it.

A service level is a measure of operational behavior. SLM ensures applications behave accordingly by applying resources to those applications based on their importance to the organization. Depending on the needs of the organization SLM can focus on availability, performance, or both. In terms of availability, the service level may be defined as "99.95% up time, during the hours of 9:00 AM to 10:00 PM on weekdays." Of course, a service level can be more specific stating "average response time for transactions will be two seconds or less for workloads of 500 or fewer users."

For a service level agreement to be successful all of the parties involved must agree upon stated objectives for availability and performance. The end users must be satisfied with the performance of their applications and the DBAs and technicians must be content with their ability to manage the system to the objectives. Compromise is essential to reach a useful SLA.

A proper SLM discipline makes performance management predictable. SLM manages the expectations of all involved. Without a pre-defined and agreed upon SLA how will the DBA and the end users know whether or not an application is performing adequately. Not every application can, or needs to, deliver sub-second response time. Without SLAs, business users and DBAs may have different expectations, resulting in unsatisfied business executives and frustrated DBAs. Not a good situation.

With SLM in place, DBAs can adjust resources by applying them to the most mission critical applications as defined in the SLA. Costs will be controlled and capital will be expended on the portions of the business that are most important to the business.