mirrors/tractorjuice--arckit-gemini

Fork 0

Files

T

wehub-resource-sync 4050a9af7b chore: import upstream snapshot with attribution

2026-07-13 12:35:03 +08:00

24 KiB

Raw Permalink Blame History

Platform Strategy Design Guide

Guide Origin: Official | ArcKit Version: [VERSION]

/arckit:platform-design designs multi-sided platforms using Platform Design Toolkit (PDT) methodology with 8 canvases for ecosystem analysis.

What is Platform Design Toolkit
When to Use This Command
The 8 PDT Canvases
Prerequisites
Command Usage
UK Government Context
Integration with ArcKit Workflow
Examples
Common Pitfalls
Further Reading

What is Platform Design Toolkit

The Platform Design Toolkit (PDT) is an open-source methodology from Boundaryless.io for designing multi-sided platforms. It provides 8 interconnected canvases that help you systematically design platforms that:

Enable transactions between supply and demand sides
Reduce transaction costs (search, information, negotiation, coordination, enforcement)
Create network effects (same-side, cross-side, data, learning)
Build defensible moats through liquidity and ecosystem effects
Solve chicken-and-egg problems through bootstrapping strategies

Platform vs. Traditional Business

Traditional Business	Platform Business
Creates value directly	Enables others to create value
Linear value chain	Network of value exchanges
Owns resources	Orchestrates ecosystem
Revenue from products	Revenue from transactions/data
Economies of scale	Network effects

Examples of Multi-Sided Platforms

Government: GOV.UK (citizens ↔ services), Digital Marketplace (buyers ↔ suppliers)
Healthcare: NHS App (patients ↔ providers), booking platforms
Education: Online learning (students ↔ educators ↔ employers)
Procurement: G-Cloud (public sector ↔ suppliers)
Data: Data marketplaces (data providers ↔ data consumers)

When to Use This Command

✅ Use platform-design when

Multi-sided market: You have supply side + demand side (e.g., buyers & sellers, patients & providers)
Transaction-based: Value comes from enabling exchanges between parties
Network effects: More participants = more value for everyone
Ecosystem strategy: You're orchestrating, not just building
Government as a Platform (GaaP): Designing reusable services/APIs for other departments

❌ Don't use platform-design when

Single-sided product: Traditional SaaS/software for one user type
Linear workflow: Sequential process without network dynamics
Internal system: No external ecosystem (use /arckit:diagram instead)
Simple integration: Just connecting two systems (use /arckit:requirements)

Decision Tree

Is there a supply side AND demand side?
├─ No → Use /arckit:requirements + /arckit:diagram
└─ Yes → Does value increase with more participants?
    ├─ No → Traditional marketplace (use /arckit:requirements)
    └─ Yes → Use /arckit:platform-design ✅

The 8 PDT Canvases

1. Ecosystem Canvas

Purpose: Map all entities in your platform ecosystem

Key Questions:

Who are the platform's supply side entities? (sellers, providers, creators)
Who are the demand side entities? (buyers, consumers, learners)
What supporting entities exist? (regulators, payment processors, data providers)
How do they connect?

Output: Entity relationship diagram (Mermaid), entity classification table

Example (NHS appointment booking):

Supply: GP practices, hospitals, specialists
Demand: Patients, caregivers
Supporting: NHS Digital, ICB data services, payment gateway

2. Entity-Role Portraits

Purpose: Deep dive into 3-5 key entities to understand motivations

Key Questions:

What is this entity's context? (industry, size, maturity, constraints)
What performance pressures do they face? (cost, time, quality, risk)
What are their goals? (strategic objectives, outcomes)
What gains does the platform provide? (pain relievers, gain creators)

Output: 3-5 detailed portraits with context → pressures → goals → gains chain

Why Important: Without understanding entity motivations, you can't design valuable transactions.

3. Motivations Matrix

Purpose: Identify synergies and conflicts between entities

Key Questions:

Where do entity goals align? (win-win transactions)
Where do they conflict? (zero-sum dynamics, trust issues)
How can platform reduce conflicts? (governance, reputation, escrow)
What new collaborations are possible? (unexpected pairings)

Output: Cross-entity synergy/conflict matrix with mitigation strategies

