Well, it is that time of year when everyone is making New Year’s resolutions that they probably will not keep. In fact, by the time you get to read this, many of you will have already broken your New Year’s resolutions. That’s okay; if you’re a DBA, I’ll help you to make some new ones.

1. It’s All About the Business

DBAs tend to be overly fond of technology. We like to immerse ourselves in the bits and bytes of technical solutions and learn all there is to know about the software we use. This is fine as such, but technology-loving DBAs have to be sure they do not blind themselves to the business reasons for the software and hardware they love so much.

The DBA’s work must be integrated with the goals and operations of their organization. Doing so requires merging business with technology to build what is known as Business Service Management, or BSM. DBA services need to be integrated with the other core components of the IT infrastructure. Although this is not simple, more work is required than just linking to the IT infrastructure. To fulfill the promise of BSM, business services must be linked to each component of the underlying technology.

This means that a DBA should be able to immediately ascertain that an outage in a particular production database, server, or transaction translates into a particular business outage. For example, the DBA should be able to immediately comprehend that an outage to the XWPD459I database means that stores in the Western region cannot conduct sales. Yes, the DBA must focus on fixing XWPD459I, but communication to management and end users has to focus on the business impact. And the severity of the business impact must guide and prioritize the actions taken by the DBA.

Today’s modern corporation needs technicians who are cognizant of the business impact of their management decisions. As such, DBAs need to get busy transforming themselves to become more business-savvy … that is, to keep an eye on the business impact of the technology under their span of control.

2. Service Level Management (SLM)

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. In order to effectively manage service levels, the business needs to prioritize applications and identify the amount of time, effort, and capital that can be expended delivering service for those applications.

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 (SLA) 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.

In practice, though, many organizations do not institutionalize SLM. Oh, when new applications are delivered there may be vague requirements and promises of sub-second response time. But the prioritization and costing required to assure such service levels are rarely tackled unless the IT function is outsourced. Internal IT organizations are loathe to sign service level agreements because any SLA worth pursuing will be difficult to achieve. Furthermore, once an SLA has been created, the business will be more readily available to assign the SLA to an outsourcer. With the difficult negotiation of service levels complete, the business can seek out lower cost providers than the internal IT group.

DBAs should make one of their New Year’s resolutions to institute a rigorous SLM methodology for the applications they must manage. Work on getting management sponsorship and build procedures and policies to enforce service level identification — and then manage to the specified service levels.

Face it, if you do not identify service levels for each database transaction, then you will always be managing to an unidentified requirement. 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.

If someone calls you up to complain about poor performance, they will always be right (or wrong, depending on your perspective). And you will always be on the hot plate to make things perform better. You’d be much better off with a pre-arranged agreement for each service — and then you’ll know what is the required level of performance that you must support.

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.

3. Warm and Fuzziness

A frequent criticism of the DBA staff is that they can be difficult to deal with. Sometimes viewed as prima donnas, DBAs can be curmudgeons who have vast technical knowledge but limited people skills. Just about every database programmer has their favorite DBA story. You know, those famous anecdotes that begin with, “I have a problem ...” and end with, “... and then he told me to stop bothering him and read the manual.” DBAs simply do not have a “warm and fuzzy” image. This probably has more to do with the nature and scope of the job than anything else. The DBMS spans the enterprise, effectively placing the DBA on call for the applications of the entire organization.

The fact that DBAs often must sit down and work things through on their own can be a mitigating factor in this poor reputation. Many database problems require periods of quiet reflection and analysis to resolve. So DBAs do not generally like to be disturbed. But even though many problems will require solitude, there are many other problems that require a whole team to resolve. And due to the vast knowledge most DBAs possess, their quiet time is usually less than quiet; constant interruptions to answer questions and solve problems is a daily fact of life.

DBAs should not be encouraged to be anti-social. In fact, DBAs should be trained to acquire exceptional communication skills. Data is the lifeblood of computerized applications. Application programs are developed to read and write data, analyze data, move data, perform calculations using data, modify data, and so on. Without data there would be nothing for the programs to do. The DBA is at the center of the development life cycle — ensuring that application programs have efficient, accurate access to the corporation’s data. As such, DBAs frequently interface with many different types of people: technicians, programmers, end users, customers, and executives. However, many DBAs are so caught up in the minutiae of the inner-workings of the DBMS that they never develop the skills required to relate appropriately with their co-workers and customers.

Sometimes bad management exacerbates the anti-social behavior of DBAs. A manager who rises from DBA to DBA manager might not know how to curb the curmudgeon. Worse yet, he might agree with the behavior. DBA management must help to grow the DBA staff in the desired direction through encouragement, opportunity, and incentives. Even more importantly, the DBA manager must lead by example — a curmudgeonly manager will more than likely cultivate curmudgeonly DBAs.

If your DBAs are curmudgeons, or you are a curmudgeonly DBA yourself, make one of your resolutions this year to become more “warm and fuzzy.” A better attitude will translate into a better working environment — and more productivity for your entire organization. Modern DBAs cannot afford to be curmudgeons. In this day and age of inter-connected systems and complex technology, interpersonal relationships and teamwork are required for a DBA to succeed.

Happy New Year!

I think we should stop there. I mean, how many resolutions can a DBA be expected to keep anyway? If you can, resolve to take at least one of the resolutions discussed above to heart — and work on improving it for 2004!

--

Craig Mullins is an independent consultant and president of Mullins Consulting, Inc. Craig has extensive experience in the field of database management having worked as an application developer, a DBA, and an instructor with multiple database management systems including DB2, Sybase, and SQL Server. Craig is also the author of the DB2 Developer’s Guide, the industry-leading book on DB2 for z/OS, and Database Administration: Practices and Procedures, the industry’s only book on heterogeneous DBA procedures. You can contact Craig via his web site at http://www.craigsmullins.com.