Top 5 CMDB Best Practices (And Worst CMDB Mistakes)

Steve Manjaly May 19, 2022
- 8 min read

A robust IT asset management solution is key to the efficient delivery of IT services to an organization. It’s important to keep track of the organization’s assets, both hardware and software, to ensure continued service delivery. Without this, these assets may fail or stop functioning as intended and can cause inconvenient service disruption. 

An asset management tool such as InvGate Insight can help you manage the licenses, maintenance, upgrades, and lifecycle of the organization’s assets. And a CMDB is one of the core parts of an organization’s asset management strategy. Here we explore what a CMDB is, some of the common CMDB mistakes, and five best practices that can help you build and maintain a robust CMDB. 

First off, what is a CMDB?

A CMDB, or Configuration Management Database, is an essential element of IT asset management that stores information about the organization’s IT network. The database is used to store information about the different hardware and software components and their relationship with each other. 

A CMDB shows a complete picture of the organization’s configuration items or CIs through a dashboard. The dashboard helps IT teams understand the different components and how changes can affect them. 

Modern CMDBs can also automatically collect information about the CIs and CI types through APIs and asset discovery tools and automatically populate them in the solution. They play a huge role in keeping records of the assets for compliance and audits. 

CMDB elements

Software solutions such as InvGate Insight feature various IT asset management capabilities which include the ability to quickly and easily populate your CMDB with your company's IT assets. These are presented in visual CMDB data model, allowing you to identify trends, patterns and outliers in an attractive, easy to comprehend presentation.

What are some of the common CMDB mistakes? 

While there are many benefits of using a CMDB, the route to getting your CMDB to work for you is filled with mistakes. Here are some of the common mistakes.

Not integrating with other tools

CMDB is essentially a reference tool. When you’re making a new change in your network architecture or is upgrading your hardware, it helps you gain a clear picture of the systems that may be affected, and determine how you can best plan your change. If this data doesn’t reflect the latest status of these assets or configuration items, it will affect any plans you’ve made. 

This is where integrations come into play. An organization’s IT service management often relies on multiple tools. These tools monitor the components and make changes to them. It's important to update these changes to the CMDB to keep the data up-to-date. 

The integrations work the other way too. By integrating the CMDB with other ITSM tools, there’s the possibility of enhancing their functions. These tools can leverage the CMDB data to help you manage your network; for example, identify the components that may be affected by a virus by analyzing the relationships between them and isolate them from the network. 

Most often CMDBs are just databases, they just store the data about different CIs. But by integrating them with other tools, you can visualize and analyze these data. 

InvGate Insight, for instance, integrates its CMDB seamlessly with InvGate's IT service management solution InvGate Service Desk, allowing you to keep track of incidents and requests for each physical, virtual, and cloud asset.

InvGate Insight CMDB integrates with InvGate Service Desk

Lack of accessibility 

There are many aspects to accessibility. First off, the CMDB has to be easy to use. Users with different levels of technical skills will want to use the CMDB and a complicated interface can make it difficult to find the CIs. When users find it difficult to navigate the interface, the adoption rate goes down. And when the owners of CIs can’t access the CMDB, the data is not maintained or updated. 

Another aspect is that the relevant stakeholders are not often given access to the CMDB. Often the team that invests in or builds the CMDB takes care of it, and there’s nothing wrong with it. But when other teams or stakeholders are not given access, the organization will lose out on many use cases. And of course, the earlier problem of CMDB data not getting updated happens here too.

Including everything and anything in the CMDB

An oft-discussed aspect of CMDBs is the data we need to include and what we don’t need to include. A common mistake is that ITSM teams often fill up their CMDBs with all the data that they have about their CIs, be it relevant or irrelevant. The idea that the data may be needed in the future and treating the CMDB as just a data storage tool drives most of these decisions. And often this means that the quality of data is left behind. 

For example, automated discovery tools or APIs may collect a lot more data than required. For a router, you may need only its position in the network, but these tools collect everything from the manufacturer information to its warranty information. And the CMDB just stores all this information making it difficult to get to the important piece of data. 

At the core of these problems is not having a clear or definite requirement for the CMDB. Of course, the IT team recognizes the need for CMDB, but the exact purpose of the tool and the problem its supposed to solve is not clearly defined. This means the CMDB owners don’t know what data is important and what is not and they end up storing everything. 

Not investing in executive buy-in 

