📋 PLAYBOOK
One address lit and named. The rest of the map is waiting.
📍 IN BRIEF
By the end of this you will be able to sequence CSDM adoption the way a city actually gets built, in districts, each one settled and paying its way before the next breaks ground. The discipline is not modelling faster. It is refusing to start the next stage until the one you are standing in has earned the trust that funds it.
Nobody has ever built a city all at once. The ones that work grew district by district, each proving it could hold people before the next was surveyed, and the ones that were master-planned in a single heroic push are the cautionary tales urban planners tell each other. Yet a single heroic push is exactly how most organisations attempt their service data model, one programme, the whole estate, one big reveal. ServiceNow’s own method behind CSDM 5 says the opposite, and says it plainly. Do not implement the whole model at once. It lays out a staged path, a foundation first and then four expansions it calls crawl, walk, run and fly, and that sequence is not project garnish, it is the strategy itself. This playbook walks the sequence as a city build, and names the trap waiting at each stage.
When to use this
This is for platform owners and governance leads starting a CSDM adoption programme, or restarting one that stalled. It assumes you have backing for a multi-stage journey rather than a single delivery date, and some working form of change governance. If your model is already live and the problem is trust rather than sequence, this still applies. Re-enter at the stage whose output you cannot currently defend, and run it properly this time.
Stage 1, survey the land before the first building
Put the organisation's reference data in order before you model a single service, who you are, how you are structured, where you operate, who supports what.
Every city begins with a survey and a land registry, not with architecture. The equivalent here is the unglamorous shared data, legal entities, business units, departments, locations, and support groups, that every report groups by and every workflow routes on. The guidance behind CSDM 5 is unusually direct about this layer. Most programmes consider it far too late, and the reporting, workflow and AI ambitions people bring to a platform depend on it more than on the configuration data itself. Decide early who maintains each piece of it, because organisations restructure constantly and the reference layer decays faster than anything built on top of it.
The gotcha is that this stage feels like administration, so teams skip ahead to the interesting part. The cost hides for months, then surfaces all at once, the first executive report cannot be grouped by business unit and every routing decision lands on a blank field. Foundations are cheap on day one and painfully expensive to retrofit under a live city.
Stage 2, build the first district where people already live
Model the minimum application slice your daily operations lean on, the one that makes incident, problem and change work visibly better, and stop there.
The first district of a new city is never the grandest, it is the one people already need to live in. Here that means the applications your operational decisions turn on today. The payoff should be immediate and visible, the next incident raised against a recognisable application with a known support path, the next change able to say what it touches, the model proving itself when proof matters. Just as important is what you write down as out of scope for now. Development and test estates, systems already on the road to decommission, the shadow IT you know is out there, all of it can wait, and saying so in writing is what protects the stage from creep.
The gotcha is boiling the ocean, because the moment tooling can see the whole estate, the temptation is to model the whole estate. Resist it, because coverage without trust is worse than modest scope with it. A model that is half-finished everywhere is doubted everywhere, and doubt, once established, does not stay confined to the unfinished parts.
Stage 3, appoint a custodian for every district
Give every area of the model a named owner who decides what good data looks like, and split each record honestly between what automation is trusted to maintain and what only people are.
A city's register stays accurate because keeping it accurate is somebody's job. The same split works here, and it is worth being precise about. Automated discovery is excellent at the facts a scan can see, and those facts should belong to it. Judgement, which system matters most, who supports it, how critical it is to the business, belongs to people, and each area of the model needs one named custodian who defines what a complete record looks like, approves any exception, and checks a sample often enough to catch drift early. This is the same discipline that makes a single accountable name worth more than a workshop full of stakeholders. Data, like a decision, needs exactly one owner.
The gotcha is assuming automation will keep the model honest on its own. Automation is a diligent surveyor and a terrible referee. When two sources write the same fact and nobody has named which one wins, the result is the mystery overwrite, and the first unexplained overwrite a team notices is usually the moment their trust in the whole model quietly ends.
Stage 4, extend the city in value order, not ambition order
Expand from applications to infrastructure, then to business services, then to business capabilities, and gate each extension on the last one being trusted.
The expansion sequence is where the staged method earns its keep. First comes the management of the infrastructure underneath your first district, the utilities under the streets, so support teams can work from the model rather than around it. Then come business services, and this is the stage where the platform changes what it can say. An outage stops reading as a technology failure and starts reading as what the business is losing. Last come business capabilities, the city-planning layer, where technology investment can finally be argued in the same terms the board already uses. Each extension is gated, and the gate is an exit test you name before the stage begins, a plain sentence describing what will be true when the stage is done.
Stage | The city equivalent | What it makes possible |
|---|---|---|
Foundation | The survey and the land registry | Reports and routing that agree on who and where |
Crawl | The first settled district | Daily operations run against named applications |
Walk | Utilities under the streets | Support works from the model, not around it |
Run | The city's public face | Impact read in business terms, not technical ones |
Fly | The planning department | Investment argued through capabilities |
The gotcha is expanding on ambition. A coverage target or an enthusiastic tooling roadmap will happily pull you into the next stage while the current one is still doubted, and a stage entered without an exit test never finishes, it just fades into the one after it.
Stage 5, keep the register current or lose the city
Put recurring confirmation on the data, custodians re-certifying what they hold, health being measured, and a governance group meeting on the results.
A land registry that was accurate in the year of the survey is a historical document, not a working one. The mature version of this stage has three parts. Custodians periodically confirm, on the record, that what they hold is still true. Health is measured in plain terms, whether the data is complete, whether it is correct, whether it meets the standards you set. And a governance group actually meets on those measures, because a metric nobody reviews is a metric nobody fears. It is the same clock that keeps a configuration estate honest. Confirmation has to recur, or it never happened.
The gotcha is the launch-day map. Teams pour months into standing the model up, celebrate the diagram, and never set the clock. Two restructures later the model is quietly wrong, the teams that notice conclude it cannot be relied on, and that conclusion makes itself permanent.
The checklist
Survey - Put the reference data in order first, entities, business units, departments, locations, support groups, each with a named maintainer.
Settle - Model the application slice daily operations turn on, and write down what is out of scope and when you will revisit it.
Custodians - Name one owner per area of the model. Automation keeps the facts a scan can see, people keep the judgement.
Extend - Infrastructure, then business services, then capabilities, each stage gated on an exit test written before it starts.
Certify - Recurring confirmation, health measured as complete, correct and compliant, and a forum that meets on the results.
Common failure modes
The all-at-once city. The whole estate modelled in one programme, delivered as a reveal, doubted within a year. The fix is the gate, one stage at a time, with nothing breaking ground until the current district is settled, owned and certified.
Foundations discovered late. Reference data treated as someone else's admin until the first report fails to group and the first workflow fails to route. The fix is to make it Stage 1 on purpose, with named maintainers, even though it is the least glamorous work in the programme.
Custodians in name only. Ownership parked with the platform team because they were nearest, which is how a model becomes IT's data and stops being corrected by anyone else. The fix is custodians who sit close to the thing described, who can be asked whether the record is right and are expected to answer.
No declared edge. Nothing written down as out of scope, so everything creeps in and the stage never ends. The fix is a sentence per exclusion, naming what you are not modelling and roughly when you will look again.
The bottom line
The sequence is the strategy. Each stage of a CSDM adoption exists to earn the trust that pays for the next one, and a skipped stage is not time saved, it is debt moved downstream to the worst possible moment, the outage bridge or the budget round where the model is finally asked a question it cannot answer. If you protect one thing, protect the gate.
A service data model is built like a city, one district at a time, each one lived in before the next breaks ground.
P.S. Before your next planning round, write the exit test for the stage you are in now, one sentence, agreed with the people who fund the next one. If you cannot write that sentence, you are not mid-stage, you are mid-drift, and the model will tell the business before you do.