Iterating on IT Service

Last week I spoke with a Hungarian banker about the CMDBf specification. He was broad and burley, with a thick beard, a muscular neck, shoulders like a bear, and a gruff, heavily accented voice. "CMDBf?" he sneered with a toss of his head. "I'll believe it when I see it."

I was dumfounded, though not with his skepticism. After all, although I see widespread adoption of the CMDBf specification as very likely, mine is an insider's view that I don't necessarily expect the rest of the world to share. I know that the federation of management data sources (MDRs) is important because I've seen organization after organization struggle to make sense of the wealth of information and dearth of coherency that characterizes so much of IT. No, what astounded me was that he had heard of CMDB federation and had heard enough to form an opinion. Had he read my blog?   

His organization is embarking on its ITIL journey and he and his Hungarian banker colleagues (all IT professionals) had many questions on where to start and how to maximize and hasten ROI. The fact that this organization, only just beginning to establish consistent IT management practices, recognizes the importance of federation, tells me something about the sophistication of IT practitioners today. It underscores the fact that federating MDRs is not a theoretical problem on the horizon. It's a real problem being faced today around the world--literally.

The Hungarian bankers asked questions about CMDB practices that I have heard many times--questions that anyone who is contemplating installing a CMDB should consider carefully.    

"Where should we start?" I told them that the starting point for a successful CMDB installation is to understand your needs. Every IT organization has its own set of priorities, the things that it does that are most important. That is where you must begin. Identify the most important services you provide, then the infrastructure and subservices that support those critical services. These are your core configuration items (CIs).

"What's next?" I warned about the temptation to skip the next step. Don't. Identify the processes that you use to establish and maintain the base line authorized configurations for those CIs. If they are vague and not well defined, you should take time to tighten them up. Identify the tools and processes you use to discover the as-is configuration of those CIs. Find out who is responsible for operation and maintenance of each of these CIs. Using your knowledge of baselines, as-is configuration, and distribution of responsibility, load your CMDB. Add CI relationships, either through auto-discovery or manually. Add relationships that can be used to trace impacts and root causes from CI to CI. Those are simple instructions for a big and complicated job.

"When will we get value from our CMDB?" In my experience, three areas, all related to the service desk, are usually the first places benefit is seen. First is change impact. Avoiding adverse impacts of planned changes becomes much easier with a CMDB in place. Second is incident impact analysis. A CMDB helps evaluate which incidents affect critical services, which do not, making it possible to allocate resources to quickly resolve the most significant incidents first. The third is root cause analysis. A CMDB helps trouble shoot service impairments down to their causes which speeds remediation.

And finally, "What should we look out for?" I answered that the worst thing to do is to load a CMDB heedless of process. CMDBs were originally conceived of to support ITIL configuration management practice. That is still probably the prevalent way to use a CMDB, although you can certainly derive value from a CMDB using your own practices, and sites may discover effective ways of using their CMDB that have yet to be included in ITIL practice. The key is to understand the CIs you have, how you will use the data you track on them, and how you will maintain the data. You must understand all of this before you begin to populate the CMDB. Sites that neglect these processes seldom do well. The worst messes appear when sites load CI data into their CMDB just because they can--creating a tangle as complicated as the situation they were trying to remediate.

We parted friends--all wiser for the discussion. They received some valuable and practical CMDB advice that, if taken, should pave the way for an expedient CMDB implementation free of heartache. As for me, I learned that IT (that's Information Technology) is a small world--after all.