There’s a fantasy that sits underneath a lot of architecture conversations: that somewhere out there is the right design for this system, and if we’re clever enough and argue long enough, we’ll find it, build it, and be done. It’s a comforting idea. It’s also wrong, and holding onto it quietly makes systems worse.
There is no final answer, because the forces move
I’ve banged this drum before: a good architecture is the one that best fits what you’re optimising for right now. But “right now” is the catch. The load changes. The team grows or shrinks. The business pivots, a feature that was central becomes a footnote, a regulation appears, a cheap managed service turns expensive. The forces you designed against are not fixed — so an architecture that was genuinely correct in year one can be genuinely wrong in year three without a single line of it having changed. It didn’t rot. The world moved.
That reframes what “getting it right” even means. It can’t mean finding a design that’s correct forever, because no such design exists. It can only mean building something that fits the forces now and can be reshaped when they move. Fitness, not perfection — and fitness is always relative to an environment that won’t hold still.
Architecture as something that evolves
This is the core idea behind evolutionary architecture, the term Neal Ford, Rebecca Parsons and Patrick Kua gave to treating architecture as something that changes incrementally over time rather than something you set in stone at the start. The shift is from architecture-as-monument to architecture-as-organism: you don’t design the final state, because there isn’t one; you design something that can be guided as it grows.
And the whole reason that’s even possible is reversibility. An architecture can only evolve to the extent its decisions can be revisited — which is exactly why so much of the day-to-day work is turning one-way doors into two-way ones. Boundaries you own, contracts you can version, deploys you can decouple from releases: none of these are tidiness for its own sake. They’re what let the system move when the forces do. It’s also why the pragmatic middle ground of a modular microlith beats committing to a topology up front — you keep the option to extract a service without paying for it until a real force demands it. Evolvability is the -ility that lets you buy all the others later.
Fitness functions: how you steer without a map
If there’s no final design to aim at, how do you avoid drifting into a mess? This is where evolutionary architecture earns its keep, with the idea of a fitness function: an objective, usually automated, check that tells you whether the system still has the properties you care about. Not a diagram of the destination — a test of whether you’re still heading somewhere good.
The point is to make the -ilities you value measurable and enforced, so they can’t quietly erode while everyone’s busy shipping features:
- Performance — an automated check that a key endpoint stays under a latency budget, run on every build, so a regression is caught the day it lands and not in an incident.
- Structure — a test that asserts the domain layer doesn’t import the web layer, or that one module never reaches into another’s internals, so the boundaries you drew on the whiteboard stay real in the code.
- Resilience — deliberately killing a dependency in a test environment and asserting the system degrades the way you designed it to, rather than hoping.
- Security and compliance — an automated gate that fails the build if a rule you must not break gets broken.
Each of these encodes a property you’d otherwise only assert in a design review and then watch decay. A fitness function turns “we care about latency” into something the build can prove or disprove — which means the architecture can change freely underneath, as long as it keeps passing. You stop guarding a specific design and start guarding the qualities that made it good.
Why this is liberating, not lax
Letting go of the “right” architecture sounds like an excuse to stop thinking hard. It’s the opposite. If you believed you could design the correct system once, the rational move would be to delay building until you’d finished arguing — which is how you get twelve months of design and a system obsolete before launch. Accepting that the target moves changes the job entirely: design something reasonable for the forces you can see, make sure it can be steered, put fitness functions around the properties that matter, and then let it evolve on real evidence instead of guesses.
That’s also the honest counterweight to over-engineering. You don’t need to future-proof against every scenario you can imagine, because you’re no longer betting the whole design on predicting the future correctly — you’re betting on your ability to respond when the future arrives. That’s a far safer bet, and a far cheaper one.
So the next time a design debate stalls on finding the right architecture, it’s worth saying out loud: there isn’t one. There’s an architecture that fits today, and there’s the question of whether we can change it cheaply when today becomes yesterday. Get those two right and you’ve done the job. Chase the mythical correct answer and you’ll either never ship, or ship a monument to a world that’s already moved on.