Chapter 5 Flashcards — Identifying Architectural Characteristics
flashcards fsa architecture-characteristics requirements kata
What is the primary skill an architect uses when reading domain requirements?
?
Domain translation: converting business concerns and stakeholder language into specific, measurable architectural characteristics. It requires both domain knowledge and architectural judgment, not mechanical keyword matching.
What is the difference between an explicit and an implicit architectural characteristic?
?
An explicit characteristic is directly stated in requirements (e.g., “must handle 10,000 concurrent users”). An implicit characteristic is never stated but is nonetheless expected by any reasonable stakeholder (e.g., basic availability, security, reliability). Violating an implicit characteristic surprises and upsets stakeholders even though they never mentioned it.
Give three examples of implicit architectural characteristics that almost every production system requires.
?
- Availability — the system is expected to be up during the relevant operating window.
- Reliability — the system is expected to produce correct results.
- Security (basic) — the system is expected not to expose or leak sensitive data, even without an explicit security requirement.
What is a composite architectural characteristic? Give an example.
?
A composite characteristic is a high-level label that is actually composed of several more specific, measurable sub-characteristics. Example: agility decomposes into deployability (ease of releasing new versions), testability (speed and reliability of testing), and modularity (localization of change). Composites cannot be measured or governed directly — only their components can.
What does “agility” decompose into for architectural purposes?
?
Agility decomposes into three sub-characteristics: deployability (how safely and quickly new versions reach production), testability (how fast and reliably the system can be validated), and modularity (degree to which the system is partitioned so that changes are localized). All three must be addressed for a truly agile architecture.
What does “reliability” decompose into?
?
Reliability decomposes into availability (percentage of time the system is operational), recoverability (how quickly the system recovers after failure — related to RTO), and data integrity (correctness and consistency of stored data).
Why does Richards & Ford recommend limiting architectural characteristics to approximately 7?
?
The seven (or fewer) rule reflects human cognitive limits when balancing trade-offs and the observation that most systems have only 3-5 genuinely critical characteristics. Adding more characteristics adds complexity, increases cost, and creates conflicts that become unmanageable. It is a discipline heuristic, not a hard limit.
What technique can architects use to prioritize characteristics when multiple seem equally important?
?
Pairwise comparison: for each pair of characteristics, ask “if forced to sacrifice one, which survives?” The characteristic that survives more comparisons ranks higher. This forces explicit trade-off decisions rather than deferring them to implementation.
What is a “domain concern trigger word” and give two examples?
?
A trigger word is a term in stakeholder language that maps to a known architectural characteristic. Examples: “large number of users” triggers scalability; “the system must always be available” triggers availability. Richards & Ford provide a standard mapping table that architects use during requirements analysis.
What domain concerns typically map to the characteristic of security?
?
Domain concerns that map to security include: data sensitivity, compliance requirements (HIPAA, PCI-DSS, GDPR), mentions of authentication/authorization, audit trail requirements, third-party integrations that handle sensitive data, and any concern involving regulatory or legal obligations.
What domain concerns typically suggest scalability or elasticity as a characteristic?
?
Scalability/elasticity is suggested by: “large number of users,” global user base, national or international expansion plans, high transaction volume, variable or seasonal load patterns, and mentions of rapid growth. Elasticity specifically implies dynamic scaling (burst capacity), while scalability implies the ability to grow over time.
In the Silicon Sandwiches kata, what are the top 3 prioritized architectural characteristics and why?
?
- Availability (rank 1) — online and kiosk downtime directly loses revenue; any moment of unavailability has an immediate, measurable business impact.
- Scalability (rank 2) — the national franchise model means new stores are regularly added; the system must grow without rearchitecting.
- Performance (rank 3) — slow kiosk ordering creates physical queue problems in stores, directly harming customer experience.
What implicit characteristic is most critical in the Silicon Sandwiches scenario and why?
?
Reliability — specifically, orders must not be lost or corrupted. Even though it is never stated explicitly, a customer who orders a sandwich and does not receive it (or receives the wrong one) represents a fundamental failure of the system’s core purpose. This is also an implicit data integrity requirement.
What architectural implication does the “loyalty/rewards program in the future” requirement create for Silicon Sandwiches?
?
It creates the characteristic of extensibility (and contributes to agility). The architecture must be modular enough that the loyalty module can be added to the system without rearchitecting the core ordering system. This suggests a well-defined internal API boundary or a plugin/module pattern around the core ordering domain.
What is the “Wishlist Architecture” antipattern?
?
Wishlist Architecture occurs when an architect accepts all stakeholder characteristic requests without filtering or prioritizing, resulting in a requirements list of 10-15+ characteristics. This produces an impossible, prohibitively expensive, or incoherent design. The fix is pairwise prioritization and explicit trade-off documentation with stakeholders.
What is “Characteristics Inflation” and how do you prevent it?
?
Characteristics Inflation is when an initial, disciplined list of 7 characteristics grows to 15+ over time as new requirements are added without retiring outdated ones. Prevention requires treating the characteristics list as a living document with explicit retirement decisions — when a new characteristic is added, evaluate whether an existing one can be removed or downgraded.
Why is “Label-Level Design” an antipattern?
?
Label-Level Design means designing for a composite label like “scalability” or “agility” without decomposing it into specific, measurable sub-characteristics. The problem is that labels cannot be tested with fitness functions and do not produce concrete architectural decisions. Every selected characteristic must be decomposed to a measurable leaf node before design can proceed.
What are the four primary sources an architect should mine when identifying architectural characteristics?
?
- Requirements documents — explicit requirements and hidden implications.
- Stakeholder interviews — business language that must be translated to characteristics.
- Existing system pain points — what keeps breaking today reveals what characteristics were underweighted.
- Domain knowledge — architects should know the typical characteristics for their industry (e.g., finance → auditability, security).
How do you distinguish a genuine architectural characteristic from a “nice to have”?
?
Ask: “If this characteristic failed completely, would the business stop operating or would stakeholders be seriously harmed?” If yes, it is a genuine characteristic. Also apply the cost test: is the team willing to pay the architectural, infrastructure, and governance cost to achieve this characteristic? A “nice to have” is one where the answer to both questions is no.
What is the relationship between identifying characteristics and writing fitness functions?
?
Fitness functions (Chapter 6) govern architectural characteristics by providing automated checks that verify characteristics are maintained over time. But fitness functions can only be written against specific, measurable characteristics — not composites or labels. Therefore, characteristic identification (and decomposition) is a prerequisite for fitness function design. The output of Chapter 5 is the input to Chapter 6.
A stakeholder says “we need the system to be agile.” What should an architect do next?
?
Decompose the composite. Ask clarifying questions to determine which sub-characteristics are actually needed: Is the concern about deployability (releasing more frequently)? Testability (not being afraid to change code)? Modularity (one team not blocking another)? Each sub-characteristic has different architectural implications and different fitness functions. Never design against the composite label itself.
What does the conflict between “performance” and “security” typically look like, and how is it resolved?
?
Security controls (encryption, authentication checks, input validation, audit logging) add latency and CPU overhead, reducing raw performance. The resolution is to establish a performance budget that explicitly includes security overhead — the performance target is set knowing that security controls are in place, rather than measuring performance on an unsecured baseline and then trying to retrofit security.
What does the conflict between “scalability” and “data consistency” look like in practice?
?
As data is distributed across more nodes for scalability, maintaining strong consistency (all nodes see the same data at the same time) becomes expensive and introduces latency. The resolution is to choose a consistency model appropriate to the domain: strong consistency for financial transactions, eventual consistency for social feeds or product catalogs. The CAP theorem formalizes this tension.
Why is the Silicon Sandwiches scenario a useful kata for practicing characteristic identification?
?
It is a realistic, mid-complexity domain (restaurant ordering) that most architects can relate to, which means the domain knowledge barrier is low. It contains a mix of explicit characteristics (payment security, scalability), implicit characteristics (order reliability), composite characteristics (availability), and future extensibility concerns (loyalty program) — covering the full range of identification challenges in a single bounded scenario.
What makes an architectural characteristic “measurable”?
?
A characteristic is measurable when it can be expressed as a specific, observable metric with a target value and a verification method. Examples: “response time < 200ms at p99 under 1,000 concurrent users” (performance), “system available 99.9% of calendar month” (availability). An unmeasurable characteristic — like “the system should be fast” — cannot be verified, cannot be governed with fitness functions, and cannot be used to make concrete architectural decisions.
Total Cards: 25
Estimated Review Time: 35-40 minutes (first pass), 15-20 minutes (subsequent)
Priority: HIGH — characteristic identification is foundational to all subsequent architectural decisions
Last Updated: 2026-05-29