chapter four

4 Design for evolution: architecture that survives change

 

This chapter covers

  • Why systems never stay still
  • Evolvability as a first-class architectural concern
  • Sensing change through feedback loops
  • Designing for safe adaptation and delayed commitment
  • Keeping architecture soft, replaceable, and incrementally evolvable
  • The architect’s role in helping systems and teams adapt over time

As John F. Kennedy put it in 1963, “Change is the law of life. And those who look only to the past or the present are certain to miss the future.” Software architecture lives under that same reality: systems survive absorbing change without losing stability or making every future change more expensive.

Most modern systems are not designed to be perfect. They are to keep working while their context changes. In real-world scenarios, software rarely remains static. Once in use, it continuously changes, adapting to new technologies, shifting requirements, team reorganizations, budget constraints, and organizational priorities. In some cases, the original purpose fades entirely and the system takes on a different role.

4.1 Systems never sit still

4.2 Evolution as a first-class architectural quality

4.3 Feedback loops and sensing change

4.4 Designing with future change in mind

4.4.1 Avoiding premature commitment

4.4.2 Designing seams

4.4.3 The Strangler Fig pattern

4.4.4 Architecture decision records (ADR)

4.5 Keeping architecture soft, not rigid

4.5.1 Modular monolith vs. distributed monolith

4.5.2 Avoiding accidental complexity

4.5.3 Team maturity matters

4.5.4 Backward compatibility and versioning

4.5.5 Event-driven vs. request-driven evolvability

4.6 Cloud-specific evolution traps

4.7 Designing for incremental replaceability

4.8 Evolution as collaboration

4.9 The architect’s role in evolutionary systems

4.10 Summary