A configuration management database or CMDB can be a game changer in terms of service delivery. Done well, a CMDB benefits incident resolution, speeds up request fulfillment and makes change assessment safer. Implementing a CMDB is a significant task and it’s something that many IT departments struggle with. It’s very easy to make things complicated or difficult to maintain.
Let's examine how to build a practical CMDB so that it adds value and supports rather than diverts resources away from IT operations.
Understanding the technology
So many people get confused, so let’s sort out the technology, once and for all:
- CMDB: a database that stores configuration records throughout their lifecycle. The CMDB also maintains the relationships between configuration records. In other words, the CMDB captures the building blocks that make up IT systems and how they work together to deliver business services. Read more in our comprehensive CMDB definition.
- CMS: a set of tools, data and information that is used to support service configuration management. A CMS can be made up of multiple CMDBs, asset databases and knowledge information.
- CI: configuration item, any component that needs to be managed in order to deliver an IT service.
Set your scope
The first thing to do is define a scope.
So many CMDB initiatives fail because people try to do too much at once, resulting in a product that is big, unwieldy, and difficult to keep updated. When we’re building our CMDB, we’re going to use the ITIL principle of keeping it simple. It’s always easier to build up over time or to add things as you go along. The more CI attributes you add now, the more detail you’ll have to maintain in the future so pick a single business service and build it in your CMDB. An achievable way of doing this is to start with your most well-known service and map it out from end to end. This gets you used to the process, CI mapping and capturing all the attributes, and relationship information. By starting with an easy service, you’ll build confidence and the next service won’t seem so daunting.
Another ITIL principle that’s especially helpful with building CMDBs is to start where you are. OK, you’re not going to have a readymade, perfect CMDB already in place but what you will probably have is asset information or databases, spreadsheets with technical data or support information in your ITSM tool. This also applies to the detail you capture. At the beginning consider limiting what you capture to the following:
- Unique Identifier
- CI type e.g., server, network device, application
- Version Number
- Support Details
- Vendor Details
- Relationship to other CIs and services.
It’s all about the data
CMDB benefits are plentiful, but your CMDB is only as good as the data it contains so build check points into your process to ensure your CMDB is up to date and accurately reflects your live environment. The quickest and easiest way to check if the data is correct is to have people use it. Here are some examples:
- Ask your service desk analysts to try and categorize incidents and service requests using the CMDB.
- Ask support teams to raise changes with impacted services flagged into the CMDB.
- Ask your change enablement teams to impact assess change against the service information in the CMDB
- Ask problem management to use the CMDB to support problem and known error analysis.
Once colleagues start using the CMDB build in some process steps to protect data integrity for example:
- Have the service desk update incorrect CI data in the moment, when logging incidents or requests.
- Work with your change enablement practice and agree to some success criteria that supports configuration management. An example could be a change can only be closed off as successful when the CI or service information is updated.
- Work with your security teams so that any security incidents are automatically linked to a service so they can be managed more effectively
Track CIs over their lifecycle
Every CI has a lifespan so when maintaining your CMDB, you’ll need a process for recording and reporting the lifecycle of each configuration item. Some example statuses could include:
- In test environment
- In production environment
- Maintenance /Repair
By building status accounting into your CMDB working practices, you’re ensuring that all CIs that make up the service baseline have been captured and that all changes have been captured by and reflected in the CMDB.
Keep moving forward
Build up your CMDB over time. Use that first service as a prototype. Once you have that service, you’ve got an approach that works so repeat the process again for the next service, and the next, and so on. Keep going until you've captured all your most critical systems before you know it, you’ll have an effective CMDB.
Use the right tools
To build a thorough CMDB and keep an accurate inventory of your catalogue, you need to make sure you're using the right IT Asset Management (ITAM) tool; one that allows you to easily manage, control, and organize all your IT assets, in addition to automatically discovering new assets, tracking your compliance, and easily preparing for an audit.
InvGate Insight is a top-of-the-line ITAM tool that will provide your organization with a unified inventory of all network-connected IT assets across workstations and servers, network appliances, mobile devices, cloud instances, and IoT devices. Its discovery capabilities provides you with a dynamic, 360 degree view of the relationships between your systems and applications. You'll have up-to-date visibility of your asset and configuration management data.