CMDB implementation? What do you think

Is there a wrong way to do it...

Reg Technology Panel If you've had any encounters recently with vendors who sell service management solutions, you'll undoubtedly have had the acronyms "ITIL" and "CMDB" thrown at you on quite a few occasions. ITIL is the best practice framework that basically tells you how to deliver IT services effectively and efficiently, and one of the basic principles behind it is if you don't know what's in your IT infrastructure and how all the pieces hang together, you stand a snowflake in Hell's chance of extending it, maintaining it and supporting it successfully.

This is where Configuration Management Databases, aka CMDBs come in. The idea is to build a repository or set of linked repositories that hold details of not just IT assets, but how they relate to both each other and the higher level services they enable – i.e. all of the configuration and dependency related information. This is obviously pretty handy for all kinds of things, from troubleshooting issues when they arise in a help desk context, to figuring out the impact of a proposed system change or new system rollout so all of the necessary preparations can be made. The same repository keeps track of how things change over time, which has advantages in compliance terms as well as from an operational management perspective.

CMDBs are a great idea in principle and if most IT departments could wave a magic wand and have one magically appear, pre-populated with all of the details of their infrastructure, systems and services, they would probably embrace the whole concept immediately. Back in the real world, however, it ain't that easy, and the attractive sounding CMDB idea soon translates to a bunch of complex and difficult questions such as:

How many CMDBs do we actually need or want? One big central repository, or multiple repositories that coordinate with each other? If the latter, how do we keep them synchronised?

Then there is the question of whether CMDBs compliment or conflict with more traditional asset management systems or other ways in which configuration management information is held, e.g. within systems monitoring and management software suites. And when it comes to implementation, should we start by sucking all of our asset information into the CMDB first then building up the higher level view of logical systems and services from that, or should we start by defining the services that are most important to the business, then pull in the details of the components they are dependent on more selectively?

Tales of CMDB implementations crashing and burning because of problems with the implementation approach are all too common, and while various gurus and advisors all have an opinion on what works and what doesn't, there is no better means of hammering out the right and wrong way than to ask lots of people who have "been there, done that" for their experiences.

So, if you have experience of, or even just an opinion on, some of the questions we have raised above, we need your input into the latest Reg survey. There are some traditional tick and bash multiple choice questions in there, but also a chance to express yourself freely, so get across there now and let us know what you know.

As usual, we'll then pull everything together and feed back the results for the collective benefit of the broader Reg Reader community.®

Sponsored: 5 critical considerations for enterprise cloud backup