CMDB, Discovery and ITAM

The disciplines of IT Asset Management (ITAM) and ITIL Configuration Management share the need for reliable data about components in the IT environment. So it's natural to ask: can the same discovery tools (a scalable means of keeping accurate data on deployed IT components) and a CMDB (a repository for reconciling and accessing discovered data) serve both ITAM and Configuration Management?

While it is possible to use the same discovery tools to populate separate repositories (an asset repository for ITAM, a CMDB for Configuration Management), this would not only create redundant efforts and opportunity for data conflicts, it would also deny a golden opportunity to connect ITAM to other ITIL processes. Because there is a significant overlap between what you will deem worth tracking as CIs and as assets, you can benefit from a unified approach to IT component tracking, whereby objects in the CMDB can be managed as both CIs and assets — without duplication of investments and messy integrations between separate repositories.

In this case, IT Asset Management – just like Change, Incident and Capacity Management – can be just another process consuming and contributing data to the CMDB, creating value by taking actions based in part on CMDB data.

But as we have already seen, there is not 100 percent overlap between assets and CIs. And more importantly, different kinds of data must be related to the IT components depending on how they are being managed (e.g. costs and contracts for ITAM, relationships and configuration detail for ITIL). So the question arises, what data belongs in the CMDB?

First, you may free yourself from the daunting task and paralyzing thought of starting a CMDB implementation where every discoverable attribute of every component and relationship in your enterprise must be catalogued in the CMDB. To do so you will need to intelligently apply the following principle: Populate the CMDB with the minimum amount of data needed for maximum value. This requires that you start with a clear understanding of your business objectives, followed by an analysis of what processes need to interact with which data to achieve those objectives. So long as your CMDB is architected for growth over time in both breadth (number of CIs and relationships) and depth (attributes of CIs and relationships), you can make decisions incrementally on what CIs and assets to manage and at what level of detail, gradually adding more as your processes mature and expand.

For example, you may decide to start CMDB population based on an IT Asset Management project with desktops and servers, or your change management effort with only servers, or your service impact initiative with CI relationships within a single critical business application. As you become comfortable, based on real-world experience, with the level of CI attribute and relationship detail needed in the CMDB to support your core asset, change or service impact requirements, you can expand to more manage more assets, CIs and relationships at the appropriate level of detail.

To maintain CMDB scalability and focus on the IT production environment, assets not in the production environment (e.g. a network switch on order from a vendor, or toner cartridges in a stock room) need not be entered into the core CMDB. Until they are received or scheduled for deployment, these asset records can be stored in a logically (if not physically) separate asset repository, which should ideally share the CMDB’s data model to facilitate easy migration of asset inventory records to the production CMDB.