Setting-up a CMDB for Beginners

This is a follow-up to my earlier beginners Asset Management and Configuration post.

I described previously how it was difficult to keep an Asset register up to date – but keeping a CMDB up to date is harder because it holds more information.

Here’s the problem. In the previous post I mentioned some computers (Items) that ran enterprise-level services, and how we’d show them on a CMDB. Part of the information we’d store about each Item might include

Operating System (such as Win2003)

Major Patch Level (such as Service Pack One)

Configured network cards

…and so on. The problem is that this can change – for instance, Microsoft might release another major service pack, and an engineer takes this one evening and updates the server. So now something quite important in the information we hold is incorrect – even though the machine is sitting exactly where it was, doing exactly the same job. Anyone using this data for Incident management (or any other discipline) will now be working with incorrect data.

To spell it out, CMDBs are more of a problem to maintain because they hold more data.

Typically, Change Management is used to keep the CMDB up to date by having a specific stage or task within the Change process where the CMDB is brought back in line. Without an effective (and strictly observed) change process, you’ll struggle to maintain the integrity of your data.

Maintenance is only part of the issue. I described previously how the Asset register could be created by just ‘walking about’ recording what you see. With a Configuration Data Base, you have to understand how complex systems are constructed from parts that themselves might be complex – and then be able to represent that in a comprehensible and useful form.

So far, I’ve only talked about the challenges of creating and maintaining a CMDB, and said nothing of the advantages. There are many however, such as some objective information from which you can perform impact assessments for use in Change Management.

To sum up, what you do will be driven by the resources you have, what you are trying to achieve, and where you are right now in terms of your IT service management maturity.