Example: GP practices want fewer no-shows (cost) ↔ Patients want easy rebooking (convenience) → Platform sends SMS reminders + one-click reschedule

4. Transactions Board

Purpose: Design the core value exchanges enabled by the platform

Key Questions:

What transactions happen between entities? (bookings, payments, data sharing)
What transaction costs exist today? (search time, information asymmetry, contract negotiation)
How does the platform reduce each cost? (search algorithms, reviews, standard contracts)
What data flows enable transactions? (patient records, availability data, payment info)

Output: 10-20 transactions with cost analysis and platform services

Why Important: Transaction cost reduction is the core platform value proposition.

5. Learning Engine Canvas

Purpose: Design services that help ecosystem participants improve over time

Key Questions:

What data does the platform capture? (usage, ratings, outcomes, behaviors)
How can entities learn from this data? (benchmarks, recommendations, training)
What feedback loops drive improvement? (ratings → better matching, outcomes → better protocols)
What network learning effects exist? (more data → better algorithms → better outcomes)

Output: 5+ learning services with data sources and feedback loops

Example (G-Cloud):

Supplier performance data → Buyer recommendations
Procurement patterns → Cost benchmarks
Security assessments → Risk scoring

6. Platform Experience Canvas

Purpose: Map the end-to-end journeys for each entity type

Key Questions:

What is the onboarding journey? (signup → verification → first transaction)
What is the transaction journey? (search → negotiate → complete → rate)
What are the touchpoints? (web, mobile, API, support)
What emotions do users feel at each stage? (excited, frustrated, confused)
What business model supports this? (commission, subscription, freemium)

Output: 2+ journey maps with business model and unit economics

Why Important: Great platform mechanics mean nothing if the experience is poor.

7. Minimum Viable Platform (MVP) Canvas

Purpose: Design a validation strategy for your riskiest assumptions

Key Questions:

What assumptions must be true for the platform to work? (entities want this, price is right, liquidity achievable)
What is the minimum feature set for first transaction? (no bells and whistles)
How do you bootstrap liquidity? (seed supply side, incentivize demand, staged rollout)
What metrics validate success? (transaction volume, retention, NPS)
What is the validation strategy? (alpha test, pilot region, private beta)

Output: Assumption-risk matrix, MVP feature set, bootstrapping plan, validation metrics

Why Important: Platforms fail from lack of liquidity, not lack of features. MVP validates demand before scale.

8. Platform Design Canvas

Purpose: Synthesize all insights into cohesive platform strategy

Key Sections:

Value Proposition: What unique value does the platform create?
Ecosystem: Who participates and why?
Transactions: What exchanges happen and how?
Learning: How does the platform get smarter?
Governance: What rules/policies guide behavior?
Business Model: How does the platform capture value?

Output: One-page strategic overview synthesizing all 8 canvases

Why Important: Ensures all design decisions cohere into a viable platform strategy.

Prerequisites

Required

Architecture Principles (/arckit:principles)
- Platform governance principles will reference these
- Example: "Open Standards" principle → platform uses open APIs

Recommended (enables auto-population)

Stakeholder Analysis (/arckit:stakeholders)
- Stakeholders → Entity portraits
- Drivers → Performance pressures
- Goals → Entity goals
Requirements (/arckit:requirements)
- Functional requirements → Platform capabilities
- Data requirements → Data flows in transactions
- Integration requirements → Supporting entities
Wardley Maps (/arckit:wardley)
- Component evolution → Build vs. buy decisions
- Example: "Payment processing" at Commodity (0.9) → Use Stripe/GOV.UK Pay, don't build

Workflow Order

1. /arckit:principles      → Governance foundation
2. /arckit:stakeholders    → Entity portraits
3. /arckit:requirements    → Platform capabilities
4. /arckit:wardley         → Build vs. buy strategy
5. /arckit:platform-design → Synthesize platform strategy ✅
6. /arckit:diagram         → Architecture diagrams
7. /arckit:backlog         → Implementation roadmap

Command Usage

Basic Usage

/arckit:platform-design Design NHS appointment booking platform

Output: Creates projects/<id>/ARC-<id>-PLAT-v1.0.md with all 8 canvases

