roadmap cmdb configuration management maturity itil

We need a strategy and roadmap to implement a CMDB

By ITIL® from Experience©

This Configuration Management Database (CMDB) implementation roadmap proposes 5 stages. It enables the organization to build their capabilities1 to maintain and sustain a CMDB. Each stage is a building block to the next and provides immediate value.

Another advantage of this approach is each IT group can move at their own pace through these stages. Moreover, at each stage one group usually emerges as an early adopter who wants to mature their capabilities and willingly want to move to the next stage. Thus, focusing on early adopters avoids the common mistake of simply loading Configuration Items because it can be done. This roadmap enables the organization to eat the CMDB elephant one bite a at at time and avoids trying to boil the ocean (see What are the top 10 mistakes when building a CMDB).

Stage 1: Initiation by recording against generic CIs

At this stage, incidents, service requests, problems and Request for Changes (RFC) are logged against a generic Configuration Item (CI) such as a router, a server or an application. LittleConfiguration Management work and CI definition is required for this stage. Only one CI without any attributes is needed for each CI type2 . A very basic CMDB structure needs to be put in place which will be refined in the next stage.

The value of this stage is that the organization is now able to report on the number of incidents caused by the network versus the applications. It also helps to raise awareness for the need of a CMDB and discovers early adopters that are eager for the next stage. Finally, it gets people into the discipline of following simple procedures (see Why is the CMDB inaccurate).

Stage 2: The CMDB Structure

The goal of this stage is to provide more granular reporting and management capabilities to the early adopters by properly designing their CMDB structure for the CIs they are responsible for. The basic CMDB structure from the earlier stage is replaced by a classification hierarchy or in other words a taxonomy3 . For example, the CMDB structure can be based on how the CI is used like, core router, DB server, Business Applications followed by more specific classifications based on the model or type (e.g. CISCO 1500, CISCO 2500, UNIX or Windows Server, Finance Applications) (See Is there a standard we can use for the CMDB structure).

Even though specific CIs are not loaded at this stage, it is important to determine the CI naming conventions for the CI Types being worked on since it influences the CMDB structure and vice versa. For example, a server name can be WIN123456 or 123456 in the WIN branch of the CMDB.

Caution is needed to ensure that this stage does not become a quest to answer “What do you want to report on" as it will cause the premature use of CI attributes before the organization understands its requirements. Which, typically results in using too many attributes without considering the effort needed to manage them vs the value of doing so (see Should each software version be a separate CI –or- should it be an attribute of the CI.

Stage 3: Process to record against specific CIs

At this stage CI owners replace their generic CI Types with their specific configuration items. Thus, a process is required to add them to the CMDB. Roles and responsibilities of the process owner, the CI owner and the Configuration Librarian must be addressed at this stage (see How many Configuration Librarian(s) do we need).

Given that many IT groups will already have CI and IT Asset information in other tools (e.g. database, spreadsheets) each CI owners need to answer the following:

Do we maintain more than one source of data for our CIs or take the opportunity to consolidate and retire data sources/tools in favor of a centralized CMDB?
In absence of consolidation, will the CIs be manually be inputted in the CMDB (i.e. a step in a process) or do we need an interface between data sources/tools resulting in federating data?

The centralization or federation is not an "all or nothing" approach to the CMDB. Each CI owner can decide the best approach to meet their needs. Regardless of the approach, and especially if CI data is replicated (i.e. federated), processes are required to ensure data accuracy between systems and in relation to the live environment. It is recommended that each data source to be centralized should be considered a project on its own! (see Should we automatically import auto-discovered CIs in the CMDB.

Another key question CI Owners must answer is: Will the CMDB also be used to manage assets or strictly be used for impact analysis? This helps determine when in its lifecycle the CI should be added to the CMDB as illustrated in the following diagram4 .

Configuration Management status within the asset lifecycle

Automated interfaces with discovery tools might be considered here, although most organizations should first refine their processes before considering automation (see Should we automatically import auto-discovered CIs in the CMDB). The same goes with CI attributes; they should be limited until the group who owns them matures its processes and capabilities to manage them to that level of granularity.

Stage 4: CI Attributes and Relationships

The first task at this stage is to decide if the organization needs to mature its IT Asset Management (ITAM) practice or needs to focus on Configuration Management. This clarifies the scope of the work going forward.

The second task is to prepare a work plan to support the ITIL® processes implemented to date. It is important to focus on the current process needs. This helps to avoid: 1) building a CMDB for the sake of having a CMDB and, 2) having people create a wish list of 'things' they want, like a child in a toy store! Remember that there is a cost to manage each attribute throughout the CI's lifecycle (see Why asking what you want to report on is the wrong way to implement a tool.

An owner for each attribute should also be identified so that data quality and discrepancy issues can be addressed. For relationships, the article “Who is responsible for the CI relationships” can help in determining the right approach.

Stage 5: Automate and audits – Deal with data quality issues found by automation

Needless to say that interfaces between the CMDB and other systems is "technology." However, without people properly trained and with processes to address discrepancies between these sources the CMDB will quickly become inaccurate. Management must also establish how it will deal with unauthorized changes. Audits should also be considered to identify data quality, process and discipline issues (see Should RFCs be logged when an undocumented or unauthorized change is discovered.

Conclusion

Given that some IT groups will be progressing faster than others through these stages the CMDB should be considered a program5 with a series of projects who’s aim are to advance each IT group's CI management practices according to their capabilities and maturity.

Last updated on: 2018-02-27
Published on: 2013-09-06

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

More Quotes

Related:

Page actions