Chapter 03 · L01 — how architects turn fuzzy words like "secure" and "fast" into scenarios you can actually test, plus the tactics and design decisions that make them real.
State what the system must do — "the system shall <behavior>." Their implementation plan lives in the detailed design.
Judge the system as a whole rather than one behavior. Their implementation plan lives in the architecture.
Architecture documents serve many stakeholders — developers, managers, sales, testers, support, maintenance, customers — and each cares about a different quality attribute most:
Quality attributes are constraints on how the system delivers its functionality — not the functionality itself. They're the criteria used to judge the system's performance and effectiveness during and after development (efficiency, availability, scalability, adaptability, security, dependability...).
Same functional requirement, three different QA lenses: "When the user presses the green button, the Options dialog appears."
Quality attributes often have unstable definitions or overlapping concerns. Classic example: is a system failure from a Denial-of-Service attack about availability, performance, security, or usability?
System is down
System becomes very slow
The attack is a breach
Users can't access the service
All four are "correct" — the same problem overlaps multiple attributes. Vague labels aren't precise enough to design or test against.
Example — Availability, made concrete: If the payment server crashes during a transaction (stimulus), the system shall automatically switch to a backup server within 2 seconds (response), guaranteeing 99.99% uptime (measure). Now it's clear, testable, and non-overlapping.
"Some (source) generates some events (stimulus) that arrive at some (artifact) under some conditions (environment) and must be dealt with (response) in a satisfactory way (response measure)."
Crash — sudden failure of the system.
Omission — failure to respond when expected.
Timing — response arrives at the wrong time.
No Response — complete lack of a response.
Incorrect Response — the system responds, but wrongly.
Internal to system — a bug, a memory leak — problems from within.
External to system — a power outage, a hacking attempt — problems from outside.
Tactics are primitive design techniques an architect uses to achieve a quality-attribute response — architectural building blocks, much like design patterns, distilled from years of experienced-architect know-how.
In short: tactics are intended to control responses to stimuli.
Purpose: prevent system failure when a component fails.
Tactic: run multiple instances of critical components so others take over if one fails.
Stimulus: hardware failure, network outage.
Response: automatic failover to backup systems.
Purpose: improve response time, reduce system load.
Tactic: store frequently accessed data somewhere fast to reach.
Stimulus: a high number of read requests.
Response: serve from cache instead of re-fetching from primary storage.
Architecture design is a systematic way of making decisions — and those decisions sort into 7 categories.
| Decision | What it's really about | Example |
|---|---|---|
| Allocation of Responsibilities | Which part of the system handles which task | Login module vs. cart module vs. payment module in a shopping app |
| Coordination Model | How parts communicate and work together | Payment system informs inventory when an item sells |
| Data Model | What data exists, how it's organized and accessed | A Customer object with name, address, order history |
| Management of Resources | How memory, CPU, and bandwidth are allocated | Reserving extra server capacity for high-traffic periods |
| Binding Time | When architectural elements get set or chosen | Language preference set at install vs. at runtime |
| Choice of Technology | Languages, databases, platforms selected | Python backend + PostgreSQL + AWS hosting |
| Mapping among Elements | How code modules map to runtime elements | A UI module mapped to the services it calls at runtime |