Software Architecture Is About Things Hard to Change
Every team talks about architecture - yet most struggle to define what it actually is. When asked, they point to diagrams, frameworks, or infrastructure choices.
But it’s not a diagram or technology stack. The real problem isn’t missing documentation or better tools - it’s a missing understanding of what architecture truly represents.
Ralph Johnson and Martin Fowler arrived at a deceptively simple answer:
Architecture is about the important stuff. Whatever that is.
But what makes something important? The answer lies in reversibility.
The Cost of Changing Your Mind
Not all decisions have equal weight. Choosing a variable name? Change it in seconds. Renaming a class? Some decisions - once made- become load-bearing walls in your system.
Architecture is the set of decisions that are hard to change.
This is the definition that matters. It shifts the focus from what you’re building to what you’re committing to.
Consider the difference:
Easy to change: A function’s internal logic, a UI component’s styling, a local variable name.
Hard to change: The programming language, the database engine, the communication protocol between services, the system boundaries.
When you choose PostgreSQL over MongoDB, you’re not making a database decision - you’re making an architectural decision. Your team will write queries, design schemas, and build tooling around that choice for years.
Why “Hard to Change” Matters
This definition is powerful because it’s actionable. It tells you where to invest your thinking.
Before you commit to a decision, ask:
How expensive will it be to reverse this decision in 12 months?
If the answer is “a few hours of refactoring,” - it’s not architecture. Move fast.
If the answer is “we’d have to rewrite three services and migrate a year of data” - you’re looking at architecture. Slow down. Think harder. Get more input.
This framing also explains why architecture evolves. What’s hard to change today may become easy tomorrow. Containerization made infrastructure more reversible. Feature flags made deployment decisions more reversible. The job of a modern architect is to reduce the surface area of irreversibility - to make fewer things architectural.
The Practical Test
When evaluating any technical decision, run it through the reversibility filter:
Service boundaries: Hard to change. Once teams, APIs, and databases align to a boundary, moving responsibilities is expensive.
API contracts: Hard to change. External consumers depend on them. Breaking changes cascade.
Programming language: Hard to change. Training, tooling, and hiring all compound.
Internal class structure: Easy to change. Refactor freely.
Framework choice: It depends. A thin wrapper? Easy. Deep integration? Hard.
The boundary between “architecture” and “design” isn’t fixed - it’s determined by reversibility in your context.
Summary
Software architecture is the set of decisions that are hard to change.
This definition:
Focuses attention on high-stakes decisions
Provides a clear test: How hard is this to reverse?
Explains why architecture is context-dependent - what’s hard to change varies by team, system, and tooling
Guides architects toward reducing irreversibility wherever possible
Without this lens, teams over-engineer trivial decisions and under-invest in critical ones.
Architecture isn’t about diagrams. It’s about knowing which decisions will haunt you - and getting those right.
References
Martin Fowler, Software Architecture Guide
Martin Fowler, Patterns of Enterprise Application Architecture