Auto-versioning: Re-running this command when a document already exists automatically increments the version (minor for refreshed content, major for changed scope) instead of overwriting.

Advanced Usage

/arckit:platform-design Design Digital Marketplace for training services connecting:
- Supply: Training providers, independent trainers, content creators
- Demand: Public sector organizations, L&D departments, individual learners
- Supporting: Accreditation bodies (e.g., CPD Standards Office), payment gateway, LMS integrations

Focus on:
1. Liquidity bootstrapping (solve chicken-and-egg)
2. Quality assurance (accreditation, reviews, outcomes)
3. GaaP integration (GOV.UK Pay, Notify, Design System)
4. Data sharing (GDPR compliance, learner records portability)

What the Command Does

Checks prerequisites: Validates architecture-principles exists, reads stakeholders/requirements/wardley if available
Creates project: Uses create-project.sh to create/find numbered project directory
Auto-populates from context:
- Stakeholders → Entity portraits (context, pressures, goals)
- Requirements → Platform capabilities (FR/DR/INT requirements)
- Wardley maps → Build vs. buy decisions (component evolution)
- Architecture principles → Governance principles
Generates all 8 canvases: Complete PDT methodology with depth
Adds UK Government context: GaaP, TCoP, Service Standard, Digital Marketplace
Creates traceability: Links to stakeholders, requirements, principles, Wardley maps
Writes file: Uses Write tool to create markdown document (avoids token limit)
Shows summary: Displays key metrics, entity counts, transaction types (not full document)

UK Government Context

Government as a Platform (GaaP)

The UK Government's GaaP strategy treats common capabilities as platforms:

Platform	Supply Side	Demand Side	Transactions
GOV.UK Pay	Payment providers (Stripe, Worldpay)	Public sector services	Payment processing
GOV.UK Notify	Telcos (SMS, email providers)	Government services	Notifications
Digital Marketplace	Suppliers (G-Cloud, DOS)	Public sector buyers	Procurement
GOV.UK Design System	Design contributors	Service teams	UI components, patterns
GOV.UK Verify (deprecated)	Identity providers	Services needing auth	Identity verification

Platform Design Principles (from GaaP):

Common components: Reusable across departments
Open standards: Avoid vendor lock-in
Self-service: Low friction onboarding
API-first: Programmatic access
Data portability: User owns their data

Technology Code of Practice (TCoP)

Platform designs must align with TCoP points:

Point 3 (Be open and use open source): Platform APIs should use open standards (REST, GraphQL, OAuth2)
Point 5 (Use cloud first): Platform infrastructure on AWS/Azure/GCP
Point 8 (Share, reuse and collaborate): Leverage GOV.UK common platforms
Point 11 (Define your purchasing strategy): Digital Marketplace for commercial services

Service Standard

Platform services assessed against 14 points:

Point 2 (Solve a whole problem for users): Platform solves transaction costs, not just matching
Point 5 (Make sure everyone can use the service): WCAG 2.2 AA accessibility
Point 9 (Create a secure service): Secure by Design (NCSC CAF)
Point 13 (Use and contribute to open standards): Open Data Contract Standard for data products

Digital Marketplace Integration

Platform designs often need to procure services via Digital Marketplace:

G-Cloud: Buy cloud software/support (e.g., CRM platform, analytics tools)
DOS: Commission custom development (e.g., platform MVP, integration work)

Use /arckit:gcloud-search to find relevant services, /arckit:dos to generate procurement docs.

Integration with ArcKit Workflow

How platform-design Uses Other Artifacts

graph TD
    A[ARC-000-PRIN-v1.0.md] -->|Governance| H[ARC-id-PLAT-v1.0.md]
    B[ARC-id-STKE-v1.0.md] -->|Entity Portraits| H
    C[ARC-id-REQ-v1.0.md] -->|Capabilities| H
    D[wardley-maps/] -->|Build vs Buy| H

    H -->|Informs| E[diagrams/ARC-id-DIAG-001-v1.0.md]
    H -->|Informs| F[ARC-id-BKLG-v1.0.md]
    H -->|Informs| G[ARC-id-SOW-v1.0.md]

    style H fill:#e1f5ff

Input Artifacts:

