Core Idea
Most architecture decisions aren’t binary but rather exist on a spectrum between extremes. The appropriate position on the spectrum depends on the specific context and priorities of the project. Perfect solutions don’t exist; aim for the option that best serves current constraints—the “least worst architecture.”
The third law of software architecture, defined in “Fundamentals of Software Architecture” by Mark Richards & Neal Ford - “Most architecture decisions aren’t binary but rather exist on a spectrum between extremes.”
Spectrum Thinking: (nuance over binary choices). Most decisions involve degrees along a continuum rather than simple yes/no answers.
Context is key: The appropriate position on the spectrum depends on the specific context and priorities of the project. A decision that is right for one system might be wrong for another, which is why the “why” behind a decision is often more important than the “how.”
Least Worst Architecture: (pragmatic realism). Perfect solutions don’t exist; aim for the option that best serves current constraints—the one with the fewest trade-offs given your current situation.
Why This Matters in Practice
Architects who treat decisions as binary often force systems into ill-fitting extremes. For example:
- Synchronous vs. asynchronous communication is not binary. Systems often combine both based on consistency and latency requirements per use case.
- Monolith vs. microservices is not binary. Modular monoliths, service-based architectures, and micro-frontends exist between the extremes.
- SQL vs. NoSQL is not binary. Polyglot persistence selects the appropriate data store for each domain.
The appropriate spectrum position depends on the specific trade-offs prioritized by the architecture characteristics (performance, scalability, consistency, cost) of the current system.
Related Concepts
- Everything in software architecture is a trade-off. - The second law of software architecture; spectrum thinking is how trade-offs are navigated in practice
- Why is more important than how. - Understanding context (why) determines the right spectrum position (how)
- Trade-Offs-and-Least-Worst-Architecture - Formalizes the “least worst” choice as the practical architectural goal
- Architecture-Decision-Records - Documents which spectrum position was chosen and why, enabling future re-evaluation
- Architecture-Decision-Criteria - The criteria that determine the appropriate position on a decision spectrum
Sources
- Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Third Law of Software Architecture
- Discussion of spectrum thinking and context-dependent decisions
- Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
Note
This note was researched and drafted with AI. How these notes are written →