The Configuration Management Database (CMDB) provides a single database that contains information about the enterprise’s assets, both logical and physical. In modern service management platforms, it provides core functionality that is referenced by all of the service management practices, including some business-facing practices. As a result of its core functionality, the CMDB as a source of truth is uniquely positioned with information concerning configuration items (CIs) and their relationship to other CIs, including business services.
Practice and Process Support
In modern service management in larger, more mature organizations, the CMDB can play a central role in supporting and automating service management activities. The diagram to the right shows only a few of the data and process interfaces between the most common service management activities, including process automation and the CMDB. It’s worth looking at the indented interrelationships of a few of these more closely:
- Event management needs information about the affected configuration item as well as both its history of changes/maintenance and its relationship to other configuration items
- Incident management has similar data requirements, and both of these need information about support and escalation teams, how an asset is used, its business criticality, recent changes, and any known errors (problems).
- Event and incident management both interface with problem management, a practice which will use data to perform root cause analysis, understanding the history and relationships of an asset to see what may be causing a repetitive incident or event
- Change Management needs a source for information on maintenance windows, approvers, audit status (SOx for example), the assets use (production vs. pre-production) and its relationship to other CIs to ensure the change is appropriately scheduled and to provide risk information
- Changes to applications need to be housed in a common data store for audit and operational processes and need a way of triggering automated deployment capabilities on approval a deployment
- Information security management needs a way to make sense of the thousands of security vulnerabilities, understanding which ones affect assets in the environment and how critical those assets are
- Process automation and predictive intelligence need a hub to store information used to automate activities in any/all of the areas mentioned
As a common component or data store in most service management platforms, the CMDB is uniquely positioned to become the data hub all of these practices need, but only if it is established and used as a single source of truth to be used by the entire IT staff and others that work with IT. Configuration data can come into the CMDB from several sources: monitoring systems, discovery tools, application code repositories, Agile tools, local CMDBs and others but there are several critical aspects that enable the CMDB to be the source of truth needed:
- The technical information contained in the CMDB needs to be automatically populated and updated whenever a change is made (authorized or not): when data is provided manually the source of truth becomes questionable as a typo can render it useless.
- Service mapping is critical to success as it provides the relationships that convert an asset management listing into a configuration management system: the relationship of a CI to a business service or application and its criticality are the least amount of data needed for prioritizing issues and understanding the impact/use of a CI in its environment.
- Real-time visualizations provide more insight into the CMDB by representing the organizations infrastructure visually, and the dependencies between all devices being managed. This allows IT staff to quickly understand where an issue might be, and to and restore service outages quicker and with less people involved.
- Processes and adoption are needed to ensure the availability and accuracy of non-discoverable data needed to support services.
- Integration to change management processes may be key for keeping the non-discoverable data accurate over time and for auditing changes to technical information that’s discovered against authorized changes, investigating the reason for data changes that do not correspond to known, authorized changes.
These criteria for making the CMDB a source of truth are critical for having data that is trustworthy and are a valid reason many CMDB initiatives have failed to become this source of truth: when data is manually maintained, and people find differences in the data between tools, the CMDB is no longer trustworthy and thus, no longer a source of truth.
The need for a source of truth that everyone can use is pretty clear but worth calling out:
- For efficiency purposes the data hub must be in the
tool used for everyday work and available to all of IT or it cannot be
- The old practice of each technical silo having its own data repository always failed to live up to the needs of the organization because only the silo that owned it had access to it.
- The discovery of the data must be automated and
trustworthy so everyone is working with the same data, if not people will draw
- Effective root cause analysis and risk assessments require everyone to be working from the same data set.
- The data must always be accurate or incorrect decisions and loss of faith in the data will result
As a tool that is highly embedded into every application within a service management platform, a well built, automated and properly maintained CMDB meets all of the criteria needed for it to be the source of truth off which daily decisions are made and information is gathered. With the configuration item as a common link within records (for example: affected CI/caused by CI for incidents, event, and problems), the service management platform’s data becomes extensive:
- Relations between configuration items and the services they support become clear
- A full historical record of all components used by a service is maintained: user support needs, repairs, changes, technical issues, configuration records, etc.
This data store of historical information tied together by a common configuration item record enables the service management platform to become the Service Knowledge Management System or SKMS that was written about in the IT Infrastructure Library (ITIL) years ago. The SKMS was touted as the way data grows into information, then knowledge and, eventually, wisdom. Many ITIL Foundation students were puzzled about it, but with a mature CMDB as the source of truth, along with the use of artificial intelligence and machine learning, the service management platform has now become that source of wisdom: the SKMS. Essentially, by being able to crawl and analyze a large volume of data, machine learning capabilities can use data in the service management platform to alert operators that something is not operating normally, but only when a mature CMDB is at the center of the analysis. Otherwise, there is no record available to be used in correlating the data and its importance.
Another aspect of the CMDB as a source of truth and data point that allows correlation is the use of the CMDB as a central hub for the financial management of services. If time tracking and other financial information are stored in the “tickets” within the service management platform, it’s possible to get an accurate picture of costs to support, operate, repair, and maintain all of the configuration items used by a service. While some mechanism needs to be developed to apportion shared costs, all of this can be made possible when the CMDB is the central source for information.
As you start to look at the CMDB’s potential from this standpoint, it becomes far easier to make a business case for spending time and money building and then maintaining the CMDB tool. With the demand for high availability and service performance seen in most IT organizations, it’s almost more a question of “why are you not using the CMDB as a source of truth for service management” rather than “why should it be?”