Chapter 1 Flashcards — What Happens When There Are No “Best Practices”?
flashcards saht trade-offs adr fitness-functions
Why do software architects say there are no “best practices” in architecture?
?
Because every architectural decision is context-dependent. What works at one scale, team size, domain, or technology generation may fail in another. Best practices embed hidden assumptions about context — when that context doesn’t match, the practice can actively cause harm. The correct alternative is trade-off analysis: explicitly identifying what each option gains and what it costs in your specific context.
What is a trade-off in the context of software architecture?
?
A situation in which every available option has both benefits and costs, and the architect’s job is to determine which costs are acceptable given the current context. There is no option with only benefits in real architectural decisions. The author’s core thesis is that architecting is fundamentally an act of choosing which trade-offs to accept.
What is an Architectural Decision Record (ADR)?
?
A short, structured document capturing a single architectural decision. Standard sections include: Title (short noun phrase), Status (Proposed/Accepted/Deprecated/Superseded), Context (situation and forces at play), Decision (what was decided, active voice), and Consequences (both positive and negative effects). ADRs make decisions auditable, teachable, and revisable.
Why is the “Consequences” section the most important part of an ADR?
?
Because it explicitly surfaces what was traded away, not just what was gained. Without consequences, an ADR is merely a changelog. With consequences, future architects can understand whether the assumptions that justified the decision still hold, making it possible to revisit and revise decisions as context changes. ADRs without consequences hide costs.
What problem do ADRs solve that informal decision-making does not?
?
Tribal knowledge loss. Without ADRs, architectural decisions become embedded in the system’s structure but lose their reasoning. New team members see what was decided but not why. When the original decision-makers leave, the context (especially constraints that ruled out alternatives) is lost. ADRs preserve the reasoning so future architects can re-evaluate decisions with full information.
What is an architecture fitness function?
?
An objective function — automated or manual — used to evaluate whether an architecture satisfies a specific architectural characteristic (e.g., performance, coupling, security). Borrowed from evolutionary computing, where fitness functions score candidate solutions against a target. In architecture, they detect architectural drift — the gradual degradation of structural intent — before it becomes irreversible.
Name the two main dimensions along which fitness functions are classified.
?
By trigger: Continuous (every build/commit), Triggered (on schedule or demand), or Temporal (time-based). By scope: Atomic (single characteristic in isolation) or Holistic (multiple interacting characteristics). They can also be Automated (code-based, e.g., ArchUnit, load tests) or Manual (review processes, governance gates).
What is architectural drift, and how do fitness functions address it?
?
Architectural drift is the gradual accumulation of small, locally-reasonable decisions that collectively move a system away from its intended structure. Each individual change seems fine; the cumulative effect violates architectural intent. Fitness functions address drift by encoding architectural intent as executable tests that run continuously, detecting violations immediately rather than letting them accumulate silently.
Give a concrete example of an automated fitness function for coupling.
?
An ArchUnit rule (Java) that fails the build if any class in the order package imports a class from the payment package directly. This enforces service boundary isolation as an architectural characteristic, making coupling violations visible at compile/test time rather than during architecture reviews. The fitness function turns a governance concern into an automated test.
How do the authors define the distinction between architecture and design?
?
Architecture is whatever is hard to change later — decisions with high impact if wrong, requiring coordination across teams, services, or data boundaries to reverse. Design is everything else. This definition is deliberately context-sensitive and technology-agnostic: the same decision (e.g., choosing a data structure) might be design in a small utility and architecture in a shared library used across services.
Why do the authors reject the term “non-functional requirements”?
?
Because calling qualities like performance, security, and scalability “non-functional” implies they are less important than functional requirements — which is false. The authors prefer architectural characteristics to signal that these qualities are first-class concerns that constrain and shape the architecture, not afterthoughts bolted on once functional requirements are satisfied.
What is an architectural characteristic?
?
A system quality attribute — such as scalability, elasticity, reliability, security, or performance — that an architecture must satisfy. Also called non-functional requirements (a term the SAHT authors reject). Architectural characteristics are the things you care about in addition to whether the system does the right thing — they constrain how it does it.
Why is data a first-class architectural concern in distributed systems?
?
Because data ownership, consistency requirements, and schema evolution often determine which architectures are even feasible. Architects who design service interactions without deciding data ownership are only designing half the system. In distributed systems, where data may live in multiple stores owned by different services, decisions about who can change data, how changes propagate, and what consistency guarantees apply are architectural — not implementation — decisions.
What tension exists between shared databases and per-service databases in distributed architectures?
?
Shared database: Simpler to query across domains, supports ACID transactions across entities, but structurally couples services — a schema change in one domain can break another. Per-service database: Services are independently deployable and evolvable, but querying across services requires API calls or event-driven synchronization, and cross-service consistency requires distributed transaction patterns (sagas, eventual consistency). Neither is universally better.
What is the Sysops Squad, and why is it introduced in Chapter 1?
?
The Sysops Squad is a fictional IT support ticketing company used as a case study throughout the book. It has a monolithic legacy system with shared databases, accumulated technical debt, and business requirements (ticket routing, billing, SLAs) that impose real constraints. It is introduced in Chapter 1 to ground the book’s abstract trade-off analysis in a concrete, realistic system — demonstrating that architectural decisions arise from the intersection of business constraints, team structure, and technical debt.
Why do best practices “age poorly” in software architecture?
?
Because they embed assumptions about technology, scale, team topology, and domain that change over time. A “best practice” validated in 2010 (e.g., “use a service bus for all inter-service communication”) may be obsolete, actively harmful, or simply superseded by better approaches by 2021. Advice framed as trade-off analysis ages better because the trade-offs themselves remain true even as the specific technologies involved change.
What is the difference between a triggered and a continuous fitness function?
?
A continuous fitness function runs on every build or commit — e.g., a performance regression test in CI that fails if p99 latency exceeds a threshold. A triggered fitness function runs on a schedule or on demand — e.g., a monthly security scan or a quarterly architecture review checklist. Continuous functions catch violations immediately; triggered functions are appropriate for checks that are too expensive or slow to run on every commit.
What is an architectural quantum? (Brief definition — full treatment in Chapter 2)
?
An architectural quantum is a unit of architecture with high functional cohesion and independent deployability. It represents the smallest unit of architecture that can be deployed independently while still delivering meaningful business value. Introduced briefly in Chapter 1 as part of the book’s vocabulary, developed fully in ch02-coupling.
What ADR anti-pattern involves writing the record after the decision is already finalized and uncontested?
?
The rubber-stamp ADR anti-pattern: writing an ADR purely to document a decision that was already made informally, with no genuine consideration of alternatives or trade-offs. This defeats the primary purpose of ADRs, which is to make the decision-making process — including the options considered and rejected — explicit and auditable.
What is the risk of only recording successful architectural decisions in ADRs?
?
Decisions that were reversed, superseded, or abandoned are equally valuable — sometimes more so. They record what was tried, why it failed or was rejected, and what constraints ruled it out. Without these records, future architects may attempt the same failed approach without knowing it was already tried. ADRs for superseded decisions should reference what replaced them and why.
Why might a practice that is “best” at Google’s scale be harmful at a startup?
?
Because scale changes the trade-offs. Practices designed for large scale (e.g., complex distributed caching, multi-region replication, extensive observability infrastructure) carry operational overhead, cost, and complexity that a small team cannot sustain. Applying them prematurely (premature optimization at the architectural level) consumes resources that small teams need for product development. Context — team size, traffic scale, operational maturity — determines which trade-offs are acceptable.
What does it mean for an architectural decision to be “hard to reverse”?
?
A decision is hard to reverse when changing it requires coordination across multiple teams, services, or data boundaries. Examples: changing whether a service owns its data (requires data migration and API renegotiation), changing the communication style between services from synchronous to asynchronous (affects all callers), or changing a shared database schema (affects all services that query it). Hard-to-reverse decisions are architectural; easy-to-reverse decisions are design.
How does the framing of “trade-offs” in SAHT differ from the framing of “best practices”?
?
Best practices framing: one option is presented as correct; others are presented as inferior. Costs of the “best” option are hidden or minimized. Trade-off framing: all options are presented with their benefits and costs explicitly. No option is universally correct. The question is always “under what conditions does this option’s benefits outweigh its costs?” Trade-off framing is more honest, more durable, and more useful for context-specific decision-making.
What is the purpose of the “Context” section of an ADR?
?
To capture the situation and forces that made a decision necessary — including technical constraints, organizational factors, timeline pressures, and the alternatives that were considered. The context section is what allows future architects to determine whether the decision should be revisited: if the context has changed materially, the decision may no longer be valid, and the ADR should be updated or superseded.
Total Cards: 24
Priority: HIGH
Last Updated: 2026-05-30