​

Wardley Mapping

​

What is Wardley Mapping?

1. Value Chain (Y-axis): User needs → capabilities → components (top to bottom)
2. Evolution (X-axis): Genesis → Custom → Product → Commodity (left to right)
3. Movement: How components evolve over time
4. Dependencies: Component relationships

​

Evolution Stages

​

Component Positioning

​

Visibility (Y-axis: 0.0-1.0)

• 0.90-1.0: Direct user needs (what the user sees/interacts with)
• 0.60-0.89: Enabling capabilities (user-facing features)
• 0.30-0.59: Supporting components (business logic, services)
• 0.00-0.29: Infrastructure (databases, cloud, networks)

​

Evolution (X-axis: 0.0-1.0)

• 0.00-0.25 (Genesis): Novel, unproven (e.g., custom AI model, new algorithm)
• 0.25-0.50 (Custom): Bespoke, emerging (e.g., custom integration, specialized service)
• 0.50-0.75 (Product): Commercial products (e.g., Salesforce, Oracle, SAP)
• 0.75-1.00 (Commodity): Utility/cloud (e.g., AWS S3, Azure SQL, Auth0)

​

Example: Benefits Eligibility Chatbot (UK Government)

title DWP Benefits Eligibility Chatbot - Procurement Strategy

anchor Citizen [0.95, 0.63]
annotation 1 [0.35, 0.25] HIGH-RISK AI - Human oversight mandatory
annotation 2 [0.85, 0.92] Use GOV.UK services - don't build
annotation 3 [0.48, 0.45] Build custom - competitive advantage
note G-Cloud procurement for commodity/product components [0.75, 0.15]

component Citizen [0.95, 0.20]
component Benefits Eligibility Guidance [0.92, 0.25]
component Conversational Interface [0.85, 0.38]
component Human Review Queue [0.82, 0.45]
component GPT-4 LLM Service [0.68, 0.72]
component Benefits Rules Engine [0.65, 0.42]
component Bias Testing Framework [0.62, 0.35]
component GOV.UK Notify [0.55, 0.92]
component GOV.UK Design System [0.72, 0.75]
component Authentication [0.48, 0.68]
component DWP Benefits Database [0.45, 0.52]
component Cloud Hosting AWS [0.28, 0.95]
component PostgreSQL RDS [0.25, 0.92]

Citizen -> Benefits Eligibility Guidance
Benefits Eligibility Guidance -> Conversational Interface
Benefits Eligibility Guidance -> Human Review Queue
Conversational Interface -> GPT-4 LLM Service
Conversational Interface -> Benefits Rules Engine
Human Review Queue -> GOV.UK Notify
Conversational Interface -> GOV.UK Design System
Conversational Interface -> Authentication
Benefits Rules Engine -> DWP Benefits Database
Benefits Rules Engine -> Bias Testing Framework
GPT-4 LLM Service -> Cloud Hosting AWS
DWP Benefits Database -> PostgreSQL RDS
PostgreSQL RDS -> Cloud Hosting AWS

pipeline Benefits Eligibility Guidance [0.92, 0.25, 0.55]

evolve GPT-4 LLM Service 0.85 label Commoditizing fast
evolve Benefits Rules Engine 0.68 label Move to product in 18m

style wardley

​

Build vs Buy Analysis

​

Build (Genesis/Custom)

• ✅ Benefits Eligibility Guidance (0.25 - Genesis): Core user need, build custom
• ✅ Conversational Interface (0.38 - Custom): Competitive advantage, build
• ✅ Human Review Queue (0.45 - Custom): Compliance requirement, build
• ✅ Benefits Rules Engine (0.42 - Custom): Domain-specific, strategic IP
• ✅ Bias Testing Framework (0.35 - Custom): HIGH-RISK AI requirement

​

Buy - Product (G-Cloud)

• ✅ GPT-4 LLM Service (0.72 - Product): Commercial LLM via Azure/AWS
• ✅ Authentication (0.68 - Product): Use Auth0 or GOV.UK Verify

​

Buy - Commodity (G-Cloud)

• ✅ Cloud Hosting AWS (0.95 - Commodity): G-Cloud AWS
• ✅ PostgreSQL RDS (0.92 - Commodity): AWS managed database

​

Reuse (GOV.UK Services)

• ✅ GOV.UK Notify (0.92 - Commodity): Email/SMS notifications
• ✅ GOV.UK Design System (0.75 - Product): Frontend components, accessibility

​

Mapping Modes

​

Mode A: Current State Map

• Starting a new project
• Understanding existing system for modernization
• Identifying technical debt and inertia
• Baseline for future state mapping

​

Mode B: Future State Map (Desired)

• Strategic planning and roadmap development
• Technology modernization initiatives
• Cloud migration planning
• Post-requirements, pre-design phase

​

Mode C: Gap Analysis Map

• After creating both current and future state maps
• Investment prioritization
• Risk assessment
• Change management planning

