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 inert offering — the service layer is populated, the groups are wired, and the offerings carry no Managed By, Support Group or Change Group. Nothing is missing on the diagram; nothing reaches the devices either. This is the one that survives an audit, because every object exists.

The interview cycle

A CSDM model has two halves, and they are filled by completely different means. The lower half is principally machine-observable: devices, the software installed on them, the service instances that software forms. Scanners reach it — though not trivially, which is why ServiceNow supports several different ways to populate an Application Service rather than one. The upper half — what the organisation promises, to whom, at what commitment, and who is accountable when it breaks — is declarable only. No packet on the wire carries it. Buying better discovery does not move it, because there is nothing there to find.

Declaration usually means asking someone — but not only that. Sometimes an authoritative record already holds the answer: a service catalogue, a contract, an org chart, a portfolio system. Those are evidence too, and ServiceMatch reads them when they exist. What no amount of scanning produces is the answer itself. The cycle is small and it repeats — the model’s own gaps generate the questions, the answers close gaps and expose new ones, and the cycle stops when nothing is left that a person could settle. Nobody writes a questionnaire. A service that publishes no offering, an instance nothing claims, a device class reaching nothing at all: each of those is a structural fact about the graph, and each turns into a question ranked by how much it unblocks and addressed to the person who could plausibly know.

The part that matters most is knowing which gaps are not questions. Ask a business lead whether a particular switch supports pharmacovigilance and you will get an answer, because people are helpful — and that answer is a guess which becomes a claim which survives in the CMDB for years. So gaps sort into three kinds and only two of them are ever put to a human:

• →A person settles it. Who owns this service, what do we promise, which team operates these devices. The answer is the fact.
• →A person informs it. What a class of equipment is used for, day to day. Genuinely useful, genuinely knowable — but it becomes a hypothesis to verify against the devices, never an attachment on its own.
• →Nobody can settle it. Whether a specific machine supports a specific service. This is a search, not a question, and it never goes to a stakeholder.

Watch one get derived

Press play, or step through it a beat at a time. Every step is the same three moves, landed separately: what somebody said or a scanner found, the claim extracted from it, and the records that claim instantiates. The model does not know about the step until that third beat — so the coverage numbers are not narrated alongside the animation, theyare the animation. Two streams feed it: what the scanners find, working up from the metal, and what people say, working down from the business. Twelve of the twenty steps quote one sitting; one more stands in for the four sessions that followed, and says so rather than inventing eighty further turns. Watch the bar through the first four steps: devices attach to applications and to support groups and nothing turns amber, because attached is not parked until a person has named who operates it.

Watching the model fill in

Below is one estate at four points in the cycle. The first panel is not a mock-up of an immature customer — it is the same estate with everything a person declared removed, leaving only what discovery could have produced on its own. That is the honest starting line, and it is where the argument lives.

Run the cycle yourself

The same generator, live. Answer a question and watch the coverage change — then watch what it refuses to change. That turns out to be the more useful lesson.

Where does a class of device actually end up?

Dependency maps answer “what does this service need?” The more useful question for a CMDB owner is the inverse: pick a class of device, and show me where instances of it land — with the reason for every hop, and an honest marker where the chain stops. Every evidence line below is a governed decision: in the product it is an entry in the decision record, not a label.

Walking the chain on a worked estate

Failure modes are easier to recognise against something concrete. Below is a fabricated biopharma estate — deliberately imperfect — walked from business capability down to metal, with the first break on each path marked and the breaks ranked by how many configuration items sit behind them.

Where the entity you mean and the table you query diverge

One quality failure has nothing to do with your data and everything to do with the schema: two CSDM tables each carry two different conceptual entities, told apart only by a classification value that survived a rename. Query either table without filtering and the number you report is the sum of two unrelated populations — which is why offering counts so often fail to reconcile between two people looking at the same instance.

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 CSDM doctrine).
• →Every business service is checked for an accountable owner, and a missing one is reported against the design — a service without an owner is a diagram.
• →Every offering is checked for what it propagates. Managed By, Support Group and Change Group are what CSDM copies from an offering onto the devices beneath it, so an offering missing them is reported as inert rather than complete — and the devices it strands are counted. The fix is an interview question, never a derived value.
• →Every business placement records who asserted it, not only who last confirmed it. The named claim and the device evidence both stay on the relationship, so the model can answer who said it, what confirmed it, and who approved it.
• →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.