Welcome to Part 1 of this 2 part series discussing the value to your business that can be found within a quality, well-maintained Configuration Management Database (CMDB).
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 CMDB. 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 and Asset Management 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 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.
Figure 1: CI vs. IT Asset
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 email 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 email stopped working was because we had a double disk failure in a storage cluster that underpins the Exchange database for the Northeast region, causing email to bounce all over the system, which led to high congestion rates, that ultimately made the email 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 email”, 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?
THE CMDB AND INCIDENT MANAGEMENT
If you ask the average end-user what it is that IT provides, their answer will almost always be something that relates to Incident Management. “They fix my computer when it’s broken.” “They fix email when it’s down.” “They fix…{insert service name here}.” Bottom line, Incident Management is the most visible process we perform, and it is the most thankless job I can think of that does not involve coveralls or a hard hat.
And, guess what? A good CMDB will make this job just a little less painful. Rather than scurrying around like rats on a sinking ship trying to plug the holes, we now have a wealth of data and metrics at our fingertips that can provide us with near-instant feedback on what might be wrong.
I worked for almost 10 years in a very large IT organization which supported a business that was, in fact, an IT business. We provided small businesses with domain names, web hosting, secure certificates, shopping carts, and the like. When I started there, I was personally responsible for about 150 servers. Seemed like a huge number to me on day one. By the time I left, my responsibility had expanded to include somewhere in the vicinity of 5,000 servers. And that was not even half of the entire portfolio. We had 3 system administrators who were responsible—24×7, 365—for the health and efficiency of every one of those servers. So, when I got a call from our operations center at 3 a.m. on a Sunday, how important do you think it was that I knew exactly what the system I was about to start grinding away on was supposed to do? I held what we dubbed the ‘keys to the kingdom’. I was personally, and for several years, solely responsible for the systems that encrypted and decrypted credit card data for our company’s shopping cart. If those appliances went down, we lost anywhere from $50,000 to $100,000 per half hour of downtime. It turns out it is pretty important to know what system you’re dealing with when the rubber meets the road.
So, when you think about how a CMDB can help your Service Desk and Incident Management, think about how much more quickly and accurately they will be able to address and resolve every ticket that comes in. Additionally, when the CMDB is tied to metrics and monitoring, it can even make your team more proactive in solving issues. Rather than just playing whack-a-mole trying to find the real cause of an outage, tying systems to one another and ultimately to a service can be immensely powerful in reducing effort and time. And that means ultimately happier customers. In the next part of this two-part series on finding ROI from your CMDB we will dive into the specific wins you’ll receive from Problem Management, Change Management, and finally tips and tricks of how to properly implement your CMDB.