In very simple terms, Configuration Management manages data related to active IT infrastructure items (called Configuration Items or CIs) in the Configuration Management Database (CMDB). By active, I mean CIs that are live in the network.

I have deliberately removed several details of Configuration Management as this simple definition is enough for the purpose of this article.

The focus of this article is to highlight the interdependence between Asset Management and Configuration Management to effectively manage asset data in the Book of Record (BOR). It summarizes the approach by which these processes can exchange data with each other and does not go into the implementation details.

I have assumed that asset BOR and CMDB are in one system. If you have them in two different systems, you will have to integrate them so that records are updated automatically.

Now, let’s look at how Asset Management and Configuration Management are related.

Figure 1 shows a simplified form of asset lifecycle stages and the process that manages asset data related to those stages. It also shows example asset data attributes that each lifecycle stage can populate in the BOR/CMDB. As shown, Asset Management manages assets and their data throughout their lifecycle, whereas Configuration Management manages their CI data during their active stage.

Let’s now explore how this model works for physical, virtual and cloud environments and what happens when a new asset/CI is created and an existing asset/CI is updated.

Below is the summary of how physical asset data can be kept up to date in both asset BOR as well as CMDB throughout its lifecycle.

Acquisition of physical assets is done by Asset Management process. For the purpose of this article, we are not going deeper into the whole acquisition process where other processes, such as procurement, can also be involved. At the end of the day, when assets are acquired, it is Asset Management’s responsibility to ensure that they are registered in the BOR. At this stage, asset records must be created in the asset BOR and their corresponding CI records should be created in the CMDB. This is the data sent by Asset Management to Configuration Management (to maintain the CMDB).

After the asset is deployed, Asset Management must update its record with proper status and additional data relevant for this lifecycle stage (e.g., location, environment). At the same time, Configuration Management must also update the CI in the CMDB. Assuming the CMDB has reliable integration with infrastructure discovery/scanning solutions (potentially more than one solution is integrated) and has strong reconciliation rules, CIs are automatically updated when the asset is “discovered” or “scanned” by one of these discovery/scanning solutions. When that happens, the asset record should also be updated using the CI data. This is the data sent by Configuration Management to Asset Management to maintain the asset record.

Most of the changes that impact assets during this lifecycle stage — such as adding/removing software or hardware, clustering and other changes — can be automatically “discovered” and both CI and asset records can be reliably updated. For non-discoverable attributes, such as location and environment (e.g., prod, non-prod), data should be collected from the source process that is used to deploy assets, such as Change Management or Request Management, and both CI and asset records should be updated.

Between Asset and Configuration Management, Configuration Management needs to play the leading role to collect data throughout this lifecycle stage unless there is very specific data that only asset management requires. For example, if for some reason the cost center has changed (or needs to change) during this lifecycle stage, then Asset Management needs to take care of that.

Once the asset is decommissioned and taken off the network, it is Asset Management’s responsibility to collect relevant data and update the asset record. If necessary, it should also update the CI record — for example, by marking the CI as “retired.”

Virtual and cloud assets are not “acquired” like physical assets, they are simply “created,” “spun up” or “instantiated” through an automated process — “at the click of a button” as they say.. For these assets, the data exchange between Asset and Configuration Management is slightly different.

Let’s start with their birth.

The CMDB should have integration with the virtual environment or cloud platforms and collect newly created asset data and create their Cis. Cloud folks say “resources,” “micro-services,” “instances,” “containers,” “virtual machines” and so on, but for the purpose of this article, I am using asset/CMDB terms. It can also be done via discovery or scanning solutions, but direct integration gives much more reliable data.

In addition, since cloud environments can dynamically create and remove assets without the click of a button, real-time integration can bring those in as well and not lose them, however short their life may be. The CMDB can — and should — always use both integration and discovery to enrich CI data.

Assuming that you have decided which assets/CIs you need from these virtualized and elastic cloud environments and what attributes you need to collect, the integration should be able to capture them and populate the CMDB with new CI details. Once that happens, the corresponding asset records can also be created. Asset Management can then collect any missing asset-specific attributes, such as cost, financial owner and others, to complete its record.

Implemented integration or discovery will track changes in these virtual assets and update the CMDB. When that happens, the asset BOR can also be updated, if needed, depending on what attributes have changed.

Finally, when a virtual asset is decommissioned or dynamically deleted or spun down due to reduced workload, the integration will update its CI record in the CMDB, and the corresponding asset can be marked as decommissioned.

Configuration Management should take the leading role in maintaining asset and CI data in the virtualized and cloud environments.

In summary, Asset Management and Configuration Management processes and their corresponding Book of Records (i.e., Asset BOR and CMDB) must be tightly integrated so that they can exchange data with each other and deliver highly reliable asset/CI data.

From the people/organization perspective, I also believe that these teams should be consolidated into one so that it becomes a “single throat to choke” when it comes to asset/CMDB data quality governance.