Good architecture removes complexity. Most adds it.

Ask ten engineers to define good architecture and you will get ten diagrams. Boxes, layers, arrows, a service mesh, an event bus, a golden path. What you rarely get is the only definition that matters to the business: an architecture is good when the next change is easier because of it.

By that test, a lot of what passes for architecture fails. It does not remove complexity. It relocates it, adds a layer, and calls the layer a solution.

The tell is what happens to the next decision

Complexity is not the number of components on a diagram. It is the number of things a person has to hold in their head to make a safe change. A system with forty services can be simpler than a system with four, if the forty are boring, independent and clearly owned, and the four are tangled together with shared state and undocumented assumptions.

So the useful question is never "is this elegant?" It is "when we come back in eighteen months to change one thing, how many other things will we need to understand first?"

Good architecture drives that number down. It is why a team can onboard a new engineer in a week, ship a change on a Thursday, and sleep on Thursday night. Bad architecture drives it up, quietly, one reasonable decision at a time.

How complexity gets added on purpose

Almost nobody sets out to build a system nobody can change. Complexity arrives dressed as prudence.

• "For flexibility." A team adds an integration platform so future systems can plug in easily. Three years later, every change touches the platform, no single person understands the routing, and a one-line fix takes a fortnight because nobody can predict what it will break.
• "To be safe." An abstraction is introduced to avoid being locked into a vendor. The abstraction now has to be maintained, tested and understood, and it is thinner than the thing it wraps. The lock-in was cheaper.
• "Best practice." A pattern that made sense at the scale of a thousand engineers is adopted by a team of twelve, who now carry the operational weight of a problem they do not have.

Each of these is defensible in the room where it is decided. The cost is not paid in that room. It is paid every year afterward, by people who were not there, in change requests that take longer than they should.

What removing complexity actually looks like

The work is unglamorous, and that is the point.

It looks like deleting the integration layer and letting two systems talk directly, because there were only ever two. It looks like choosing boring, well-understood technology over the interesting option, so that the pool of people who can operate it is large and calm. It looks like drawing a hard line around each part of the estate so ownership is obvious and a failure in one place does not become a mystery everywhere. It looks like saying no to a pattern that would be correct at ten times your size.

None of that makes an impressive slide. All of it makes the next change cheaper.

A test you can apply this week

Take the last three significant changes your teams shipped. For each, ask how many systems they had to understand to make it safely, and how long it took from decision to production. Then ask a harder question: is that number trending down or up?

If it is going up, no amount of new architecture will help until you understand why. Usually the answer is not that you need more structure. It is that structure has been accreting for years, each layer added to manage the last, and nobody has been given permission to take any of it away.

The best architecture is the one you stop noticing, because it never gets in the way. If your teams talk about the architecture constantly, that is not a sign of sophistication. It is the sound of complexity asking to be paid.

---

Argentum advises on the decisions that shape a technology estate: what to keep, retire, consolidate or rebuild, and on the architecture and governance that keep future options open. If your teams are spending more to change less, start a conversation.