CMDB Remediation Before Discovery Rollout
A logistics company has 6,000 servers across three data centers. Its CMDB holds 22,000 CIs, but an audit sample shows 38% duplicates, 27% missing owner, and 41% missing environment. Discovery is licensed but not enabled. Leadership wants Discovery enabled in 30 days to support a new incident-routing model and service mapping for four critical services. There is no identification and reconciliation engine configuration beyond the base system. Two configuration managers own different CI classes and disagree on naming standards. The service mapping team has not started. The routing model depends on accurate service and environment attributes. Leadership’s success criterion is “discovery coverage within 30 days,” and they have asked you to start Discovery in all three data centers on day one. The CMDB has no health dashboard in use.
1. Should you start Discovery in all three data centers on day one? Sequence the work and justify it.
Read the worked answer
No - starting Discovery in all three data centers on day one will amplify the existing data problem. Discovery will identify and insert CIs; without identification and reconciliation rules, it will add to the 38% duplicate rate and make the routing model less trustworthy.
Sequence:
- Fix CMDB governance: one data owner, common naming standard, CI class model, and required attributes such as owner, environment, and service.
- Configure IRE identification and reconciliation rules for the CI classes in scope; define authoritative sources.
- Pilot Discovery in one data center on a limited IP range, for example 100–200 servers. Validate duplicates, completeness, and correctness against the audit sample.
- Expand to the remaining data centers in waves only after the pilot meets thresholds.
- Start service mapping for the four critical services after the CMDB baseline is stable; mapping on dirty data produces inaccurate service maps. In 30 days, a realistic outcome is governance plus a validated pilot, not full coverage.
2. What governance would you put in place between the two configuration managers?
Read the worked answer
Create a single CMDB governance board with one accountable data owner, not two parallel class owners.
- Publish one naming standard and one CI class and attribute model; resolve disagreements by decision, not by parallel standards.
- Define RACI for each CI class: who creates, who certifies, who reconciles, who retires.
- Use CSDM to anchor services and environments rather than inventing a local model.
- Require changes to identification rules to go through change control and be tested in a sub-production instance.
- Establish an exception process with expiry dates.
- Report health metrics monthly: duplicate rate, owner completeness, environment completeness, reconciliation exceptions.
- Escalate unresolved standards conflicts to the CIO or architecture board; otherwise Discovery will encode both standards.
3. How would you redefine success so leadership does not optimize for raw CI count?
Read the worked answer
Redefine success from coverage volume to trustworthy data.
- Duplicate CI rate, targeting a defined reduction from 38%.
- Owner completeness, currently 73%, and environment completeness, currently 59%.
- Correctness on a sampled audit, not just record count.
- Reconciliation rate and unresolved exceptions.
- Service mapping coverage and accuracy for the four critical services.
- Routing accuracy: percentage of incidents routed to the correct service or group using CMDB data.
- Time to remediate data defects. Coverage can rise while quality falls. Tie the program to the routing model’s accuracy and the service map’s usability, and publish a quality dashboard alongside coverage. That prevents the team from optimizing for the number of CIs discovered.