Should we automatically import auto-discovered CIs in the CMDB

By ITIL® from Experience©

Populating and keeping the Configuration Management Database (CMDB) up to date can be a monumental task. Given that most ITSM tools can import configuration items (CI) from inventory and discovery tools, many organizations consider importing this data on a regular basis in their CMDB.

ITIL® says that “It is important that automatically collected data is compared to the desired1 configuration, rather than simply being recorded and accepted as correct.”2 This means that the import job should compare the discovered items against the authorized state, which in most cases is the CMDB. However, other methods can also be used. For example, some organizations compare their server configuration against the authorized “gold” or “official” image. Regardless, the data should first, be compared, then differences addressed before it is imported.

To be correct, the “import job” should in fact be called the “audit job” and generate a list of discrepancies. Then, people need to follow a process to address this list of data issues. Without this process, the results will be a CMDB that cannot be trusted due to its inaccuracy.

Many things can cause the CMDB to be out-of-synch with the live environment like:

Unauthorized changes3
Lack of integration with complimentary processes such as:
- IT Asset Management (ITAM)
- Decommissioning process (see How to ensure that applications and servers are decommissioned)
Discipline and controls to ensure that processes are followed

A common mistake is to expect the Configuration Manager to address these issues since he/she is responsible for the CMDB. The challenge is that it is very difficult for this person to resolve data issues someone else owns. The Configuration Manager is the custodian of the CMDB container, structure, format, standard the Configuration Management Process; not its content. The data belongs to each operational group. For this reason it is important to identify CI owners that are accountable for the quality of their data (see ((How many Configuration Librarian(s) do we need|How many Configuration Librarian(s) do we need))). This enables CI owners and Librarians to address discrepancies by: 1) investigating the cause of the disparity, 2) resolving the issue and to reconcile the CMDB record.

Simply importing discovered data is only looking at the technology part of the equation. To have a complete and sustainable solution people and process must also be considered. Thus, the following policy or business rule is recommended:

Every CI must have an owner and a maintenance process before it is loaded in the CMDB.

As we have seen automatically importing CIs in the CMDB has not been made its upkeep easier except to avoid manual data entry. For this reason, start with a small set of CI to bring under the control of Change Management and expand the scope of CIs under change and configuration control from there (see We need a strategy and roadmap to implement a CMDB).

Finally, yes; automatically import CIs in the CMDB when you have a process and people to address discrepancies, since ”you don’t want to rely upon Auto Discovery as your only means to manage the accuracy of the CMDB.”4

Last updated on: 2016-05-30

CMDB across the nation...you are littered with CIs that were loaded without a process to maintain or retire them.

More Quotes

Related: