The Architecture You Remove Still Has to Exist

There is a question that quietly appears in almost every architecture discussion.

Can we remove this?

Sometimes it is a service. Sometimes it is an orchestration layer. Sometimes it is a workflow engine, a semantic model, a validation step, or an approval process. Someone looks at the diagram and points to a box that seems unnecessary.

The proposal sounds reasonable.

"Let's simplify it."

Often, everyone agrees.

The conversation usually ends there.

The interesting question rarely gets asked.

If we remove this responsibility from the architecture, where does it go?

That question has changed the way I evaluate almost every proposal that claims to reduce complexity.

Simplicity is not subtraction#

We naturally associate simpler diagrams with simpler systems.

Fewer boxes. Fewer arrows. Fewer technologies. Fewer moving parts.

Sometimes that intuition is correct.

Many systems become healthier because unnecessary abstractions disappear.

But there is another kind of simplification that only changes appearances.

A workflow engine disappears, but every application now contains its own workflow logic.

A semantic layer disappears, but every dashboard now implements business definitions independently.

A validation stage disappears, but downstream consumers each invent their own interpretation of valid data.

The architecture became smaller.

The system did not.

The complexity simply migrated.

Complexity always has an owner#

Every production system has unavoidable complexity.

Permissions exist. Business rules exist. Exceptions exist. Operational timing exists. Recovery exists. Observability exists.

None of these disappear because we decide they are inconvenient.

If the architecture no longer owns them, someone else does.

Sometimes it becomes application code.

Sometimes it becomes configuration.

Sometimes it becomes documentation.

Very often, it becomes people.

Engineers remember unwritten rules. Support teams learn which reports can be trusted. Customers discover edge cases through experience.

The responsibility still exists.

It simply stopped being explicit.

Hidden complexity is more expensive than visible complexity#

Visible complexity attracts attention.

People ask whether a service should exist. They challenge whether a workflow has too many stages. They question whether a model contains unnecessary abstractions.

Hidden complexity rarely receives that scrutiny.

Instead, it appears as small inconveniences.

A report requires a caveat. A deployment checklist gains another manual step. An onboarding guide grows by two more pages. A senior engineer becomes essential because they know how everything really works.

Each change seems harmless.

Together they form a second architecture that nobody intentionally designed.

This invisible architecture often determines how the organization actually operates.

It lives inside habits instead of systems.

Ask a different question#

When someone proposes removing part of an architecture, I find it useful to ask one question before discussing implementation.

"Which responsibility disappears, and which responsibility moves?"

Those are very different outcomes.

If the responsibility genuinely disappears because the requirement no longer exists, the simplification is real.

If the responsibility merely moves into another layer, another application, another team, or another person's memory, then the proposal is not eliminating complexity.

It is redistributing it.

Redistribution is not automatically bad.

Sometimes moving responsibility closer to where it belongs is exactly the right decision.

The important part is making that movement explicit.

Architectural diagrams tell only part of the story#

A clean diagram can create false confidence.

It is easy to mistake visual simplicity for operational simplicity.

The most useful architecture documents are not the ones with the fewest boxes.

They are the ones that make responsibility obvious.

A system becomes understandable when you can answer questions like:

• Where do business rules live?
• Where does validation happen?
• Where are permissions enforced?
• Where is operational state managed?
• Where does exception handling belong?
• Who owns each decision when something changes?

Those answers matter more than the number of services or components in the diagram.

Better systems make responsibility easier to find#

The healthiest architectures I have encountered are not necessarily the smallest.

They are the ones where responsibility has a clear home.

When a rule changes, everyone knows where to look.

When behavior seems incorrect, everyone knows which layer owns that decision.

When a new engineer joins the team, they learn the structure instead of collecting tribal knowledge.

That is a different definition of simplicity.

Instead of asking how many components a system has, ask how easily someone can explain why each one exists.

If every responsibility has an intentional home, the architecture may still contain complexity.

But it will be honest about where that complexity lives.

And honest systems are almost always easier to evolve than systems that only appear simple.