​

Mode D: Vendor Comparison Map

• During vendor procurement
• After receiving vendor proposals
• Evaluating build vs buy decisions
• Assessing vendor lock-in risks

​

Mode E: Procurement Strategy Map (UK Government)

• Before creating SOW/RFP
• When deciding procurement routes (G-Cloud, DOS Outcomes, DOS Specialists)
• For build vs buy decisions at component level
• When identifying reuse opportunities

​

UK Government Digital Marketplace Strategy

​

GOV.UK Services Mapping

component GOV.UK Notify [0.45, 0.92]
component GOV.UK Pay [0.42, 0.90]
component GOV.UK Design System [0.72, 0.75]
component GOV.UK PaaS [0.28, 0.85]
component GOV.UK Verify [0.38, 0.68]

​

Technology Code of Practice Mapping

• Point 3 (Open Source): Annotate components that should use open source
• Point 5 (Cloud First): Highlight commodity cloud services
• Point 8 (Share/Reuse): Identify GOV.UK services and cross-government reuse
• Point 11 (Purchasing): Link to Digital Marketplace procurement strategy

​

Strategic Analysis

​

1. Build vs Buy Decision

• Genesis/Custom (< 0.50): Consider building if strategic differentiator
• Product (0.50-0.75): Buy from market unless very specific needs
• Commodity (> 0.75): Always use utility/cloud services

​

2. Inertia Factors

• Skills inertia (team expertise in legacy tech)
• Process inertia (established workflows)
• Vendor lock-in (contractual/technical dependencies)
• Cultural inertia (“we’ve always done it this way”)

​

3. Evolution Velocity

• Fast (moving 0.2+ in next 12 months): Monitor market closely
• Medium (0.1-0.2 movement): Standard planning
• Slow (< 0.1 movement): Stable, long-term investment

​

4. Risk Assessment

• Single vendor dependency
• Genesis component failure risk
• Rapid commoditization risk
• Skills gap risk

​

Usage

​

Basic Command

/arckit.wardley NHS appointment system

​

With Context

/arckit.wardley Create current state map for payment gateway
/arckit.wardley Future state map for cloud migration
/arckit.wardley Build vs buy analysis for authentication

​

Map Visualization

• Spot strategic patterns
• Identify clustering (areas of focus)
• See evolution trajectories
• Communicate strategy to stakeholders

​

Integration with ArcKit Workflow

​

Before Map Creation

/arckit.principles      # Establish architecture standards first
/arckit.requirements    # Define requirements before mapping

​

After Map Creation

/arckit.sow            # Create RFP for vendor procurement
/arckit.tcop           # Validate TCoP compliance
/arckit.ai-playbook    # Assess AI Playbook compliance (if AI)
/arckit.hld-review     # Review HLD against Wardley Map positioning

​

Output File Format

projects/{project-number}-{project-name}/wardley-maps/ARC-{PROJECT_ID}-WARD-{NNN}-v1.0.md

​

Map Quality Standards

​

Good Wardley Maps ✅

• All components have clear visibility and evolution positions
• Dependencies flow top-to-bottom (user needs → infrastructure)
• Evolution stages match reality (don’t misclassify commodity as Genesis)
• Strategic decisions (build/buy) align with evolution stage
• Inertia factors explicitly identified
• Movement/evolution predictions included
• Traceability to requirements and principles

​

Poor Wardley Maps ❌

• Arbitrary positioning without rationale
• Missing dependencies
• Building commodity components (waste)
• Buying for Genesis needs (no market exists)
• Ignoring inertia
• Static map with no evolution predictions
• No traceability to requirements

​

Common Mistakes to Avoid

​

1. Misclassifying Evolution Stage

• ❌ Positioning cloud services as “Custom” (they’re Commodity 0.90+)
• ❌ Positioning novel AI models as “Product” (they’re Genesis if truly novel)

​

2. Wrong Build vs Buy Decisions

• ❌ Building commodity components (e.g., custom auth instead of Auth0)
• ❌ Buying for Genesis needs (no market solutions exist yet)

​

3. UK Government Specific Mistakes

• ❌ Building custom notification service instead of GOV.UK Notify
• ❌ Not using GOV.UK Design System (accessibility, consistency)
• ❌ Wrong Digital Marketplace framework for evolution stage

​

4. AI Project Mistakes

• ❌ Not mapping human-in-the-loop as mandatory component
• ❌ Missing bias testing for HIGH-RISK AI
• ❌ Not flagging ATRS publication requirement

​

Related Commands

• /arckit.requirements - Define requirements first
• /arckit.principles - Establish principles before mapping
• /arckit.research - Research technology options
• /arckit.sow - Generate RFP for vendor procurement
• /arckit.diagram - Create visual architecture diagrams
• /arckit.hld-review - Review HLD against Wardley Map
• /arckit.roadmap - Create multi-year strategic roadmap