Afraid of the CMDB?

Have you ever been involved in setting up and maintaining a configuration management database (CMDB)?  If you have, you will know that the chances of success are slim.  With the help of an eager-beaver ITIL consultant you can improve the likelihood of failure to just about 100%.

Many companies never really manage to get their CMDB set up, others eventually give up as the data gets more and more out of date.  A few spend huge amounts to ensure that the data in their CMDB gets updated automatically only to drown in the complexity of maintaining all the integrations.  What makes it so hard?

When an organization decides to set up its CMDB to keep track of its hardware and software, they normally get a representative from each support team around the table.  There will be someone from the Network team and the Unix Servers team to ensure that they will be able to use the CMDB for the equipment that they are responsible for.  Typically, a consultant will guide them through the steps, so they start by deciding which assets should be registered in the CMDB.  The list will ultimately look something like this: PCs, servers, routers, monitors, printers, databases, software, etc.

The next step is to decide what information should be registered for each of these asset types.  That is a little harder, but the room is full of specialists who know the information they need.  So within minutes you know that for a PC it is good to know properties like: the amount of internal memory, disk space, processor type, number of USB ports, etc.  You will find out that there are useful things to know about PCs that you had never even heard of.  The same goes for the databases, routers and printers.

Now the organization knows how its CMDB should be set up.  A consultant will ensure that the different CI types that fall within the scope of the organization’s configuration management process can be registered.  A whole lot of fields are then added so ensure that all the attributes for these CI types can be entered.

During the next step, things get interesting.  Populating the CMDB with the organization’s CI information invariably turns out to be harder than anticipated.  When the specialists were asked which information they would like to have available in the CMDB they basically wanted everything.  That’s because they rely on this information.  When these same specialists are asked to put this information into the CMDB, there is less enthusiasm.  Suddenly they no longer see the value of the exercise.  That’s because they already have access to most of this information; they look it up in their system management tools.

“Ah, no problem!” says the consultant, “We can integrate the system management tools with your CMDB.” So more weeks pass and eventually everything is integrated and all the information from the system management tools is available in the IT service management (ITSM) application.

All this is wonderful, except for a few things.  First, the initial workshops to define the scope and detail are time-consuming.  Second, the customization of the CMDB is costly and so are the integrations.  This approach is simply not realistic for most organizations.  There has to be an easier way.

There is.  The trick is not to duplicate what is already in the system management tools.  Use the CMDB to focus on the information about the CIs that cannot be discovered automatically.  This can include information like the supplier from which the CI was acquired, the price that was paid for it, when its warranty will expire, which team is responsible for its support, what its physical location is, who is using it, etc.  Next, make sure that you include a link to the CI’s record in the system management tool.  This allows a specialist to access the CI’s current technical details with a click on the link.

The screenshot below shows an example of such a link in an ITRP configuration item record.

Using this approach eliminates the need for integrations.  It may be relatively easy to build such integrations, but when there are several tools in use to manage the Oracle databases, Unix servers, Cisco routers, network printers, etc., it quickly adds up and becomes impractical to maintain.

Better still, this allows organizations to start populating their CMDB right away, since there is no customization required.  It keeps things simple and cost-effective.