CMDBs Explained: Configuration Management Databases

For many IT organizations, having complete end-to-end visibility of their IT assets as well as a comprehensive understanding of integrations, dependencies and changing statuses is an ideal position rather than a reality.

This is especially true for organizations with legacy on-premises systems spread across many environments. Those that were cloud native or successfully migrated to the cloud had the privilege of cloud tools to visualize individual environments. Then again, this would still be a challenge if a multi-cloud or hybrid posture was chosen.

CMDBs are meant to provide such visibility — but they are routinely underutilized.  Let’s tackle this challenge in this article.

What is a CMDB?

First, let’s review the basics. The Configuration Management Database (CMDB) is the system deployed to maintain records about:

• Service components (hardware, software, licenses, virtual machines, containers, devices, etc.)
• The attributes of service components
• Their relationships throughout their service lifecycle

While the CMDB remains a fundamental capability in most modern IT service management (ITSM) solutions, maximizing its value is a significant endeavor. Gartner reported that just about 25% of organizations receive meaningful value from their CMDB investments.

Maximizing value from CMDBs & configuration management

So, what can organizations do to ensure that their approach to implementing and maintaining a CMDB leads to improved IT service delivery, compliance and cost management? Let’s look at this challenge it through the PDCA cycle:

• Plan: Define your configuration management approach well in advance.
• Do: Assign responsibility for CMDB data management and maximize your CMDB capabilities.
• Check: Regularly review CMDB data to ensure it is still valuable and relevant.
• Act: Be proactive in promoting the CMDB as the source of truth for ITSM practices.

CMDB Planning (Plan)

Success in configuration management can only be made possible with a well-thought-out plan. Start by determining the specific set of outcomes and benefits that the practice will deliver for your organization. Then, track only the configuration items (CIs) and relationships that are necessary for the achievement of those outcomes.

The VeriSM service management approach states that relationships or dependencies are the lifeblood of a CMDB. Indeed, failure to determine them only makes the CMDB a glorified asset inventory. As such CMDB planning should be the first step in ensuring that the implementation of the CMDB has:

• A defined scope of IT assets to be covered
• The support of leadership and IT stakeholders
• A clearly defined process for entering, validating and using CMDB data
• Established standards for the quality of CMDB data

Scoping for CMDB data should primarily focus on critical business services first. Risk assessment and business impact analysis are valuable inputs in determining what CIs in production should be entered into the CMDB. Planning should also involve capacity building for IT staff who will populate, manage and use CMDB data.

There’s no point in having a CMDB that has tons of information, yet IT personnel neither understand nor utilize it.

(Learn about data quality and data normalization.)

CMDB Execution (Do)

With a defined process in place, then the actual work of putting data into the CMDB begins. For that, the responsibility matrix must be clearly articulated, with clear roles for data entry as well as validation to ensure that the entered data is complete and accurate.

Whether the CMDB is populated manually or — better still — through automated discovery, there some human intervention is required to review the data and compare it with existing knowledge to validate that it is sensible and fit for purpose.

The right CMDB solution can go a long way in generating the value that the IT organization seeks from visibility and insights on how different systems elements interrelate. An IT organization should select and deploy the solution that gives coverage to the IT environment and technologies they run, be it on-premises, cloud or hybrid. Some of these systems discover or can intake massive amounts of data such as types, versions, vendor information, location/environment information, related services/records, etc. That means care has to be taken to ensure users are not overwhelmed as they discover and access relevant information.

Making CMDB data available to stakeholders and associated practices like change enablement, incident and problem management is as much a marketing exercise as it is a technical activity. Simplify access to CMDB data depending on the audience and need:

• A CIO would be better suited to accessing a dashboard.
• Members of a change authority could directly reference the visualized configuration model.

CMDB Audit (Check)

With IT environments anything but static, a lack of oversight can quickly see the CMDB data grow stale and unusable. This hampers the effectiveness of the configuration management practice and thereby limits its value to IT operations.

Starting from planning, conduct a scheduled, regular audit of the CMDB data, with key stakeholders participating. Such audits are useful in uncovering issues such as:

• Discovery not capturing new network segments or cloud environments
• Mismatching associated records such as change requests, incidents or problems

When such discrepancies are unearthed, address this through prompt corrective action and then track and report on that.

Schedule CMDB audits depending on the volatility of the IT environment. Additionally, other mechanisms should be used to contribute to detecting anomalies and proposing updates to enhance the quality of CMDB data, such as such as deployment plans, change assessments and problem investigations.

As part of governance, a metric on the accuracy of CMDB data should be reported to IT leadership.

CMDB Improvement (Act)

A well-oiled CMDB that underpins the configuration management practice can result in positive outcomes such as:

• Optimized solution design and implementation
• Successful change enablement
• More effective service support

ITIL^® 4 guidance outlines some use cases for configuration management that would produce these outcomes including impact analysis, cause and effect analysis, risk analysis, cost allocation, and availability and performance planning and analysis. That means you’ll have to make a concerted effort to track the value accrued, and associated effort and costs from the CMDB.

The scope of coverage and usage of the CMDB must continue evolving even as the business and IT strategies shift to address the needs of the operating environment.

Final thoughts on configuration complexity

According to VeriSM, configuration management is often referred to as the unicorn of the service management world — everyone has heard of it and knows (or thinks they know) what it is but in reality, no one has seen it in real life.

Having full visibility of IT configurations and keeping this information updated is a challenge few organizations have managed to surmount. Yet this need is not going away anytime soon, since the complexity of the IT environment will continue to grow. We can borrow from ITIL 4 guiding principles in the spirit of continual improvement, to start where you are and progress literately with feedback. Proper scoping, diligent data collection, widespread usage and consistent review are habits that raise the probability of delivering full value from the investment in a CMDB.