It began as a hardware asset when your company received the pre-shipping notice, and it will remain a hardware asset until it is disposed of. But your laptop is, if anything, a means for you to consume IT services, not to deliver them. As such it will never be managed by Configuration Management, and therefore, it will never be a CI. Thus, the expression, “Every CI is an Asset, but not every Asset is a CI”.

Why Things Go Wrong

If you want to set up a CMDB from scratch you need the technology, processes, governance, and people staffed to do it correctly. And the reality is, just like any technology initiative, they all cost money. Imagine a Venn diagram, where one side represents the assets in the CMDB, and the other represents the assets in the AMDB. Instead of these two databases overlapping slightly, the CMDB can often fit entirely ‘inside’ the AMDB. And while the data about an asset is different from one database to the other, the asset itself can exist in BOTH databases.

Lastly, we cannot forget about the Asset Lifecycle. The CMDB primarily concerns itself with active and managed assets – CIs by definition, while the ITAM Asset Lifecycle may begin in the planning phase or when the pre-shipping notice is received. Many clients want a ‘hand-off’ point, where ownership officially transfers to the CMDB group, and out of the hands of the ITAM team, and vice versa. But the reality is, the ITAM/HAM team will always have involvement with hardware assets. The hardware continues to exist in BOTH databases, throughout each respective lifecycle.

So  two databases, similar assets, and we know both are a challenge to setup. Is it any surprise that so many organizations just say “let’s put it all into the CMDB”?

How to Fix your CMDB

The only assets in the CMDB should be those that are subject to change management, incident management, or support a service.

And the key fields should be related to those functions, while the physical, contractual, and financial data should exist in the AMDB. Following this ensures that as long as the change management processes is adhered to, once an asset does becomes a CI, the data won’t go stale. Ignore this, and a few thousand CIs can quickly become tens of thousands, or even hundreds of thousands. So you need to ask yourself, does the cost of setting up a basic AMDB outweigh the cost of overly customizing your existing CMDB, the cost of bad CMDB data, and the cost of fixing the CMDB after it goes south?

The Case for Hardware Asset Management and CMDB

An end user might use the same laptop for two years without so much as a ‘cannot print…’ support ticket. But that laptop has software on it, which happens to be quite expensive, and it also may contain sensitive information that carries risk to the organization. Minimizing this risk, and improving the utilization of assets, is what we strive to do with ITAM. Where is the asset physically located? Is it being used? How much does it cost and is it being depreciated? Who owns it? Is the maintenance contract up to date? These are the questions keeping the ITAM professionals up at night.

At the same time, the CMDB answers its own equally important questions, and plays a critical role to the ITSM organization. While ITAM, with the exception of Software Asset Management, is not included the ITIL framework. We must also consider virtual machines, which by definition do not fit the HAM framework. This is where we rely on the CMDB to fill in the blanks. The AMDB simply cannot fit the role of the CMDB, and the CMDB cannot fit the role of the AMDB.

So if you’re looking to ‘fix’ your CMDB with Hardware Asset Management, you really just need to use both.