Code changes all the time.
Architecture doesn’t.
And that’s exactly the problem.
Code is flexible — architecture is not
Code is local.
It can be:
- modified
- refactored
- replaced
Architecture is different.
It defines:
- how systems communicate
- how data flows
- how decisions propagate
Architectural decisions affect the entire system and are costly to change once implemented, because their impact is spread across the codebase
Which means:
code evolves faster than architecture.
Architecture captures assumptions — not reality
Every architectural decision is based on assumptions:
- expected scale
- user behavior
- business needs
- available technology
But those assumptions change.
Research shows that requirements volatility directly impacts architecture, forcing systems to adapt to shifting contexts
The problem is:
architecture doesn’t update at the same speed.
Good decisions still age badly
Most architectural decisions are not wrong.
They are correct — at the time.
But over time:
- context shifts
- constraints change
- new requirements appear
As a result, even well-made decisions turn into limitations.
Not because they failed.
Because the environment moved.
Architecture is harder to replace than code
You can rewrite a function.
You can’t easily rewrite:
- data models
- communication patterns
- system boundaries
That’s why, as described in
Why Software Rarely Gets Rewritten From Scratch
systems are rarely rebuilt.
And why, as described in
Migration Projects That Never Finish
architecture changes take years — if they finish at all.
Old architecture survives inside new systems
Even when code is updated, architecture often remains.
As described in
Old Code Survives Because Replacement Is Hard
systems accumulate layers.
New code sits on top of old decisions.
Over time, this creates:
- mismatched abstractions
- duplicated logic
- hidden constraints
Complexity grows around outdated decisions
As systems evolve, they don’t replace architecture.
They adapt around it.
This leads to what is often called architecture erosion, where systems drift away from their original design over time
And eventually:
no one fully understands the system anymore.
As described in
The Systems Nobody Fully Understands Anymore
complexity becomes the default state.
Humans adapt to architecture, not the other way around
When architecture no longer fits reality,
teams don’t remove it.
They work around it.
As described in
Why Humans Struggle to Oversee Complex Automated Systems
people adapt to system limitations.
Not the reverse.
Architecture ages because the world moves faster
Technology evolves.
Business models evolve.
User expectations evolve.
But architecture is built for a snapshot in time.
What this actually means
Architecture doesn’t age because it’s poorly designed.
It ages because it’s fixed.
Code can keep up with change.
Architecture can’t.
And over time,
the system stops reflecting current reality —
and starts reflecting past decisions.