ARC-000-PRIN-v1.0.md → Governance principles for platform
ARC-<id>-STKE-v1.0.md → Entity portraits (stakeholders = entities)
ARC-<id>-REQ-v1.0.md → Platform capabilities (FR/DR/INT requirements)
wardley-maps/ARC-<id>-WARD-*.md → Build vs. buy strategy (component evolution)

Output Artifacts (created after platform-design):

diagrams/ARC-<id>-DIAG-001-v1.0.md → C4 diagrams of platform technical architecture
ARC-<id>-BKLG-v1.0.md → MVP features converted to user stories, sprint plan
ARC-<id>-SOW-v1.0.md → RFP for platform development (if procuring vendor)
ARC-<id>-EVAL-v1.0.md → Vendor scoring (if multiple proposals)
ARC-<id>-TRAC-v1.0.md → Requirements → Platform components → Tests

Typical Workflow

# Phase 1: Foundation
/arckit:principles       # Define governance principles
/arckit:stakeholders     # Analyze ecosystem entities

# Phase 2: Strategy
/arckit:platform-design  # Design platform strategy (8 canvases)
/arckit:wardley          # Map component evolution (build vs buy)

# Phase 3: Requirements
/arckit:requirements     # Define technical requirements
/arckit:data-model       # Design data architecture
/arckit:diagram          # Create C4/deployment diagrams

# Phase 4: Procurement (if buying)
/arckit:research         # Research platform vendors
/arckit:sow              # Create RFP
/arckit:evaluate         # Score proposals

# Phase 5: Delivery (if building)
/arckit:backlog          # Create sprint plan
/arckit:hld-review       # Review high-level design
/arckit:dld-review       # Review detailed design

Examples

Example 1: NHS Appointment Booking Platform ✅

Use Case: Enable patients to book GP/specialist appointments across trusts

Why Platform Design:

Supply side: GP practices, hospitals, specialists (own calendars/availability)
Demand side: Patients, caregivers (need appointments)
Transaction: Appointment booking (reduces search time, phone wait times)
Network effects: More providers → more choice → more patients → more data → better matching

Key Canvases:

Ecosystem: NHS trusts, GP practices, patients, NHS Digital (identity), ICBs (data governance)
Transactions: Book appointment, reschedule, cancel, SMS reminder, outcomes reporting
Learning Engine: No-show prediction, optimal appointment duration, provider ratings
MVP: Pilot with 3 GP practices in one ICB, 1000 patients, validate 20% reduction in phone bookings

Outcome: Platform design feeds into technical requirements, data model (patient records, calendars), integration requirements (NHS Login, PDS, GP systems), architecture diagrams.

Example 2: Digital Marketplace for Training Services ✅

Use Case: Connect public sector organizations with training providers

Why Platform Design:

Supply side: Training providers, independent trainers, content creators
Demand side: Public sector L&D departments, individual civil servants
Transaction: Course booking, certification, outcomes tracking
Network effects: More providers → more courses → more learners → more data → better recommendations

Key Canvases:

Ecosystem: Training suppliers, accreditation bodies (CPD Standards Office), public sector orgs, learners, LMS integrations
Transactions: Search courses, compare providers, book training, track CPD, share certificates
Learning Engine: Course effectiveness (pre/post assessments), provider quality (ratings + outcomes), skill gap analysis
MVP: 10 accredited providers, 5 departments, 100 learners, validate 30% cost reduction vs. traditional procurement

Outcome: Informs G-Cloud service search (LMS, video platforms), DOS procurement (custom development), requirements (GDPR for learner data, WCAG 2.2 AA), Service Standard assessment.

Example 3: Internal Employee Directory ❌

Why NOT Platform Design:

