We need a small-scale bite-size approach to populate the CMDB

By ITIL® from Experience©

A small-scale approach is to use a series of SMART1 objectives. This enables the implementation of a Configuration Management Database (CMDB) along with the processes and capabilities needed to maintain accuracy in small incremental steps.

This contrasts the approach of many projects that start by defining the CMDB structure based on CI Types2 . Then, requirements are gathered and a project plan is prepared. The problem is that an image found at the end of a rainbow is painted where the CMDB is a one stop shop for all IT data regardless of resources or capabilities of the organization. Given that many ITSM tools can also do IT Asset Management (ITAM) everything is thrown in but the kitchen sink. The CMDB becomes all things to all people and is doomed to fail as it is impossible to meet all expectations as the project tries to boil the ocean. Moreover, the CMDB becomes an end in itself and it is not driven by business needs.

Start by answering: What are we trying to achieve? Identify one specific business goal or pain point to address. For example, is the goal to improve an ITIL® support process (e.g. Change Management, Incident Management or Problem Management), to improve the management of critical CIs (e.g. core routers, firewalls, data center) or to properly manage a critical business service from end-to-end? Then, identify one or two SMART objectives to move towards that goal.

Loading data is relatively easy. However, it should be the last step. First, determine if the data is available in other systems or from infrastructure and operational management tools should not be replicated in the CMDB unless automated. This includes the number of CPUs, the amount of memory, disk space and IT asset information. Otherwise, duplication will result and accuracy will be a challenge unless the data is federated through automated interfaces (see Should we automatically import auto-discovered CIs in the CMDB).

Then, for every Configuration Item type to be loaded in the CMDB, identify an owner and a group responsible to maintain it. Second, it is imperative to add procedures to existing processes to create, maintain and retire CI (e.g. a trigger from Change Management, updates from Release and Deployment Management, or Service Request to provision a CI). Once these two steps are done, load the minimum information required to meet the immediate objective. Finally, repeat this cycle with a new SMART objective and only load the minimum information that can be controlled and managed to support an ITIL® process to meet a specific business objective.

The challenge of populating the CMDB with a series of SMART objectives, is that each objective may require the participation of an IT group which may not have the process maturity and capabilities of delivering on the objective. Thus, caution is in order to select an objective that solicits a group that is willing to be an early adopter with good discipline of executing processes.

Be careful with scope creep that leads to too much data being replicated in the CMDB with the statements such as "it would be nice if know this" as it is usually the kiss of death of CMDBs. Finally, it is important to remember that the CMDB is not a technical project to consolidate or replace all IT databases. The goal is not to take over the world! Like a carpenter's toolbox, IT has many tools for different purposes. What makes the CMDB unique is that it contains a reference of how items are related to each other — and that it has records of service events for those CIs (e.g. Incidents, problems, changes). Therefore, the CMDB may only contain a reference to 20% of all IT Assets.

Last updated on: 2016-01-29

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

Related: