For over a decade, I have yet to meet a client that does not experience some level of shame when discussing their CMDB. For the record, most of the people that I speak to on this topic work in the IT Service departments of companies with a household name. They would all quickly tell you about recently completed projects indistinguishable from magic. Yet, the CMDB remains a subject for grumbling. Why all the guilt? Why everyone?
Every CMDB is Beautiful in its Own Way
Each of us for whom the topic bears relevance was raised in the same textbook, and we read it very early on. A CMDB or Configuration Management Database simply records every person place or thing in the IT space and maps the relationships among each to another. Once this is complete, such a mapping will be very valuable as a foundation for conducting Change Management and all sorts of other value-creating ITIL activities. Theoretically, this is true.
Unfortunately, if not impossible, creating and maintaining such a repository is impractical. I cut my teeth in the airlines, another industry that created CMDBs. In an airline, the Configuration Management Database was created to facilitate the maintenance program. They recorded every screw on every aircraft, the last time it was tightened, and the requirements for the next time it needed to be tightened. Without such information, engines fall off moving aircraft more frequently, so it does tend to focus the mind. When such a project was successful, installation took 5 years and cost 150 million late 1990s dollars. Maybe consultants and airlines got better at it, but a thumb in the wind, that still seems like a fair estimate of effort.
The effort required for the IT task as defined above is at least as significant and seems to be expanding all the time. The group of objects to be contained within a CMDB include not just hardware, software, people, and places, but abstract items as well such as Services and Business Units. In English, we call the members of that group nouns. In IT, we call them Configuration Items (CIs).
Given that the scope of items collected exceeds that of the airline example and that the rapidity of change within those items outpaces it as well, it does not seem like creating and maintaining such a repository would be less expensive in time or money. Our pleasant conversation becomes much less pleasant when it is suggested that a textbook CMDB is going to cost $150M and will be ready to use productively in just 5 short years.
The good news is that we are not bound by the textbook. Nor are we haunted like the airlines by the specter of falling engines or the reality of righteously zealous regulators (your regulators may not have earned that level of zealotry, but persist nonetheless). Happily, we live in a real world where the only money we are compelled to spend is that which will return a net present value exceeding our investment. Under no circumstance should we invest money or effort in our CMDB that does not meet that condition?
Let me take a moment here to summarize. Nearly every owner I meet believes that their CMDB is the worst (I mean, we can’t all get a trophy). I believe the reason for this is that the textbook has placed upon us unrealistic expectations about the level of detail in the CMDB that is possible or required. I cannot imagine a scenario where the left mouse button, the center mouse button, the right mouse button, the scroll wheel, and the mouse itself are all mapped into the CMDB along with each button’s relationship to the mouse, and the mouse’s relation to the device it controls. The failures of my imagination aside, this is the concept suggested by the textbook. We all fail in the attempt to produce this level of detail. We always will. That should not be a source of shame. In fact, it should not bother us in the slightest.
The real reason that we feel this way is that there is always somebody approaching us with the grievance, “The CMDB is [terrible]” (expletives deleted). Unpleasant as this is, this exclamation is our greatest asset. It allows us to ask the question, “Terrible at what?” The utterer of the curses will invariably and immediately have the source of the complaint at the ready e.g.: Disaster Recovery.
This opens up a very productive line of dialogue if you are in the position to be receiving such grievances. “What do you need to make it work?” The answer is typically as quickly forthcoming, but long. A generalized summation is, that for this class of infrastructure, I need these 15 attributes and these 10 relationships. You may not make it to the end of that diatribe, so you may want to lead with this, “What would you pay to wave a wand and have it work?” You know you know the kind of answers this question gets, “I don’t know, 100 MILLION DOLLARS!” Now we’re just about talking airline money.
This is the first time it’s fun to be you. “Fine, let’s set up a meeting with the infrastructure owners. I’m sure we can get you that. It’ll only take ten.” The truth of it is, that the effort won’t cost more than a bit of process change and communication. In that meeting, the infrastructure owners will say, “I didn’t know you needed that, we can pull that out of discovery.” Worst case, “that’s manual, it will take some time.”
In the course of an hour-long meeting, several positive changes occurred. First, you’re on your way to improved Disaster Recovery (or comparable initiative). Second, and perhaps more importantly, the infrastructure owners have a compelling reason for populating the CMDB. This approach transforms a soul-sucking and impossible task into one where the value to the organization is clear to those doing the work and the value of the CMDB is clear to the people that are paying for it and relying on it.
Smile the next time someone tells you that the CMDB is #%$&@%. It’s money in the bank.
To be continued . . .