Wardley Mapping
Map components by the value they provide and how evolved they are, from genesis to commodity.
To an executive
A single picture of what you offer, what it depends on and how mature each part is lets leaders see the landscape and agree where to invest, buy or rent.
To an engineer
Map components from user need down to infrastructure, and place each by maturity. Experiment with novel parts, buy products, and rent commodities instead of building them.
The idea
Simon Wardley developed his maps to give strategy the thing it usually lacks: a picture of the landscape. A Wardley map has two axes:
- The value chain, running from the user and their need at the top, through the components that serve it, down to the invisible infrastructure at the bottom.
- Evolution, running left to right through genesis, custom-built, product and commodity.
Components drift to the right over time as markets mature. Strategy follows from position: build what is novel, buy what is a product, and rent what is a utility. Because the map shows movement, it also lets you anticipate what will commoditise next.
Why it works
It makes the landscape visible. Most strategy documents are lists of goals. A map shows the components, their dependencies and their maturity on one page, so people can point at the same thing.
Position suggests the method. Novel components need experimentation; commodities need efficiency and outsourcing. Treating them the same way wastes money in one place and stifles innovation in the other.
It exposes disagreement early. When two people place the same component in different columns, they have found an assumption worth discussing.
Where it applies
- Sourcing and build-versus-buy decisions, spotting what the market now offers as a product or utility.
- Technology strategy and roadmaps, anticipating which components will commoditise and planning around it.
- Vendor selection, checking that a supplier's offering matches how evolved the need really is.
- Operating model design, matching team styles (Wardley's pioneers, settlers and town planners) to component maturity.
How to apply
- Start with the user and their need, at the top of the map.
- List the components that meet that need, and draw their dependencies downwards.
- Place each component on the evolution axis, and discuss disagreements.
- Look for mismatches: custom work on commodities, or rigid processes around novel components.
- Add movement, marking what is evolving, and turn the insights into sourcing and roadmap decisions.
Example scenario
A platform team was proud of its custom container orchestration and asked for more people to extend it. The enterprise architect ran a mapping session with the team and its customers.
The map placed the team's users and their deployment needs at the top, and orchestration far down the chain in the commodity column, where managed services were widely available. Seen that way, the custom work was not differentiating. Moving to a managed service freed most of the team for work higher up the chain that customers did notice.
Questions to ask
- Where does each component sit on the evolution axis, and do we agree?
- Are we custom-building something the market now sells as a product or utility?
- What is likely to commoditise in the next two years, and what would that change for us?
When not to use it
- Small, tactical decisions, where drawing a map costs more than the decision is worth.
- When nobody will act on the result, since the value comes from the conversation and the decisions, not the diagram.
How it misleads you
Treating maps as precise measurements. Placements are judgements, and a confident-looking map can hide weak assumptions. Use maps as tools for conversation and shared understanding, and revisit them as the landscape moves.
In the wild
Further reading
Last reviewed · Suggest an improvement