There is a particular kind of pride that architecture can produce — the pride of a design that is comprehensive, interconnected, and technically impressive. It shows well in presentations. It impresses in reviews. And it tends to become extremely painful to maintain eighteen months after it goes live.
A pattern that repeats itself: organisations choose architecture that is impressive over architecture that is appropriate. The impressive version wins in the room, and the engineering team pays for that decision long after the people who made it have moved on.
The honesty problem
Most architectural complexity is not chosen deliberately. It accumulates because each individual decision seemed reasonable at the time. An extra service here. An integration layer there. A framework adopted because it was the current standard, even if the team had no experience with it. None of these looked like bets on complexity. But together, they create a system that is harder to change than it needed to be.
Simple architecture requires a kind of honesty that is harder than it sounds. It requires the team in the room to say: we do not need this yet. We do not know if we will ever need this. We are adding it because it feels safer to build for a future that may not arrive than to admit that we are uncertain. That admission is difficult when there are stakeholders expecting a sophisticated design.
The architects who do this well have learned to distinguish between complexity that solves a real problem and complexity that manages anxiety about future problems that have not happened yet.
What winning actually looks like
Simple architecture wins on a timeline that most organisations measure poorly. In the first six months, it looks identical to complex architecture — everything is working, the system is new, and nobody has yet encountered the friction that over-engineering creates. The difference appears later, when requirements change.
A simple architecture adapts. The team can understand it well enough to modify it confidently. The failure modes are known and bounded. New engineers can be productive quickly because the design does not require weeks of archaeology before making changes.
A complex architecture resists change. Modifying one part requires understanding three others. The team develops an unspoken fear of touching certain components — the ones that nobody fully understands and that seem to work for reasons that are not entirely clear. These components become permanent. They outlast the people who built them and become anchors that constrain every subsequent decision.
The discipline of removal
Good architects add things. Great architects remove them. The discipline of looking at a design and asking "what can we take out?" is rarer and more valuable than the discipline of adding capabilities.
This applies at every level. A microservice that could be a function. An integration layer that could be a direct connection. A caching system introduced for performance that was never measured and never needed. A framework chosen because it was popular, used for ten percent of its features, and now impossible to remove.
The right moment to remove things is before they become load-bearing. Once a component is depended upon by three other components, removing it requires understanding all three. Before that point, it costs an afternoon. Waiting costs much more.
Why the simpler one ages better
Architecture is not an intellectual exercise. It is a set of decisions that will be lived with by engineers, under pressure, for years. The architect who optimises for the elegance of the design in the room has picked the wrong moment to optimise. The one who optimises for clarity in production — at 2am, when something is failing and the person debugging it has never seen this system before — is building something that will actually hold.
Simple architecture wins. Not immediately, and not visibly. But consistently, over time, and in the moments that matter most.
What to watch for
- Distinguish between complexity that solves a current problem and complexity that manages anxiety about hypothetical future problems. Only the first kind is justified.
- Review your architecture periodically for components that exist because of past decisions, not current needs. Removal is an architectural contribution as valuable as addition.
- Measure simplicity by how quickly a new engineer can make a productive change. If it takes weeks, the design has accumulated too much weight.