Joining the 5% club – How to make a CMDB in the real world
The CMDB is rather like a unicorn. Everyone knows what they look like but no one has seen one for real. In fact, there is a term within the ITSM industry for the CMDB, the 5% club. That is that only 5% of organisations that set out to create a CMDB actually get the desired value from it.
Joining the 5% club – How to make a CMDB in the real world
I personally warn clients that the CMDB is the ‘graveyard of ITSM’ as most times it becomes a meta data dumping ground that quickly becomes the poster child for bureaucratic bloat and inefficiency: inaccurate, resented by those who have to keep it up to date, and used by only one or two people in the organisation.
So how do you avoid that fate? I have designed CMDBS for almost 10 years and run quite a few of them myself since I started my own ITSM career back in 1998 and have an approach that seems to work for me. I will be presenting on that approach on 8th June at 3.30 pm at SITS16 – The Service Desk & IT Support show at Olympia in London, but for now here are some of the major pitfalls to be aware of when building a CMDB.
Pitfall 1: Failing to identify the goals and requirements of a CMDB.
Firstly, you must remember, the CMDB (and its upgraded cousin the CMS) is a tool. Nothing more, nothing less. It’s a relational database designed to present relevant information to relevant people. An IT department asked to create a database would normally approach it by performing requirements analysis and creating use cases and so on. But time and again I see that this stage is skipped when people create a CMDB. The biggest, and most worrying phrase that I hear is ‘We just want it out of the box’. If you hear your management using that phrase, I will personal guarantee that you are already halfway towards failure. This is the big secret, there is no such thing as ‘out of the box’ for a CMDB. To suggest that there is means that you believe your infrastructure and requirements are the same layout and configuration as a banks, a university, a financial services firm, a law firm….
If you fail to properly define the goals and requirements for your CMDB you will be building a toolset with no clear idea of what you are building it for. How will you know when it’s done?
Pitfall 2: Turning your CMDB into a metadata dumping ground.
The CMDB cannot, and should not, manage every asset, document, or process throughout your entire enterprise. Your CMDB should contain only those CIs that you plan to actively manage. This is the most common mistake and normally means that you will end up with a bloated, inaccurate and unused mess, not a useful and relevant CMDB.
Pitfall 3: Ignoring the need for effective change management.
Without an effective change management process, a CMDB will soon be out of sync with reality. Avoiding this requirement will place the CMDB implementation on a downward spiral to failure. Don’t forget that even if your monitoring tools can tell you what you have, and where it is, you need to see the relationships too. Including ones such as ‘backs up’, ‘fails over from’ which no toolset can tell you.
Pitfall 4: Proceeding without buy-in from key stakeholders.
If key stakeholders are not involved from the beginning and if they don’t buy in to the true value that a CMDB can deliver, then the information gathering and relationship building is almost impossible. Don’t forget your building this toolset to be used by the staff in your IT department. Leaving them out of the design phase almost guarantees that they will not want to utilise what is forced onto them later on.
These pitfalls are by no means the complete list but it’s a start. If more organisations were aware of the most common pitfalls, and what to do about them, perhaps the 5% club would be a little larger?