Fantastic CMDBs and How to Find Them
The book acts as a reference and guidebook for all the mythical creatures that you find in the Harry Potter world. It’s a textbook that is even referenced in the Harry Potter films as something the main characters must study.
But what has this got to do with IT asset management (ITAM), I hear you ask yourself as you read this blog?
Well, a good CMDB (configuration management database) is almost as rare as some of the creatures mentioned by Rowling in her book. I say "almost" because her creations don’t exist, but CMDBs do!
The problem with a CMDB is…
…that it is so easy to get wrong. Whether through human error, lack of attention, or even inventory tools being incorrectly configured, having rubbish data in your CMDB is a lot easier than having accurate data.
There are several common ITAM related problems within a CMDB that frustrates and upsets even the most seasoned ITAM professional:
- Assets with the incorrect status (active, stock, retired etc)
- Assets logged with the incorrect model/user/location/spec/CI
- Assets with the incorrect or relevant relationship mapping
- Software versions wrongly listed
- Lack of audit history due to the CI/asset not listed for incidents or tasks
We’ve already identified how this can happen, but the consequences of poor data within a CMDB are huge.
ITAM and configuration management’s stock within the organization declines because everyone knows they are sitting on bad data and subsequently making poor decisions.
This leads to no one being willing to follow the correct processes that includes the CMDB as they think: “What’s the point? It’s got rubbish data in there anyway. Us not following the process won’t make a bit of difference.”
It’s basically not worth the database it’s saved on or the pixels on your screen.
Getting It Right
Never fear, you can get it right! It may be hard to change historical references if you haven’t got the data (such as problems from an incident, previous licenses assigned, previous laptop names, etc.) but you can clean up some of the data and get it right moving forward.
From a hardware and mobile point of view, the following datasets will help you massively:
- Disposal certificates from your hardware disposal company
- Reporting on incidents, requests with asset references (such as asset tag or serial number)
- Procurement records to validate models, purchase date, support levels and warranty expiry dates
- Updated inventory reports from your ITAM tools to identify associated users and their assets
- If you’re concerned that the serial numbers do not match the models listed, ask the vendor or your reseller to confirm
This takes a lot of time and data crunching and unfortunately, there is no way of getting around it. Some CMDBs may be in such a state of disrepair that it is easier and quicker to take a snapshot of the existing CMDB and completely start again.
In order to do this, you need to make sure that your integration with the inventory tools you’re going to use to populate the new CMDB are accurate, working correctly, and populating the fields you require.
It’s also important that you map the correct asset to CI (configuration item) relationship. For infrastructure assets, the assets' relationship with key services, offices or other assets that will help in the event of a major incident or request for data.
You also need to make sure you have the processes in place to ensure the CMDB is maintained correctly. This includes things like making sure that ITAM is on the CAB (change advisory board), that you have asset and CI ownership assigned, and that your incident, request, problem ITIL processes includes an action to update the CMDB.
The problem with a bad CMDB is you fundamentally need an accurate CMDB to deliver ITAM as robustly as you can. Whilst fixing it will take time and a lot of manpower, it is worth it in the long run, and you’ll wonder how you survived without such a brilliant CMDB!
The Holy Grail
Ultimately—and I think you’ve heard this before—the CMDB should be your central source of truth for your IT estate. It needs to be your IT warehouse, providing you with the ability to paint an accurate picture of your IT estate and how it is all linked together, as well as the ability to report on what IT assets are where and who they are being used by.
The Holy Grail (being a trustworthy and accurate CMDB) is a rarity and has taken the organization a long time to get right with many mistakes and bad data instances along the way. To achieve a trustworthy CMDB, organizations have:
- Multiple inventory sources populating IT and software assets to create and enrich data
- Defined, published, and followed processes for updating data and ensuring ownership and accountability for teams’ assets
- ITIL processes followed to allow for better asset lifecycle management (change management and the service desk ensuring they link the right CIs and assets to incidents and requests)
- Regular self-audits to verify the data accuracy within the CMDB for IT assets and their relationships (including audit reports on percentage accuracies and risks)
- A good technology for automation
Having seen several CMDBs in different formats and technologies over the past ten years, I really feel that the last point plays a pivotal role in having a Holy Grail CMDB. I’ve witnessed CMDBs trying to be maintained manually via spreadsheets, Visio diagrams and free tooling, right the way through to a full CMDB technology with integration with various inventory sources and automated processes.
Now, the Visio and free tooling option happened to be one of the best CMDBs I’ve seen—but that was thanks to the configuration manager (Mr. Paul Fyles) who owned it. That organization got lucky in that they had a CMDB guru in place, but it took so much time and effort to maintain.
Organizations that have a technology in place for a CMDB but don’t maintain it properly are more middle of the road. They get by with what they have and make decisions based on the data. It’s common knowledge that the “CMDB isn’t updated or valid, so our report on laptops and their users may not be accurate…”
This doesn’t evoke trust or reliability and in some cases it’s better to just start again. I’ve found it harder to try and fix wholesale data issues within a CMDB that starting one from scratch.
The CMDB Holy Grail, on the other hand, is extremely trustworthy and requires far less administration and human input.
Maintaining the Holy Grail
Once you’ve achieved a trustworthy CMDB, the work doesn’t stop there; you need to ensure the data quality remains high and accurate. There is no point in spending all that time and effort winning the trust of your customers and stakeholders only to neglect your CMDB and let it fall into a state of disarray.
By automating the process around data enrichment and populating removes a lot of the human touch points, as mentioned previously, but it doesn’t mean the technologies will always be 100% accurate.
Regular audits and reviews of your CMDB are an absolute must along with re-affirming your key processes that involves a CMDB such as the change management process and ensuring your service desk and end user computing (EUC) staff are associating the correct asset or CI to a request or incident.
So, we are all in agreement that CMDBs take a lot of love and attention to get right, but when you do get it right, they become a hugely valuable asset to your organization.
Circling back to the first part of this blog we mentioned a Harry Potter book that finds rare creatures within the world created by J.K. Rowling. There are professionals who have experienced bad CMDBs that would claim that you are far more likely to find a Chinese Fireball Dragon than a CMDB you can use and rely on.
And to those people I say, “Have the faith!” Awesome CMDBs are out there and you can even turn your dud CMDB into the Holy Grail you so crave.