Skip to main content
Featured

Platform Engineering Evolution: From Custom Scripts to Self-Service

January 18, 2025By Steve Winter5 min read
...
wardley-maps

A Wardley map showing the evolution of platform engineering capabilities, from basic scripts to sophisticated developer platforms.

Legend

Component
High Inertia
Dependency
Annotation

Understanding Platform Engineering Through Wardley Mapping

Platform engineering is moving from a nascent discipline to a core capability. This Wardley map visualizes where different components sit in their evolution and helps you make strategic decisions about what to build, buy, or ignore.

Reading the Map

The Axes

Vertical (Visibility/Value): How visible is this to users? Components at the top directly serve developer needs. Components at the bottom are infrastructure nobody sees but everyone depends on.

Horizontal (Evolution): How mature is this capability?

  • Genesis (0-25%): Experimental, unique, requires custom development
  • Custom (25-50%): Understood but not standardized, still requires significant work
  • Product (50-75%): Commercial or open-source products available
  • Commodity (75-100%): Standardized, utility-like, little differentiation

Key Insights from This Map

1. Legacy Inertia Is Your Enemy

The "Custom Scripts" component sits high in visibility but low in evolution. This is technical debt at its worst—highly visible to users but stuck in the genesis phase. The "inertia" marker indicates resistance to change (political, cultural, or technical).

Action: Actively migrate away from custom scripts toward Infrastructure as Code. Set a sunset date.

2. Self-Service Is Your Differentiator

The Self-Service Portal sits in the product phase (0.55) but could evolve further. This is where you create competitive advantage—making it radically easier for developers to get what they need.

Action: Invest here. Don't build from scratch (use Backstage, Port, or similar), but customize ruthlessly for your developers.

3. Don't Rebuild Commodities

Container Runtime, Cloud APIs, and Authentication are all commodities (75-100% evolution). These are solved problems.

Action: Use off-the-shelf solutions. Your time is better spent elsewhere.

4. Kubernetes Is Still Evolving

At 70% evolution, Kubernetes is solidly in the "Product" phase but not yet commodity. It's complex and requires expertise.

Action: If you're not already on Kubernetes, consider managed services (EKS, GKE) or alternatives (Cloud Run, Fargate). Don't build your own control plane.

Strategic Movements

Near-Term (Next 6 Months)

  1. Reduce Custom Scripts: Migrate manual processes to Infrastructure as Code
  2. Enhance Self-Service: Add common workflows (database provisioning, environment creation)
  3. Standardize Observability: Consolidate on one stack, make it self-service

Medium-Term (6-12 Months)

  1. Platform as a Product: Treat your platform team like a product team—talk to customers (developers), measure satisfaction, iterate fast
  2. Golden Paths: Create opinionated, pre-approved workflows for common tasks
  3. Policy as Code: Move from manual approvals to automated guardrails

Long-Term (12+ Months)

  1. Full Self-Service: Developers provision everything they need without tickets
  2. Shift Security Left: Automated security scanning, policy enforcement
  3. FinOps Integration: Cost visibility and optimization built into the platform

Dependencies and Flow

Notice how components depend on each other:

  • Self-Service Portal depends on API Gateway and Authentication (both commodities—good!)
  • CI/CD Pipeline depends on Container Registry and Kubernetes (products—manageable)
  • Infrastructure as Code depends on Cloud APIs (commodity—excellent)

This dependency structure tells you where risk lies. If a component depends on something in genesis, that's a red flag. If it depends on commodities, you're building on solid ground.

How to Use This Map

  1. Plot Your Current State: Where are your components today? Be honest about evolution (custom scripts are genesis, no matter how long you've had them).

  2. Identify Inertia: What's preventing evolution? Technical debt? Skills gap? Organizational resistance?

  3. Plan Movements: Where should components move? (Usually: leftward along the evolution axis)

  4. Make Build/Buy Decisions:

    • Genesis/Custom: Consider building if it's your differentiator
    • Product: Buy or use open source
    • Commodity: Always use existing solutions
  5. Review Quarterly: The landscape evolves. What was custom-built last year might be a product today.

Common Patterns to Watch

The "Pioneer-Settler-Town Planner" Pattern: You need different teams for different evolution stages:

  • Pioneers: Build novel solutions (genesis)
  • Settlers: Productize and scale (custom → product)
  • Town Planners: Operate commodities efficiently

Don't ask your pioneers to run production systems. Don't ask your town planners to invent new things.

The "Commodity Trap": Building custom solutions for commodity problems. If it's evolved to commodity, your custom version is waste.

The "Product Plateau": Getting stuck in the product phase when you should move to commodity. Example: Running your own Kubernetes when managed services exist.

Next Steps

  1. Create Your Own Map: Plot your specific platform components
  2. Gather Team Input: Different perspectives reveal blind spots
  3. Identify Top 3 Movements: What needs to evolve most urgently?
  4. Share Broadly: Use the map in strategy discussions, quarterly planning, hiring decisions

Wardley mapping isn't about perfection—it's about shared understanding and better decisions. Start simple, iterate, and use it as a conversation tool.


Further Reading