No multi-sided market (just employees looking up colleagues)
No transactions (just information retrieval)
No network effects (value doesn't increase with more users)
Linear workflow (search → view profile)

Correct Approach: Use /arckit:requirements for functional requirements, /arckit:diagram for architecture.

Example 4: Data Marketplace for Local Authorities ✅

Use Case: Enable councils to share/buy datasets (e.g., planning data, environmental sensors)

Why Platform Design:

Supply side: Local authorities with datasets, IoT sensor providers
Demand side: Local authorities needing data, researchers, urban planners
Transaction: Data product licensing (Open Data Contract Standard v3.0.2)
Network effects: More data sources → richer analytics → more demand → more supply

Key Canvases:

Ecosystem: 317 local authorities, central government, researchers, data processors, cloud storage (AWS S3)
Transactions: Publish data product, license dataset, query API, manage access controls, data quality SLA
Learning Engine: Data quality scoring (completeness, timeliness), usage patterns → recommendations, schema evolution
MVP: 5 councils, 20 datasets (planning, transport, environment), 10 consumers, validate 50% faster data access vs. FOI requests

Synergy: Use /arckit:data-mesh-contract after platform-design to define data product contracts (SLAs, schemas, governance).

Common Pitfalls

1. Confusing Platform with Product

Mistake: Designing a single-sided product but calling it a platform.

Example: "HR platform for managing employees" → This is HR software (product), not a platform (no multi-sided market).

Fix: If there's no supply + demand + transactions, use /arckit:requirements instead.

2. Ignoring Liquidity Bootstrapping

Mistake: Designing platform mechanics without solving chicken-and-egg problem.

Example: "We'll launch with perfect matching algorithm" → But no supply to match with demand.

Fix: MVP Canvas should prioritize bootstrapping strategy (seed supply, incentivize demand, staged rollout).

3. Over-Engineering the MVP

Mistake: Building all 8 canvases worth of features before first transaction.

Example: "We need learning engine, advanced analytics, and mobile app before launch."

Fix: MVP Canvas should identify minimum features for first transaction (e.g., manual matching, basic profiles, email notifications).

4. Neglecting Transaction Costs

Mistake: Focusing on matching but ignoring why transactions are costly today.

Example: "Platform matches patients with doctors" → But doesn't address trust (doctor credentials), coordination (scheduling conflicts), enforcement (no-shows).

Fix: Transactions Board should analyze all 5 transaction costs and how platform reduces each.

5. Forgetting Data Governance

Mistake: Designing data flows without GDPR/data protection considerations.

Example: "Platform shares patient data with all providers for better matching."

Fix: Platform Design Canvas should include governance rules (consent, data minimization, right to erasure). Use /arckit:dpia for GDPR compliance.

6. Assuming Network Effects

Mistake: "More users = more value" without understanding why.

Example: "More doctors on platform = better outcomes" → Not if matching algorithm is poor or supply/demand is imbalanced.

Fix: Learning Engine Canvas should explain specific feedback loops (e.g., more bookings → better no-show prediction → better scheduling → fewer wasted slots).

24 KiB Raw Permalink Blame History

Platform Strategy Design Guide

Table of Contents

What is Platform Design Toolkit

Platform vs. Traditional Business

Examples of Multi-Sided Platforms

When to Use This Command

✅ Use platform-design when

❌ Don't use platform-design when

Decision Tree

The 8 PDT Canvases

1. Ecosystem Canvas

2. Entity-Role Portraits

3. Motivations Matrix

4. Transactions Board

5. Learning Engine Canvas

6. Platform Experience Canvas

7. Minimum Viable Platform (MVP) Canvas

8. Platform Design Canvas

Prerequisites

Required

Recommended (enables auto-population)

Workflow Order

Command Usage

Basic Usage

Advanced Usage

What the Command Does

UK Government Context

Government as a Platform (GaaP)

Technology Code of Practice (TCoP)

Service Standard

Digital Marketplace Integration

Integration with ArcKit Workflow

How platform-design Uses Other Artifacts

Typical Workflow

Examples

Example 1: NHS Appointment Booking Platform ✅

Example 2: Digital Marketplace for Training Services ✅

Example 3: Internal Employee Directory ❌

Example 4: Data Marketplace for Local Authorities ✅

Common Pitfalls

1. Confusing Platform with Product

2. Ignoring Liquidity Bootstrapping

3. Over-Engineering the MVP

4. Neglecting Transaction Costs

5. Forgetting Data Governance

6. Assuming Network Effects

Further Reading

Platform Design Toolkit (PDT)

Platform Economics

UK Government Resources

Related ArcKit Commands

24 KiB

Raw Permalink Blame History