Framework library · Technology management
Wardley mapping
A Wardley map places every component needed to meet a user's need on two dimensions: up the page by how visible it is to the user, and across by how far it has evolved, from genesis through custom built and product to commodity. Components move right over time, and the stage each has reached says how to treat it: build and experiment on the left, buy products in the middle, use utilities on the right.
Use it when
- You are deciding what to build in house, what to buy and what to rent as a utility, across a whole service rather than one component at a time.
- A programme is spending engineering effort on components the market already sells, and you need to show it.
- You want to see which parts of your service are becoming commodities before you commit to building or selling them at product prices.
- Several teams need a shared picture of a service before they agree an architecture.
Avoid it when
- There is no identifiable user and need. The map hangs from a user; without one the positions are arbitrary.
- The decision is how to source one component. Score the routes directly with a build, buy or partner comparison.
- You need numbers. Positions on the map are judgements about evolution, not measurements. Put the money in a total cost of ownership or a business case.
How to run it
Name the user and the need
Start at the top with who the map is for and what they need: "an enterprise customer needs a private network slice for one site, ordered in a day".
List the components that meet the need
Work down the value chain: what the user touches, what that depends on, and so on down to compute and power. Place each component below the ones that depend on it.
Draw the dependencies
For each component, name what it depends on. The links show how a change low in the chain reaches the user.
Place each component by how evolved it is
Genesis: new and uncertain. Custom built: understood by a few and built for a purpose. Product: sold by several suppliers and compared on features. Commodity: standardised, compared on price and bought as a utility.
Compare how you source each with where it sits
Building a commodity in house, or buying a product for something still in genesis, are the mismatches the map exists to find.
Mark where components are moving
Note which will evolve in the next two to three years and what that changes. A custom component that is about to be sold as a product is a poor place for a large build.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Mapping the organisation chart or the systems list instead of a user need. Without a user at the top there is no value chain to read.
- Placing components by how good your own version is. Evolution describes the market: a component you built badly can still be a commodity.
- Treating the map as finished. Its use is in the argument about positions, and it needs redrawing as components move.
- Drawing every component. Keep to those that bear on the decision. A map with forty components cannot be read.
Where it comes from
Simon Wardley drew his first map in 2005, for an online photo service he ran, and set out the method in Wardley Maps, a book published chapter by chapter on Medium from 2016. Source.
Wardley mapping is the work of Simon Wardley. This workbench is Blue Prysm's own design, built from the published method, and is not endorsed by him.
Use it with
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.