If you're here, chances are you're planning to implement or improve a configuration management database (CMDB) and are looking for some advice. You've come to the right place!
As you likely know, CMDBs can be tricky. When implemented well, they are invaluable for IT teams. A single place to view everything involved in running your services and all the relationships and dependencies is excellent for forward planning, solving incidents, change management, and more.
Need to fix a server? You can easily see which services/applications will be affected. Need to install new security software on all Linux servers? You can get a complete list from the CDMB plus extra information like if they are a production environment or not so you can plan accordingly.
But CMDBs are also time-consuming to build and maintain; there is no sense in pretending otherwise. However, approach your CMDB with careful consideration, and they become far more manageable. From our experience working with IT teams and helping them build CMDBs, we've collected ten best practices to help you run a successful CMDB project.
- Understand why CMDBs fail
- Don't get caught up in terminology
- Be aware that your company is unique
- Start small and increment
- Communicate your scope clearly and early
- Choose a CMDB platform that supports your needs
- Think of your CMDB as a process
- Automate, automate, and then automate some more
- Get your team onboard
- Share value as soon as possible and as often as possible
1. Understand why CMDBs fail
You may have heard the old statistic that 85% of CMDB projects end in failure. We believe the real number is likely lower now as the industry has become more careful when implementing CMDBs, but still, projects do fail. By understand why they fail, you can avoid your project falling into the same traps.
The most common reasons CMDBs fail, in our experience, are:
-
Trying to be too complex too soon
-
Underestimating time and cost
-
Things changing too fast with no process to handle changing data
-
Management doesn't understand the value and pulls the project
We will share advice to avoid these situations further below.
2. Don't get caught up in terminology
CMDBs store configuration items or CIs. But what is a CI exactly? There is a lot of discussion about what are assets versus CIs and asset management versus configuration management. But the truth is, it doesn't matter all that much what you call them. What matters is you have an object you want to track (physical or virtual) along with data about the object and its relationships with other objects.
Whether you store some attributes about the object that are technically asset management data in the database you call a CMDB doesn't affect how valuable that information is to your team. So our advice is to focus on what you need to know about your CIs/assets/objects/things to do your job more effectively, not the official terminology.
A small side note on terminology that does matter: a discovery tool is not the same as a CMDB, which is a surprisingly common misconception. Lansweeper, for example, can find assets/CIs and create relationships between them, but it is not a CMDB. It focuses on cataloguing your equipment, but you can't bring in your own CIs or build as complex, custom relationships as you can in a CMDB platform.
Discovery tools are ideal for populating your CMDB rather than acting as a CMDB themselves.
3. Be aware that your company is unique
There is a big difference between a small or medium-sized company with a few hundred or thousand CIs and a Fortune 500 company with millions of CIs spread across the globe. What you read in blogs and on forums may not be relevant to your company.
A complete, perfectly ITIL-aligned CMDB is almost certainly far too much for a smaller company so don't strive for this. But having some extra information about what your services depend on and how your equipment is configured can be very helpful.
However, a large enterprise likely has the resources and budget to implement a more robust CMDB. It will feel the benefit more than a small company, as even a tiny increase in the IT team's efficiency can have significant impact on the business due to its scale. For example, when managing incidents that impact global customers (like Crowdstrike or Meta have needed to do), a 15-minute shorter resolution can save millions of dollars.
4. Start small and increment
Avoiding scope creep is hard. When people get excited about the potential of a CMDB, it's easy to try to do everything. But this is a huge source of failure. Start with one area where a problem will be fixed by a CMDB—be it laptops, communication devices, or business-critical services—and go from there.
Only add the CIs (and related or dependent CIs) that you need. You can always add the 'nice to have's later. By ensuring you have a specific need for your CIs, it will be clearer what metadata you need to store about your CIs too, which helps you avoid having too many fields that are difficult to populate.
Once you have conquered one area, you can move on to another.
5. Communicate your scope clearly and early
Ensure you communicate the timelines, starting scope, and any planned future iterations to your team and stakeholders early. This will help with:
- Setting expectations with management so they don’t get nervous when your CMDB doesn't contain everything three months later
- Help you plan your project resources and get the budget approvals you need
- Alert your colleagues that a change is coming that may require them to alter their behaviour (more on this in a moment)
6. Choose a CMDB platform that supports your needs
Once you know what you want to store in your CMDB, and its use cases, you can look for a suitable platform. At this point, it's good to consider the future of your CMDB so you can choose a platform that will scale with you to avoid painful migrations later. We also recommend considering how your CMDB plugs into other platforms and any existing ITSM practices.
Some things to consider at this point are whether you want to only store configuration data or do you want asset management information too? Do you want to build a service catalogue and link them to your CIs in the same tool?
Do you already have a service desk or ticketing system? If so, do you plan to continue using it, in which case do you want to build a way to link your CIs to your incidents, changes, requests, etc.? Or are you open to a combined CMDB and service desk/ticketing platform?
And what about the data types you want to store on your CIs? Do you only need structured data, or would unstructured data like images or PDFs be helpful to store too?
Your platform choice will be impacted by your answers to all of these questions. We recommend considering something flexible and scalable so you can start small and add more capabilities as you go.
7. Think of your CMDB as a process
Building a CMDB is reasonably straightforward. Keeping it up to date is much more complicated and a significant source of CMDB frustration, as well as why projects get scrapped. IT professionals who have succeeded with CMDBs reinforce the idea that CMDBs should be thought of as a process, not a database.
While building your CMDB, you must focus on developing processes and assigning responsibilities with your colleagues to help keep it updated.
The moment data becomes inaccurate you risk making incorrect decisions and can erode trust with colleagues using the CMDB. So we cannot overstate enough the importance of building the processes during implementation, not as an afterthought.
8. Automate, automate, and then automate some more
When we say assign people to be responsible for keeping various parts of the CMDB updated, we don't mean manually. Much of the changes to CIs can be reflected automatically in your CMDB, via a combination of APIs, pre-built integrations between tools, scheduled runs of discovery tools, and the automation features of most CMDB tools.
As with the scope of the entire CMDB, start small with automations and prioritise those for CIs that change often and are hard to do manually. Over time, automations should build up so that the CMDB is almost entirely automated, which will improve the accuracy as any changes can be reflected very quickly.
9. Get your team onboard
Without people supporting you and your CMDB, it is at risk. You need people willing to commit to keeping the CMDB updated. However, some people prefer to avoid change and may be happy updating their isolated spreadsheets as they always have. They may even feel threatened by a new tool taking on ‘their work’.
To help with this, we recommend offering lots of training and reassurance that the CMDB will be valuable for the whole team and communicating exactly how it will make people's lives easier. This is also why we recommend communicating the scope of your CMDB early to get people prepared.
There are many digital transformation resources on how to cope with the people side of things. Some IT teams we've spoken to have even enlisted the help of senior management and had 'maintain CMDB data accuracy' added to the team's annual goals to stress how big a focus it should be for relevant team members.
10. Share value as soon as possible and as often as possible
To help maintain enthusiasm for the CMDB, keep management invested, and secure your budget for future iterations, as soon as you have a success, share it! And share as many as you can until the CMDB is considered critical to your team's efficiency.
Success could be in the form of time saved during a routine change. Or anecdotal feedback from colleagues on how much simpler it was to solve an incident with the data from the CMDB. You have a reason for implementing a CMDB, so comparing before and after is a good approach too.
Summary
There you have it, our top 10 best practices for CMDB victory as learnt from working with IT teams to implement various ITSM practices. We hope you now have some new advice that will make your project a resounding success.
About Starhive
Starhive is a revolutionary data management platform that lets users define whatever type of database they want, including a CMDB. Built by a team with a long history in the ITSM world, it has a uniquely flexible data model so you can track and manage exactly what you need in a way that makes sense for your business.
Complete with ticketing, asset management, service cataloguing, and ITOM capabilities, it can scale from a small CMDB to a full ITSM solution.
