Finding ROI in a Configuration Management Database (Part 1)

Written by Mark Hillyard

This is a 5-part series discussing the value to the business that can be found within a quality, well-maintained Configuration Management Database.

A Brief History Of Configuration Management

In olden times (pre-2000), we tended to keep some spreadsheets around that might have some useful data about some of our systems. Then came the great specter. For anyone working in IT in the mid- to late 90s, Y2K—while now a punch-line more than anything—was a very real doomsday revelation. If you were lucky enough to know COBOL or FORTRAN, you probably made enough money to buy a small island…like Manhattan. But, beyond the programming hysteria, there was something else looming: If the computers went dark, how would we know what systems supported which services? The answer was simply that we couldn’t. There wasn’t really a process in place to store all of that information. Thus, the first configuration management system was created. It was probably written on a cocktail napkin, but it was a start. We sent our data center technicians out into the racks and made them take notes on every server, switch, router, and storage device we had. Trace all the cables. Where do they lead? System Administrators were frantically trying to tie software to databases, and databases to services. And we did a reasonably good job. Then the big day came. Everyone held their collective breath, and…nothing happened. So, we all went back to business as usual, and we forgot about all that data we compiled. It went into a database, or a spreadsheet somewhere, and we just kind of ignored it.

Luckily, not everyone jumped off the bandwagon so quickly. Some CIOs and CTOs and even Service Desk Managers realized that this was really useful stuff. They could actually track all sorts of useful metrics based on what assets they had. So it grew. ITIL v2 called it, “Configuration Management”. It was, by no means, the lynchpin that held the library together, but it was nonetheless considered relatively important. And when it came time to update ITIL, those who saw the value in it expanded on it to create what we now know as, “Service Asset and Configuration Management”. It is one of the more prominent processes within Service Transition, and mature organizations spend a lot of time and money building and maintaining their CMS.

Do You Need a CMDB?

So, why all the hoopla? What’s so sexy about a Configuration Management System, or, more specifically, why do you even need a CMDB?  There are three generally accepted processes that are very well supported by a CMDB:  Incident Management, Problem Management, and Change Management. However, in my opinion, this is not enough to justify the cost of building a full-fledged Configuration Management Database.  There is a benefit that ties these three processes together in a way that can illustrate real business value. It both feeds and is fed by the other three, to be sure. Any time you can improve what are likely the 3 processes you will find in almost any IT organization, you’re probably going to get—at the very least—a big fist bump from your management. However, when you are trying to pitch the cost and resources necessary, you really need that neat little bow to tie it all together. And that is where Asset Intelligence comes into play.

I should probably take a small step back here and just clarify the difference between what ITIL terms as asset versus configuration item. It is a small distinction, but it is worth noting. When we talk about assets, we really are talking about the financial aspect of our CMS. How many servers do we have, what are the lease terms, warranty expiration, etc.? What we are not particularly interested in at that level is what the asset actually does. This is important to remember for one very big reason. Your customers don’t really care what your assets do, not on a level that the Service Desk or engineers are concerned. And we always need to be mindful of our audience. Who is our customer? It is almost always the end-user. And I think we can all pretty much agree that there aren’t many end-users that care that Database 4 in Server 28 on Rack 4.23 in the Houston Datacenter is down. They are just upset that they can’t get their e-mail.

Now when we get to talking about Configuration Items, we are very interested in the function of the component. And it can be anything. It isn’t just servers in a rack, or the router at the end of the row. It is the software installed on that server in Houston. It’s the licenses for Windows 7 that you bought last year. It is the laptop the VP of Marketing drags all over the Midwest selling widgets to corporate farmers. And that is where actual Asset Intelligence can start to shine.

The biggest coup you can provide when talking about a CMDB is traceability. What I mean by that is being able to say that this one single component belongs to a series of components which make up a system, which can then be traced to a larger system, which can ultimately be traced to a service, and that service is what provides your business value. If you build a thorough and well-maintained CMDB, you will be able, at a glance, to explain why e-mail stopped working 7 minutes ago. Not, “Well, something must have broken.” You will, without having to research more than a couple of minutes, be able to say that the reason e-mail stopped working was because we had a double disk failure in a storage cluster that underpins the Exchange database for the Northeast region, causing e-mail to bounce all over the system, which led to high congestion rates, that ultimately made the e-mail service tank. Hopefully, you have sufficient capacity management controls in place to avoid such a thing, but that’s a discussion for another day. The point here is that you can trace from the smallest piece of hardware or software, all the way back to the service being impacted. Now, think about how that plays with the CFO. Rather than saying, “I need to spend $1 million on infrastructure this quarter to fix e-mail”, you can actually have meaningful graphs and charts, showing that the components which underpin the systems that support the e-mail service are insufficient to handle projected loads. No more guessing and trying to slog through mountains of disjointed data to come up with justification for spending your company out of its annual bonus budget.

And it is not only for broken stuff.

Think about the last time your organization made a change to a system thinking it was non-impactful and later found that some Tier 1 service depended on the component you had to restart. Gee, would it not be awesome to know that before you make such a change? You could do actual risk analysis, notify users, schedule during off hours to minimize impact. The list goes on. And, yes, a thorough, well-maintained CMDB can provide you with that insight. In fact, a truly mature CMDB can probably handle the risk analysis part on your behalf. How much is that worth to your business?

Continue to part two, “The CMDB and Incident Management” >>>


Originally published April 04 2013, updated January 01 2019