A CMDB is a place to store data regarding your configurable items (CIs), also known as IT assets. But, CMDBs are no ordinary data repositories. They act as a centralised system that encompasses the entire IT environment. Enabling you to monitor, track, and manage your IT estate in one place.
In this guide, you’ll see how CMDBs play a significant role in IT management principles. Particularly your IT asset management (ITAM) and IT service management (ITSM) processes. As well as how they are designed to help you better understand the ties between your CIs.
What Is a CMDB?
A configuration management database is a data repository file used to store information about your IT environment. A CMDB’s main functions include discovering, controlling, and keeping track of relationships between IT assets. As well as highlighting their individual configurations.
For ITIL initiatives to succeed, decisions should be based on accurate and current information. Particularly with processes such as change, incident, problem, availability, and release management.
This is where configuration management comes into play.
Configuration management practices provide information about CIs and their configurations. As well as their relationships with other assets. This data can help system administrators, IT managers, and application managers with:
- Resolving problems
- Responding to incidents
- Deploying network components
- Planning strategies
- Making budgetary forecasts
A CMDB can play many parts in helping to improve your IT services. For instance, you can be more efficient in troubleshooting a network disruption affecting all workstations. Especially if you knew which routers and servers those machines are connected to. Or you can prevent a potential malware outbreak if you tracked the versions of each desktop’s operating system. In turn, determining which ones needed patching.
How Does a Configuration Management Database Work?
All configuration data and asset relationships have to be stored somewhere. In most cases, that ‘somewhere’ would be a CMDB. A CMDB information on:
- Assets, or CIs
- The relationships/dependencies of CIs and other related entities
- Other configuration data
Configurable items include hardware, software, documentation, facilities, and staff and vendors. CI relationships are associated with incidents, issues, changes, and deployments.
Before a CMDB can be of any use, it must be populated with data. This is usually carried out through a combination of manual and automated methods. Although data accuracy can’t be 100%, the aim is to achieve the highest level of accuracy possible. Otherwise, a CMDB’s purpose in life will never be realised.
To make a CMDB reliable, it’s necessary to involve the ‘owners’ of CIs. Both before and during the CMDB population process. These owners should review the data for accuracy, completeness, and consistency.
Once the CMDB has been populated, the challenge shifts into keeping the CMDB updated. Because an IT framework can easily consist of a million moving parts, that won’t be an easy task. This is due to configuration changes, new CIs, deprecated CIs, mergers, and acquisitions. However, it needs to be done for a CMDB to function the way it’s supposed to.
What Are the Pros and Cons of CMDBs?
The main objective of a CMDB is to provide efficient management of your IT estate. This means it must be easy to organise and navigate. But, like most deployments to the management and control of IT infrastructure, a CMDB comes with both its advantages and drawbacks.
- Reducing an asset’s Total Cost of Ownership (TCO)
- Reducing downtime of infrastructure
- Minimizing the costs of operations and equipment repair with automated tasks
- Performing root cause analysis (RCA) to understand CI issues and resolve them
- Providing a single source of truth regarding a business’s IT infrastructure
- Delivering records of service codes and billing to finance teams
- Helping to meet regulatory compliance standards
- Infrequent IT asset discovery can lead to a lack of data accuracy
- There is a lack of opportunities for integration with other tools
- Wrong data that has been stored in a CMDB can lead to ineffective decision making
- It can be difficult and time-consuming to collect all data in a CMDB
- The introduction of too many assets or CIs can be difficult to manage
What’s the Difference Between ITAM and a CMDB?
ITAM is a set of IT practices similar to IT Inventory Management, with financial and contractual components. But, whereas inventory management is concerned with asset quantity, location, and ownership, ITAM further expands on those concerns.
Although CMDB is a component of both IT asset management and configuration management, it differs from ITAM by containing and storing assets as CIs. By doing so, and per ITIL, a CMDB focuses more on the data used in managing assets within an IT landscape.
With ITAM, you would typically focus on the lifecycle of assets and provide answers to questions such as:
- How much does an asset cost?
- What is its current accumulated depreciation?
- What contracts and maintenance agreements are associated with it?
- Is it still under warranty?
- If it’s a software asset, what are the licence details?
- What is its current version?
- Which endpoints are running it?
IT asset management tracks and manages assets throughout each asset’s lifecycle. From the moment the asset is requested, through its procurement, deployment, and installation. Up to the point that it is retired and ultimately disposed of.
Because the coverage of ITAM is broad, it consequently overlaps with, involves, and integrates with other processes. Including request management, inventory, procurement, and financial management. As well as configuration management.
This enables businesses to gain a comprehensive view of the organization’s assets. Especially from a financial and contractual standpoint.
Why a CMDB Is Key for Improving Your IT Asset Management
First, let’s put things in the right context. A CMDB can only be useful to your IT asset management for as long as it can be tightly integrated with ITAM processes. If these processes can’t easily retrieve configuration data when needed, the CMDB won’t be as valuable.
Fortunately, most CMDBs now either act as a central repository of configuration data that’s accessible to other processes. Or one that can be easily integrated with the datastores of other processes.
Some CMDBs store information about devices on a network as well as software contracts and licences. These CMDB architectures enable information generated in one process to be easily seen by other associated processes. In turn, this tight integration can enhance each associated process.
Hardware and software data are typically gathered by configuration management applications. However, this information can also be used to support an ITAM process like procurement. If the ITAM software can easily retrieve usage data, that data can be used to inform and streamline purchasing decisions.
Tight integration of CMDB and ITAM can also reduce risks.
Let’s say a server is originally deployed at a particular business unit. As per ITAM practices, that server is recorded into the CMDB under the ownership of that business unit. Shortly after, a configuration management solution’s automated scanning tool gathers information regarding that server’s CPU, RAM, IP address, and MAC address, and then stores these configuration data into the CMDB.
Incidentally, after a couple of months, the same scanning tool discovers the same CPU, RAM, and MAC address at another IP address. This could raise red flags if no change of ownership is recorded.
On a slightly different note, if another scanning tool discovers an application that never went through the proper channels, i.e. it was never requested, procured, or installed, as per CMDB records, then it could be a rogue application.
Rogue applications can introduce vulnerabilities or can be outright threats themselves. Both can harm business continuity.
As this shows, ITAM and configuration management don’t have to operate independently all the time. There are many situations when practitioners of these two disciplines can gain better insight when information is shared. The best way to do that, as stated earlier, is a centralised or tightly integrated CMDB.