Design It!

Contents

• Part 01 · Software Architecture Fundamentals
  01Become a Software Architect
  02Design Thinking Fundamentals
• Part 02 · Architecture Design Process
  03Devise a Design Strategy
  04Empathize with Stakeholders
  05Dig for Architecturally Significant Requirements
  06Choose an Architecture (Before It Chooses You)
  07Create a Foundation with Patterns
  08Manage Complexity with Meaningful Models
  09Host an Architecture Design Studio
  10Visualize Design Decisions
  11Describe the Architecture
  12Give the Architecture a Report Card
  13Empower the Architects on Your Team
• Part 03 · The Architect's Toolbox
  14Activities to Understand the Problem
  15Activities to Explore Potential Solutions
  16Activities to Make the Design Tangible
  17Activities to Evaluate Design Options

Become a Software Architect

Every team has at least one architect; the great teams have several. Keeling defines software architecture as the set of significant design decisions that shape a system's quality attributes, lays out the architect's six recurring responsibilities, and introduces the three architectural structures (modules, components-and-connectors, allocations) plus the running Project Lionheart case study.

Architecture Defined

A system's architecture is the set of significant design decisions about how the software is organized to promote desired quality attributes. Significance is judged by impact on qualities, not on features — features can usually go anywhere, but qualities are baked into structure.

What Software Architects Do

Six recurring responsibilities: engage stakeholders, focus on quality attributes, manage technical debt, decide what is architecturally significant, define engineering practices, and grow the team's architectural skills. Architecture is a role, not a title.

Three Architectural Structures

Every system has three coexisting structures: modules (design-time code units), components and connectors (runtime computational units and their pathways), and allocations (mappings to hardware, teams, and environments). Each answers different questions for different stakeholders.

Quality Attributes Drive Architecture

Architecture exists to promote externally observable properties — performance, availability, security, modifiability. Features can be added almost anywhere; qualities are determined by structure and are nearly impossible to retrofit.

Become an Architect for Your Team

Anyone making architecturally significant decisions is already practicing the architect role. The goal is to do it deliberately rather than by accident, regardless of title or seniority.

Build Amazing Software

The architect's purpose is enabling teams to ship valuable software, not producing diagrams. Architecture is a means; the working system is the end.

Project Lionheart

The recurring case study throughout the book: a digital marketplace connecting lawyers with low-income clients. It makes techniques concrete by showing them performed on a single realistic project.

Software Architecture

The set of significant design decisions shaping how a system is organized to promote desired quality attributes.

Module

A design-time code unit (package, class, file) — what you touch when you edit source.

Component

A runtime unit of computation (process, service, object) that performs work while the system executes.

Connector

A runtime pathway through which components interact (HTTP, queue, shared memory, method call).

Allocation

A mapping from software elements onto non-software elements such as hardware, teams, or deployment environments.

Quality Attribute

An externally visible property used to judge the system (performance, availability, security, maintainability).

Technical Debt

Accumulated cost of past decisions that makes future change harder; architects actively manage it.

Architecturally Significant Decision

A decision whose change would be expensive or disruptive — these are what architecture concerns itself with.

Multiple choice

According to Keeling, what makes a design decision architecturally significant?

• AIt changes user-visible functionality
• BIt is documented by a person holding the title "Architect"
• CIts change would be expensive or disruptive, and it shapes a quality attribute
• DIt is made early in the project rather than late

Multiple choice

A teammate insists their team has "no architect" because nobody on the org chart carries that title. What's the most accurate response based on Chapter 1?

• AThey're right — without a designated architect, the system has no architecture
• BSomeone is already making architecturally significant decisions; architecture is a role, not a title
• CThey should immediately hire an external architect to fill the gap
• DOnly modules need an architect; runtime structure emerges from code

Spot the issue

A team plans to deliver a high-availability trading platform by first shipping features quickly, then "adding availability later" once revenue justifies the work. What's the main risk?

• AThey should write availability tests before any feature code
• BQuality attributes like availability are baked into structure and cannot be reliably retrofitted onto an existing architecture
• CThey need a senior architect to sign off before shipping any code
• DAvailability is a feature, so it can be slotted in like any other story

Multiple choice

Which trio correctly names Keeling's three coexisting architectural structures?

• AFrontend, backend, and database
• BLayers, services, and pipelines
• CModules, components-and-connectors, and allocations
• DDiagrams, decisions, and documents

Design Thinking Fundamentals

Architecture is a creative human activity, not a deterministic engineering output. Keeling adapts Meinel and Leifer's design thinking to software, introducing four universal principles (Human, Ambiguity, Redesign, Tangibility), four iterative mindsets (Understand, Explore, Make, Evaluate), and the Think-Do-Check loop that structures any design activity.

The Four Principles of Design Thinking

Meinel and Leifer's universal rules — Human, Ambiguity, Redesign, Tangibility — apply to software architecture as much as to industrial design. They frame architecture as social, exploratory, derivative, and concrete.

Human Rule

All design is social. Architecture is done by people, for people, and with people; ignoring stakeholders produces technically correct systems that fail socially.

Ambiguity Rule

Preserve ambiguity. Don't collapse the solution space too early — multiple viable designs almost always exist, and premature commitment forecloses better options.

Redesign Rule

All design is redesign. Patterns, reference architectures, and prior systems are starting points; pure greenfield design is rare and usually unwise.

Tangibility Rule

Make ideas tangible. Sketches, models, and prototypes let teams critique and converge on ideas that would otherwise stay vague in conversation.

The Four Design Mindsets

Understand, Explore, Make, Evaluate. Architects move fluidly among these stances rather than executing them as a linear waterfall; each mindset asks a different question of the work.

Think, Do, Check

The iteration engine: form a hypothesis (Think), run a small experiment (Do), then critically examine results (Check) before the next step. This is how architectural learning compounds.

Architecture as Wicked Problem

Architectural problems are ill-defined; the problem and solution co-evolve. Exploring solutions actually clarifies the problem — which is why you can't fully analyze before designing.

Design Thinking

A creative, analytical approach that puts humans at the center and treats design as iterative learning.

Design Mindset

A stance (Understand, Explore, Make, Evaluate) an architect adopts toward the work at a given moment.

Understand

Activities aimed at learning the problem — stakeholder interviews, requirements gathering, context investigation.

Explore

Activities generating candidate solutions — divergent ideation, pattern selection, sketching alternatives.

Make

Activities turning ideas into tangible artifacts — diagrams, prototypes, models, documentation.

Evaluate

Activities testing whether designs fit the problem — reviews, scenarios, prototypes, metrics.

Think-Do-Check Loop

Plan a learning step, perform it, reflect on what was learned — the cyclic execution unit of design.

Co-Evolving Problem and Solution

The idea that the problem isn't fully knowable until you sketch solutions; each clarifies the other.

Multiple choice

Which sequence best captures the four design mindsets Keeling adapts from Meinel and Leifer?

• APlan, Design, Build, Test — applied in that strict order
• BUnderstand, Explore, Make, Evaluate — moved among fluidly, not as a waterfall
• CDiverge, Converge, Document, Ship
• DRequirements, Architecture, Implementation, Maintenance

True / False

Because architectural problems are well-defined engineering problems, the architect can fully analyze the problem before generating any candidate solutions.

• TrueTrue
• FalseFalse

Spot the issue

After a single ninety-minute whiteboard session, a lead architect declares "we've found the design" and tells the team to start coding. No alternatives were sketched, and dissent is treated as obstruction. Which design-thinking principle is most directly violated?

