Architecture Is Not a Blueprint. It’s a Set of Decisions.

Most IT strategies fail not because the direction was wrong, but because the organisation couldn’t execute consistently. Architecture is how you prevent that, not through control, but through a small set of shared decisions that keep hundreds of independent choices pointing in the same direction.

In 1884, Sarah Winchester, widow of William Winchester and heir to the Winchester repeating rifle fortune, began building a house in San Jose, California. A spiritualist medium had told her the family was cursed by the spirits of those killed by Winchester rifles, and the only way to keep them at bay was to build continuously. If construction ever stopped, she would die.

She took this seriously. She employed carpenters around the clock, seven days a week, for the next thirty-eight years. By the time she died in 1922, the house had grown to an estimated 160 rooms, 2,000 doors, 10,000 windows, staircases that rose directly into ceilings, doors that opened onto sheer drops, and chimneys that stopped just short of the roof serving no fireplace. There was no master plan. Each morning she met with her foreman and sketched that day’s instructions on scraps of paper. No coherent vision. No intention beyond continuation.

I find it the most useful metaphor in technology. Not because enterprise IT systems are haunted, though some feel that way, but because the pattern is identical. Sprint by sprint, project by project, teams make locally reasonable decisions: a new integration here, a bespoke data store there, another microservice, another pipeline. No single decision is obviously wrong. But nobody is asking the question architecture requires: how does this fit together? What will we regret locking in? The result is what software engineers call the big ball of mud, structure without coherence. Expensive to change, impossible to explain, dependent on the institutional memory of whoever built each room.

The Role of Architecture Is to Constrain Design

The opposite of the Winchester Mystery House is the shipping container. In the 1950s, global trade had a problem that wasn’t ships, it was handoffs. Every transition between sea, rail, and road was slow, manual, and unpredictable. The shipping container fixed this not by being a better ship, but by being a constraint: standard dimensions, standard locking points, standard handling equipment. That single design decision made handoffs predictable across every mode of transport. Once the interface was standard, everything else could evolve around it.

This is the role of architecture: not to design everything, but to constrain the decisions that, left inconsistent, break the whole. A small set of shared boundaries, sources of truth, and interaction patterns that make handoffs predictable across teams, systems, and programmes. Not a blueprint. A set of decisions that allow everything else to evolve without fragmenting.

Architecture Is the Thinking Behind the Drawing

Ask most people what architecture is, and they’ll point to a diagram. Boxes and lines. A system context view. A technology stack. But architecture is not the drawing, it’s the thinking behind it.

At its core, architecture is a set of intentional, consequential decisions that determine how systems are structured, how they behave under pressure, how they scale, and how they evolve. As Gregor Hohpe defines it: architecture must include significant decisions that are well documented and based on a clear rationale. The documentation isn’t the architecture. The decision, and the reasoning behind it, is.

What separates architecture from mere construction is intention. Architecture begins with purpose, works within constraints, and makes trade-offs explicit. It asks: what qualities are non-negotiable? What will we need to change in two years that we can’t afford to lock in now? What is worth paying for, and what should we simply consume? Without those questions, you build rooms. With them, you build something that works.

Every Architectural Decision Is a Trade-Off

In preparation for the D-Day landings, British engineers faced a precise problem: how to get tanks safely across mined beaches while under enemy fire. Standard tanks couldn’t do it. So Major General Percy Hobart’s team built a series of radically modified vehicles, ‘Hobart’s Funnies’, each designed to solve a specific battlefield constraint.

The most famous was the Flail Tank. A rotating drum with heavy chains struck the ground ahead of the vehicle, detonating mines before they could be triggered by the tank’s weight. It worked. But the trade-offs were deliberate and fully understood: the flail obscured the driver’s vision, reduced speed, and meant the gun could not be fired while mine-clearing was in progress. Survivability was bought at the direct cost of offensive capability.

These were not cosmetic changes. They were non-trivial architectural decisions, made with clear awareness of what was being given up and why. That precision, knowing what you are trading, not just what you are gaining , is what distinguishes architecture from wishful thinking.

I’ve seen the same dynamic repeatedly in practice. In the travel sector, architects face a persistent tension between data freshness and system performance. Customers booking complex holiday packages expect fast, accurate results. But real-time pricing checks across dozens of supplier systems create latency and instability. Cache the data and risk showing stale prices. Fetch it live and risk a slow, frustrating experience.

There is no universally correct answer, only a context-dependent trade-off. And whichever way you decide, that decision shapes your infrastructure design, your team ownership model, your SLA commitments, and your cost base for years. That is what makes it architecture.

Architecture Is Technical and Sociotechnical

One of the most important, and most frequently missed, truths about IT architecture is that it is not purely technical. It is sociotechnical: a blend of the systems themselves and the people, teams, and ways of working that build and operate them.

Conway’s Law states that any organisation which designs a system will produce a design whose structure mirrors its communication structure. In other words: if your teams are siloed and fragmented, your systems will be too, regardless of how elegant the technical diagrams look. Architectural decisions about platforms and integration patterns cannot be separated from decisions about team ownership, governance, and delivery practices.

The practical implication is powerful: if you want a different architecture, you may need to design different teams. The Reverse Conway Manoeuvre, deliberately shaping your team structures to produce the architecture you need, is one of the most effective tools available to an IT leader, and one of the least used.

Team Topologies, the framework created by Matthew Skelton and Manuel Pais. Team Topologies gives the sociotechnical insight of Conway’s Law a practical design language: stream-aligned teams that own end-to-end outcomes, platform teams that reduce cognitive load, enabling teams that build capability, and complicated-subsystem teams where genuine specialist depth is required. Team boundaries and interaction modes are not soft concerns, they are structural design decisions that shape flow, risk, and speed.

