Mesa Development

Service

CMDB Amplified Implementation

Typical engagement  ·  6–12 weeks

Most CMDBs are not broken because nobody scanned. They are broken because two authoritative sources disagree about the same server and nothing arbitrates between them. Fixing that is a data-governance problem wearing a technical costume.

Rack-mounted equipment in near-darkness, cabling coiled and dressed to the frame.

The CMDB is the layer nobody looks at until something breaks. Remediation is mostly making it match what is physically there.

Where duplicate CIs come from Two authoritative data sources both insert server records; with no identification rule to arbitrate, the CMDB holds a stale duplicate alongside the current configuration item. Discovery Asset import Identification Rule cmdb_ci_server duplicate CI (stale)
Discovery
Discovery is one authoritative source writing into the CMDB. It is rarely the only one.
Asset import
Asset imports are the other common writer. Two sources describing the same hardware differently is how most duplicate CIs begin.
Identification Rule
Identification rules arbitrate between sources that disagree. Getting these wrong is the most common cause of duplicate CIs in ServiceNow.
cmdb_ci_server
The record that should exist exactly once, and that incident routing depends on being right.
duplicate CI (stale)
What appears when no rule arbitrates: two records for one machine, and an incident routed to whichever was found first.

Two authoritative data sources both insert server records; with no identification rule to arbitrate, the CMDB holds a stale duplicate alongside the current configuration item.

  • Discovery — service
  • Asset import — service
  • Identification Rule — application
  • cmdb_ci_server — host
  • duplicate CI (stale) — host
  • Discovery depends on Identification Rule
  • Asset import depends on Identification Rule
  • Identification Rule depends on cmdb_ci_server
  • Identification Rule depends on duplicate CI
Where duplicate CIs come from

01

Phases and deliverables

Stated before the work starts, so "done" is not a matter of opinion at the end.

  1. 01

    2 weeks

    Diagnose

    • CMDB health assessment with a prioritised defect list
    • Source-of-truth map per CI class

  2. 02

    3–8 weeks

    Remediate

    • Identification and reconciliation rules rebuilt
    • Duplicate resolution executed with a rollback position
    • Class hierarchy corrected

  3. 03

    1–2 weeks

    Govern

    • Health dashboards with named owners
    • Data governance policy and review cadence

02

What gets measured

Baselined at the start and reported at the end. These are the measures themselves, not claims about past results.

  • m01 CI accuracy sampled against physical or cloud reality
  • m02 Duplicate CI count, trended
  • m03 Percentage of CIs with a current authoritative source
Talk about CMDB Amplified All services