• AThe Human Rule — the architect didn't talk to enough users
• BThe Redesign Rule — they should have started from an existing pattern
• CThe Tangibility Rule — the whiteboard wasn't a real prototype
• DThe Ambiguity Rule — the solution space was collapsed before alternatives were considered

Multiple choice

In Keeling's Think-Do-Check loop, what does the Check step actually require?

• ARun an automated test suite against the production build
• BCritically examine the results of the experiment and decide what was learned before the next step
• CGet sign-off from a senior architect before moving on
• DDocument the decision in an ADR and move on

Devise a Design Strategy

Effective architects pick a design strategy before they pick a design — deciding how much to design up front, which risks to chase, and how to structure learning. Keeling frames architecture as risk-driven and satisficing rather than optimizing, and introduces the lightweight Design Plan that organizes the work.

Design as a Series of Experiments

Designs are hypotheses about how to meet requirements. The strategy decides which hypotheses to test first and how to test them cheaply, treating each design step as a learning experiment.

Risk-Driven Design

Let risk choose the next move. If you have no significant risks remaining, you've designed enough; if you do, attack the riskiest one with the cheapest method that retires it. Drawn from George Fairbanks.

Risk Expression Format

Keeling's template: "[Conditions] might result in [consequences]." Naming both conditions and consequences makes risks discussable, prioritizable, and falsifiable rather than vague worries.

Risk Response Options

Five legitimate responses: reduce probability, reduce impact, shorten the window of exposure, transfer, or explicitly accept. Acceptance is a real move, not a failure to act.

Satisficing, Not Optimizing

Borrowing from Herbert Simon: aim for a design that is satisfactory and sufficient given constraints, rather than chasing an unreachable optimum. Architecture is a satisficing discipline.

How Much Up-Front Design?

A spectrum from none to total. Pick a point based on risk, team experience, novelty, and rate of change — not dogma about agile vs. big up-front design.

Simplify the Problem

Use chosen constraints, scope cuts, and assumptions to shrink the design space until a satisficing solution becomes findable. Constraints are tools, not obstacles.

The Design Plan

A lightweight living artifact recording what you know, what you don't, the biggest risks, and the next design activities. The architect's working document, not a deliverable.

Design Strategy

The architect's plan for how to do design — how much up front, which risks to target, which activities to use, when to stop.

Risk

A condition that, if it occurs, threatens a quality attribute or project outcome.

Risk-Driven Design

An approach in which presence and severity of risks dictate which design activities to perform next.

Satisficing

Choosing a solution that is satisfactory and sufficient rather than optimal; the practical aim of architecture work.

Constraint

An unchangeable design decision, imposed externally or self-imposed, that reduces the design space.

Business Constraint

A constraint affecting people, process, cost, or timeline.

Technical Constraint

