Manu's Vault

Fundamentals of Software Architecture - Richards & Ford - 2020

5 min readStatus:Growing

Fundamentals of Software Architecture - Richards & Ford

Complete Bibliographic Citation

Richards, Mark and Neal Ford. (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4. Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/

Fair Use Notice

This note contains summaries and analysis of copyrighted material for educational and commentary purposes. This constitutes fair use/fair dealing under copyright law. The original work remains the property of its copyright holders. Full citation provided above.

What This Work Argues

Fundamentals of Software Architecture reframes software architecture as a discipline about trade-offs, not patterns or best practices. The authors argue that architecture is multidimensional — encompassing structure, characteristics, decisions, and principles — and that architects succeed not by knowing the “right” answer but by understanding which trade-offs matter in context. The book’s central claim: “there are no right or wrong answers in architecture — only trade-offs.”

A second running argument is that architecture is a collaborative, leadership role as much as a technical one. Architects who operate in isolation, delegate everything, or become bottlenecks all fail in different ways.

Main Ideas

Architecture has four dimensions — structure alone is insufficient Most practitioners describe architecture only by structure (e.g., “we use microservices”), but this misses three other dimensions that drive real decisions: characteristics (the -ilities that define success criteria), decisions (explicit rules for how the system must be built), and principles (guidelines for preferred approaches). A system described only by its deployment topology is under-specified. Defining Software Architecture

Architects need breadth over depth, and every decision is a trade-off Unlike developers who should go deep in a few areas, architects need to know enough about many technologies to evaluate trade-offs across them. The “knowledge pyramid” frames this as expanding what you know you don’t know — awareness of five caching solutions is more valuable than mastery of one. This breadth directly enables the core skill: trade-off analysis. Every architectural decision involves choosing what to optimise and what to sacrifice; the goal is the least-worst combination for your specific context. Architecture Versus Design, Breadth vs Depth

Architecture characteristics (the -ilities) must drive style selection Before choosing an architecture style, architects must systematically identify which characteristics — operational (availability, scalability, performance), structural (maintainability, testability, deployability), and cross-cutting (security, compliance) — matter most for their system. Characteristics come from both explicit requirements and implicit domain knowledge. An e-commerce system nearly always needs availability and performance; a healthcare system nearly always needs security and auditability. The “least worst architecture” is the style whose characteristic trade-off profile best matches the ranked priorities. Architecture-Characteristics-Categories, Explicit-Architecture-Characteristics, Implicit-Architecture-Characteristics, Architecture-Style-Selection-Framework

Characteristics must be measurable and enforced automatically Aspirational characteristics (“we want high performance”) are meaningless without measurement. The book introduces Fitness Functions as automated tests that verify characteristics remain healthy as the system evolves — a page-load test in CI/CD, a layering rule that fails if presentation code touches the database, a deployment frequency check. Without this, architectural drift is inevitable: developers under deadline pressure make exceptions that gradually erode the structure. Measuring-Architecture-Characteristics, Architectural-Governance

Architecture decisions require explicit documentation Undocumented decisions lead to three anti-patterns: Covering Your Assets (decisions without justification), Groundhog Day (repeatedly re-arguing settled decisions), and Email-Driven Architecture (decisions buried in threads). Architecture Decision Records (ADRs) solve this by capturing context, decision, and consequences — creating institutional memory that survives team turnover and prevents redundant debates. Architecture-Decision-Records, Architecturally-Significant-Decisions

Architecture is a collaborative, leadership role as much as a technical one Architecture fails when architects operate as either control freaks (bottlenecking every decision) or armchair architects (disconnected from implementation). Effective architects mentor developers, define checklists that empower teams to make good local decisions, and communicate architecture through consistent diagramming standards. Negotiation — with business stakeholders (frame as cost/risk/time), other architects (cite principles and data), and developers (demonstrate feasibility) — is as essential as technical skill. Architect-Personalities, The-Four-Cs-of-Architecture, Architecture-Diagrams-Standards

Key Frameworks or Models

  • Architecture-Quantum — the smallest independently deployable unit with high functional cohesion; in microservices, each service is a separate quantum with its own characteristic requirements
  • Connascence — a more nuanced coupling metric than cohesion/coupling alone; asks “if this code changes, how many other places break?”
  • Conway’s-Law — organisations produce designs that mirror their communication structure; team organisation and architecture style must be co-designed
  • Risk-Storming — collaborative workshop to identify architectural risks before decisions are locked in: identify → build consensus → mitigate
  • The-20-Minute-Rule — invest 20 minutes daily in deliberate learning; over a year this compounds to 120 hours of professional development

Key Concepts Extracted

Foundations & Fundamentals

Modularity & Component Modeling

Architecture Characteristics

Governance & Fitness Functions

Distributed Systems & Styles

Architecture Styles

Decision-Making

Communication & Documentation

Architect Role & Soft Skills

Sources

Note

This note was researched and drafted with AI. How these notes are written →

Graph View

Backlinks