What Is Solution Architecture?
This chapter introduces the role of solution architecture, why it matters, and a practical mental model (CORE) you can use to structure decisions across projects.
Solution architecture turns business intent into a system design that can be built, operated, and evolved with confidence. The best architecture is rarely the fanciest one; it is the one that makes constraints, trade-offs, and future change visible.
Solution architecture sits between enterprise architecture (the “big picture” of strategy, standards, and roadmaps) and detailed implementation. It answers the question: given a specific business problem, what system design best solves it within the constraints of the organisation?
In practice, a solution architect is responsible for:
- Defining the high-level structure of a system
- Making technology choices aligned with business goals
- Balancing functional requirements with quality attributes (scalability, security, maintainability, cost)
- Communicating the design to developers, operations, and executives
These responsibilities are not separate tasks; they are different ways of making the same thing clear: what to build, why to build it that way, and how to keep it adaptable.
The CORE Framework
Throughout this book we refer to CORE — a simple mental model for solution architecture.
| Letter | Pillar | Focus |
|---|---|---|
| C | Constraints | Budget, timeline, regulations, legacy systems, team skills |
| O | Outcomes | Business goals, success metrics, user needs |
| R | Risks | Technical debt, single points of failure, security threats, unknowns |
| E | Evolvability | Future-proofing, modularity, upgrade paths, experimentation |
Guideline
When evaluating a technology choice, map your reasoning to CORE. If a decision doesn't clearly connect to any pillar, it may be based on habit rather than analysis.
Why Solution Architecture Matters
Without intentional architecture, systems tend toward:
- Entropy — unmanaged dependencies, copy-paste patterns, growing maintenance cost
- Brittleness — small changes break seemingly unrelated parts
- Opacity — no one understands how the system works as a whole
Solution architecture introduces deliberate structure to counteract these forces.
| Force | Effect | Architecture Response |
|---|---|---|
| Entropy | Code quality decays over time | Defined boundaries, ADRs, governance |
| Brittleness | Changes cause unexpected failures | Loose coupling, encapsulation, testing |
| Opacity | No shared mental model of the system | Diagrams, documentation, reviews |
The Scope of This Book
We cover the full arc of solution architecture:
- Frameworks and methods (Chapters 3-4)
- Design and patterns (Chapter 5)
- Infrastructure and operations (Chapters 6, 9)
- Cross-cutting concerns — security, data, integration (Chapters 7-8)
- Evaluation and evolution (Chapter 10)
Each chapter ends with practical takeaways you can apply immediately. Read sequentially for a full overview, or jump to individual chapters as needed. Cross-references point to related content throughout.
Key takeaways
- Map decisions to the CORE pillars: Constraints, Outcomes, Risks, Evolvability.
- Prefer explicit trade-offs over implicit assumptions.
- Keep documentation (ADRs, diagrams) current to reduce system opacity.
- Design for evolvability: small, reversible changes beat large, risky rewrites.