A client calls your service desk to report that your retail banking service is unavailable. But the base metrics indicate that all the components are available, so you log the incident and tell the caller that you'll look into it. A deeper investigation reveals that a component in the service chain isn't mapped as part of the dependency map and it has been unavailable for almost an hour. So instead of one irate caller, you now have thousands. You long for the days when you knew all the components in the service and could check them off one by one. Today, the complexity of the environment doesn't allow this and we have to rely on accuracy and completeness of service in the Configuration Management Database or CMDB.

The CMDB is often seen as a mystery, a failed project or an expensive asset repository. For those who have executed well, however, it is vital cog of IT that ensures highly available services, especially in this emerging hybrid world.

The hybrid IT estate implies multiple suppliers including "cloud" and "cloud" implies virtualization. Most of these implementations have been rushed into production without the quality and control afforded traditional investments by process standardization and best practices like ITIL. The very nature and complexity of these services mandates automation, including the optimization of resources in order to deliver highly available and dynamic IT services.

So why do some think that these environments, with their aura of self-management, don't require the structure and rigor of process such as ITIL and the CMDB? I believe they do-but based on their complexity and level of automation, they require it in an automated form.

Most organizations I talk with have some form of investment in their CMDB journeys. Typically, they have some from Configuration Items based on the IT service view and not business services as the highest order CI's. Implementations that are more mature are linking the CI's to metrics that are business-like. That said, much of this is manual or semi-manual and the implementation evolves in the more mature organizations based on gaps and a strong change rigor that ensures updates when change is moved to production.

This works quite well in an environment of controlled change and discipline. But it adds significant overhead and effort in the cloud and hybrid world, where automation isn't leveraged, leading rapidly to an incorrect CMDB. The IT Director at an organization I visited this week told me that they were now totally virtualized and were abandoning the CMDB!

The reality is that automation of process actually allows for greater accuracy of your CMDB since you can ensure that it is updated automatically as part of the process. You just have to include time as part of your automation process development to ensure the repository is updated and then allow for automated change collision detection, and proactive alerting. This will also enable the Service Desk to be aware of the current configuration just in case there is an incident....

So the next time you hear from an irate caller, you can quickly resolve the incident. Or, even better, you can identify the component failure and restore it before you even get the call!