Which CIs to load first in the CMDB

By ITIL® from Experience©

The first Configuration Items (CIs) to load should provide:

  • An approach to “divide and conquer”
  • A low hanging fruit with visible benefits, and
  • A showcase model for subsequent CIs to follow to “put the train on the right track”

Carving out a piece of the Configuration Management Database (CMDB) to divide and conquer can be done numerous ways. For example it can be done by:

  1. Group: The advantage of this approach is that in most organizations a CI Type1 is owned by one organizational group. It is also easier to coordinate training
  2. Location: The scope can be geographically or location based like a data center, building or floor of a building. The main disadvantage is that many groups usually need to be involved and they may not have the required level of maturity or discipline required
  3. CI Type: This is easy for I.T. to understand and track progress.
  4. Process or project: A low hanging fruit is often found by leveraging existing processes. For example, using lifecycle replacement (i.e. Evergreening) or by loading items as they are received from suppliers. Similarly projects deploying new technology can also be used to progressively populate the CMDB (e.g. wireless network, server virtualization, cloud).

However, simply loading records in the database does not necessarily make it a CMDB2 .

The challenges with most approaches are that: a) dependent CIs are not yet loaded to establish relationships and, b) that processes are not in place to manage and maintain these relationships. Take applications for example. Having all applications (Commercial-Off-The-Shelf, in house-developed) in the CMDB provides limited ability to assess risks and impacts of a change until relationships to the lower, infrastructure level CIs are present in the CMDB. Until this happens, the value of all this effort can be elusive.

Loading CIs by organizational groups, CI Types or by leveraging a process or project typically result in a horizontal or layered approach. This reinforces the issue mentioned in the previous paragraph. Nonetheless, all CIs of a layer do not need to be completed before moving to the next layer. For example, not all servers need to be loaded before starting to load application CIs. But this can easily make it overly complex for people to keep track and manage.

Loading all CIs by locations, system3 or service is taking a vertical approach or slice. This provides the most value and a show case of the ultimate goal. But, caution should be used since CIs from most if not all layers must to be present to enable relationships. This requires buy in from most IT groups and they may not all have the maturity level to manage their CIs to the standard required for the model to be maintained.

An alternative is to find the origin of the CMDB or in other words its “ground zero.” For most organizations the origin of their infrastructure is their core router(s) to the Internet. This usually offers a limited number of CIs to manage by a relatively small group of individuals. This limited scope makes it relatively easy to build solid procedures that can be used as a show case model for other groups and CIs to follow. Since these CIs are usually not changed, replaced or configured frequently it is simpler for people to buy in.

Moreover these CI’s provide the most value as everyone I.T. and the business relies on them for infrastructure and application availability.

Other CIs can then be loaded and brought under the control of Configuration Management by following relationships (i.e. dependencies). For example, the core routers are connected to the firewall and the DNS. Next, servers can be added travelling upward the layers towards business applications. (See Who is responsible for the CI relationships )

This approach can be compared to an inverted pyramid where ground zero is at the bottom. Combining approaches mentioned above will be required as one move up the pyramid.

Regardless of the approach used challenges abound. It is therefore imperative to make it easy for people to understand so that they can comply with the process.

Last updated on: 2015-04-12
Published on: 2013-12-09


More on Configuration Management

From Around the Web:

ITIL Process > Configuration Management


CI Type: (ITIL® Service Transition) A category that is used to classify configuration items. The CI type identifies the required attributes and relationships for a configuration record. Common CI types include hardware, document, user etc.
Source: ITIL® glossary and abbreviations, English, 2011,http://www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

2 Configuration Management Database: (ITIL® Service Transition) A database used to store configuration records throughout their lifecycle. The configuration management system maintains one or more configuration management databases, and each database stores attributes of configuration items, and relationships with other configuration items. Source: ITIL® glossary and abbreviations, English, 2011, http://www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

System: A number of related things that work together to achieve an overall objective. For example:

  • A computer system including hardware, software and applications
  • A management system, including the framework of policy, processes, functions, standards, guidelines and tools that are planned and managed together – for example, a quality management system
  • A database management system or operating system that includes many software modules which are designed to perform a set of related functions.

Source: ITIL® glossary and abbreviations, English, 2011, http://www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx


Copyright 2013-2018 - ITIL® from Experience - D.Matte