A constraint restricting technology choices (e.g., must run on JVM, must use the company's auth service).

Design Plan

A short, living document recording knowns, unknowns, key risks, and next design steps.

Multiple choice

Under Keeling's risk-driven approach (after Fairbanks), how does an architect decide whether they've designed enough?

• AWhen the team has produced a fixed number of diagrams and ADRs
• BWhen a senior architect signs off on the design document
• CWhen no significant risks remain that justify further design activity
• DWhen the schedule for design work has been exhausted

Multiple choice

Which of the following is not one of Keeling's five legitimate responses to a risk?

• AReduce the probability that it occurs
• BTransfer the risk to another party
• CEliminate the risk entirely before any design work continues
• DExplicitly accept the risk

Spot the issue

A team's risk register reads: "The system might be slow." Leadership keeps asking what to do about it, and the team keeps debating without converging. What's wrong with this risk?

• AIt's not testable because no acceptance criteria were defined
• BIt states neither the conditions that trigger it nor the consequences if it occurs, so it can't be prioritized or falsified
• CPerformance isn't a real architectural risk — only security is
• DThe risk should have been transferred to operations rather than discussed

True / False

Because architecture should always seek the optimal solution, satisficing is a sign that the architect gave up too early.

• TrueTrue
• FalseFalse

Multiple choice

How should an architect decide how much up-front design to do on a new project?

• APick a point on the spectrum based on risk, team experience, novelty, and rate of change
• BAlways do extensive up-front design — agile is incompatible with architecture
• CAlways do minimal up-front design — agile teams architect emergently
• DMatch whatever the previous project used, for consistency

Empathize with Stakeholders

Architecture begins with understanding people, not technology. Great software only emerges when the architect deeply understands the humans whose lives the system will affect, and this chapter provides concrete tools — stakeholder identification, mapping, and goal discovery — to build that understanding before any design choice is made.

Stakeholders

Anyone with a vested interest or concern in the software — users, sponsors, operators, developers, regulators. Identifying them is one of the architect's first responsibilities because their needs shape every downstream decision.

Talk to the Right People

Deliberately seek a representative cross-section of stakeholders rather than only the loudest or most accessible. The architect's job is to hear all the voices that should influence design.

Stakeholder Map

A network diagram showing all the people involved with or affected by the system and the relationships between them. It makes invisible stakeholder ecosystems visible so none are forgotten.

Business Goals

The high-level outcomes the organization wants from the software — revenue, compliance, market position. Architecturally significant requirements are derived from and traceable back to these goals.

Empathy as a Technical Skill

Empathy isn't soft; it's how the architect avoids solving the wrong problem. Understanding stakeholder perspectives is a disciplined competence, not a personality trait.

Architect as Facilitator

The architect doesn't unilaterally collect requirements; they orchestrate interviews and workshops so the whole team builds shared understanding of who matters and why.

Point-of-View Mad Lib

A structured sentence template ("[user] needs [need] because [insight]") that turns raw research into a crisp framing of one stakeholder's problem.

Stakeholder

Any person, group, or organization whose interests are affected by the system.

Stakeholder Map

A network/relationship diagram visualizing stakeholders and how they interact.

Business Goal

A measurable outcome the organization wants the system to enable — the upstream "why."

Empathy (architectural)

A disciplined effort to see the system from each stakeholder's perspective.

Interview Stakeholders

The book's structured one-on-one conversation technique for surfacing needs and concerns.

Point-of-View Mad Lib

A fill-in template for crisply stating a stakeholder need and the insight behind it.

Project Lionheart

The book's recurring case study used to demonstrate each technique end to end.

Multiple choice

What is the purpose of building a stakeholder map at the start of a project?

• ATo assign blame when requirements change
• BTo make the invisible network of people involved with or affected by the system visible so none are forgotten
• CTo rank stakeholders by seniority for prioritization
• DTo document who has approval authority over each decision

Multiple choice

Fill in the Point-of-View Mad Lib template: "[user] needs [need] because ____."

• A[a competing solution exists]
• B[the business goal demands it]
• C[insight]
• D[acceptance criteria]

Spot the issue

An architect spends a week interviewing only the two loudest executives and the engineering manager, then declares stakeholder discovery "done." A month into the build, regulators raise blocking compliance concerns nobody surfaced. Which Chapter 4 principle was violated?

• AThe architect should have written more ADRs during discovery
• BThe architect failed to deliberately seek a representative cross-section of stakeholders and missed voices that should have influenced design
• CEmpathy is a soft skill and shouldn't drive architectural decisions
• DCompliance is a feature, not an architectural concern

True / False

Empathy is a soft personality trait, so it isn't part of an architect's technical toolkit.

• TrueTrue
• FalseFalse

Multiple choice

According to Chapter 4, how should architecturally significant requirements relate to business goals?

• AASRs should be traceable back to high-level organizational outcomes the software is meant to enable
• BThey are independent — business goals belong to product, not architecture
• CBusiness goals are derived from ASRs once the architecture is set
• DBusiness goals only matter for commercial software, not internal tools

Dig for Architecturally Significant Requirements

Not all requirements influence architecture, but a critical few do, and missing them is the most common cause of failure. This chapter teaches the architect to systematically uncover Architecturally Significant Requirements by examining four sources — constraints, quality attributes, influential functional requirements, and other influencers — and to capture them in an ASR Workbook the whole team shares.

Architecturally Significant Requirements

Any requirement that strongly influences the choice of structures. Identifying ASRs is the architect's core responsibility because they drive every major structural decision; missing them is the usual reason architectures fail.

Constraints

Unchangeable design decisions you're given or give yourself. They split into technical (platform, integrations) and business (people, process, cost, schedule) and narrow the design space before exploration begins.

Quality Attributes

Non-functional system properties — performance, scalability, availability, security, testability, maintainability, time-to-market. The architecture's job is to promote the ones stakeholders care about most, trading off the rest.

Quality Attribute Scenarios

A structured testable statement using stimulus, environment, artifact, response, and response measure. Turns vague goals like "fast" into measurable claims like "respond in <200ms 99% of the time."

Influential Functional Requirements

Rather than enumerating every feature, group functions into classes and look for the small set whose existence reshapes the architecture (e.g., "must support offline mode" is architecturally loaded).

Other Influencers

A catch-all bucket for team experience, organizational politics, available skills, and prior commitments. These bend architectural choices even though they aren't in the formal requirements list.

Dig for Information

ASRs are usually undocumented and must be excavated through interviews, prototyping, observation, and asking uncomfortable questions. Don't expect them to be handed to you.

ASR Workbook

A living artifact recording all ASRs — constraints, scenarios, influential functions, other influencers — so programmers, testers, and architects share the same context and the team needs less ongoing architectural oversight.

ASR

An Architecturally Significant Requirement — one that strongly influences structure.

Constraint

An unchangeable design decision, technical or business.

Quality Attribute

A measurable non-functional property (an "-ility").

Quality Attribute Scenario

A six-part testable statement: source, stimulus, environment, artifact, response, response measure.

Stimulus

The triggering event in a quality attribute scenario.

Response Measure

The quantifiable yardstick that determines whether the response is acceptable.

Influential Functional Requirement

A feature whose presence or scale forces a particular structural choice.

ASR Workbook

The shared record of all architecturally significant requirements.

Multiple choice

Which of the following best characterizes an Architecturally Significant Requirement?

• AA user-facing feature that appears in the product backlog with the highest business priority.
• BAny requirement the product owner has formally signed off on.
• CA requirement that strongly influences the choice of architectural structures.
• DA bug or defect that has been escalated to the architecture team.

Multiple choice

A stakeholder says, "The system should be fast." Which response best converts this into something architecturally useful?

• AAdd "fast" to the non-functional requirements list and move on.
• BPromise sub-second latency in the product brochure to lock in expectations.
• CMark performance as the top-priority quality attribute and pick a pattern known for speed.
• DWrite a quality attribute scenario specifying stimulus, environment, response, and a response measure.

True / False

Most ASRs are already captured in the formal requirements document handed to the architect, so the architect's main job is to read them carefully.

• TrueTrue
• FalseFalse

Spot the issue

A team starts designing a new claims platform and lists hundreds of functional requirements but only one line about constraints: "must integrate with existing systems." Halfway through implementation they discover the existing auth service only supports SAML, blocking their planned OAuth flow and forcing a rewrite of the identity layer. What was the main architectural mistake?

• AThey should have chosen OAuth before learning what auth the company supported.
• BThey never treated technical integration constraints as ASRs worth digging into up front.
• CThey had too many functional requirements relative to non-functional ones.
• DThey failed to write a quality attribute scenario for security.

Choose an Architecture (Before It Chooses You)

With ASRs in hand, the architect must actively choose a structure rather than let one accrete by default. The chapter frames design as an iterative diverge-converge process: deliberately generate many alternatives, then narrow them by weighing options against constraints, quality attributes, functional responsibilities, and likely future change.

Diverge to See Options, Converge to Decide

The central rhythm: first expand the option space (sketches, alternatives, brainstorms), then narrow through analysis and consensus. A "decision" with only one option isn't a decision — it was made for you.

Accept Constraints

Constraints aren't obstacles to fight; they're the boundaries of the playing field. Internalizing them early prevents wasted exploration of designs that can never ship.

Promote Desired Quality Attributes

Choices should actively elevate the quality attributes stakeholders prioritize — which often means accepting trade-offs (e.g., favoring availability over consistency in a CAP-style decision).

Assign Functional Responsibilities

The mechanical core of designing: take required functions and allocate each to a specific architectural element (module, component, service) with clear ownership.

Design for Change

Anticipate where the system will evolve and place boundaries at the joints where change is likely. Future modifications stay localized rather than rippling across the system.

Architectural Elements

The named building blocks the architect arranges — modules, components and connectors, allocation elements. The architecture is the pattern of relationships among them.

Decision-Support Techniques

Named convergence activities: Decision Matrix, Risk Storming, Scenario Walkthrough, Sketch and Compare, Sanity Check. Used to converge rationally rather than by gut.

Architecture Decision Records

A lightweight format for capturing each significant decision, its context, alternatives considered, and consequences — so future teams know why the architecture looks the way it does.

Diverge / Converge

The two phases of design exploration — generate options, then narrow them.

Design Space

The full set of architectural alternatives that satisfy the constraints.

Architectural Element

A first-class building block — module, component, connector, allocation — of the architecture.

Responsibility Assignment

Mapping a system function to the specific element that will fulfill it.

Trade-off

A conscious sacrifice of one quality attribute to better promote another.

Design for Change

Placing modular boundaries where future change is anticipated.

Decision Matrix

A scoring tool for comparing alternatives against weighted criteria.

Architecture Decision Record

A written record of one significant architectural decision and its rationale.

Multiple choice

According to Keeling, what is wrong with a "decision" that has only one option on the table?

• ANothing — single-option decisions are the fastest way to ship.
• BIt violates ADR formatting rules, which require listing at least three alternatives.
• CIt actually isn't a decision — the choice was made for you, by default, without exploring the design space.
• DIt is fine if the option was suggested by the most senior architect on the team.

Multiple choice

A team must pick between a strongly-consistent SQL store and a highly-available eventually-consistent store for the same workload. Which Chapter 6 concept best frames this choice?

• ADesign for Change — the future will pick for them.
• BAccept Constraints — the budget will dictate the answer.
• CArchitectural Elements — the database is just one element.
• DPromote Desired Quality Attributes — they must consciously trade availability against consistency based on stakeholder priorities.

Spot the issue

A team finishes designing a new platform and the architect closes the meeting saying, "Great, I'll write up the chosen design." Six months later, new engineers join, question why the team picked queues over synchronous calls, and end up re-running the same debate from scratch. What did the architect fail to do?

• AHold a longer design meeting so everyone would remember the outcome.
• BPick a more popular pattern that wouldn't have raised questions.
• CCapture each significant decision in an ADR with context, alternatives considered, and consequences.
• DMandate that all new engineers shadow the architect for a month before contributing.

Multiple choice

Which of these is not one of Chapter 6's named decision-support techniques for converging on an architectural choice?

• APair Programming
• BDecision Matrix
• CRisk Storming
• DScenario Walkthrough

Create a Foundation with Patterns

Architects rarely invent structure from scratch; they start from time-tested patterns that bundle proven solutions to recurring structural problems. This chapter defines what an architecture pattern is, catalogs the ones a practicing architect should know cold, and shows how to combine and adapt them as the foundation of a new system.

What Is an Architecture Pattern?

A reusable, named solution to a recurring structural problem in a given context. Patterns give the architect shared vocabulary, a head start on structure, and known trade-offs to reason about.

Layers Pattern

Organizes the system into horizontal layers (presentation, business, data) where each layer only depends on the ones below it. Promotes separation of concerns and modifiability at some performance cost.

Ports and Adapters

Hexagonal architecture: isolates core business logic behind technology-agnostic ports so external systems plug in via adapters. The core can be tested and reused independent of UI, database, or messaging choices.

Pipe-and-Filter

Decomposes processing into independent filters connected by pipes — ideal for transforming streams of data. Each filter has one responsibility and filters can be recombined.

Service-Oriented Architecture

Decomposes the system into independently deployable services that communicate over a network; modern microservices are a variant. Trades local complexity for distributed-system complexity.

Publish-Subscribe

Components emit events to topics; other components subscribe. Publishers and subscribers don't know about each other directly, enabling loose coupling and asynchronous flows.

Shared-Data

Multiple components coordinate by reading and writing a common store. Useful for analytics and integration; the data store becomes both the integration point and a coupling risk.

Big Ball of Mud

An anti-pattern describing a system with no discernible structure. Called out so architects can recognize it forming and intervene before it solidifies.

Architecture Pattern

A reusable, named, structural solution to a recurring problem in a context.

Layers

Pattern of stacked, downward-only-dependent horizontal slices.

Ports and Adapters

Pattern isolating core logic behind interfaces (ports) implemented by interchangeable adapters.

Pipe-and-Filter

Pattern of single-responsibility processing stages connected by data pipes.

Service-Oriented Architecture

Pattern of independently deployable, network-accessible services.

Publish-Subscribe

Pattern of decoupled, event-driven communication via topics.

Shared-Data

Pattern where coordination happens through a common data store.

Big Ball of Mud

Anti-pattern — a system with no coherent architecture, dominated by ad hoc dependencies.

Multiple choice

A team wants to make its core business rules testable independently of the database, the HTTP API, and the message broker, so any of those externals can be swapped without touching the rules. Which Chapter 7 pattern is the most direct fit?

• APorts and Adapters
• BLayers
• CPipe-and-Filter
• DShared-Data

Multiple choice

In a strict Layers architecture, which dependency direction is permitted?

• ALayers may freely depend on any other layer in either direction.
• BHigher layers depend only on layers below them; lower layers do not depend on higher layers.
• CLower layers depend on higher layers to receive instructions.
• DAdjacent layers may depend on each other, but non-adjacent layers may not.

Spot the issue

Two years after launch, a system has no clear module boundaries: any class can reach into any other, the same domain concept lives in five places under different names, and new engineers can't predict where to add code. The lead architect insists "we don't follow rigid patterns here." What is the architectural problem?

• AThe team should have written more unit tests.
• BThe team should have adopted a stricter coding style guide.
• CThe system has decayed into a Big Ball of Mud — an absence of architecture that the architect failed to recognize and intervene on.
• DThe team needs a faster CI pipeline so refactors are easier.

True / False

Adopting a Service-Oriented Architecture eliminates complexity because each service is small and independent.

• TrueTrue
• FalseFalse

Manage Complexity with Meaningful Models

Successful systems accumulate complexity, and architects manage it by building meaningful models — abstractions that establish shared vocabulary, focus attention on significant detail, and let the team reason about quality attributes before code exists. The chapter walks through using models to reason, designing a deliberate meta-model, and building those concepts into the source code itself.

Abstraction as Complexity Control

A good architectural model deliberately hides what doesn't matter so the team can think about what does. Complexity is inevitable; unmanaged complexity is a choice.

Four Qualities of a Good Model

A meaningful model (1) establishes a shared design vocabulary, (2) focuses attention on significant details, (3) lets you reason about quality attributes, and (4) captures architect intent.

Meta-Model

The set of element types, relation types, and rules that *your* architecture is made of (e.g., "Service," "Adapter," "calls," "subscribes-to"). It's the schema the diagrams and code both speak.

Elements and Relations

The two primitive building blocks of any architectural model: things (elements) and the ways they connect (relations).

Model-Code Gap

The inevitable divergence between abstract model and running code. You can't eliminate it, only narrow it through naming, structure, and enforcement.

Build Models into the Code

Use architecture vocabulary as actual code identifiers, organize packages to mirror architectural elements, and enforce relations (dependency rules) so violations break the build.

Reason about the Architecture

Models exist to be queried: walk through scenarios, trace quality-attribute behavior, and check whether the structure actually delivers the required properties before committing.

Model

A purposeful abstraction of the system that highlights some properties and hides others.

Meta-model

The vocabulary — element types, relation types, constraints — used to construct a model.

Element

A named thing in the architecture (component, module, service, store).

Relation

A named connection between elements (uses, calls, depends-on, contains).

Design Vocabulary

The shared set of names and concepts the team uses to discuss architecture.

Model-Code Gap

The conceptual distance between what the architecture model says and what the source code does.

Abstraction

A simplified representation that suppresses detail to make reasoning tractable.

Architectural Intent

The "why" behind the structure — the qualities and decisions the model is meant to preserve.

Multiple choice

According to Chapter 8, what is the inevitable distance between the abstract architectural model and the running source code called?

• ADesign entropy
• BArchitectural drift
• CModel-Code Gap
• DImplementation debt

Multiple choice

Which of the following is not one of Keeling's four qualities of a meaningful architectural model?

• AEstablishes a shared design vocabulary.
• BFocuses attention on significant details.
• CLets the team reason about quality attributes.
• DCaptures every implementation detail of the running system.

Spot the issue

An architect produces a beautiful UML diagram showing "PaymentService" and "OrderAggregate" with clean relations, but in the codebase those names appear nowhere — the packages are called `util`, `helpers`, and `manager`, and any class can call any other. Six months later, no one can map the diagram to the code. Which Chapter 8 practice was skipped?

• AUsing a stricter UML tool to enforce notation.
• BBuilding the model into the code by using architecture vocabulary as code identifiers and enforcing relations.
• CAdding more diagrams to clarify the original one.
• DChoosing a simpler meta-model with fewer element types.

Multiple choice

What does a meta-model define for an architecture?

• AThe specific values of configuration parameters in production.
• BThe element types, relation types, and rules that the architecture's model is built from.
• CThe list of stakeholders the architect needs to interview.
• DThe set of test cases the system must pass before release.

Host an Architecture Design Studio

A design studio is a time-boxed, collaborative workshop where a mixed group rapidly generates, shares, and critiques candidate architectures, building both diverse options and team buy-in. Keeling provides a repeatable structure — plan, kick off, create, share, critique, iterate, close — and stresses that productive disagreement is the point.

The Design Studio Loop

A repeating cycle of Create → Share → Critique → Iterate, bracketed by a Kickoff and a Close. Each pass surfaces options and converges them.

Plan a Design Studio

Before the meeting: define the goal, gather ASRs, pick activities, prepare materials, decide what "done" looks like. A bad plan produces a bad studio.

Choose Appropriate Activities

Match the activity to the phase. Round-Robin Design, Whiteboard Jam, Group Posters, and Event Storming are studio staples.

Invite the Right Participants

Three to ten people with diverse roles (developers, testers, product, ops, stakeholders). Too few = narrow thinking; too many = conversation breakdown.

Time-Boxing

Short, strict time boxes — often five minutes minimum per activity — force quick sketches and prevent over-polishing. Diverge first to see options, converge later.

Manage the Group

The facilitator draws out quiet voices, watches for groupthink, keeps activities on the clock, and enforces fact-based critique rather than vague reactions.

Productive Disagreement

Frictionless agreement usually signals shallow exploration. The facilitator's job is to surface dissent safely, not suppress it.

Work with Remote Teams

Adapt the studio with virtual whiteboards, smaller breakouts, slower pacing, and explicit turn-taking to compensate for lost in-person cues.

Design Studio

A focused, time-boxed collaborative workshop for exploring architecture options as a group.

Kickoff

The opening phase where the facilitator shares context, goals, ASRs, and ground rules.

Round-Robin Design

A studio activity where each participant sketches, passes the sketch to the next person to critique, then to a third to refine.

Time-Box

A fixed, short, unextendable duration assigned to an activity.

Diverge / Converge

Expanding the option space, then narrowing to a chosen path.

Facilitator

The neutral host who runs the studio without pushing their own design.

Critique

Specific, fact-based feedback distinct from opinion or general reaction.

Groupthink

The failure mode where social pressure produces premature consensus.

Multiple choice

A facilitator is planning a design studio and considers inviting the entire 22-person engineering org so "nobody feels left out." What's the best response?

• AGo ahead — broader input always produces better designs.
• BCap the room at roughly three to ten people with diverse roles and run separate sessions if needed.
• CRestrict it to the three most senior architects so decisions get made faster.
• DSkip the studio and just send a survey to everyone instead.

True / False

If a design studio ends with the whole group nodding along to a single proposal and no real disagreement, that's a sign the facilitator did a great job.

• TrueTrue
• FalseFalse

Spot the issue

A studio's first activity is "Round-Robin Design." The facilitator tells participants to "take as long as you need to get the diagram right" before passing it on. Two hours in, only one rotation has happened. What's the main problem?

• ARound-Robin Design isn't appropriate this early in a studio.
• BThe facilitator should be doing the sketching themselves to set a baseline.
• CThe activity wasn't time-boxed, so participants are over-polishing instead of diverging.
• DThe group is too small for round-robin to work.

Multiple choice

Which sequence best describes the inner loop of a design studio after kickoff?

• ACritique → Create → Iterate → Share
• BShare → Critique → Create → Iterate
• CIterate → Share → Create → Critique
• DCreate → Share → Critique → Iterate

Visualize Design Decisions

Diagrams are how architecture becomes tangible to other people. The chapter teaches how to show a system through different views — each a window onto one aspect — and how to draw individual diagrams that communicate. The guiding mantra: accurate, not precise.

Different Views

No single diagram captures a whole system. Pick complementary views (module/static, runtime/component-and-connector, allocation/deployment) and let each answer a specific question.

A View Is a Window

Each view projects the underlying model through one lens; together they triangulate the design. Choose views based on stakeholder concerns, not on what's easy to draw.

Accurate, Not Precise

Precision (exact UML semantics, pixel-perfect notation) gets in the way of communication. Aim for faithfulness to the meta-model, not formal correctness.

Anatomy of a Great Diagram

Every diagram needs a meaningful title, a legend, a consistent notation, supporting prose, and a single clear message. Without a legend it is decoration, not documentation.

Sketch First, Polish Later

Start drawing immediately when discussing an abstract idea; the act of sketching makes it tangible and surfaces problems faster than discussion alone.

Match the View to the Audience

Different stakeholders care about different views. Design the diagram for whoever has to read it, not for the architect.

Consistency Across Diagrams

Reuse shapes, colors, and naming across a set of related diagrams so the same element looks the same everywhere. Inconsistency forces readers to re-learn the notation on each page.

View

A representation of the architecture from one perspective, addressing specific concerns.

Viewpoint

The template defining what a view contains — its elements, relations, and intended audience.

Notation

The visual language (shapes, lines, colors) used in a diagram, formal or informal.

Legend

The key mapping each shape and line style back to a meta-model element or relation.

Module View

A view showing implementation-time structure — packages, classes, modules, static dependencies.

Runtime View

A component-and-connector view showing execution-time structure.

Allocation View

A view showing mapping from software elements to deployment hosts, teams, or files.

Sketch

A deliberately rough, fast, low-fidelity drawing used to make abstract ideas tangible.

Multiple choice

A reviewer rejects a team's architecture diagram because it doesn't use strictly correct UML 2.5 notation for one of the arrows. Which chapter principle is the reviewer ignoring?

• AAccurate, not precise — communication beats formal notational correctness.
• BDifferent views — one diagram can't capture everything.
• CConsistency across diagrams — shapes should match.
• DMatch the view to the audience.

Spot the issue

A team publishes a single, dense system diagram for everyone — operations, frontend developers, and the security team. Each group complains they can't find what they need. What's the architectural diagnosis?

• AThe diagram lacks a legend so it isn't documentation.
• BThe team is trying to compress every stakeholder concern into one view instead of using complementary views.
• CThe notation isn't formally precise enough.
• DThe diagram needs more colors and more boxes.

Multiple choice

You're sketching architecture options at the whiteboard for a 20-minute discussion. Which approach matches Keeling's advice?

• AStep away to draft a polished diagram in a CASE tool, then bring it back.
• BTalk through the idea verbally; only diagram once everyone agrees.
• CSketch immediately while talking, even roughly, to make the idea tangible.
• DWait until the discussion ends, then write up the agreed design as a single polished diagram.

Multiple choice

Which element does Keeling say turns a decorative picture into actual documentation?

• ASticking to a single shape style so every box looks identical.
• BA meaningful title and a legend mapping shapes back to the meta-model.
• CStrict UML 2.5 compliance.
• DExhaustively labeling every element with its fully qualified type name.

Describe the Architecture

Architecture descriptions exist to communicate decisions to the people who will use, build, evolve, or audit the system. Keeling argues for matching description formality to situation — start lightweight, organize multiple views around stakeholder concerns, and always document rationale so future readers understand the why, not just the what.

Tell the Whole Story

A good description weaves context, requirements, structures, and rationale into one coherent narrative — not just a pile of diagrams. The reader should understand both what was built and why.

Match Description Method to Situation

Two questions choose the method: how likely are decisions to change and how widely must they be shared. The answers land you in one of four quadrants: tribal, communal, formal, or wasteful.

Tribal Description Methods

Oral tradition, whiteboard sketches, system metaphors, storytelling. Cheap to change, hard to share at scale — appropriate for small co-located teams and fast-moving designs.

Communal Description Methods

Lightweight, shareable artifacts: ADRs, Architecture Haiku, an architecturally evident coding style. Use these when you find yourself telling the same story repeatedly.

Formal Description Methods

Heavy, structured documents — e.g., a full Software Architecture Document following Views and Beyond or ISO/IEC/IEEE 42010. Worth the cost only for high-risk systems, regulated industries, or wide long-lived audiences.

Respect Your Audience

Use empathy mapping to understand readers' goals, vocabulary, and time budget. A polished, professional document signals trustworthiness and gets read; don't write for yourself.

Organize Views around Concerns

Architecture is too big for a single diagram. Use multiple views grouped into viewpoints that each address a related set of stakeholder concerns (e.g., C4, Kruchten's 4+1).

Explain the Rationale

Document not just what was chosen but what was rejected and why. The list of discarded alternatives is often more illuminating than the defense of the survivor.

Architecture Description

The set of artifacts (sketches, views, ADRs, narratives) communicating an architecture to its stakeholders.

View

A representation of the system from one perspective.

Viewpoint

A reusable template defining what a category of view shows and which concerns it answers.

Stakeholder Concern

A specific interest, need, or quality requirement; drives which viewpoints you create.

Rationale

Recorded reasoning behind a decision, including alternatives considered and trade-offs.

Architecture Haiku

A single-page architecture summary covering essentials — context, drivers, key decisions, constraints.

Architecturally Evident Coding Style

A coding convention where code itself makes architectural intent visible.

4+1 / C4 Model

Two well-known viewpoint catalogs used as starting points.

Multiple choice

A startup of six co-located engineers is shipping weekly and their architecture changes constantly. Which description method best fits?

• AA full Software Architecture Document following ISO/IEC/IEEE 42010.
• BTribal methods — whiteboard sketches, system metaphors, and oral storytelling.
• CA 200-page formal viewpoint catalog refreshed each sprint.
• DNo description at all; agile teams don't document.

Spot the issue

A senior architect produces a 180-page Software Architecture Document for an internal CRUD admin tool used by five teammates that gets rewritten every quarter. The author is proud of the rigor. What's wrong?

• AThe document should be even longer to be authoritative.
• BThe method is mismatched to the situation — formal artifacts aren't justified when decisions change often and the audience is small.
• CADRs should never be used; only full SADs count.
• DThe team should have used oral tradition exclusively, even at this scale.

Multiple choice

According to Keeling, what often illuminates a design decision more than the defense of the chosen option?

• AThe size of the diagram.
• BThe number of stakeholders consulted.
• CThe list of alternatives that were considered and rejected, with reasons.
• DThe formality of the notation used.

True / False

A communal description method like an ADR or an Architecture Haiku is most appropriate when the team finds itself telling the same architectural story over and over.

• TrueTrue
• FalseFalse

Give the Architecture a Report Card

Evaluation is a learning activity: you test the design against the requirements that matter to discover risks, gaps, and misunderstandings before they ship. Keeling promotes lightweight scenario-based evaluation built around a design rubric derived from the ASRs, scaling from a quick desk-check up to a full ATAM-style review.

Evaluate to Learn

The point isn't a grade; it's to educate the team, create buy-in, surface risk, and improve the architecture. Treat findings as input to the next design iteration, not as a verdict.

Design Rubric

Build a rubric of testable criteria derived from the ASRs. Good criteria are important, essential, distinct, observable, measurable, precise, and unambiguous.

Rating Scales

Choose the scale to fit: 1–2 for pass/fail, 1–3 for a minimum threshold, 1–4 for richer feedback. Always discuss any "1" score, even if the average looks fine.

Host an Evaluation Workshop

Five steps: prepare, prime reviewers, assess against the rubric using scenarios, analyze findings into themes, follow up by turning risks into action.

Scenario-Based Evaluation

Probe the design with concrete quality-attribute scenarios — performance, security, modifiability — and walk through how the architecture handles each. This is the lightweight cousin of formal SEI methods.

ATAM as Gold Standard

The SEI's Architecture Tradeoff Analysis Method is the heavyweight reference: it produces risks, non-risks, sensitivity points, tradeoff points, and risk themes tied back to business drivers. Use it as inspiration, not default.

Start with Low-Ceremony Methods

Use Scenario Walkthrough, Code Review, and Architecture Briefing before reaching for ATAM. Small frequent reviews beat one big audit.

Erosion and Drift

Continuous evaluation guards against two decay modes: erosion (implementation deviates from intended architecture) and drift (the architecture no longer fits a changed business context).

Design Rubric

Criteria plus rating scale derived from the ASRs, used to score the architecture.

Evaluation Criterion

One testable rubric statement (e.g., "p95 latency under 200 ms for search").

Scenario Walkthrough

A lightweight evaluation technique tracing a quality-attribute scenario through the architecture.

ATAM

A heavyweight, scenario-based SEI evaluation method surfacing risks, sensitivity, tradeoffs, and non-risks.

Risk

A decision (or absence) that may cause the system to fail a quality requirement.

Non-Risk

A decision confirmed sound for its requirement — worth recording so it isn't re-litigated.

Sensitivity Point

A property components have on which a particular quality attribute strongly depends.

Tradeoff Point

A decision that is a sensitivity point for two or more quality attributes pulling against each other.

Multiple choice

A team finishes a scenario-based evaluation. The rubric averages a respectable 3.1 out of 4, but one criterion received a 1 from two reviewers. What does Keeling say to do?

• ATrust the average and ship — 3.1 is above threshold.
• BRedo the entire workshop because one outlier invalidates the run.
• CDiscuss every "1" score even when the average looks fine.
• DDrop the outlier ratings and recompute the mean.

Spot the issue

An organization wants to evaluate a small team's new architecture and immediately schedules a three-day ATAM with two SEI-trained facilitators, formal risk themes, and a 60-page report. What's the architectural critique?

• AATAM doesn't surface sensitivity points so it's the wrong method.
• BHeavyweight ATAM is overkill here; start with low-ceremony methods like Scenario Walkthrough, Code Review, or Architecture Briefing and use ATAM as inspiration, not default.
• CThe team should skip evaluation entirely since the system is small.
• DATAM should be used without a rubric.

Multiple choice

Continuous evaluation defends against two long-term decay modes. Which pair does Keeling name?

• AEntropy and bit rot.
• BErosion (implementation deviating from intended architecture) and drift (architecture no longer fitting a changed context).
• CCoupling and cohesion.
• DRisks and non-risks.

Multiple choice

Where should evaluation criteria in a design rubric come from?

• AThe architect's personal preferences about clean code.
• BThe standard SEI list of quality attributes, copied wholesale regardless of project.
• CThe architecturally significant requirements (ASRs).
• DWhichever metrics the team's CI pipeline already happens to collect.

Empower the Architects on Your Team

The most resilient architectures come from teams that think architecturally, not from a single hero architect handing down decisions. Keeling reframes the architect's job as coach, mentor, and facilitator: spread architectural thinking, create safe practice for less experienced teammates, and delegate authority deliberately so the team grows into shared ownership.

Promote Architectural Thinking

Treat software architect as a way of thinking available to every team member, not a job title. Teams that internalize this produce better software because more eyes are on design.

Facilitate, Don't Dictate

The architect's value is often in running the conversation, not making the call — surface options, ask questions, let the team reason together. The discussion develops architectural judgment.

Safe Practice

Let teammates make real design decisions in low-stakes situations: pair design, peer review, assigned design spikes. People need reps without risking the system.

Scaffolding for Delegation

Provide templates, checklists, ADR formats, and review questions so a less experienced person can do good architectural work without reinventing the structure.

Architectural Guide Rails

Define constraints — allowed languages, patterns, layering rules, fitness functions — that bound the design space. Inside the rails, anyone decides; outside, they escalate.

Delegate Design Authority

Hold authority where the cost of being wrong is high; hand it off where the team can learn and recover. Be explicit about who decides what.

Design Together

Use collaborative practices — design studios, group modeling, architecture katas, pair design — so architecture is produced by the team rather than handed to it. Buy-in is a side effect of participation.

Architect as Mentor

The senior architect's primary output is other architects. Code reviews framed as teaching, pairing on tough decisions, and information sessions all grow team capability.

Architectural Thinking

The habit of considering trade-offs, quality attributes, and structures — distinct from holding the title.

Pair Design

Two people working through a design problem at the whiteboard, analogous to pair programming.

Architectural Guide Rails

Pre-agreed constraints — rules, patterns, fitness functions — that keep delegated decisions inside acceptable bounds.

Design Authority

The right to make a binding architectural decision; held, shared, or delegated explicitly.

Scaffolding

Reusable supports — templates, checklists, ADR skeletons — that let less-experienced teammates produce good architectural work.

Safe Practice

A low-consequence setting (spike, kata, pair session) where a teammate exercises design skills with feedback.

Fitness Function

An automated check enforcing an architectural property in code or CI.

Information Session

A short focused teaching event — brown bag, tech talk, walkthrough — used to diffuse architectural knowledge.

Multiple choice

A new architect joins a team and immediately starts handing down decisions to "stop the bikeshedding." A year later the team still escalates everything to her. What's the strategic problem?

• AThe team needs a more rigid ADR template.
• BShe's dictating instead of facilitating, so the team isn't growing architectural judgment of its own.
• CShe should hire more senior engineers.
• DArchitectural thinking is a job title, not a habit.

True / False

According to Keeling, the senior architect's primary output is the architecture document — not other architects.

• TrueTrue
• FalseFalse

Spot the issue

A staff architect wants to delegate decisions but is afraid juniors will pick the wrong databases or violate layering. He keeps stepping in to overrule them. What practice would Keeling recommend?

• AStop delegating; keep all decisions centralized.
• BReplace the juniors with senior hires.
• CEstablish architectural guide rails — allowed patterns, layering rules, and fitness functions — so anyone can decide inside the rails.
• DForce every decision through a full ATAM evaluation.

Multiple choice

Which is an example of "safe practice" for growing architectural skill?

• ALetting a junior unilaterally redesign the production payment service overnight.
• BAssigning a junior to lead a design spike with pair design support and peer review before any commitment ships.
• CTelling juniors to read the ADR archive and not ask questions.
• DRestricting juniors from any design conversations until promoted.

Activities to Understand the Problem

The first chapter of Part III's toolbox catalogs activities for the Understand mindset, where the team uncovers ASRs, quality attributes, stakeholder concerns, and business goals before sketching solutions. Each activity is short and lightweight; Keeling presents them as building blocks you mix and match for agile teams.

Empathy Map

A four-quadrant canvas — Says, Thinks, Does, Feels — used to build empathy for a specific stakeholder. Use early when you suspect the team is making assumptions about user needs.

Goal-Question-Metric Workshop

A facilitated workshop that turns fuzzy goals into measurable metrics by deriving questions from goals and metrics from questions. Use when stakeholders can name goals but not how to measure success.

Interview Stakeholders

Structured one-on-one or small-group conversations to surface needs, concerns, and constraints. Use at kickoff and whenever a new stakeholder group appears.

List Assumptions

A rapid brainstorm to make hidden assumptions explicit so they can be validated or challenged. Use before any major commitment.

Quality Attribute Web

A radar/spider diagram visualizing the relative priority of quality attributes — performance, security, usability, etc. Use to align stakeholders on what "good" means.

Mini-Quality Attribute Workshop

A lean facilitated session adapted from the SEI's full QAW; produces a prioritized list of quality attribute scenarios in a few hours. The workhorse activity for ASR discovery.

Point-of-View Mad Lib

A fill-in-the-blank framing: "[user] needs [need] because [insight]." Converts raw research into a sharp problem statement.

Stakeholder Map

A visual diagram of stakeholders, their relationships, and their influence. Use to identify who must be consulted, informed, or convinced.

Empathy Map

A four-quadrant Says/Thinks/Does/Feels canvas for one stakeholder.

Goal-Question-Metric

A measurement framework tracing every metric back to a goal through an intermediate question.

Mini-QAW

A lightweight workshop producing prioritized quality attribute scenarios.

Quality Attribute Web

A spider/radar diagram showing relative QA priority.

Persona

A fictional but research-grounded representative of a stakeholder class.

Stimulus / Response / Response Measure

The three core elements of a quality attribute scenario.

Constraint

A non-negotiable boundary on the design.

Stakeholder Map

A visual diagram of stakeholders and their relationships.

Spot the issue

Stakeholders agree the new portal must be "successful" but every person describes success differently — adoption, revenue, fewer support tickets — and no one can name a number to hit. Which Chapter 14 activity best fits?

• AEmpathy Map, to capture what each stakeholder Says/Thinks/Does/Feels
• BStakeholder Map, to chart who influences whom
• CGoal-Question-Metric Workshop, to derive measurable metrics from each goal
• DList Assumptions, to surface what the team is taking for granted

Multiple choice

Which four quadrants make up an Empathy Map as Keeling describes it?

• AGoals, Frustrations, Tasks, Tools
• BSays, Thinks, Does, Feels
• CWants, Needs, Fears, Hopes
• DStimulus, Response, Environment, Measure

Spot the issue

The team can list eight quality attributes the system "should have" but no one can say which matter most, and arguments stall. Which Understand activity gets them aligned fastest?

• AInterview Stakeholders one by one to gather more requirements
• BPoint-of-View Mad Lib to crystallize each user need
• CList Assumptions to expose hidden beliefs
• DQuality Attribute Web to visualize and align on relative QA priority

True / False

The Mini-Quality Attribute Workshop produces a prioritized list of quality attribute scenarios in a few hours and serves as the workhorse activity for ASR discovery.

• TrueTrue
• FalseFalse

Activities to Explore Potential Solutions

Nine generative activities for the Explore mindset, where the team produces and considers many candidate solutions before converging. The activities emphasize divergent thinking, structured brainstorming, and getting ideas out of heads onto a shared surface; Keeling stresses producing a quantity of options first — evaluation comes later.

Personify the Architecture

Treat the system as a character — write its bio, imagine how it talks — to surface tacit assumptions and personality of the design. Use to break creative blocks.

Architecture Flipbook

A sequence of related diagrams shown in rapid succession to compare alternative structures. Use to make trade-offs between candidates visible at a glance.

Component Responsibility Collaborator Cards

Index cards listing a component's name, responsibilities, and collaborators (adapted from Wirfs-Brock's class CRC cards). Use to explore decomposition without committing to a notation.

Concept Map

A node-and-link diagram showing how domain concepts relate. Use to build shared vocabulary before discussing structure.

Divide and Conquer

Split a large problem into independent sub-problems small groups can attack in parallel. Use when the team has many people and a broad design space.

Event Storming

A workshop where participants use orange stickies to plaster a wall with domain events in timeline order, then add commands, aggregates, and bounded contexts. Adopted from Alberto Brandolini; especially useful before microservice decomposition.

Round-Robin Design

Participants individually sketch a design, then pass to a neighbor who continues or revises; rotate several times. Mixes ideas and prevents one person dominating.

Whiteboard Jam

Collaborative whiteboarding where the group iterates on a single drawing until it captures shared understanding. The default tool for live design conversations.

Divergent Thinking

Generating many candidate ideas without judging them.

Convergent Thinking

Narrowing candidates down to a chosen option.

Domain Event

A past-tense meaningful occurrence in the business domain (e.g., "Order Placed").

Bounded Context

A DDD term for an explicit boundary inside which a particular model is defined.

Aggregate

A cluster of domain objects treated as a single unit for consistency.

CRC Card

A Component (or Class) Responsibility Collaborator index card.

Collaborator

Another component a given component depends on to fulfill its responsibilities.

Concept Map

A node-and-link diagram of domain concepts and their relations.

Spot the issue

A team is about to carve a monolith into microservices but can't agree on where the seams should go. They need a workshop that surfaces domain events, commands, and bounded contexts on a shared wall. Which activity fits?

• APersonify the Architecture
• BWhiteboard Jam
• CEvent Storming
• DArchitecture Flipbook

Multiple choice

A facilitator wants to prevent one loud architect from dominating an early ideation session and ensure each candidate design absorbs multiple perspectives. Which Explore activity is designed for that?

• ARound-Robin Design, where sketches are passed to neighbors who continue or revise them
• BConcept Map, where the group catalogs domain vocabulary
• CDivide and Conquer, where sub-problems are tackled in parallel
• DPersonify the Architecture, where the system is given a character

Multiple choice

The team wants to explore a component decomposition quickly without committing to a notation or formal diagram. Which Chapter 15 activity is purpose-built for that?

• AConcept Map
• BWhiteboard Jam
• CEvent Storming
• DComponent Responsibility Collaborator Cards

True / False

The Explore phase emphasizes convergent thinking — narrowing the design quickly to a single chosen option — over generating many alternatives.

• TrueTrue
• FalseFalse

Activities to Make the Design Tangible

The Make phase converts ideas into concrete artifacts — diagrams, documents, decision records, prototypes — that can be shared and reviewed. This chapter's activities favor lightweight documentation over heavyweight architecture description templates, aiming at minimum viable artifacts that capture decisions and rationale.

Architecture Decision Records

Short markdown documents (typically: title, context, decision, status, consequences) capturing one decision each. Popularized by Michael Nygard; retain the *why* alongside the code.

Architecture Haiku

A one-page, severely-constrained description of an architecture's essential decisions and rationale (originated by George Fairbanks). Use when stakeholders need the gist without wading through full docs.

Context Diagram

A boxes-and-lines drawing showing the system as a single box surrounded by its external actors and systems. Use to define scope and external interfaces.

Inception Deck

A ten-slide kickoff deck (from Jonathan Rasmusson) covering why-we're-here, elevator pitch, NOT list, neighborhood, solution sketch, risks, size, trade-offs, schedule, what-it-takes. Use at project start to align everyone.

Modular Decomposition Diagram

A tree showing how the system breaks down into modules and sub-modules at varying granularities. Use to communicate static structure and code organization.

Paths Not Taken

A brief log of design alternatives the team considered and rejected, with rationale. Use to prevent re-litigating settled debates.

Prototype to Learn or Decide

Build a small, throwaway implementation to answer a specific question — feasibility, performance, ergonomics. Use when a decision can't be settled on paper.

System Metaphor

A unifying analogy ("pipes and filters", "marketplace") that gives the team a shared mental model. Borrowed from XP; useful for quick shared vocabulary.

Architecture Description

The collection of artifacts that documents an architecture.

View

A representation of the architecture from a particular concern.

Module View

A view focused on static code structure.

Runtime View

A component-and-connector view focused on execution behavior.

Notation

The visual or textual language of a diagram (UML, C4, informal).

Decision Log

Cumulative record of architectural decisions, often a folder of ADRs.

Spike

A small time-boxed implementation built to answer a question rather than to ship.

Lean Documentation

Producing only enough documentation to be useful — refusing to gold-plate.

Spot the issue

Six months after a key technology decision, a new engineer asks "why on earth did we pick this database?" and nobody on the current team can reconstruct the reasoning. Which Chapter 16 activity would have prevented this?

• AInception Deck capturing the project's elevator pitch
• BContext Diagram showing external systems
• CSystem Metaphor for shared mental model
• DArchitecture Decision Record capturing context, decision, and consequences

Multiple choice

A team is kicking off a new project and needs to align everyone on why they're here, what's in/out of scope, the neighborhood of stakeholders, top risks, and rough trade-offs — all in one sitting. Which activity fits best?

• AArchitecture Haiku
• BInception Deck
• CModular Decomposition Diagram
• DPaths Not Taken

Multiple choice

The architect needs a one-page summary of the architecture's essential decisions and rationale to hand a busy stakeholder who won't read a full document. Which artifact fits?

• AArchitecture Haiku
• BContext Diagram
• CModular Decomposition Diagram
• DPaths Not Taken

Spot the issue

The team can't decide between two persistence strategies on paper — performance and ergonomic claims keep clashing with no resolution. Which Make activity should they reach for?

• AModular Decomposition Diagram to break down the system
• BContext Diagram to bound the scope
• CPaths Not Taken to log the rejected option
• DPrototype to Learn or Decide — build a small throwaway to answer the question empirically

Activities to Evaluate Design Options

The Evaluate phase tests whether a candidate architecture will actually meet its quality-attribute targets and surfaces risks before they become production defects. The chapter's activities range from lightweight peer review to formal scenario-based analysis. Keeling positions evaluation as continuous and embedded, not a one-time gate at the end.

Architecture Briefing

A short, focused presentation of the architecture to a specific audience for feedback. Use when you need stakeholder buy-in or a sanity check from senior architects.

Code Review as Architectural Evaluation

Inspect actual code as architecture evaluation, not just quality check. Use to confirm implementation matches intended architecture and catch architectural drift.

Decision Matrix

A grid that scores design alternatives against weighted criteria (often quality attributes). Use to compare candidates objectively when trade-offs are non-obvious.

Observe Behavior

Watch the system run — production telemetry, load tests, demos — to evaluate it empirically. Use when paper analysis can't predict real performance.

Question-Comment-Concern

A structured feedback format where reviewers raise items in three categories: clarifying question, neutral comment, concern. Makes architecture reviews safer and more actionable.

Risk Storming

A workshop (originated by Simon Brown) where each person privately marks risks on architecture diagrams using colored dots, then the group discusses hotspots. Collaborative risk identification per quality attribute.

Scenario Walkthrough

Step through how the architecture handles a specific quality-attribute scenario, narrating responsibilities and interactions. The core technique for QA-based evaluation, rooted in SEI ATAM.

Sketch and Compare

Draw two or more candidate solutions side by side and have the team articulate differences. Use to make trade-offs visible during a decision meeting.

Risk

A condition that, if realized, threatens an architectural goal.

Tactic

A reusable design decision that influences a quality attribute response.

Trade-off

A decision favoring one quality attribute at the expense of another.

ATAM

The SEI's heavyweight scenario-based evaluation method.

Architectural Drift

Divergence over time between architecture as designed and as implemented.

Sensitivity Point

A design decision a particular quality attribute is highly sensitive to.

Utility Tree

A hierarchical refinement of quality goals into concrete scenarios.

Evaluation

The deliberate act of judging whether a design meets its targets.

Spot the issue

The team has a candidate architecture and needs every reviewer to flag risks privately first, then converge on the hottest spots together — and they want risks bucketed by quality attribute. Which activity fits?

• AArchitecture Briefing
• BScenario Walkthrough
• CRisk Storming, where reviewers privately mark dots on diagrams then discuss hotspots
• DDecision Matrix

Multiple choice

Two competing architectures are on the table and the team needs a way to score them objectively against weighted quality-attribute criteria. Which Evaluate activity fits?

• ADecision Matrix
• BObserve Behavior
• CArchitecture Briefing
• DQuestion-Comment-Concern

Multiple choice

The architect wants to validate that a candidate design will actually meet a specific "p95 latency under 200 ms" quality-attribute target by tracing how the architecture responds to that scenario step by step. Which activity is the core technique for this?

• ACode Review as Architectural Evaluation
• BArchitecture Briefing
• CSketch and Compare
• DScenario Walkthrough

Spot the issue

A team's intended architecture says all data access must go through a repository layer, but they suspect implementation has begun bypassing it. Which Evaluate activity should they reach for?

• ASketch and Compare to redraw the layers
• BCode Review as Architectural Evaluation to confirm code matches intended architecture
• CObserve Behavior in production telemetry
• DQuestion-Comment-Concern feedback session