Quick Navigation
- Start here — Architecture and delivery
- What architecture runway is
- Phased implementation
- Managing dependencies
- Keeping teams unblocked
- Spikes and POCs
- When architecture goes wrong
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Architecture that cannot be delivered is just a drawing. Delivery without architecture is just code that will need rewriting. I've seen architects produce designs that teams couldn't implement, and teams produce code that architects didn't approve. The result is either slow delivery or incoherent architecture.
Architecture and delivery are not in conflict — they require each other. Architecture runway is the foundation of implemented architecture that lets teams deliver features without first doing design work — keeping delivery fast while architecture stays coherent.
The architect's delivery responsibility: keep teams unblocked — not just be correct.
Keep it in mind.
1. Architecture and delivery — Enabling, not controlling
In many organisations, architecture and delivery are in tension. Architects produce designs that teams can't implement. Teams produce code that architects didn't approve. The result is either slow delivery or incoherent architecture.
The relationship between architecture and delivery falls into one of four modes:
flowchart TD
REL["🏛️ Architecture ↔ Delivery"]
REL --> BLOCK["🚫 Architecture blocks delivery\nDesigns too far ahead\nDecisions too rigid\nTeams wait for approval"]
REL --> DRIFT["🌀 Architecture is ignored\nTeams build without guidance\nDebt accumulates\nSystem becomes incoherent"]
REL --> BALANCE["✅ Architecture enables delivery\nDecisions stay ahead of teams\nTeams move without waiting\nArchitecture stays coherent"]
REL --> RUNWAY["🛫 Architecture runway\nFoundation is built first\nTeams deliver features on top\nBoth move fast"]
The target: architecture enables delivery. Decisions are made just in time — not too early (wasteful) and not too late (blocking). The runway provides the foundation so teams don't have to solve architectural problems while building features.
Architecture that blocks delivery isn't doing its job. Architecture that is ignored isn't doing its job. The sweet spot is architecture that is just ahead — enabling, not controlling.
The architect stays one step ahead — making decisions before teams need them, not after teams are blocked.
Try it yourself — The mode check
Which mode describes your architecture-delivery relationship right now?
| Mode | Evidence |
|---|---|
| Architecture blocks delivery | e.g. Teams wait weeks for architecture approval |
| Architecture is ignored | |
| Architecture enables delivery | |
| Architecture runway |
If you're in the first two modes, the problem isn't the teams. It's the architecture process.
2. What architecture runway is — And why it matters in agile contexts
In agile delivery, teams need to start building features immediately. But some architectural decisions — choosing the database, setting up the messaging infrastructure, defining the API framework — must be made before feature work begins.
Architecture runway is the set of architectural decisions and infrastructure that is implemented before feature teams need it. It's the road surface that is laid before cars can drive on it.
flowchart LR
RUNWAY["🛫 Architecture Runway"]
RUNWAY --> FOUND["🏗️ Foundation\nTechnology selection\nInfrastructure provisioned\nCore frameworks chosen"]
FOUND --> STRUCT["📐 Structure\nComponent boundaries defined\nAPI contracts established\nIntegration patterns chosen"]
STRUCT --> TEAM["👥 Teams\nDeliver features on top\nof the established runway\nNo architectural blockers"]
FOUND -->|"Built by"| ARCH["Architects + Platform team"]
STRUCT -->|"Built by"| ARCH
TEAM -->|"Built by"| DEV["Delivery teams"]
What runway includes: Technology decisions — databases, frameworks, cloud services, libraries. Infrastructure — environments, CI/CD, monitoring, logging. Core patterns — how components communicate, how data flows, how errors are handled. Shared services — authentication, logging, configuration, feature flags. Standards — API conventions, coding standards, testing practices.
What runway does NOT include: Feature logic — that's the team's responsibility. UI design details — that's design's responsibility. Business rules — that's product's responsibility.
How far ahead should runway be? Too short — 1 sprint ahead. Teams blocked frequently — runway runs out. Just right — 2-4 sprints ahead. Teams have clear path; decisions based on real needs. Too long — 6+ months ahead. Wasted effort — requirements change before runway is used.
Runway = architecture implemented ahead of delivery — teams build features on a prepared foundation.
Try it yourself — The runway check
How much runway do you have right now?
| Question | Your answer |
|---|---|
| How many sprints ahead are architectural decisions made? | |
| Are teams blocked waiting for architectural decisions? | |
| Is the runway being replenished as fast as it's consumed? |
If teams are blocked, your runway is too short. If decisions were made 6 months ago and requirements changed, it's too long.
3. Phased implementation — How to sequence delivery without sacrificing coherence
You can't build everything at once. But sequencing delivery randomly creates architectural debt — partial implementations that become permanent, dependencies that block later work, and integrations that are never finished.
Phased implementation sequences delivery so that each phase builds on the last, maintaining architectural coherence throughout.
flowchart TD
PHASE["🪜 Phased Implementation"]
PHASE --> P1["Phase 1: Foundation\nCore infrastructure\nShared services\nAPI framework\nBasic CI/CD"]
P1 --> P2["Phase 2: Core Capabilities\nFirst bounded contexts\nIntegration patterns\nData ownership established"]
P2 --> P3["Phase 3: Expansion\nAdditional capabilities\nCross-context integration\nAdvanced features"]
P3 --> P4["Phase 4: Optimisation\nPerformance tuning\nCost optimisation\nAdvanced patterns"]
Sequencing principles: Build shared foundations first — infrastructure, authentication, logging, CI/CD. Build the spine before the flesh — end-to-end integration for one flow, then add more. Sequence by dependency — what must exist before what can be built. Sequence by risk — tackle the hardest, riskiest parts early. Sequence by value — deliver business value at every phase, not just at the end.
The walking skeleton approach: build the smallest possible end-to-end flow. One request → one service → one database → one response. Prove the integration works. Expand from there — add capabilities, add services, add complexity. The skeleton stays working at every step.
Phase delivery by dependency and risk — foundations first, spine before flesh, value at every step.
Try it yourself — The phase plan
What are your phases?
| Phase | What's delivered | What value does it deliver? |
|---|---|---|
| Phase 1: Foundation | ||
| Phase 2: Core Capabilities | ||
| Phase 3: Expansion |
If any phase doesn't deliver business value, it's not a phase. It's preparation.
4. Managing technical dependencies — Identifying what must be in place before what
Teams can't build what they need if what they depend on doesn't exist yet. Technical dependencies are the invisible chains that slow delivery — and they're often discovered too late.
Dependency management means identifying, mapping, and sequencing technical dependencies before teams hit them.
flowchart TD
DEP["⛓️ Dependency Management"]
DEP --> ID["🔍 Identify\nWhat does each team need\nfrom other teams or systems?"]
ID --> MAP["🗺️ Map\nVisualise the dependency graph\nFind the critical path"]
MAP --> SEQ["📅 Sequence\nWhat must be built first?\nWhat can be parallelised?"]
SEQ --> RISK["⚠️ Assess risk\nWhat if this dependency is late?\nWhat is the mitigation?"]
Types of technical dependencies: Infrastructure dependencies — "we need the database provisioned before we can build." API dependencies — "we need the Orders API before we can build the Fulfilment feature." Data dependencies — "we need the customer data model defined before we can build the dashboard." Integration dependencies — "we need the event bus configured before we can publish events." Decision dependencies — "we need the security model approved before we can design authentication."
Dependencies discovered during sprint planning are already too late — they should be identified during architecture planning.
Map dependencies before teams hit them — dependency surprises during sprint planning are architectural failures.
Try it yourself — The dependency map
What dependencies are your teams carrying?
| Dependency | Provider | Consumer | Type | Due by | Risk |
|---|---|---|---|---|---|
| e.g. Order API v2 | Ordering team | Fulfilment team | Hard | Sprint 4 | High — contract not finalised |
Any "hard" dependency without a due date is a blocker waiting to happen.
5. Keeping teams unblocked — The architect's delivery responsibility
Architects can make correct decisions and still fail if teams are blocked waiting for those decisions. The quality of an architect's delivery contribution is measured by team velocity, not by the elegance of their designs.
Keeping teams unblocked requires proactive work — staying ahead of team needs, removing blockers before they impact velocity, and making decisions fast enough that teams don't wait.
flowchart TD
UNBLOCK["🔓 Keeping Teams Unblocked"]
UNBLOCK --> PRE["🔮 Anticipate\nStay 2-4 sprints ahead\nIdentify upcoming decisions"]
UNBLOCK --> DECIDE["⚡ Decide quickly\nTimebox decisions\nDelegate when possible"]
UNBLOCK --> DEFAULT["📋 Provide defaults\nSensible defaults teams can adopt\nWithout waiting for perfection"]
UNBLOCK --> ESC["🚨 Escalate\nDecision stalling? Escalate\nDo not let teams wait"]
PRE --> OUT["✅ Teams move without waiting"]
DECIDE --> OUT
DEFAULT --> OUT
ESC --> OUT
Principles for keeping teams unblocked: Stay ahead — know what teams will need 2-4 sprints from now. Decide quickly — a good decision now is better than a perfect decision in two weeks. Provide defaults — give teams a sensible default they can adopt without waiting. Delegate routine decisions — not every decision needs an architect. Escalate stalled decisions — don't let teams wait while you deliberate.
The architect's delivery job isn't to have all the answers — it's to ensure teams are never blocked waiting for architectural answers.
Team velocity is the architect's delivery metric — if teams are blocked, the architect is not doing their job.
Try it yourself — The blocker audit
How many architectural blockers did your teams hit last sprint?
| Blocker | What was it? | How long did teams wait? | Could it have been anticipated? |
|---|---|---|---|
If the answer to the last column is "yes," the architect was behind.
6. Architecture spikes and proof of concepts — Reducing risk before committing
Some architectural decisions are high-risk — you don't know if the chosen technology will work, if the integration pattern will scale, or if the approach is feasible. Making these decisions without evidence is gambling.
Spikes and proof of concepts are timeboxed experiments that reduce uncertainty before committing to an architectural direction.
flowchart TD
RISK["⚠️ Architectural Risk"]
RISK --> SPIKE["🔬 Spike\nTimeboxed investigation\nAnswer a specific question\nThrowaway code acceptable"]
RISK --> POC["🧪 Proof of Concept\nWorking implementation\nProves feasibility\nMay become foundation"]
SPIKE --> Q1["Does this API\nwork for our use case?"]
SPIKE --> Q2["Can this database\nhandle our data volume?"]
SPIKE --> Q3["Is this integration\npattern viable?"]
POC --> W1["End-to-end flow\nwith real technology"]
POC --> W2["Performance validation\nunder realistic load"]
Q1 --> DEC["✅ Informed Decision\nBased on evidence\nNot assumption"]
W1 --> DEC
Spike vs POC: Spike — purpose: answer a question. Duration: hours to days. Code: throwaway — exploration only. Output: recommendation with evidence. POC — purpose: prove an approach. Duration: days to weeks. Code: may evolve into production. Output: working implementation.
Spikes and POCs aren't waste — they're risk reduction. The cost of a spike is always less than the cost of a wrong architectural decision discovered in production.
Spike to learn, POC to prove — reduce risk before committing, not after.
Try it yourself — The spike plan
What architectural decisions are you making without evidence?
| Decision | What don't we know? | Spike or POC? | Timebox |
|---|---|---|---|
| e.g. Choose event broker | Can it handle our throughput? | Spike | 2 days |
If you're making high-risk decisions without spikes, you're gambling.
7. When architecture goes wrong in delivery — The signs and how to recover
Even with the best intentions, architecture can go wrong during delivery. The signs are visible — but only if you know what to look for.
These are the warning signs that architecture is failing during delivery:
flowchart TD
SIGNS["🚨 Warning Signs"]
SIGNS --> S1["🐌 Velocity dropping\nFeatures take longer every sprint\nNot because they are harder\nBut because the system is harder to change"]
SIGNS --> S2["🔗 Growing coupling\nChanges in one area break another\nTeams afraid to touch certain code"]
SIGNS --> S3["📋 Rising defect rate\nMore bugs per release\nRegression failures increasing"]
SIGNS --> S4["🚫 Team frustration\n'I can't work in this codebase'\n'I don't understand the architecture'"]
SIGNS --> S5["🏗️ Undesigned workarounds\nTeams building around the architecture\nInstead of through it"]
S1 --> RECOVER["🔧 Recovery"]
S2 --> RECOVER
S3 --> RECOVER
S4 --> RECOVER
S5 --> RECOVER
RECOVER --> R1["Pause and assess\nWhat is actually broken?"]
RECOVER --> R2["Refactor deliberately\nFix the worst coupling first"]
RECOVER --> R3["Re-establish runway\nRebuild the foundation\nBefore adding features"]
RECOVER --> R4["Document decisions\nSo the same mistakes are not repeated"]
Recovery strategies: Pause and assess — don't keep building on a broken foundation. Diagnose first. Fix the worst coupling — identify the dependencies that cause the most pain. Address them first. Re-establish runway — rebuild the architectural foundation before adding more features. Document decisions — capture what went wrong and why, so the team learns. Sequence the recovery — don't try to fix everything at once. Prioritise by impact.
Architectural failure during delivery is recoverable — but only if you recognise it early and act deliberately.
Velocity dropping + coupling growing + team frustrated = architecture is failing — pause, assess, recover.
Try it yourself — The recovery check
Are any of these signs showing in your system?
| Sign | Evidence | Severity |
|---|---|---|
| Velocity dropping | ||
| Growing coupling | ||
| Rising defect rate | ||
| Team frustration | ||
| Undesigned workarounds |
If you have two or more, it's time to pause and assess. Don't keep building.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
ARCH["🏛️ Architecture Decisions"]
ARCH --> RUNWAY["🛫 Runway\nFoundation built ahead\nof team needs"]
RUNWAY --> TEAMS["👥 Teams\nDeliver features on\nthe prepared runway"]
TEAMS --> SHIP["🚢 Software Shipped"]
RUNWAY --> DEP["⛓️ Dependencies\nMapped and sequenced"]
RUNWAY --> PHASE["🪜 Phasing\nDeliberate sequencing"]
DEP --> TEAMS
PHASE --> TEAMS
TEAMS --> SIGNS["🚨 Warning signs?\nVelocity dropping\nCoupling growing"]
SIGNS -->|"Yes"| RECOVER["🔧 Recovery\nPause · Assess · Fix"]
SIGNS -->|"No"| CONTINUE["Continue"]
RECOVER --> RUNWAY
The foundation:
Architecture enables delivery — it doesn't block it. If teams are waiting for architectural decisions, the architect is behind. Stay one step ahead. Architecture runway is the foundation built before teams need it. Technology, infrastructure, and patterns ready when teams arrive — not discovered during sprint planning. Dependencies must be mapped before teams hit them. Dependency surprises during sprint planning are architectural failures, not team failures.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Architecture enabling delivery | Stay one step ahead | Sprint lookahead, just-in-time decisions |
| Architecture runway | Foundation built ahead | Technology, infrastructure, patterns ready |
| Phased implementation | Deliberate sequencing | Dependency-first, spine-first, value at every step |
| Dependency management | Map before teams hit them | Dependency matrix, critical path, risk assessment |
| Keeping teams unblocked | Velocity is the metric | Timebox decisions, provide defaults, escalate stalled |
| Spikes | Answer a question | Timeboxed investigation, throwaway code |
| Proof of concepts | Prove an approach | Working implementation, may become foundation |
| Recovery | Pause, assess, fix | Strangler Fig, fix worst coupling, rebuild runway |
How to know if this landed
You'll know this has landed when someone stops treating architecture as a phase that ends before delivery starts and starts treating it as a continuous activity that stays ahead of team execution. Fewer than 2 architectural blockers per sprint — teams move without waiting. Runway is 2-4 sprints ahead — decisions made before teams need them. Decisions are timeboxed — no indefinite deliberation. Dependencies are mapped in advance — no surprises during sprint planning. Cycle time is stable or decreasing — velocity is not slowing due to architecture. And recovery is possible — when architecture goes wrong, there's a clear path back.
What changes when the mental model clicks
I've run this session with teams where 6 teams working on a platform had velocity drop 60% over 3 months — every sprint had 5+ architectural blockers, no dependency mapping, architecture designed 6 months ago and stale before implementation started. The gap at the start is usually not about understanding delivery — it's about the architect staying one step ahead.
What changes after this session:
Teams stop treating architecture as a bottleneck and start treating it as runway. The sprint lookahead exercise — "what will teams need 2-4 sprints from now?" — is always the moment things click. People stop treating spikes as waste and start treating them as risk reduction. Their results get better. They stop blaming teams for slow delivery when the real problem was that architectural decisions weren't made in time.
The dependency mapping exercise tends to immediately change how teams plan their sprints. They start mapping dependencies before sprint planning, not during. Their blocker rate drops. They stop discovering dependencies mid-sprint when the real problem was that nobody looked ahead.
Book a Workshop
Ready to make architecture and delivery work together?
or
1-day workshop includes architecture-delivery relationship assessment — where are you on the spectrum, runway planning exercise — build your runway for the next quarter, dependency mapping workshop — find the hidden chains before teams hit them, spike and POC planning — reduce risk on your highest-uncertainty decisions, recovery planning — what to do when architecture goes wrong in delivery, and agile architecture checklist — practical practices for architects in agile teams.