Some time ago, the configuration management database or CMDB was hailed by some as the silver bullet for IT asset management. CIOs could finally get to grips with what their enterprises had in terms of IT resources and how those resources mapped onto business needs and opportunities. That was a big promise to live up to, but, in theory, the CMDB had what it took – as long as a few obstacles could be overcome in its implementation. Sadly, it seems that those stumbling blocks dampened the enthusiasm of more than one IT department. Indeed, after a moment in the spotlight about six or seven years ago, the CMDB has since taken something of a back seat. Still, recent developments in other areas of IT might just bring it to the fore again.
To understand the fuss – or lack of it – it’s important to know a little about what a CMDB is and does. Essentially, it’s a repository of information about IT resources, things related to those resources and the relationships between any or all of them. A CMDB’s “currency” is the configuration item or CI. This is any resource or element referenced in the repository. CIs can include servers, applications and network equipment. They can also correspond to facilities, people, (non-IT) products and services, markets, vendors, suppliers, partners and clients. Using its information on the CIs and the relationships between them, a CMDB can offer a number of capabilities:
• At-a-glance views of how an information system has been built and configured
• Information about upstream and downstream dependencies between IT resources or CIs
• Whether or not production systems correspond to approved configurations
• Reconstruction of IT systems in IT disaster recovery situations
• Change management with impact analysis
• Support and troubleshooting with root cause analysis
• Business intelligence insights through statistics and analytics
In particular, business intelligence from a CMDB can give you information like “How many users in the production department use ERP at the start and the end of a month?” To yield this kind of insight, a CMDB needs to be based on something more than a simple SQL database, requiring technology more similar to online analytical processing (OLAP). The CIs must also be in the CMDB and be up to date, although care must be taken to avoid trying to include every possible piece of data. Too broad a scope means a lack of focus on the CIs and relationships that are of real business importance. Many early CMDB initiatives were hampered by these factors, even if functions like data federation from different sources and autodiscovery helped to populate a CMDB and systematically check for changes.
Now, the growth of DevOps – with its emphasis on automation – could give the CMDB a chance to shine again. DevOps uses tools like software version control, continuous integration servers and deployment management applications to put a continuous delivery system in place. It relies on code components being correct at each stage; however, this creates a risk of incorrect versions being used, either because of human error or malicious intervention. A CMDB can be used to verify at each stage that code components (handled as CIs) are correct and that no unauthorized modifications have been made. By making new releases of code automatically discoverable by the CMDB, security and reliability of the DevOp’s continuous delivery chain can be enhanced.
Insights from the CMDB can also be used to determine the new features to be developed as a priority and to guide deployment strategies in a way that best serves business requirements. With a range of CMDB products available both commercially and as open source, enterprises have the building blocks and the automated functionality they need. What they must add is a business-goal oriented, phased implementation plan to get the CMDB working usefully, while avoiding the temptation to try to do everything at once and end up with little or nothing to show for it.