[object Object]

The CMDB has 280,000 CIs, the duplicate rate is 18%, the average CI has not been touched in 11 months, and the change team uses spreadsheets because the CMDB is unreliable. The data model is not the problem — the problem is governance that nobody owns and identification rules that ship in defaults nobody validated. The fundamentals below are what a CMDB needs to be trusted instead of decorated.

The Base Tables

CMDB is built on a class hierarchy rooted at cmdb_ci (Configuration Item). Every CI type extends it — servers (cmdb_ci_server), databases (cmdb_ci_db_instance), applications (cmdb_ci_appl), services (cmdb_ci_service). The hierarchy goes deep; know the structure before extending it. Custom classes should extend the right ancestor, not branch from cmdb_ci directly.

Relationships live in cmdb_rel_ci with a type reference to the relationship type table. The relations you will touch most are parent/child, runs on, depends on, member of, and used by. Each relationship type has direction semantics that matter for impact analysis — get the direction right, or the dependency map flows the wrong way.

Common CI hierarchy fragments:
  cmdb_ci
    -> cmdb_ci_hardware
       -> cmdb_ci_computer
          -> cmdb_ci_server
             -> cmdb_ci_linux_server
    -> cmdb_ci_appl
       -> cmdb_ci_db_instance
          -> cmdb_ci_db_oracle_instance
    -> cmdb_ci_service
       -> cmdb_ci_service_business
       -> cmdb_ci_service_technical

Classes Are Hierarchical — Use That

Do not create flat custom classes. Extend the right ancestor — a custom load balancer class should extend cmdb_ci_lb_service, not cmdb_ci. Extension gives you inherited fields, identification rules, and existing Discovery and Service Mapping patterns. Flat custom classes lose all of these and require parallel maintenance for every cross-cutting concern.

Identification and Reconciliation

IRE (Identification and Reconciliation Engine) is how the platform decides whether an incoming CI matches an existing one. Misconfigured IRE creates duplicates (different rules match the same CI on different attributes) or overwrites good data (incorrect coalesce on a non-unique attribute). Review identifiers per class; do not leave defaults in place without verifying they match your data.

IRE identifier example for cmdb_ci_server:
  Primary identifier: serial_number + manufacturer
  Secondary identifier: ip_address + dns_domain (when serial unavailable)
  Composite key behavior: required, fallback to next on miss

Data Certification

A CMDB without review goes stale in months. Schedule quarterly certification campaigns per CI class. Owners verify their CIs are current, correct, and have required fields populated. The certification engine ships with the platform; configuration is the work — defining the campaign scope, the questions, the SLA for response, and the consequence for non-response (CI marked stale, owner notified, escalation to manager).

Service Mapping vs Discovery

Discovery finds infrastructure: hosts, processes, listening ports, network adjacency. Service Mapping models logical services that span that infrastructure — the dependencies of “Customer Order Service” across web, app, database, and queue tiers. Most organizations need both; Discovery alone produces a CMDB of components, Service Mapping alone has nothing to map. Start with Discovery, add Service Mapping for the top 20 business services where impact analysis pays back.

// Helper: count CIs by class for sanity-check
var ag = new GlideAggregate('cmdb_ci');
ag.addAggregate('COUNT', 'sys_class_name');
ag.groupBy('sys_class_name');
ag.query();
while (ag.next()) {
  gs.print(ag.sys_class_name + ': ' + ag.getAggregate('COUNT'));
}

Common Failure Modes

CIs created by manual entry without identifiers — they cannot reconcile against Discovery and become orphans. Require identifier fields on manual creation forms. Relationships created without a relationship type — defaults to a generic “related to” that is useless for impact analysis. Always pick the specific type. Stale CIs marked active because nobody runs the retirement workflow — schedule a job that flags CIs with no Discovery touch in 90 days.

What Changed in 2026

The Zurich release improved IRE diagnostics and added a “would have matched” preview that shows what existing CI an incoming record would coalesce against. Use it before changing identifier rules. Newer Service Mapping patterns include better support for cloud-native services (Kubernetes, serverless) than older releases.

Cost Considerations

CMDB storage scales with CI count and relationship count. Multi-million-CI instances are common in large enterprises and the storage cost is meaningful. Retire CIs aggressively when their hosting infrastructure is decommissioned; an “active” CI for retired hardware is technical debt and a reporting hazard.

Implementation Sequence

Validate the IRE rules for your top 5 most-populated classes before any new Discovery scope rolls out. Establish certification cadence for the same classes. Add new classes to the certification rotation as they grow. The CMDB cleanup project that tries to fix everything at once stalls; iterating class-by-class makes progress visible and motivation sustainable.

What to do this week: query cmdb_ci for the duplicate rate on your top three classes (records with the same serial_number or ip_address); the duplicate count is your IRE audit baseline.

[object Object]
Share