Stackbook Logo
economics-evolutionestablished · medium operational burden

Architecture Runway

Also known as: architectural-runway, enabler-epics

Intent

Build just enough technical foundation ahead of feature work so teams can deliver without constant rework.

Problem

Feature teams outrun the platform and accumulate shortcuts, while up-front architecture phases delay value. Foundations such as environments, shared services, and security controls arrive too late or too early.

Forces

  • •Features need technical capability to land
  • •Building too early wastes effort on unneeded generality
  • •Building too late forces rework and delay
  • •Planning horizons are short and uncertain

Solution

Overview

Architecture runway, from the Scaled Agile Framework, is the existing technical infrastructure that lets new features be implemented without major redesign. Think of an airplane needing enough runway to take off, but not a runway to the horizon.

Runway is a planning idea rather than a structure. It answers one question: can the teams start the next features without waiting for architecture work? If yes, runway is healthy. If the answer is no, the enabler backlog is behind the roadmap.

How it works

Enablers are pulled by upcoming features and sized to a bounded horizon.

Roadmap (next 3 increments)
  F1 Self-serve billing   needs: metering service, idempotent API
  F2 EU launch            needs: data residency, regional deploy
Enabler backlog:
  E1 metering service   (before F1)
  E2 regional stack     (before F2)
Runway = increments of features startable without new enablers

Enabler work comes in four common types: architectural, infrastructure, exploration, and compliance. Exploration enablers, such as spikes, reduce uncertainty before committing to larger builds. Review the enabler list at each planning cycle and drop items whose feature demand disappeared.

Pitfalls

  • Building enablers for features that are not yet committed
  • Letting enabler capacity be eaten by urgent features
  • Measuring runway only in story points, not in feature readiness
  • Treating all refactoring as runway instead of tying it to upcoming need

Key takeaways

  • Plan foundation for the next few increments only
  • Reserve a steady capacity share for enablers
  • Tie each enabler to a named upcoming feature
  • Replenish runway before it runs out

✓ When to Use

  • •Multiple teams share a platform or foundation
  • •Roadmap requires new technical capability soon
  • •Release trains or quarterly planning are in use

✗ When Not to Use

  • •Single-team products with simple needs
  • •No roadmap visibility at all
  • •Pure maintenance mode systems

Pros

  • +Balances speed and technical health
  • +Makes enabler work visible and plannable
  • +Reduces last-minute architecture crises

Cons

  • −Capacity split needs ongoing negotiation
  • −Forecasts can be wrong, wasting enablers
  • −Can become a vehicle for gold plating

Cost Profile

Infrastructure

Varies with enablers

Operational

Medium - planning discipline

Cognitive

Medium

Failure Modes

  • Runway exhausted, so features stall waiting on architecture

  • Enablers built for features that never arrive

  • Enabler work crowded out by feature pressure

Real-World Examples

Alternatives

    Related Patterns

    • technical-debt
    • platform-engineering

    Competency Domains

    economics evolutionrequirements constraints