Most organisations do not fail because they cannot build software. They fail because they cannot consistently turn business intent into production outcomes. Delivery is the discipline of that translation, and architecture is the first place where it happens. Long before a feature ships, someone decides what to build versus buy, which platform to stand on, how systems integrate, how much scale to plan for, and where one domain ends and the next begins. Each of those choices is treated as a technical exercise. Each is actually a wager about what the business will become, made under uncertainty, written into the system, and very expensive to take back.
The contention here is simple. Architecture is a product decision, not a technical one. The right question is rarely 'is this clean, is this scalable?' It is 'which assumptions about the business are we hard-coding, and how reversible are they if we are wrong?' Get that framing right and the canonical five choices stop being engineering preferences and become what they are: bets on the durability of intent.
The decisions that compound
The reason architecture deserves product-level attention is that its mistakes compound financially in a way that ordinary delivery mistakes do not. McKinsey estimates technical debt at roughly 20 to 40 per cent of the value of an organisation's technology estate before depreciation, and finds that 10 to 20 per cent of new-product technology budgets are diverted to servicing it, with around 30 per cent of CIOs reporting that more than a fifth of their budget goes to that drain. That is not a tax on bad code. It is mostly the accumulated interest on architecture decisions that hardened around the wrong assumptions and could not be cheaply undone.
This is the cost asymmetry that should govern the whole discipline. Architecture decisions are cheap to defer and expensive to reverse once production traffic and teams have crystallised around them. Borrow the reversibility test: a reversible decision is a door you can walk back through, and you should make it fast and locally. A one-way door, once it has org structure and live data behind it, may never open again. The skill of the delivery architect is telling the two apart before, not after, the concrete sets.
Build, buy, blend — and the AI trap
The build-versus-buy debate has largely settled. The pragmatic default is to build the differentiating core and buy or compose the commodity context, enabled by composable, API-first architecture. Gartner frames the modern application as exactly this — assembled from reusable business services — and reports the decision has shifted from a binary to 'buy, build, blend'. The translation question underneath is whether you can correctly name what actually differentiates your business. Most build/buy errors are not engineering errors; they are an organisation building its own version of a solved commodity because no one could articulate where the genuine intent lived.
AI sharpens this and sets a trap at the same time. Once generation is cheap, building the commodity layer is cheaper than ever, which tempts teams back into building things they should compose. But cheaper generation does not make a wrong domain boundary cheaper to live with. It lowers the cost of producing code while leaving the cost of the wrong structure entirely intact. The binding constraint moves downstream — to whether the output is correct, safe and worth shipping, and to the integration seams that AI cannot reason about because they live in the business, not the codebase. That migration of the constraint from generation to acceptance is the thesis we develop in The Acceptance Gap, and architecture is where it first becomes visible.
The most over-paid premium: scalability
If there is one assumption organisations systematically over-buy, it is scale. Distributed-systems complexity is purchased as insurance against load that, for most products, never arrives. The premium is paid daily, in coordination tax, operational surface and cognitive load, to hedge a problem the business does not yet have and may never have.
The evidence against scalable-by-default is now empirical, not aesthetic. An EASE'25 case study by Eldenk and Cetin identifies premature, poorly-planned decomposition as a primary cause of incidents, creating dependencies and failure points that simply did not exist in the original monolith. An IEEE Transactions on Software Engineering systematic review of monolith-to-microservices decomposition concludes that identifying appropriate service boundaries remains an unsolved problem, with most approaches unable to determine even the right number of services. The lesson is not 'never distribute'. It is that scale is an assumption to be earned by evidence, not a default to be insured against by reflex.
Every architecture decision is a bet on the durability of intent. The only honest question is not whether it is scalable or clean, but which assumptions about the business you are hard-coding — and how expensive it will be when one of them turns out to be wrong.
Domain boundaries are an org chart in disguise
Of the five, domain boundaries are the single highest-leverage and least-reversible decision, because Conway's Law converts them into organisation. The boundaries you draw in the architecture become the teams, the communication paths and the ownership lines of the company itself. Get them wrong and you have not merely mis-shaped the code; you have mis-shaped the organisation, and it will resist correction with the full weight of human politics. This is precisely why we treat the translation between business domains and system structure as a The Missing Architecture Layer Between Strategy and Delivery rather than a downstream technical concern.
The corollary from a decade of DORA research is that loosely coupled architecture — teams able to test, deploy and change independently — is consistently the strongest architectural predictor of high delivery and organisational performance. Note what that finding is really about: it is an organisational property expressed through architecture. The 2024 DORA report sharpens the warning, observing that internal developer platforms can lift individual productivity while reducing throughput and change stability unless they are built to preserve team independence. Even your platform choice is a domain-boundary decision wearing different clothes.
Govern the decision, not the decider
If architecture is this consequential, the instinct is to govern it with a board and an approval gate. The evidence says do the opposite. Thoughtworks, drawing on State of DevOps data, recommends the Architecture Advice Process — anyone may make an architecture decision provided they seek advice from those affected and from relevant experts — and notes that traditional Architecture Review Boards hinder flow and correlate with poorer organisational performance. Pair that with lightweight Architecture Decision Records and the translation layer stays close to delivery flow, where intent is least likely to be lost in handover.
That is the through-line. Build/buy, platform, integration, scalability and domain boundaries are not five technical questions. They are five places where business intent either survives into production or quietly dies in translation, and they harden faster than any other decision you make. Treat them as product decisions, test each for reversibility before you commit, and govern them by advice rather than approval. If this resonates, read The Missing Architecture Layer Between Strategy and Delivery for why the translation layer keeps disappearing from org charts, and use our The AI Engineering Maturity Model to locate where your own delivery system sits today.