The vertical slice is the real architecture

Two teams spend a month making progress.

The frontend team builds routing, state management and a component layer. The backend team creates services, schemas and deployment pipelines. Both report green status. On day 21 they connect the first real journey and discover that identity is represented differently, errors have no shared contract and the required data cannot be fetched within the interaction budget.

The work was real. The architecture was still hypothetical.

Prove one outcome through every layer

A vertical slice is a thin but complete user outcome that crosses the production-shaped system:

interface → authentication → API → business rule → data → telemetry → deployment

Choose a journey that is representative without being the hardest feature in the roadmap. “An authenticated user saves one address and sees it after refresh” is more useful than a health-check endpoint and less likely to consume the programme than “complete the entire application”.

The slice should touch the risky boundaries. Mocking the identity provider is reasonable when testing button copy; it defeats the point when identity integration is the architectural uncertainty.

What the first ten days can answer

A production-shaped slice might be planned as an investigation rather than a miniature waterfall:

Days 1–2: define the outcome

Write one acceptance path and its failure states. Decide which user can perform it, which data changes and how success is observed.

Days 3–5: connect the thinnest path

Use the real repository, build, environment, identity boundary and persistence technology. Keep the interface plain. Avoid general frameworks that have only one consumer.

Days 6–7: make failure visible

Add validation, an unavailable dependency, an expired session and a duplicate submission. Connect logs and a trace to the user-visible result.

Days 8–9: deploy and reverse

Ship behind an appropriate release control. Exercise rollback or disablement. Confirm that configuration and secrets are owned rather than copied from a laptop.

Day 10: write down what changed

Which assumptions survived? Which contract needs revision? Which abstraction is now supported by evidence? Which risk should shape the next slice?

The output is working software and a better plan.

Let abstractions arrive second

Horizontal foundation work feels efficient because it avoids visible incompleteness. It also encourages teams to solve imagined variation.

Build the first concrete path. When a second slice needs similar behaviour, compare them. Extract the stable decision and leave the genuinely different parts separate. A small amount of temporary duplication is cheaper than a universal API built around the wrong axis.

Martin Fowler describes evolutionary architecture as an approach in which architecture “works closely with programming so that architecture can react both to changing requirements but also to feedback from programming”.

The feedback is the important part. “Emergent” should not mean accidental; constraints and tests guide the change.

Add fitness checks at the boundary

Once the slice exposes an architectural property, automate the property where practical:

• a contract test for error responses;
• an accessibility test for the completed interaction;
• a performance check for the route;
• a migration test against representative data;
• an authorisation test across roles;
• a deployment smoke test that follows the real outcome.

These checks are architecture expressed as executable evidence. They warn when later slices erode the decisions the first one proved.

Do not confuse thin with disposable

A vertical slice can be small and still meet production standards. It should follow the intended security, review, deployment and observability path. Shortcuts must be named with an owner and a removal condition.

The slice is not a throwaway prototype dressed up as progress. It is the first narrow section of the product built in the manner the rest can extend.

Our web and backend work uses this shape to expose integration risk early. In complex regulated journeys such as ClearBank, a clean diagram matters less than proving that interface, permissions, data and operations agree on one outcome.

Architecture becomes credible when the system has travelled through it.

Sources

• Foreword to Building Evolutionary Architectures — Martin Fowler
• Continuous Delivery — Martin Fowler
• Architecture decision records — Technology Radar