where to start when building an efficient CMDB/CMS

This is the first in a series of posts on how to build and manage a CMDB database, which is an essential component of the success of the implementation of service management processes

A CMDB (Configuration Management Database) is seen as a key element in the efficiency of today’s IT organization, but the level of effort required for its setup and maintenance is seen by most people as quite intensive and complex.

The real issue with the CMDB/CMS is the fact you need to define which information is really needed, where it is located and the level of granularity to achieve.

Buying a tool seems to be the simplest way to create a CMDB, but if your configuration process is not defined (such as update rules, sources, Configuration Item (CI) granularity...) you won't be able to define your required configuration items and you will, in the best case, use the items defined in the solution, though you will likely have difficulty populating the attributes of each CI, as this will take quite a bit of effort and time.

a suggested approach

The first step will be to see with the other main process owners what their needs are around incident and change management. This will allow you to focus on the key elements required for these processes.

Using the information of both processes, you will be able to first identify which CI and attributes are the most subject to information search. You will also be able to locate which sources are required for each CI.

As an example, you could start with:

• a CI application with a couple of attributes such as the version, the editor, the support and the link to the server
• a CI server/virtual machine with a couple of details such as the the type, the firmware...and the link to the storage system
• a CI storage with its capacity and manufacturer information ...

Each time a new incident or change is created for one of these CI, the configuration management process should analyze the attributes involved and identify if it makes sense to add to them if they don't exist.

If an incident is detected, and it is related to a configuration item that is not defined in the CMDB, the configuration management process will analyze it, suggest possible relationships and add them to the CMDB using the change process.

If a change is required on a non-existing CI, a complementary change will be raised to add this new CI with its attributes to the CMDB.

to start...

For each service, focus first on CIs:

• that can be clearly identified
• that can be managed easily
• that can fall under the change management process

Once you have established this list, analyse how you will populate the CMDB with these CIs. Don’t forget to put in place audit and control tasks (for example – every month, review 5% of the CIs in the system and check their validity).

key success factors

• assign someone that is accountable for the data of each CI
• provide a unique identifier of the CI – be carefull with the naming convention to not be to much linked to an attribute that could change, while still allowing easy identification of a CI ( reference staring by App for the application)
• establish the main relationships
• audit the quality of the data

Once you have a first draft of your process, you can start to look at the solutions on the market, and keep in mind that configuration management process is a continuous and long-term process.

What’s your experience with creating a CMDB?