Business Eye for the DBA Guy

On why it is important for DBAs to be business-savvy…

Heads-down DBAs who know technology, but not their company’s business, soon will be on the endangered species list. Although DBAs are technologists first and foremost, we need to be ever cognizant of the business reasons that our beloved technologies support. Yes, DBAs like to immerse themselves in the bits and bytes of technical solutions and learn all there is to know about the software we use. And this is okay–up to a point. As long as we take care not to blind ourselves to the business reasons for the software and hardware they love so much.

To keep the business “top of mind,” the DBA’s tools and utilities need to be tied to business strategies and initiatives. In this way, the DBA’s work becomes integrated with the goals and operations of the organization.

The first step in achieving this needed synergy is the integration of DBA services with the other core components of the IT infrastructure. Of course, the DBA should be able to monitor and control the databases under his purview, but he should also be able to monitor them within the context of the broader spectrum of the IT infrastructure–including systems, applications, storage and networks. Only then can companies begin to tie service-level agreements to business needs, rather than technology metrics.

To fulfill the promise of business/IT integration, it will be necessary to link business services to the underlying technology. For example, a technician should be able to immediately comprehend that a service outage to transaction X7R2 in the PRD2 CICS region means that regional demand deposit customers cannot access their accounts. See the difference?

Focusing on transactions, TP monitors and databases is the core of the DBA’s job. But servicing customers is the reason the DBA builds those databases and manages those transactions. Technicians with an understanding of the business impact of technology decisions will do a better job of servicing the business strategy. This is even more true for the DBA’s manager. Technology managers who speak in business terms are more valuable to their company.

Of course, the devil is in the details. A key component to realizing effective business/IT integration for DBAs is the ability to link specific pieces of technology to specific business services. This requires a service impact management capability–that is, analyzing the technology required to power each critical business service and documenting the link. Technologies exist to automate some of this through event automation and service modeling. Such capabilities help to transform availability and performance data into detailed knowledge about the status of business services and service level agreements.

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.



I'm a strategist, researcher, and consultant with nearly three decades of experience in all facets of database systems development.
This entry was posted in DBA. Bookmark the permalink.

4 Responses to Business Eye for the DBA Guy

  1. Pingback: An interesting post on Craig S Mullins’ Blog

  2. I really agree with that. Great post. Thanks!

  3. Erin Wiggains says:

    Hey very nice website!! Man .. Beautiful .. Amazing .. I will bookmark your blog and take the feeds also…I am happy to find a lot of useful information here in the post, thanks for sharing. . . . . .

  4. Syahira says:

    Excellent post and I wish all vendors took that attitude. I hope my employer does.Unfortunately, the DBAs (or others) might not ever get the customer feedback in some orgs. Releases might be to far between, and scope so tightly controlled that documentation fixes like these stagnate in bug system. I’ve worked in places where the company was small enough that I could just be the change I wanted to see in the world. Worse case I would have to stay late and fix things after 5pm. I’ve worked in one place where I had to kick and scream to get permissions to fix my self reported bugs, but that was mostly because the person deciding what got fixed was non-technical so I had to make a customer facing argument for my changes. In that case we were an ASP, so customers would never do DB maintenance, so it was a slightly scenario.My current company has elongated their already long development cycles. I’m in a customer facing role, and not a development role. I’ve files several bugs in the bug tracker, including several documentation bugs. There not going to get fixed because of resource issues. I’m not allowed to make the changes myself. This will be the status quo for at least 2 years while we rewrite our main product.So my question is what do you do when you can’t fix your documentation, even when you know its wrong?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s