Few organizations proactively pursue Configuration Management Database (CMDB) data quality initiatives. They typically stand up a CMDB then suffer from the consequences of its gaps and stale data before eventually either abandoning it for a new one or taking on a piecemeal approach to fixing the problem.
Below are the top issues that point to data inaccuracy as a potential culprit:
- Failed Requests for Change (RFCs). These can be caused by the CMDB containing out of date or missing version information. For example, you may arrange a maintenance outage to update a server’s software version, only to find that it is retired. This wastes time and disrupts service availability.
- Breached Service Level Agreements (SLAs). Potential errors include misleading relationships or poor escalation due to Configuration Items (CIs) not being linked to the correct SLA. This presents itself in the form of an inability to prioritize work effort based on actual business impact.
- Increased incident resolution times due to inaccurate CI records. CMDBs that fail to cross-validate CI data against multiple sources can contain duplicate records for the same asset which have to be manually reconciled. Resolution times rise sharply when the duplicate CIs contain conflicting attribute values cause the analyst to waste valuable research time on dead-ends.
- Significant manual effort allocated to Inspection & Correction of data. Relying on manual input or placing too much reliance on a single discovery source can lead to a lot of corrective effort. This is a relatively straightforward metric to track and provides an indication of the effectiveness of your current CMDB data remediation efforts.
The white paper linked here from Blazent, describes a best practice approach to creating a clean CMDB in a migration scenario. It is equally applicable to the case where you simply want to start again with the same vendors CMDB or improve the quality of an existing CMDB.