Architecture · 8 min
Architecture decisions that survive a decade
Most architecture is wrong about the future. A discipline for making decisions that age well, and for knowing which decisions are worth making permanent.
The failure mode of architecture is over-committing to predictions about a future that does not arrive. We design for the system we imagine, the scale we expect, the features we believe are coming, and the business outgrows it in a direction we did not foresee. The architecture that was built to handle a million users buckles under a new regulatory requirement, or the architecture designed for a single product gets stretched across three and loses its coherence. The future is not a more elaborate version of the present. It is a different country. Because the future is unpredictable, the discipline is not to predict it better. The discipline is to separate reversible decisions from irreversible ones, and to spend the budget of certainty only where it matters. Most decisions should be made cheaply, documented, and reversible. A framework choice is reversible, with effort. A data store is reversible, with pain. These decisions deserve thought, but not permanence, and treating them as permanent is where teams freeze themselves into bad early guesses.
A few decisions deserve permanence, because they are genuinely hard to reverse and because everything else depends on them. Data ownership, the boundaries between domains, and the identity model are the classic examples. Get these right, and the rest of the system can evolve around them. Get them wrong, and every later decision is a compromise against the original mistake, because every later decision is constrained by a foundation that was laid incorrectly. These are the decisions worth slowing down for.
Boundaries are the decisions that matter most. Get the domain boundaries right and the rest is refactorable. Teams can be organized around them, work can proceed in parallel, and changes stay local. Get them wrong and every feature becomes a cross-cutting effort that touches three teams, requires a coordinating meeting, and lands regressions in places no one was watching. Boundary mistakes are not fixed by better code. They are fixed by reorganizing the system, which means reorganizing the teams, which is expensive enough that most organizations live with the mistake instead.
The test for a boundary is whether work stays inside it. If a typical change touches one boundary, the boundary is right. If it touches three, the boundary is wrong, and no amount of clever code will make it right. This test is empirical, and it should be applied early, when the boundaries are still soft enough to move. The longer a wrong boundary lives, the more code accretes around it, and the more expensive it becomes to correct. Watch the first dozen features, and adjust before the concrete sets. Document decisions as they are made. The Architecture Decision Record is the most undervalued artifact in engineering. It does not need to be long. It needs to capture the context, the options considered, the choice, and the consequences, including what was given up. That record is how a system stays coherent across the people who will inherit it. Without it, every new engineer re-litigates the decision, or worse, assumes it was arbitrary and quietly reverses it, reintroducing a problem that was already solved.
A decision record is also a kindness to your future self. Six months later, you will not remember why you chose this queue over that one, and the reasoning that was obvious in the room will be gone. The record turns a forgotten conversation into a durable artifact. When the assumptions change, and they will, the record tells you which decisions need to be revisited, instead of leaving you to guess which parts of the system are load-bearing and which are accidental.
The architecture that survives a decade is not the one that predicted the future. It is the one that made a few irreversible decisions well, kept the rest reversible, and left behind enough context that the people who inherited it could continue the work. That is the real goal. Architecture is not a building you hand over finished. It is a set of decisions and the reasoning behind them, passed forward so that the next team can decide wisely too.