Eating the CMDB elephant: A phased approach

* Take a phased approach to building a Configuration Management Database

Over the last year, I've written on the topic of the Configuration Management Database as proposed by the IT Infrastructure Library in its best practices for service management. The CMDB has since become a far hotter topic than I had imagined, a fact that I think is both a sign for optimism and for caution.

The reason for optimism is that the CMDB initiatives expose two critical trends within the industry: a focus on processes via ITIL's best practices, and a focus on architectural integration of IT management investments.  

The reason for caution is the fact that ITIL's CMDB remains a visionary endeavor that's at the embryonic stage in terms of real, architected technology and supporting standards (from an architectural perspective there are none fully baked at this point). In other words, jumping into the CMDB game - well - it's easy to get burned. The reason for this is that the CMDB, as ITIL defines it, becomes a composite not only of configuration information but also a current, trusted resource for topology and configuration across the full infrastructure. This would include applications, as it maps to business services, business constituencies, operational owners and processes, asset and investment information, contracts, and so on. The CMDB becomes, in its most evolved state, a dynamic treasure chest of information that can support virtually all IT management disciplines, from asset and inventory management, to change and configuration management, to problem and incident management, to capacity planning, application development and deployment, service-level management, etc.

It's not surprising then, that many of you are asking EMA to help you plan the CMDB so you can "eat the elephant" (as opposed to, presumably, being trampled to death by it). In this vein, I'll be speaking in two EMA Webinars on some pragmatic best practices recommendations for ITIL CMDB deployments (details below). While there are many things to say about this "big game hunting" exercise that I won't have space to address here - probably the most important planning parameter involves taking a phased approach to the CMDB rather than an all-or-nothing cavalry charge up a hill lined with bayonets.

By taking a phased approach I mean fundamentally two things: the first is that no IT organization, no matter how extensive its resources, should plan to execute on a total CMDB addressing all ITIL parameters except as a series of stages over years. I'm going to say that again - "years." I would recommend examining the rather absolutist opportunity very closely - as an objective it is, after all, a thing of beauty - and suggest that "years" might be as many as five or even 10.

As technologies and standards evolve, you want to be able to evolve your CMDB strategies, as well. Hammering hard into the short term for the CMDB is guaranteed to fail. Take a long-term view of business, process, organization, technology and architectural requirements before even embarking on a CMDB. And very importantly, do a thorough planning exercise as to what components, or as ITIL calls them "Configuration Items" - will need to go into a core CMDB vs. outlying data stores supportive of a federated CMDB system. This fits in with what I call the "big vision" axis of a phased, CMDB approach.

On the other hand, nothing stands still and implementations need to deliver value quickly. And this leads to my second recommendation: taking baby steps that lead to value quickly and relatively easily. You want to be able to show strong ROI quickly and in clear phases with defined metrics for value on a timeline, which will be re-evaluated and revised many times over the course of a long rollout.  

Once you have a larger vision in place, go for the low-hanging fruit and the most acute pain points first. Remember that what's really driving the CMDB initiatives in the industry is a mix of technology evolution and process-driven organizational transformation, and then target areas where you are prepared to make investments in software automation to support critical IT processes.  

For example, where are you most prepared to invest in infrastructure discovery?  And to support what ends? The choices may range from change and configuration control, to service-oriented root-cause analysis, to basic inventory and asset management. Recognize that what you'll do first may not even be to build what will ultimately be your core CMDB, but to focus on one of those "federated outposts" where pain points and technology readiness are most conducive to success.

There is no shame in this. CMDB initiatives will fail if they are addressed with academic rigidity. They will succeed where a powerful, long term vision to evolve organization, culture and process meets with equally powerful near-term opportunities to capture those "perfect storms" where technology, process and pain point come together to provide value.

** I'll be speaking in two Webinars on some pragmatic best practices recommendations for ITIL CMDB deployments.

The first takes place Oct. 13 at 12 p.m. ET. Please register at the EMA Web site.

The second takes place Oct. 18 at 4 p.m. ET. Please register at the EMA Web site.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2005 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)