Wardley Mapping

Make a strategic landscape discussable by placing the user-visible value chain on one axis and the evolution of its components on the other. The map is a challengeable model of a situation, not a geographic diagram or a forecast.

In one minute

A Wardley Map combines:

• an anchor: the user or stakeholder need that gives the chain purpose;
• a value chain: components connected by visible dependencies;
• visibility: how close each component is to the user need;
• evolution: movement from novel Genesis through Custom Built, Product/Rental and Commodity/Utility;
• movement and context: pressures, constraints, doctrine and strategic options annotated as hypotheses.

Position is relative and contestable. Two teams may place the same component differently because they serve different users, use different evidence or define the component at different levels.

Best for: revealing strategic assumptions about build, buy, standardise, differentiate and sequence.
Avoid when: the team only needs a process timeline, treats the x-axis as calendar time, or wants the picture to make the decision automatically.

The problem it addresses

Strategy discussions often mix user value, technical architecture, market maturity and organisational preference in one list. Wardley Mapping separates those dimensions. It makes dependencies visible and asks whether each component is novel, bespoke, productised or utility-like in the relevant market.

The map does not calculate a correct strategy. It helps participants expose beliefs, challenge evidence and design tests before committing resources.

When to use it

Use Wardley Mapping when:

• a product or service depends on a changing technology landscape;
• teams debate build-versus-buy without a shared value chain;
• a differentiated user promise rests on increasingly standard components;
• platform, sourcing or modernisation choices must be sequenced;
• a scenario needs a concrete view of capabilities and dependencies;
• strategy assumptions need visible owners and review signals.

When not to use it

Do not use Wardley Mapping:

• as a substitute for user research or architecture evidence;
• to put every item on one undifferentiated map;
• to describe workflow time; use Value Stream Mapping instead;
• to infer inevitable evolution from the diagram;
• to hide political, regulatory or ecological forces outside a component chain;
• to copy another organisation's map without rebuilding its anchor and evidence.

Inputs required

Prepare:

• one bounded strategic question and decision horizon;
• a specific user or stakeholder need;
• current components and dependency evidence;
• evidence about market availability, ubiquity and certainty;
• known constraints, inertia, power and regulatory conditions;
• competing strategic hypotheses and decision rights.

Step-by-step process

1. Frame the decision

State the decision, scope, horizon and exclusions. “Map our architecture” is broad; “decide what to own in the claims-assistant platform over 18 months” is usable.

2. Anchor on user need

Name the user and observable need. Avoid anchoring on an internal project unless that project is genuinely the beneficiary.

3. Build the value chain

Ask what the need depends on, then what each component depends on. Keep components at a level where a strategic choice is possible.

4. Position visibility

Place the anchor high and less user-visible dependencies lower. Visibility is not importance: a low component can be strategically critical.

5. Position evolution

Use evidence to place components from Genesis to Commodity/Utility. Record disagreement and confidence rather than averaging silently.

6. Add movement and constraints

Mark likely evolution, inertia, standards, regulation, supply concentration and components that may split or converge. Treat arrows as hypotheses.

7. Challenge doctrine

Check whether basic practices—user focus, situational awareness, small teams, learning, bias reduction and appropriate use of standards—are strong enough to execute any move.

8. Generate strategic options

Consider options such as extracting a platform, buying a mature utility, protecting a genuinely novel capability, open-sourcing a component, or sequencing change around a constraint.

9. Decide tests and review

For each option, record the assumption, reversible test, guardrail, owner and remapping trigger. Archive versions so changes in the landscape remain visible.

AI automation lens

AI can cluster authorised component evidence, compare supplier claims, surface inconsistent placements and maintain a versioned assumption register.

It must not:

• scrape confidential supplier or employee data without authority;
• assign evolution from popularity alone;
• present a generated map as objective market truth;
• conceal source uncertainty or disagreement;
• make sourcing, workforce or ecosystem decisions without accountable review.

Visual model

Text alternative: dependencies descend from user need to supporting infrastructure; each component is also positioned from novel to utility-like, making strategic movement discussable.

Interactive example

Scenario

A regional bank wants an AI financial-coaching service. Trustworthy customer explanations are immature and differentiating; model orchestration is becoming productised; identity, storage and messaging are utility services.

Worked answer

Anchor on the customer's need for understandable, safe guidance. Keep explanation design close to the user and test it directly. Evaluate product options for orchestration rather than building by reflex. Treat identity and messaging as utilities with resilience and exit controls. Map data rights and regulatory assurance as explicit dependencies instead of invisible assumptions.

Facilitation notes

• Let participants place components independently before convergence.
• Ask for evidence and confidence, not only intuition.
• Split components that mix different maturity levels.
• Invite product, operations, architecture, procurement, risk and affected-user views.
• Keep “where it is” separate from “what we want to do.”

Expected output

• a bounded user-anchored value chain;
• evidence-qualified evolution positions;
• visible constraints, inertia and movement hypotheses;
• two or more strategic options;
• tests, guardrails, owners and remapping signals;
• an archived map version and assumption register.

Common mistakes

1. Evolution as time. The x-axis describes market evolution, not a delivery schedule.
2. Visibility as value. Low-visible infrastructure can be indispensable.
3. A map as fact. Positions are hypotheses supported to different degrees.
4. Architecture inventory. Components without a user anchor do not form a strategic value chain.
5. Strategy by arrow. A movement annotation does not prove the move will occur.
6. Ignoring power. Regulation, lock-in and ecosystem control need explicit treatment.

Quality checklist

• The strategic decision, user and need are explicit.
• Every component has a dependency path to the anchor.
• Visibility and evolution are not conflated.
• Positions cite evidence, confidence and disagreement.
• Constraints, inertia, power and regulation are visible.
• At least two options and one disconfirming test exist.
• Sourcing and workforce effects have accountable review.
• A remapping trigger and owner are recorded.

Template

Knowledge check

Question: A component sits far right on a Wardley Map. What can the team conclude?

A. It will be delivered late.
B. It is judged relatively standard and ubiquitous in this context.
C. It is unimportant.
D. It must be outsourced.

Answer: B. The position informs options but does not decide delivery timing, importance or sourcing.

Related tools

• Porter's Five Forces examines industry structure.
• Value Stream Mapping analyses workflow and delay.
• Scenario Planning tests choices across plausible futures.
• Stakeholder Mapping makes power and impact explicit.

References

1. Wardley, Simon. Wardley Maps. Official introduction and resources (opens in a new tab). Accessed 22 September 2026.
2. Wardley, Simon. “To Thine Own Self Be True.” Open book (opens in a new tab). Accessed 22 September 2026.
3. Górski, Tomasz. “Wardley Maps in Enterprise Architecture.” Proceedings of the 19th Workshop on Trends in Enterprise Architecture Research, 2025. Paper (opens in a new tab). Independent application; it does not establish universal causal effectiveness.

Method profile

• Primary output: a user-anchored, evidence-qualified strategic landscape and option portfolio.
• Decision level: product, platform, organisational or ecosystem strategy.
• Evidence strength: influential practitioner method with growing documented applications; independent comparative validation remains limited.
• Review trigger: changed user need, supplier maturity, standard, regulation, dependency or strategic commitment.