As with any IT initiative, the success of a CMDB depends a lot on executive buy-in. It’s important to convince the management about the importance of the CMDB and its benefits. Many CMDB initiatives often fail as other projects and initiatives are given priority and CMDBs take a backseat. 

Lack of executive buy-in can also mean that IT teams don’t make use of the CMDB, the data becomes outdated, and eventually, it goes out of relevance.

There are various CMDB mistakes that can b easily avoided

Top 5 CMDB best practices 

Understand why you need a CMDB and focus on it 

This is one of the important steps to avoid too much or too little data in your CMDB. Before building your CMDB, define the requirement, and explore why you need a CMDB, the processes you will use it for, the problems it will solve, and the business benefits it brings. Once you have this information, decide the CI types you’ll need, the different attributes, and all other data you want to include in the CMDB. 

When building a CMDB, the IT teams focuses on adding the data that they have, and only that; which means the database has a ton of unnecessary data but lacks some necessary data. 

Instead of collecting all the data and the attributes and adding them to the CMDB, it's best to find out what you need, find out the data needed for different services and processes, and build a requirement based on this. And based on this, find out how you can get this data. If there are overlaps between the data sources, use the most reliable or frequently updated source. If there are gaps, that is if you can’t find certain data from the available data source, it's best to figure out a way to get that data. 

It’s also important that the stored data has some business value. If you can’t map the data to a business goal, reevaluate if that specific data point is required or not. While this can be done at the end, once you’ve decided what to collect, it's best to do this the other way round as you build the CMDB. Evaluate your business goals, find the processes related to them, and collect the relevant data. 

Make the CMDB accessible

The user interface is often not the priority when choosing a CMDB and this can create problems further down the road. When employees are not using the CMDB, the data may get outdated, which could further lower the usability, and the whole system may become useless. 

An accessible CMDB gets adopted easily in the organization and is more likely to succeed. Employees must be able to access the CMDB data through an intuitive UI. For example, Invgate Insights platform comes with a CMDB that helps users clearly visualize the relationships between different CIs. Keep in mind that not everyone who uses or has to use the CMDB would be a technical expert. 

Ideally, a simple dashboard should showcase the different Cis and users should be able to find the CIs as well as the related data with a couple of clicks. 

Integrate with other systems and IT workflows

As discussed earlier, isolated CMDBs often don’t generate value for anyone. They’ll exist purely as a database and users will have to manually access the CMDB to use it in their activities. This means the CMDB may never reach its complete potential. 

Make sure that the CMDB is integrated with other systems and workflows to ensure its used and updated. And if a process involves any changes to the configuration, for example updating the hardware or isolating a network, make sure that updating the CMDB is part of the workflow. 

For effective adoption, the team must be convinced of its benefits. They should not feel as if CMDB adds more work, but rather that it makes their work easier. It should feel like a tool and an asset, and for that, the data should be trustworthy. Integrations can go a long way in achieving that. 

Assign ownership to respective CI owners

This is fairly straightforward; make sure that CI owners are responsible for maintaining and updating the CMDB data. 

CMDBs have to be constantly updated to reflect all the changes; if not it can easily go outdated. Here the ideas discussed earlier - easy access and user-friendly design - applies. It may be a good idea to assign ownership of the entire CMDB to one person, perhaps the configuration manager. 

Use automation as much as possible

Don’t go manual all the way with CMDB. Use tools like automated device discovery to populate your CMDB. Modern tools like InvGate CMDB can discover a wide range of devices, from routers to IoT devices, and even the assets in your cloud environments. 

Automation can make the records more accurate without adding more effort. It will also ensure that the CMDB is ready for audits. 

Frequently asked questions

What is a CMDB?

CMDB or a Configuration Management Database is an asset management tool that holds information about the assets or configuration items (CIs) in an organization’s IT infrastructure. It stores the list of all CIs along with how they’re related to each other.

What is the difference between a CMDB and an asset management solution?

While CMDBs are a part of asset management, the difference is in how both systems perceive the different components. Asset management is focused on the financial aspect of the components, their value, how much returns they’re producing, their maintenance costs, etc. CMDB is more focused on the infrastructure and how these components are positioned, how the different devices are connected to each other, how a change in one may affect others, etc. 

Read other articles like this : ITAM, InvGate Insight, CMDB

Evaluate InvGate as Your ITSM Solution

30-day free trial - No credit card needed