Ask most engineering leaders what good architecture looks like and you will get an answer about today: the cleanest service boundaries, the right database, a diagram that survives the whiteboard. It is the wrong frame. Almost nothing you design will be judged on how well it fits the present, because the present is the one set of requirements you already understand. Architecture earns its keep against the requirements you do not yet have. Martin Fowler's pragmatic definition cuts to it: architecture is the set of things that people perceive as hard to change. By that definition, designing for change is not one principle among many. It is the principle, and most of the others are instruments of it.
This is consistent with the spine we keep returning to. Architecture is not diagrams or technology; it is the discipline of making decisions that let an organisation change safely and deliver consistently. Designing for change is simply that statement read backwards. The question is never whether your system can change, but whether it can change at the speed and safety the business now needs, and at a cost that does not compound every quarter.
The structural mechanism is boundaries, and it is now measurable
The mechanism by which a system stays changeable is not mysterious, and it is no longer merely a matter of taste. ISO/IEC 25010:2023 makes Modularity and Modifiability formal sub-characteristics of Maintainability. Modularity it defines as the degree to which a product is composed of discrete components such that a change to one has minimal impact on others. That is the entire game stated as a standard: cohesive content inside a boundary, minimal coupling across it, so that change stays local. When change stays local, it stays cheap and safe; when it propagates, every modification becomes a negotiation with the rest of the system.
The empirical backbone is loose coupling, and the strongest evidence comes from DORA. Where an architecture lets teams test, deploy and change their systems without depending on other teams, delivery and operational performance improve together; DORA goes as far as to recommend measuring the proportion of deployments that must be coordinated with other services as a concrete decoupling metric. That last point matters more than it first appears. Coupling is not only a property of code. It is a property of the organisation, and the cost of change is paid in coordination as much as in compilation. Designing for change means designing the team boundaries and the contract boundaries at the same time, because a clean module split that still forces six teams into the same release train has changed nothing that the business will feel.
The symmetric failure mode nobody warns you about
Here the standard advice quietly betrays you. The literature is almost entirely a polemic against rigidity: break the monolith, add seams, decouple, prefer microservices. The unstated assumption is that more flexibility is always better. It is not. Building flexibility for a change that never arrives is itself a failure to design for change, because it raises the cost of every change you do make in order to serve a hypothetical one you do not. Premature abstraction, speculative configurability and microservices-by-default are the same mistake wearing the costume of good practice. The YAGNI and speculative-generality traditions named this long ago; the 2025 practitioner reaction against reflexive microservices, and the renewed interest in the modular monolith, is the same lesson learned again the hard way, with distributed-system complexity as the tuition fee.
So the discipline is not maximising adaptability. It is choosing your axes of change. A serious architecture decision names the dimensions along which this organisation expects to move, often and unpredictably, and optimises to absorb those cheaply. It also names the dimensions that are stable, and deliberately declines to pay for flexibility there. A payments platform that re-prices constantly but never changes its ledger model should be soft where pricing lives and rigid where the ledger lives. Flexibility is a budget, not a virtue, and an architecture that spends it everywhere is as poorly designed for change as one that spends it nowhere.
Designing for change does not mean making everything easy to change. It means deciding, on purpose, which changes you will make cheap to absorb, and which you will make expensive on purpose, because some things should be hard to change.
One-way doors: the reversibility lens, applied to architecture
Jeff Bezos's distinction between Type 1 and Type 2 decisions, the one-way and two-way doors, is usually borrowed for product and strategy. It belongs in architecture, and it is the sharpest tool we have for the previous point. Most architectural decisions are two-way doors: a framework choice, an internal module layout, a caching strategy. You can walk back through them, so the correct posture is to decide reversibly and not agonise. A few are genuinely one-way: the core data model, a security or trust boundary, a public contract you have published to integrators, a deep vendor dependency. These you cannot cheaply reverse, and they deserve slow, deliberate, well-documented care. Nygard's architecture decision records exist precisely to capture this reasoning so a future team understands which door was walked through and why.
There is a real tension worth naming honestly. The Thoughtworks and lean tradition urges deferring decisions to the last responsible moment to preserve adaptability. Ben Morris's counter is fair: the last responsible moment is rarely knowable in advance, so 'defer' quietly decays into 'procrastinate', and the decision gets made by accident under pressure. The reconciliation is to stop deferring the decision and instead design the reversibility into it. Do not delay choosing the database; choose it, but put a boundary around it so the choice stays a two-way door. Options are something you build, not something you postpone.
Adaptability has to be governed, or it is just an aspiration
Modularity that nobody protects erodes. Evolutionary architecture, from Ford, Parsons and Kua, offers the governing mechanism: fitness functions. Borrowed from evolutionary computing, a fitness function is an objective test of how close the system sits to a desired characteristic, and it lets you protect coupling limits, module boundaries and replaceability as automated, enforced checks rather than wishes in a wiki. This is the architectural equivalent of a unit test for your one principle. Without it, every sprint trades a little changeability for a little speed, and the loss is invisible until the system is once again hard to change, at which point you have rebuilt the monolith you were trying to escape.
This is also where the argument stops being evergreen background and becomes urgent. DORA's 2025 work frames AI as a great amplifier: teams with loosely coupled architectures, automated testing, mature version control and fast feedback convert higher change volume and AI assistance into genuine gains, while tightly coupled teams convert the same inputs into instability. Adaptability is no longer just a maintainability nicety; it is the precondition that decides whether AI-accelerated delivery lands as throughput or as chaos. That is the same mechanism we describe in The Acceptance Gap: AI raises the volume and speed of change, and amplifies whatever changeability already exists. It adds a sharper edge, too. As more decisions are made fast and autonomously, the share that quietly pass through one-way doors rises, which makes the discipline of protecting irreversible decisions from being made quickly more important, not less.
Where this actually lives
The reason designing for change is so often reduced to a code property, modularity, fitness functions, the microservices debate, is that those are the visible artefacts. But the decision about which changes an organisation will optimise to absorb cheaply, and which it will accept as expensive, is a translation-layer decision between business strategy and engineering. It cannot be made well by an engineer who does not know the business's axes of change, nor by a strategist who cannot see the seams in the system. That seam is exactly the The Missing Architecture Layer Between Strategy and Delivery. If you want to put this into practice, do not start by drawing a target architecture. Start by writing down the two or three kinds of change your organisation will face most often over the next three years, naming the handful of decisions that are genuine one-way doors, and building reversibility into everything else. The diagram is downstream of those decisions, which is the whole point: architecture is decision quality, not drawing quality.