The Configuration Management Database (CMDB) contains information about the enterprise’s logical and physical assets. Modern service management platforms provide core functionality referenced by all service management practices, including business-facing rules. As a result of its core functionality, the role of the CMDB management process for effective IT management 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 process makes sense as a source of truth because it plays a central role in supporting and automating service management activities. The diagram above shows only a few data and process interfaces between the most common service management activities, including process automation and the CMDB. It will be helpful to look at the indented interrelationships of a few of these more closely:
- Event management needs information about the affected configuration item, its history of changes/maintenance, and its relationship to other configuration items.
- Incident management has similar data requirements. Both need information about support and escalation teams, how an asset is used, its business criticality, recent changes, and known errors (problems).
- Event and incident management both interface with problem management, a practice that uses 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 used (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 of 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 role is uniquely positioned to become the data hub all these practices need. However, it is only possible if it is established and used as a single source of truth by the entire IT staff and others who work with IT.
Configuration data can come into the CMDB management process 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 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 is 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 visually representing the organization’s infrastructure and the dependencies between all managed devices. It allows IT staff to quickly understand where an issue might be and restore service outages quicker and with fewer people involved.
- Processes and adoption are needed to ensure the availability and accuracy of non-discoverable data required to support services.
- Integration to change management processes may be vital for keeping the non-discoverable data accurate over time, auditing changes to technical information discovered against authorized changes, and investigating the reason for data changes that do not correspond to known, authorized changes.
These criteria for making the CMDB IT asset management 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, the organization should use the data hub tool for everyday work and make it available to all IT staff.
- The old practice of a technical silo where one individual has access to all the data repositories always failed to live up to the organization’s needs because only the silo had access to the data making it challenging for others to access.
- The discovery of the data must be automated and trustworthy, so everyone is working with the same data; if not, people will draw different conclusions.
- An effective root cause analysis and risk assessment require everyone to work from the same data set.
- The data must always be accurate; if not, it will lead to incorrect decisions and loss of faith in the data.
The CMDB management process works as a highly embedded tool in every application within a service management platform. When it is correctly installed into the system, automated, and maintained, CMDB meets all of the criteria needed to be the source of truth on which daily decisions are made and promotes efficient data collation.
Financial Management
Another aspect of the CMDB management process 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. Suppose 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, this can be made possible when the CMDB is the central source of information.
As you start to look at the CMDB’s IT assets management 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?”
Choose Virima CMDB for better IT management
Virima CMDB is the most intuitive and powerful solution for managing IT assets, services, and dependencies. It leverages automated discovery to populate and maintain accurate data, while dashboards and ViVID Services Maps provide insightful CMDB visualizations of asset relationships, service dependencies, and availability status. With Virima CMDB, you can:
- Monitor the state of your device inventory
- Track the status of current or future projects through a simple dashboard
- Determine which devices are likely to fail in advance
- Ensure that all critical systems are running smoothly
- Improve the efficiency of your change management processes by automating the evaluation of impact and prioritization of changes.
- Reduce time spent on manual data entry by providing a single point of access to all your critical IT assets.
- Gain greater visibility into IT infrastructure components with up-to-date information at every level of your organization.
Want to know more about what Virima CMDB can do for your organization? Schedule a demo today with our team to find out!