The CMDB. Often discussed and often misunderstood. What does CMDB mean? How can it help me? What can I use it for? How does it fit into ITSM and ITIL? And ITAM for that matter? How do I build one successfully? And so on.
These are the common questions we're going to answer today. We'll cover the basics of CMDBs including what they are and how they work. Then we'll take a look at how they interlink with ITSM and ITAM processes and explore other use cases outside of the pure IT world such as HR and facilities management. We'll end by offering our top pieces of advice for building your own CMDB from our many years of experience working with our customers.
While our experience is with CMDBs in the Jira environment, what we'll discuss today is relevant to other CMDBs too and we'll keep it very general. So let's dive in.
Jump to a specific section
What is a CMDB?
A CMDB, or Configuration Management Database, is a tool that stores the current operating state of various objects (also known as configuration items or assets) and the relationships between them. This gives you a complete overview of specific areas of your business for faster decision making. You can also use CMDBs to make fixing any problems that may occur much easier through a deep understanding of the dependencies between your objects.
CMDBs were developed as part of the ITIL process for ITSM applications. This means that traditionally they have been used to store information about IT equipment to support service, incident, change, and problem management etc.
But CMDBs can be used to store anything you find useful to understand, such as vendors, facilities equipment, and even staff members. There's no set rules for what should and shouldn't be included in a CMDB. That's up to you and is defined by the particular use case(s) that you are working with (more on those later).
Each object within the CMDB can have certain attributes that explain how the item is configured. For a server that could be the manufacturer, the OS, and the installed RAM. For a staff member it could be their job role, location and their manager.
The other key element of a CMDB is the dependencies between your objects. Understanding the details of a business service is useful for solving an issue specific to that service. But when the problem with the business service is just a symptom of a deeper server problem, it's much more beneficial if you can instantly see what server is running that service, the owner of that server, and what other services run on that same server for quick troubleshooting.
In a CMDB you can define the relationships between your objects. So instead of saying a computer is configured with a specific OS, the OS can be its own object defined in your CMDB that is linked to all of the computers that run that OS. If you need to update the OS's attributes, now you only need to do it in one place.
With your employees you can link them to the specific equipment they use. Then, when they send a service request in, you can see what equipment they have been assigned and close the ticket faster than if you need to do some back and forth getting specific specs from them or searching for the information manually.
With a CMDB you've eliminated the need to trawl through many different spreadsheets to find out who is using what, what devices are where, and what depends on a specific object or objects to work correctly. While getting data into the CMDB can be a little tricky, the time saved in future is well worth the effort and there's tools that can help you bring in data such as network scanners and importers which we will cover in the final section of this blog.
How can a CMDB help you and your organization?
We often hear that people know what CMDBs are, but not how or why you would use them. The benefits are often unclear as the CMDB has evolved over many years to what we see today. Here we will highlight the most common use cases and how they help streamline various processes. We'll focus on IT specific applications before looking at a couple of other areas. But first, we have a key question to answer.
Can I use a CMDB for asset management?
One of the most common questions, and a source of much confusion regarding CMDBs, is how they fit in with IT asset management. ITAM also requires a central repository of IT objects but traditional attributes for ITAM repositories and CMDBs have been quite different as they've had different purposes.
While CMDBs were historically more focused on the current configuration and relationships of assets, ITAM databases store more static information, such as purchase date, service contracts, cost etc.
The aim of ITAM is to manage the lifecycle of an asset and ensure it's not costing the company more than it should. It focuses more on the financial and legal aspects of an asset which is why there's usually a value threshold for an asset to be counted as an 'official asset' in an ITAM repository. A CMDB on the other hand, has no such threshold, an asset is an asset whatever it costs.
This has been fine for ITAM for a long time but there's a few questions that are difficult to answer with a pure ITAM system. For example 'am I paying too much for my software license?'. An ITAM database will give you the license size and cost but probably not much else, and definitely very little on where it's being used.
This is where CMDBs can help. If you document relationships between software and computers (or teams perhaps) you can get an idea of the number of licenses being used. Every time a service request comes in to install the software in question you get more information that can be registered in the CMDB and you can answer our hypothetical question with a lot more accuracy than you could before. You can even use a network scanner that integrates with your CMDB for very up to date, accurate information.
Because of questions around asset usage optimization, modern CMDB tools are usually able to be ITAM systems too. Meaning that if you want, you can store your assets and the required information for the finance, purchasing, and legal teams in the same place as your configuration information.
Many CMDBs offer integration tools to import or link ITAM information. For example, contracts stored elsewhere can be linked to assets in the CMDB. In fact, many CMDB vendors allow many different data types, including files as attributes so you could even store your contracts directly in the tool.
So to answer the question 'can a CMDB be used for ITAM?', the answer is yes. It's doable with most modern CMDB tools (so make sure to check with the vendor) and it can save you a lot of time and effort by having one repository for your assets and not having to switch between tools or spend time updating multiple systems.
It's up to you to decide how far you go. It's perfectly acceptable to have two separate systems but keep in mind if you're storing details about the same assets in two different locations you're increasing the risk of errors. For example, if an asset's name changes and only gets updated in one system you've lost your link. You need to have some type of communication between the two systems for this approach to work well.
How can I use CMDBs for ITSM?
The widest used and most discussed application for CMDBs is for various aspects of ITSM. The CMDB was introduced as part of the ITIL framework and has been embedded into the best practices for incident, change and problem management for a long time. We'll take a quick look at each of these areas.
1. Incident Management
Your email service is down. Panicked tickets start pouring in and IT needs to get it back up fast. With a CMDB, in just a few clicks you can see which server is responsible for the email service, who is responsible for that hardware, and even its ticket history. Because many CMDBs come with an issue management service or integrate into an existing one (e.g. Mindville's Insight CMDB integrates with Jira) the ticket history is available.
Perhaps there was a recent change that has caused this outage. CMDBs let you see object history and system relationships so when something goes wrong you can easily find what needs to be fixed, reducing the money lost from extended downtime.
2. Problem Management
Solving a problem before it becomes a problem is going to be significantly cheaper and easier. But how do you find them? Usually larger problems have symptoms, for example a set of assets could be having repeat minor incidents indicative of a deeper problem.
By understanding the relationships and the history of all your assets you can find the root cause of underlying problems and fix them before they become major. Many CMDB tools have automation rules that can be triggered based on some set criteria (such as too many incident tickets in a short time period) to flag up potential problems.
3. Change Management
There's always changes that need to be made to IT infrastructure and services. It could be because of a planned upgrade or perhaps due to an identified problem. But change is the leading cause of unplanned downtime and unplanned downtime is usually far more costly.
If you don't fully understand your system and the interdependencies, how can you be confident your change, such as a server update, isn't going to have a knock on effect? With a CMDB it is significantly easier to assess the risks associated with a change request and therefore take all the necessary steps to mitigate said risks.
Can I use CMDBs for non-IT applications?
Something that is less frequently discussed is the applications of CMDBs outside of pure IT applications. But we see users of our Insight app for Jira using the Insight CMDB for a range of other areas. Here are the two most common ones that are also being discussed in the wider industry.
There's a big push these days for HR automation in all types of processes, from recruitment to onboarding, to training and more. While not a traditional application, if you include your staff and other objects in your CMDB there's a lot you can do. For example, mapping training sessions to job roles so you can quickly see who still needs to sit certain sessions when they're next run.
You can also integrate it with IT for employee onboarding and offboarding. When a new employee joins the company, with just a few details such as their job role and department, the CMDB can quickly pull what hardware they should be given and what systems IT need to grant them access to.
Many CMDBs can also send automatic tasks to both the IT and HR queues so everything is processed correctly in advance of the employee starting, greatly improving the new employee's experience, keeping them satisfied and reducing the chances of them quitting early on.
Facilities management may not be an obvious application for a CMDB but we've seen a lot of people building a CMDB for their facilities objects that can be integrated into Jira. Meaning facility requests can be linked to the relevant equipment or location.
Just like with ITSM and ITAM, with facilities you have a large number of objects, that each have their own attributes and dependencies and getting a high level overview of this map is going to help the facilities manager deal with requests faster. Not only that, but this overview map and the detailed information will help with asset management and auditing when required.
A real-world example we've seen is organizations using it to manage access requests. By mapping the locations, access levels, and job roles in their CMDB teams can make granting access a very quick process.
A facilities asset will have attributes such as location, cost, whether it's serviceable or is a replaceable item etc. When a request to fix something comes through, it can be routed directly to the owner of that office or type of object. They can instantly pull relevant information from the CMDB so they know exactly where to send a technician or can raise a purchase order if needed.
CMDBs also come with lots of reporting tools which can be helpful for facilities managers on a tight budget and who may need to redistribute equipment. They can quickly get the location of all, for example, conference tables, locate any in storage across the business and reassign as needed. We've even seen people use QR codes to track objects and update the CMDB so they get very accurate location information.
With a CMDB you can also get a history of issues which allows people to cross reference with, say, the location to identify offices or floors where equipment is failing more often and the facilities manager can dig down to understand why this is.
What are the best practices for creating and managing CMDBs?
So now you know why CMDBs can be useful, how do you go about actually building one? CMDBs have gotten a bad rep over the years. Gartner estimated just 1 in 4 companies got meaningful value out of their CMDBs! But we speak to customers everyday who find their CMDBs invaluable so what's going on? Why are some successful and some aren't?
Well, as with any tool, how you use it will have a huge impact on what you get from it. Anyone can pick up some wood and nails and hammer them together, but it takes time, patience, and planning to make it into something actually useful.
With CMDBs, often people are trying to do too much too quickly without planning. Here are our top 6 tips to help you slow down, plan correctly, and ensure CMDB success.
1. Get everyone onboard first
As with any digital transformation project, working with people and interrupting their day-to-day processes with something new is often the biggest challenge to overcome.
Everyone needs to be moving the same way to make it work, not pulling in different directions. Get buy-in first and articulate how it will make the users' lives easier and more efficient. Keep in mind that people, on the whole, don't like change. And they especially don't like change if they think it will create more work or make them redundant.
If you're relying on the HR team to keep certain data updated, you need to have them with you and excited by the project, otherwise they might not commit to the task and you'll end up with poor data accuracy. This in turn will make the system not work as well for HR, furthering their belief that the system doesn't work and giving you an uphill battle to convince them otherwise.
This topic is so vast and so common we recommend reading some detailed articles elsewhere. We've linked to a few of our favorites here:
- How to beat the transformation odds
- Successful digital transformation begins with a cultural transformation
- 7 reasons why communication is the key to digital transformation
- Communicating your vision of digital transformation
2. Use a flexible CMDB
Some CMDB tools can be very rigid with fixed data types, predefined data structures, and limited automation capabilities. As with anything in business, things change fast so you're best off using something that will give you the ability to adapt quickly if you need to.
Look for a CMDB that is designed for scalability, gives you the option to define your own data structure and attributes, and can support a wide range of data formats. You're going to have an easier time if you can define your own asset types easily rather than waiting for the vendor to hardcode them into the tool.
3. Plan what you include carefully
CMDBs are often considered the 'single source of truth'. People often mistake that to mean 'I should put every asset I have into the CMDB' when actually it means 'of the assets I do include, this is where all the information I need should be available'. There shouldn't be a separately maintained database with duplicate data for any asset (more on this in a minute).
Our advice is to focus. Pick a process you want to enhance with your CMDB data and find the relevant assets for that process. Spend time designing your CMDB and how it's going to look, what will and won't be included, and what dependencies there are between these assets.
You can always include more assets at a later point or add new attributes to existing assets. It's best to start with a well defined project and set of assets as you navigate some of the other challenges outlined here.
4. Work with what you already have
As we said above, there shouldn't be a separately maintained database of repeated asset attributes. But this doesn't mean all attributes should be stored and updated in the CMDB itself. Some of the attributes you might want to use, especially for asset management applications, might be better maintained from a financial database or a specific licensing tool for example.
If those tools are working well for you and your business, then it may make sense to keep them. Many modern CMDBs have the option to bring in data from other tools with automated integrations. This means you can maintain your license information from your dedicated tool, but anyone viewing the asset in your CMDB gets an automatically updating copy of any relevant data to help them make decisions.
The key point is to avoid having to update asset attributes in two locations. This minimizes the chances of contradicting data and errors. If you go for this approach, make sure you're syncing information often so you don't get discrepancies.
5. Take advantage of automation to build and maintain your CMDB
Once you have planned what to put into your CMDB and where the data will be maintained it's time to create your CMDB. Building and updating your CMDB can be time consuming but there's many ways to speed things up and make your life much smoother.
For networked assets, many can be discovered by network scanners which look for connected computers, routers, switches printers etc, and pick up certain attributes. If you use a scanning agent on a target machine you will get even more information.
Some attributes, such as physical location, you may still need to add manually, but it reduces the workload significantly. Many CMDB vendors offer their own network scanners so the results can be easily integrated into the CMDB.
Network scanners can usually be set to run on a schedule so that they can look for any changes and update the CMDB accordingly, helping you keep a high level of accuracy. Not only that but these changes can trigger other actions.
For example if a server is found to be offline, you could create a high priority incident ticket or send an email to the server owner. Or perhaps a significant change has been made but there's no change request ticket so this might be something that is flagged to be investigated while the relevant attributes are updated automatically with the changes. They can also help you identify shadow IT as part of your ITAM processes.
Unfortunately, not every asset or attribute is going to be discoverable with a network scanner. Monitors for example. Or employees. For this, integrations or importers are your friend. Many CMDBs offer tools to bring in data from other sources such as CSV or JSON files, clouds services, active directory files, and other databases.
This is useful for entering the data and many of these integrations can be run on a schedule to update the data that is maintained elsewhere. But, in the case of objects stored in a spreadsheet somewhere, it's often easier to maintain directly from the CMDB. In this case, automation rules can really help.
For example, if a user submits a request for a new monitor because their current one is broken, most modern CMDB and request tools will just need the IT team member to say which new monitor will be given (which could be selected from a drop down list of in stock monitors) and all the required updating is done automatically.
The automation rules would set the owner of the new monitor, remove the owner from the broken monitor, and update the relevant statuses to 'broken' and 'in service'. Job done and IT doesn't need to worry about forgetting to update the attributes. You can define these rules however you like to keep your data accurate.
6. Accept you won't get 100% accuracy
We know it sounds a bit strange for us to say this, but many people struggle with their CMDBs because they are striving for 100% accuracy at all times. People sink so much time into trying to get this perfect database for systems that are constantly changing, that they never get around to actually using the CMDB and getting value from the 97% that is accurate and can speed up your processes.
That's not to say you shouldn't aim for 100% accuracy! You absolutely should aim for the most accurate CMDB you can with the help of good ownership, scheduled reviews by relevant teams, automation rules, and network scanners. But take advantage of what you do have rather than spending all of your time trying to make something completely perfect. As with many things, CMDBs follow the law of diminishing returns. Very often that last few percent will take the longest time but gives very little additional value.
How will you use your CMDB?
So there you have it. An in-depth look at what a CMDB is and its many uses. CMDBs have the ability to speed up your common processes within ITSM, ITAM, HR and facilities management. By linking asset data to your tickets you'll reduce your mean time to resolution, free up your time to work on other projects, and keep your customers happy! We also shared our top tips for being successful and getting actual benefits out of your database so when you come to build yours, keep these in mind.
If you work with Jira, or plan to in future, you can use the Insight app to build a CMDB within the Jira environment that can be linked to your tickets via custom fields. There's no need to migrate to a new joint ticketing and CMDB software, you can extend what you have already built in Jira. Companies such as NASA, Spotify, Vodafone and thousands more use Insight and Jira in their daily processes so check it out now.
Originally published Jul 22, 2020 10:49:24 AM