The big deal about CMDBs

Opinion
Feb 23, 20053 mins

* Why you should pay attention to CMDBs

As the noise level surrounding configuration management databases rises, particularly among management vendors, some IT organizations are wondering what the big deal is.

Most IT organizations already have a lot of configuration data, so why keep more data or another database?

If you’re a typical IT shop, your configuration data is located in various repositories across the IT infrastructure. The systems management team has its software and system hardware configuration information in one repository, while the network team has its network device and topology information stored in its own repository. The security team also has its own configuration information, and the storage management team has yet another configuration repository. Each team of specialists has the configuration information they need to do their specific jobs, but the data is scattered and separated.

Although this approach has worked in the past because many IT organizations are still structured in technology silos, there are movements afoot that will require a different approach. And the intent of the IT Infrastructure Library’s (ITIL) CMDB is to enable a different approach to configuration from a service support perspective.

There are some IT organizations that have built their own CMDBs because vendors were not yet offering them. Admittedly, the number of companies doing this are very few, and they are definitely very early adopters. The majority of IT shops may not yet be aware of CMDBs, are just beginning to become aware, or are already aware but are waiting to see what vendors offer before doing anything.

So let’s take a look at what’s so different about ITIL’s CMDB.

Many IT organizations are looking to improve their internal IT processes, which is why there is increased interest in ITIL in the U.S. This increased interest is due in part to needs such as regulatory compliance, IT efficiency and IT governance issues. ITIL focuses on processes and service management, and the CMDB is supposed to enable IT processes and service management through integration and a combined view of configuration. The ITIL concept of CMDB is not just as a management database; it’s more of an integrated approach to service support.

Although you do have configuration data that exists today in your IT management infrastructure, you most likely don’t have a federated configuration database that crosses management disciplines and spans services. It is this latter view that more closely reflects the ITIL concept of the CMDB. It is this federated configuration database that has the ability to share integrated information among a multitude of management applications.

For example, as configuration changes are made to different IT components through configuration management tools, those changes are reflected in the CMDB. If a service becomes unavailable or slows down, the change management application can see if there were any changes made to any of the components that comprise the service. If a change is determined to be the cause of the event, then the configuration management tool can roll back the configuration.

While the benefits of a CMDB can be significant, is it needed by all IT organizations? Are the benefits worth the cost and effort to deploy? Or perhaps you’re thinking, why wouldn’t I want to implement a CMDB? What’s your opinion on CMDBs?

The development of the CMDB is an emerging area, so at this point in time there aren’t necessarily right or wrong answers to the questions above. I’d like to hear what you, the IT managers, think about CMDBs. Please send your thoughts and comments to me at mailto:Rasmussen@enterprisemanagement.com