Most transformation post-mortems read like a chronicle of execution failure: the programme ran late, the budget bloated, the change management never landed. But the honest version, the one you only tell after a drink, is usually different. The transformation was decided before it started. A handful of structural choices made in the first quarter — often by people who didn't realise they were architecture decisions at all — set the ceiling on everything that followed. By the time delivery struggled, the room to manoeuvre had already been spent.
The numbers around transformation failure are sobering enough to be a cliche, so it is worth being precise. Bain & Company, analysing more than 24,000 transformation initiatives alongside a survey of over 400 executives, found that only around 12 per cent of business transformations achieve their original ambition — meaning roughly 88 per cent fall short of what they set out to do. Notably, Bain also found that having a dedicated Chief Transformation Officer correlated with capturing about 24 per cent more of the planned value. That second figure matters because it points at the real lever: not effort, but who owns the decisions and how early they are made well.
There is independent academic support for treating these as decision risks rather than execution risks. A 2024 peer-reviewed study presented at the International Conference on Big Data, AI and Risk Management (ACM) applied Failure Mode and Effect Analysis to digital transformation, building a risk-assessment system around the organisational adaptation cycle. The framing is telling: it locates the highest-severity failure modes in structural and adaptive choices, not in delivery mechanics. You can read older Standish CHAOS data the same way — large projects have long fared worse than small ones — though those figures predate 2024 and the methodology has drawn fair academic criticism, so treat them as directional rather than gospel. The pattern across all of it is consistent. The dangerous decisions are made early, and they are architectural.
Build, buy, and the doors that don't swing both ways
The build-versus-buy decision is where transformations most often quietly commit to their fate. The useful lens here is Jeff Bezos's distinction from Amazon's 2015 shareholder letter: Type 1 decisions are one-way doors — consequential and effectively irreversible, deserving slow deliberation — while Type 2 decisions are two-way doors that should be made fast and reversed if wrong. Build-or-buy is rarely treated as a one-way door, but for a core platform it usually is. Choosing to build commits you to an operating model, a hiring profile, and a maintenance liability for a decade. Choosing to buy commits you to a vendor's roadmap and data model. Both are slow doors dressed up as a procurement line item.
What complicates this further is that the economics have genuinely shifted. A 2026 arXiv preprint, 'The Buy-or-Build Decision, Revisited', argues that agentic AI is moving the line: small, AI-augmented teams now ship in days or weeks what previously took large teams months, which makes building viable for systems that would once have been an obvious buy. That is a real change, but it sharpens rather than removes the discipline. The question is no longer just 'can we build it cheaply enough?' but 'which capability is so differentiating that owning it is worth the one-way door?' — and that is a strategic judgement, not a cost comparison. We've written more on what this capability actually requires in Beyond Vibe Coding.
Platform versus product, and the org chart you're really drawing
The second decision that compounds is whether you are building a platform or a product — and the trap is that the two demand different organisations, governance, and economics, yet are routinely conflated. A product serves users. A platform serves teams who serve users. Decide to build a platform and you have implicitly committed to internal customers, versioning discipline, and a longer payback curve. Decide product and call it a platform later, and you inherit a tangle that no refactor fully untangles.
This is where Mel Conway's 1968 observation, coined in his Datamation paper 'How Do Committees Invent?', stops being a quotable aphorism and becomes a planning input. Conway's law holds that organisations are constrained to produce designs that copy their communication structures. The architecture you can actually ship is bounded by the org chart you actually have. If you intend a clean platform boundary but your teams are organised around projects with no shared ownership, the system will reflect the projects, not the platform — every time.
The architecture decisions that matter most in transformation are rarely the ones drawn on diagrams. They are the early, half-visible commitments about ownership, reversibility, and organisational shape — and they are made well before anyone notices they were decisions at all.
Integration, identity, and the question of who owns the data
Integration is the decision that determines whether your transformation produces a system or a sediment of point-to-point connections. The reversibility lens applies again: an event backbone is expensive to introduce but cheap to extend, whereas a web of bespoke integrations is cheap to start and ruinous to change. Identity sits underneath all of it, and here the governance anchor is clear. NIST SP 800-63 Revision 4, finalised in July 2025, broadens the basis for identity decisions beyond enterprise risk to mission, public-trust, and individual impacts, and integrates phishing-resistant approaches — including FIDO passkeys and syncable authenticators (vendor-adjacent framing) — into its AAL2/AAL3 assurance levels and federation model. Identity is a one-way door in disguise; choose the standard, not the convenience.
The data and operational ownership decision is the one most often deferred and most expensive to defer. The most coherent treatment of decentralised ownership is Zhamak Dehghani's data mesh, originated while she was at Thoughtworks (vendor framing). Dehghani's four principles — domain ownership, data as a product, a self-serve data platform, and federated computational governance — are worth attributing precisely, because the temptation in transformation is to adopt the slogan ('decentralise the data') while dropping the counterweight. In Dehghani's framing, data-as-a-product means data that is discoverable, addressable, trustworthy, self-describing, interoperable, and secure; and federated computational governance is the explicit answer to the chaos that pure decentralisation would otherwise produce. Decentralisation without that governance counterweight is not a data mesh — it is data anarchy with better marketing.
Why a few decisions decide the whole
The reason these specific choices dominate is that they are coupling decisions. Build-or-buy couples you to an operating model. Platform-or-product couples you to an organisation. Integration couples your systems to each other; identity couples every interaction to a trust model; data ownership couples every team to every other team's information. Coupling is what makes a decision a one-way door — and the failure mode in transformation is to make coupling decisions implicitly, fast, as if they were reversible, while spending deliberation on choices that don't matter.
The practical discipline is unglamorous. Identify which of the early decisions are genuinely one-way doors and slow those down deliberately, even when the programme pressure is to commit. Record the reasoning so the next team understands why the door was walked through. And accept Conway's law as a constraint to design around rather than a curiosity to quote — if the architecture you want requires an organisation you don't have, the org change is the architecture decision. Transformation does not fail in delivery. It fails in the quarter when these decisions were treated as administration. The work of good architecture is not the diagram; it is the quality of the decisions and the honesty about which ones cannot be unmade.