Browse documentation

CSDM

CSDM quality & scope

Heraldic crest — CSDM quality & scope

A CSDM model can be complete, conformant, and still worthless. Quality in a service model is not object count — it is whether the model can be trusted by the workflows that consume it: incident routing, change impact, portfolio decisions. These are the failure modes we design against, and the bars we hold.

How service models fail

  • The empty service layer — infrastructure fully discovered, services never connected. The model exists; nothing consumes it.
  • Everything is a business service — the application portfolio pasted into the service layer, no owners, no offerings, no consumers.
  • The architecture diagram, replicated — hundreds of objects modeling how the system is built instead of how it is operated and consumed.
  • Catch-all attribution — impressive coverage percentages built on default buckets doing no analytical work.

The quality bars ServiceMatch holds

  • No more objects than the operating workflows actually use — decompose services only where support structure genuinely differs.
  • Every business placement is evidence-backed or honestly parked on a management service — never faked from weak signals.
  • The upper layers are interviewed, never invented: capabilities, services, and ownership come from stakeholder declarations, reviewed against a pre-built draft (see Attribution & coverage).
  • Owners are mandatory, not aspirational — a service without an accountable owner is a diagram.
  • Coverage reports as three numbers; emission grows with adoption stage; the workbook is a generated view of the governed model.

Scope: the discovered estate

There are two legitimate ways service context gets into a CMDB. Where development teams own their services — cloud-native, PaaS, greenfield — declared registration works: teams register services as code or tags in their own toolchain, and the model follows their declarations. ServiceMatch works the other side: the discovered estate — the endpoints, servers, and infrastructure reported by discovery tooling, where there is no development team to declare anything and the evidence has to be assembled from what the estate actually shows.

Design Principle

Declared registration and discovered-estate conditioning are complementary lanes that meet in the same CMDB. We deliberately build for the discovered side — most of an enterprise's CIs live there, and it is the side no declaration process will ever cover.