The Configuration Management Database (CMDB) is a much-discussed and often-feared ITIL database designed to support IT Service Management practices. They’ve gained a bad reputation over the years, in no small part due to the now infamous statistic from Gartner claiming that 80 percent of CMDB projects add no value to the business!
However, a recent Forrester report emphasized the benefits of a CMDB in providing high-quality services and support, and the economic benefits this yields for a business. So it’s imperative we find a way to increase the efficacy of configuration management – and these seven steps are a great place to start.
It’s often cheaper to build a CMDB than it is to face a major incident without critical configuration data. And cheaper than the fallout of a scheduled change with unexpected costs. And cheaper than failing an audit because information is spread across 15 different spreadsheets.
With increasing migration to the cloud, CMDBs may no longer need to store the specific network card installed in an on-prem host, but they have key applications in modern IT environments. They track cloud services and monitor spend; detail the services you run and their dependencies for better incident and change management; help manage asset lifecycles; and much more. And with enterprise service management on the rise, there’s an increasing requirement that IT and non-IT items be managed together.
So CMDBs are here to stay, especially in ITIL-influenced ITSM practices. How do we make sure they’re successful? Those of us working with Insight (a configuration and asset management tool for Jira Service Management that’s centered on a CMDB) have seen success for far more than 20 percent of our customers. Here, we’ll share the best real-world takeaways we’ve garnered over the years by talking to our users.
Let’s start with the basics:
What is a CMDB?
Creating a CMDB can be quite nebulous, and it’s hard to know which sources to trust. Which advice is still relevant? What should you put in it? Some say everything, some say only certain items – the mixed messaging is a major blocker for many ITIL professionals.
A CMDB is an asset management repository that stores the details and configuration of various assets and configuration items (CIs). The difference between an asset and a CI, and how to determine which assets go in your database, are beyond the scope of this blog. And, really, there’s no right or wrong answer; anything can be added to your database, and the right decision depends on your organization’s needs and the CMDB software you use.
For simplicity’s sake, here we’ll refer to all CI types as “assets,” which refer to anything your organization needs to understand in detail in order to provide a high level of support – things like service assets, hosts, business services, software, employees, and facilities equipment. We’ll focus on ITIL use cases here, but the same advice applies to CMDB implementation for an enterprise service management system.
Many of these assets will have dependencies on one another. A CMDB lets you map out these relationships, so you get a better understanding of your systems’ current operating parameters and can make better decisions about incident management, change management, service requests, and hardware and software purchases.
If you’re interested in a CMDB to support your ITSM practices, consider these seven tips to maximize your chances of success.
Start with a specific problem
Most tools are implemented to solve a problem, and CMDBs are no exception. It could be that your incident resolution time isn’t as fast as you’d like, or perhaps changes to a specific service often cause unexpected outcomes because you can’t easily see service dependencies.
Find your problem and use that to define everything else, from who you involve to what assets and information you include in your database. Trying to do too much at once is a common source of failure for configuration management projects, so keeping a defined scope is key. Once your first problem is solved, the CMDB can grow to solve other problems.
Choose a flexible CMDB
Flexibility is your best friend when it comes to CMDBs. Being able to quickly add new asset types or add a new attribute to an existing set of assets is vital when IT infrastructure is changing faster than ever.
Find a CMDB tool that is designed for scalability and lets you define your own data structure, asset types, and attribute information so you can design a repository that meets your organization’s specific needs.
Another feature to consider is the ability to have multiple CMDBs that can share information with each other. This gives you the flexibility to split your data into different chunks in a way that makes sense for you. For example, you could split asset information by owner, so each team has just one mini-CMDB they keep up to date. But if dependency relationships can be made between different stores of data, you can build that critical high-level infrastructure map.
Start with your services
Figuring out what to include in your CMDB is tricky. Too little data and it won’t provide the additional value you hoped it would. Too much, and you’ll be looking for the proverbial needle in a haystack.
We recommend starting with the services related to the problem you’re trying to solve. Services are well defined, and it’s relatively simple to start adding the various assets they depend on to run, and, in turn, the assets that those assets depend on, and so on. Eventually, you’ll build up a complete picture of each relevant service and its dependencies.
This gives a defined set of assets to start with. You can then add other assets as needed, when new problems arise. We think it’s best practice to build your CMDB bit by bit, as it’s much easier to confirm the accuracy of small chunks of data as they’re added.
Consider what you don’t want to include in your CMDB
One of the configuration management challenges people face is over-scoping their CMDB and trying to include far too much data. Configuration Management Databases have often been referred to as a “single source of truth,” a phrase that may have done more harm than good. Often, people take it to mean they should put everything into their database, which can cause significant trouble in finding the initial data, maintaining data accuracy, and accessing the asset information you want when you need it.
Instead, think of it more as a “single pane of glass” for the data that you want to be able to access easily. Each piece of data you include should serve a purpose for your ITSM practices, and if it doesn’t, into the scrap pile it goes. You can always add more data later, but it’s often difficult to remove data “just in case” it’s needed in the future.
Our most essential piece of advice for anyone building a CMDB is to choose what you include very carefully. Be ruthless with what you do and don’t include, and again, start small.
Don’t reinvent the wheel
We mentioned earlier that a CMDB should give you visibility into all the data required for your ITSM applications. But that doesn’t mean that everything should be maintained within the database itself. A software license managing tool is almost certainly going to do a better job of managing licenses, but it could also give you a lot of useful information for solving your starting problem. That tool is already being updated, so there’s no sense in disrupting that workflow.
Instead, federate. Bring in asset information from existing databases, but maintain them in the original database and send updates to the CMDB. CMDB vendors offer all kinds of integrations with third-party tools to help with data federation. For example, it’s common to use integrations to bring in information from cloud services. The data is all maintained in the cloud service, but the integration can run on a schedule to bring in updated information that can then be used for your ITSM processes.
Sometimes it does make sense to import data into the CMDB and maintain it there. If you’re managing asset information in spreadsheets, they’re a prime candidate for migrating to the CMDB. Or if you want to reduce costs, it may make sense to bring data in from another third-party service so you can retire it.
Automate!
Many CMDBs come with the ability to automate content updates. Keeping your asset information accurate is a critical task, but it can be time-consuming. So it makes sense to automate as much as possible.
Most CMDBs offer network discovery tools that can run on a schedule, finding new connected assets and updating existing assets with any changes. Some attributes may still need to be updated manually (e.g. the owner of an asset), but these attributes are likely to be updated much less frequently.
Having automations and a CMDB that integrates with your service desk helps with these more manual changes too. As issues come in and progress, they can communicate updates automatically to the CMDB, which is much better than relying on an agent to remember to manually update one laptop as being broken and another as being newly assigned to a user.
Finally, automation rules can be set to standardize asset information. For example, the names of laptops could be standardized to “[vendor] [model] – [serial number].” Standardized attributes make it easier to keep your database tidy, searchable, and accurate.
By taking an iterative approach to building a CMDB, you can create automation rules at each iteration, making it easier to implement them. Building all the rules in one go for a huge CMDB is a massive undertaking – we recommend avoiding it.
100 percent accuracy is the goal, but not a requirement
Of course, we all want our CMDBs to be 100 percent accurate, and we should definitely strive for that. Realistically, we may only achieve, say, 96 percent accuracy – and that’s okay. CMDBs follow the law of diminishing returns, so that extra 4 percent, while nice to have, is probably not worth the effort.
Many CMDB projects fail when organizations decide anything less than perfect won’t do. They spend a long time, sometimes years, trying to make it perfect, draining resources and enthusiasm for the project in the process.
Take advantage of what is accurate and does work, and when you find inaccuracies, set up corrective actions.
So there you have it! Our top pieces of advice to avoid the perils of a poorly implemented Configuration Management Database. These tips will help you build your database correctly.
7 ways to avoid CMDB failure
– Define a problem and communicate the solution and project early with stakeholders and contributors.
– Use a flexible CMDB tool.
– Start by mapping your services, and let them define the assets you need to include.
– Choose your data carefully, and cut anything you don’t need.
– Use what you already have available whenever possible.
– Automate to maintain accuracy.
– Aim for complete accuracy, but not at the cost of paralyzing the entire effort.
Implementing these tips will help ensure you get value out of your CMDB as quickly as possible. If you use the Jira platform, you can access a free trial of Insight, a Jira-native, flexible CMDB that provides asset information directly into your Jira issues to boost efficiency and reduce mean time to resolution.