Let’s take this back a step and just remind ourselves of what a Configuration Management Database (CMDB) is supposed to be. The CMDB was born in the days of ITIL v2 when Configuration Management was introduced as a formal process within the framework.
The goal of a CMDB is to provide a repository that can be deemed authoritative for all the things an organisation cares about, there are philosophical debates and discussions about what a ‘thing’ is but they are separate from what a CMDB is intended to accomplish. Normally a ‘thing’ would be a server, a piece of network equipment, Desktop PC or Laptop and even things like HVAC systems and in some cases, we’ve seen Laundry equipment and lightbulbs be stored there.
Whatever a customer wants to track, apply Change Management processes to or deems important enough to reference on an ongoing basis likely belongs in a CMDB.
Once defined the next step is to work out what information you actually want to hold about those things, the attributes of interest. Many CMDB tools will come with a prebuilt data model for this but that doesn’t mean you have to follow that data model in your situation. The normal guidance would be to adhere to the provided model and deviate only where you need to and I would go along with that approach. In fact, in previous lives, I’ve had many conversations with organisations around how to fit esoteric devices into the packaged data models and 99% of the time we’ve found a home with appropriate attributes provided out of the box, so don’t overthink how unique your requirements are as it might be they likely aren’t.
Only store what you need to meet the needs of your consumers, what do I mean by consumers? Well, think about how the data in your CMDB is going to be used within the business, what reports, processes or activities will make use of your CMDB data? These are what you are building the CMDB for, do NOT fall into the trap of ‘dumping everything into the CMDB’ and then ‘working out what you’ll use it for later’. All that happens is your data will build up, become stale and be deemed useless and die on the vine. Your CMDB WILL fail, and by fail I mean it will not be used for the purposes it was created, data will not be maintained, you will not find owners for the data held in it and thus it will be seen as a problem rather than a solution to business challenges.
Do not over promise. Building a CMDB is a significant undertaking and requires effort, quite a lot of effort to be fair, this effort is from all areas of the business not just IT or the Configuration Management team. Consumers have input, Configuration Managers are the control point, data providers also contribute significantly to the implementation. Everyone has their role to play and this alone makes the implementation of CMDB ‘hard.’
Critical to the success of building and maintaining your CMDB is a Configuration Management Policy. One of the key elements here is defining what ‘things’ are interesting enough to be stored in the CMDB, with this in place everyone has a common understanding of ‘if’ something should be in the CMDB and then expectations are managed and set appropriately. Of course, this is not a one-time definition and depending on your situation you will want to review the criteria of ‘interesting’ as and when you deem fit. Critically, do not leave this on the shelf, keep it alive, keep it refreshed and keep it relevant.
The key to CMDB success is truly being transparent, communicative and sharing the vision of what Configuration Management means to your organisation, the contribution it will make and the value it will bring. Never lose sight of the value!
This is the first in a set of blog posts we’ll be making on the topic of CMDB. In our next thrilling instalment, (I know you are all on the edge of your seats!) we’ll talk about managing the stakeholders, strategies for on boarding and also how do you look after, feed and water the beast you are creating and keep it happy so it can continue to provide the value your organisation is investing in.
That’s it for now!
Stephen Earl, Product Manager