Concepts
Adoption stages
CSDM maturity is a journey — crawl, walk, run, fly — and a model that emits fly-stage artifacts into a crawl-stage program creates noise, not maturity. ServiceMatch stages its output to match where the program actually is.
What arrives at each stage
The white paper names specific entities per stage. Below is the whole CSDM 5.0 model with only the current stage lit — solid entities are emitted, hollow ones are designed and waiting. That distinction is the point: a partly-deployed model is a plan, not a shortfall.
Applications. The minimum CMDB that supports Incident, Problem and Change, and the foundation for Enterprise Architecture and Service Mapping later.
Designed is not the same as deferred, and neither is the same as missing
A model can be fully designed and only partly deployed, and that is a plan rather than a shortfall. Solid entities are emitted at this stage. Hollow ones, captioned with the stage they arrive at, are designed and waiting — the expansion path, not a gap. Reading the second group as failure is what makes CSDM maturity assessments so uniformly demoralising.
13 entities are shown faintest of all because the white paper’s adoption ladder never mentions them — mostly the CSDM 5 additions, which are described in the domain chapters but never placed on a stage. We have left them unassigned rather than inventing a position for them.
Capture is never gated
The stage never limits what ServiceMatch learns. Stakeholder claims, evidence, and attribution are captured in full at every stage. What the stage governs is what gets emitted: which workbook sheets are produced, which service relationships ship, which structural entities appear in exports.
One caution before the table: these rungs are ours, and one of them is not the white paper’s. The paper’s crawl is application-first — it recommends “a focus on Applications” and names business application, application service, application and server/host as its four crawl tables (p.53–54). ServiceMatch’s crawl is the infrastructure and endpoint layer instead, because that is the layer discovery can evidence on day one; the application tier arrives when claims support it. Walk, run and fly line up with the paper. Crawl does not — and two people using that word to mean opposite things is an argument worth pre-empting rather than discovering in a review.
| Stage | What emission looks like |
|---|---|
| Crawl | Two CSDM classes — infrastructure and endpoints — plus the governance artifacts. The foundation, and nothing above it. |
| Walk | Technology-management-parented service structure begins to ship; the business layer stays captured but held. |
| Run | Business-service offerings and evidence-confirmed placements ship alongside the management layer. |
| Fly | The full model, including structural capability entities, ships to the instance. |
The stage governs the model you chose
Staging is not tied to a small model. Whatever shape is active — a flat rollup, the flexible middle, the full capability tree — the stage governs how much of that model is emitted. Choosing a complete model and shipping it gradually is a perfectly ordinary way to run a program.
Where teams tend to start
What crawl answers is what do we have, and can we trust it. Impact, ownership propagation, and commitment questions arrive with the service structure at walk. Where a program settles is its own call — the stage exists so that call is deliberate rather than implied by whatever the tooling happened to emit.
The stage steers effort, not just output
The stage also orders where interview and discovery effort goes. At crawl, the stakeholder interview leads with application signals and support ownership — the evidence attribution can use immediately — and keeps capability questions brief; at run, capability depth returns. Nothing is skipped and every answer is captured; the stage decides what gets depth first, so stakeholder time converts into artifacts the program can ship now.
Readiness is not warrant
Before proposing a promotion, ServiceMatch assembles the readiness evidence from the customer's actual estate — identity quality, accepted stakeholder claims, attribution coverage — and states any gap in concrete terms, counted in devices: "promotion supported if the customer provides these artifacts." But readiness only answers whether a program can promote. Promotion also requires warrant: a named operational demand for the next layer, recorded in the decision rationale. If nobody needs the capability tier yet, staying at walk is a legitimate governed outcome — not a stalled project.
Promotion is a decision, not a drift
Design Principle
Moving between stages is a governed operator decision that lands on the decision record. The system warns and asks; it never blocks capture and it never promotes silently. This is the Armature Service Model in operation: a core rigid enough to hold every device, every owner, and every relationship in place — and a form flexible enough to take the shape your business services need at each stage, with every change of shape carrying evidence and a reason.