Turning Strategic Intent Into Architectural Guidance

Most IT strategies state an intent but leave the architecture to chance. Teams interpret what the strategy ‘means’ project by project, vendor by vendor, and the result is predictable: drift, duplicated effort, brittle handoffs, and a landscape that no longer reflects the original intent within eighteen months.

Architectural guidance prevents this by publishing a small set of non-negotiable decisions early, before delivery starts. Not a blueprint. Not a shopping list. A discipline: the few structural truths that teams must not re-decide locally, because inconsistency at those points breaks the strategy.

The process for deriving this guidance follows a clear logical chain, as shown in the diagram below.

It starts by anchoring on strategic intent and the specific value stream or customer journey the action is enabling. Then critical scenarios are written, the few situations that must work: happy path, peak load, exception, and change. These are not edge cases; they are stress tests that expose exactly where ambiguity will surface during delivery if left to local interpretation.

Capability constraints are acknowledged next, the legacy systems, data silos, and infrastructure limits that the architecture must navigate. This ensures you are designing for the real estate, not a greenfield ideal.

From scenarios and constraints, target architecture features are derived: statements of truth that define the non-negotiable properties the landscape must have for the strategy to succeed. Crucially, each feature is paired with evidence, a contract, an SLO, a conformance dashboard. Without evidence, a feature is an aspiration. With it, it becomes governable.

Using Wardley Mapping to Shape the Recommendations

Target architecture features tell you what must be true. They don’t yet tell you how to get there, what to build, what to buy, what to standardise, and what to treat as a competitive differentiator. This is where Wardley Mapping becomes essential.

A Wardley map is a visual model of how the organisation delivers value to a user. It anchors on a specific user need, shows the value chain of responsibilities required to meet it, and positions each component on an evolution axis running from novel to industrialised. That placement determines posture: a commodity responsibility should be standardised and consumed; a differentiating custom capability should be invested in and engineered for change.

Consider a retailer building a click and collect capability. The Wardley map immediately surfaces a useful distinction: the orchestration layer that defines what ‘ready’, ‘delayed’, and ‘collected’ means, the canonical state model that every channel, store, and customer service agent depends on, sits firmly in the custom-built zone. It is where customer certainty is either delivered or undermined. It should be funded as a persistent product capability, not a project.

By contrast, order management and inv, critical as they are, sit further right on the evolution axis, closer to product or commodity. The right posture there is constrained variation: integrate cleanly, prevent local reinvention, and serve these capabilities as a platform to all consumers.

The map makes it visible when organisations are accidentally differentiating on the wrong things: custom-built integration plumbing, bespoke notification mechanics, duplicated business logic replicated channel by channel. These are not competitive advantages, they are complexity costs that drain the budget needed for genuine differentiation.

Architecture and Organisation Are Inseparable

Once the Wardley map is in place, ownership must be made explicit. Which team is accountable for each responsibility? Where are the write paths? Who has decision rights when standards need to evolve?

The Wardley evolution axis doesn’t just determine technical posture, it determines the right operating model for each area. Responsibilities cluster naturally into ownership groups based on how they evolve and how tightly they are coupled by change.

Differentiating capabilities in the custom-built zone should be owned by persistent, stream-aligned teams with domain decision rights, funded as products, not projects, because this is where the business’s competitive claims are either delivered or undermined. These teams change frequently and need the autonomy to respond.

Platform-zone responsibilities , the authoritative truths that every other team depends on, such as inventory data, order state, or identity, should be owned separately and served to consumers as a product capability with clear service levels. If these sit inside a journey team, every other part of the organisation will re-litigate the same rules independently. Keeping them as a platform prevents duplicated truth from proliferating across the landscape.

Product-zone capabilities with constrained variation, packaged tooling, standard workflow engines, managed infrastructure, should be owned with a different mandate: standardise, minimise bespoke change, and integrate cleanly against the platform truths above. The risk here is not under-investment but over-customisation: the temptation to build bespoke logic that duplicates what the canonical model already provides.

The interaction patterns between teams are as important as the team types. Stream-aligned teams consuming from platform teams via X-as-a-Service, a low-friction, contract-first relationship, avoids the coordination overhead of constant joint working. Collaboration is reserved for phases where ambiguity genuinely needs resolving together; once the interface is stable and understood, the right mode is self-service. This distinction, between high-bandwidth collaboration and low-friction consumption, is one of the most consequential design decisions an IT leader can make.

The Output: A Guidance Pack, Not a Blueprint

The output of this process is not a future-state architecture diagram. It is a guidance pack: a small set of deliberate constraints and defaults that keep delivery coherent without collapsing into solution design.

A complete guidance pack contains four things. First, target architecture features with evidence, the non-negotiable properties the landscape must have, each paired with a contract, SLO, or conformance check that makes it governable. Second, a Wardley map that makes explicit who owns what, where the boundaries sit, and which interfaces must remain consistent. Third, recommendations expressed as moves with trade-offs, what to do, stop, standardise, and sequence, with the cost of each move named as clearly as the benefit. Fourth, an operating model overlay that names accountable owners, team types, interaction modes, and how conformance is handled.

Architecture Works by Influence, Not Control

The word to hold onto when thinking about architetcure is influence. Architectural guidance works by shaping the decisions that teams will inevitably make anyway, not by replacing them. The goal is enough shared structure that strategy survives contact with delivery. Not a design for everything. A small set of decisions about the things that, left inconsistent, break the whole.

These posts are early-stage extracts from The IT Strategy Playbook, which I’m currently writing. If this resonates, or if something doesn’t land, I’d love to hear from you in the comments.