Chapter 5: Identifying Architectural Characteristics
fsa architecture-characteristics requirements kata
Status: Notes complete
Overview
Identifying the correct architectural characteristics is one of the most critical — and most difficult — tasks an architect faces. Choosing too few means the system fails under real-world conditions; choosing too many produces an over-engineered, expensive system that is hard to evolve. This chapter provides a systematic process for extracting characteristics from domain concerns, distinguishing explicit from implicit needs, understanding composite characteristics, and practicing the skill through the Silicon Sandwiches kata.
5.1 Extracting Characteristics from Domain Concerns
Domain concerns are the business requirements, constraints, and goals stated (or implied) by stakeholders. The architect’s job is to translate these concerns into measurable architectural characteristics.
The Translation Process
- Listen for trigger words in requirements documents and stakeholder conversations.
- Map triggers to characteristics — the book provides a standard mapping table (e.g., “large number of users” → scalability; “the system must always be available” → availability).
- Ask clarifying questions to distinguish genuine requirements from wishes (e.g., “5 nines of availability” vs. “we’d like it to be reliable”).
Common Domain-to-Characteristic Mappings
| Domain Concern | Likely Characteristics |
|---|---|
| Mergers and acquisitions | Interoperability, scalability, adaptability, extensibility |
| Time to market / agility | Agility, deployability, testability, modularity |
| User satisfaction / experience | Performance, availability, fault tolerance |
| Competitive advantage | Agility, innovativeness, feature velocity |
| Cost/budget constraints | Simplicity, feasibility |
| Data sensitivity / compliance | Security, auditability, legality |
| Global user base | Elasticity, performance, localization |
| High transaction volume | Scalability, performance, elasticity |
Sources of Characteristics
- Requirements documents: explicit functional requirements may hide implicit characteristics.
- Stakeholder interviews: business owners often state concerns in business language, not architectural language.
- Existing system pain points: what keeps going wrong today? Those are often the most important characteristics.
- Industry domain knowledge: architects should know the typical characteristics for their domain (finance → security, auditability; e-commerce → scalability, availability).
5.2 Explicit vs. Implicit Characteristics
A crucial distinction that prevents architects from building systems that technically satisfy stated requirements but fail in production.
Explicit Characteristics
Characteristics directly stated in requirements or stakeholder conversations.
- “The system must handle 10,000 concurrent users.” → scalability / elasticity
- “Response time must be under 200ms at the 99th percentile.” → performance
- “The system must be HIPAA compliant.” → security, auditability
Explicit characteristics are the easier half — if a stakeholder names them, the architect must address them.
Implicit Characteristics
Characteristics not stated but nonetheless required for any reasonable production system. These are the “invisible” expectations that, when violated, cause stakeholders to say “of course we needed that — why would we not?”
Common implicit characteristics:
- Availability: most systems are implicitly expected to be available during business hours (or 24/7).
- Reliability: the system is expected to produce correct results.
- Security (basic): even systems with no explicit security requirement are expected not to leak user data.
- Maintainability: the system is expected to be changeable without heroic effort.
- Usability: UIs are expected to be reasonably usable.
Key insight: Implicit characteristics are often more important than explicit ones because they represent the baseline contract of professionalism. Violating them destroys stakeholder trust.
Distinguishing the Two
Ask: “If this characteristic failed completely, would a stakeholder be surprised and upset even if they never mentioned it?” If yes, it is implicit.
5.3 Composite Characteristics
Some architectural characteristics are actually composites — they are made up of several more specific, measurable sub-characteristics. Understanding decomposition is essential for creating fitness functions (Chapter 6).
Agility as a Composite Example
“Agility” is frequently requested but rarely measurable as stated. It decomposes into:
- Deployability: how easily and safely can new versions reach production?
- Testability: can the system be tested quickly and reliably?
- Modularity: is the system decomposed such that change is localized?
An architecture optimized for agility must address all three sub-characteristics.
Reliability as a Composite
- Availability: percentage of time the system is operational.
- Recoverability: how quickly the system recovers from failure (RTO — Recovery Time Objective).
- Data integrity: correctness and consistency of stored data.
Why Composites Matter
- Composites cannot be directly measured — only their components can.
- Different sub-characteristics may point to different architectural trade-offs. For example, high deployability often benefits from microservices, while high data integrity may require coordination that microservices complicate.
- Fitness functions must target the leaf-level sub-characteristics, not the composite label.
5.4 Limiting and Prioritizing Characteristics
The “Too Many Characteristics” Trap
Every added architectural characteristic imposes costs:
- Additional design complexity.
- Additional infrastructure requirements.
- Additional testing and governance overhead.
- Characteristics frequently conflict with each other.
Richards & Ford recommend treating the list of top architectural characteristics like a product backlog: ruthlessly prioritize down to the items that genuinely differentiate the system.
The Seven (or Fewer) Rule
The book recommends a working ceiling of approximately 7 characteristics at any given architectural decision point. This is not a hard rule but reflects:
- Human cognitive limits when balancing trade-offs.
- The observation that most systems have 3-5 genuinely critical characteristics; the rest are baseline hygiene.
- The architectural “sweet spot” where trade-offs remain manageable.
Prioritization Techniques
- MoSCoW-style sorting: Must Have / Should Have / Could Have / Won’t Have.
- Pairwise comparison: for each pair of characteristics, ask “if forced to sacrifice one, which survives?” The one that survives more comparisons ranks higher.
- Domain criticality: characteristics that, if violated, cause the business to stop operating rank highest.
- Risk-driven: the characteristic most likely to be violated by the default architecture gets the most attention.
Conflicting Characteristics
Architects must explicitly acknowledge conflicts and document the accepted trade-off:
| Conflict Pair | Typical Resolution |
|---|---|
| Performance vs. Security | Establish a performance budget that includes security overhead |
| Scalability vs. Data consistency | Choose a consistency model (strong vs. eventual) appropriate to the domain |
| Agility vs. Reliability | Use progressive delivery, feature flags, and canary deployments |
| Cost vs. Availability | Define an availability tier appropriate to business criticality |
5.5 Kata: Silicon Sandwiches — Full Walkthrough
The Silicon Sandwiches kata is used throughout the book as a running example. It represents a sandwich ordering platform with both in-store kiosks and online ordering.
Problem Statement (Summary)
Silicon Sandwiches is a national sandwich franchise. Requirements include:
- Customers can order online or via in-store kiosk.
- Orders go to the local store’s kitchen display.
- The system integrates with a third-party payment processor.
- Customers can customize orders.
- Nutritional information must be displayed.
- The platform must support expansion to new franchise locations.
- The company plans to offer a loyalty/rewards program in the future.
Step 1: Identify Explicit Characteristics
Scanning the requirements for trigger words:
| Requirement Phrase | Characteristic |
|---|---|
| ”national franchise” + “expansion to new locations” | Scalability, elasticity |
| ”online ordering” | Availability, performance |
| ”third-party payment processor” | Security, interoperability |
| ”loyalty/rewards program in the future” | Extensibility, agility |
| ”in-store kiosk” | Availability (kiosk must work even if back-end is slow) |
Explicit characteristics identified: scalability, availability, performance, security, interoperability, extensibility
Step 2: Identify Implicit Characteristics
- Reliability: orders must not be lost or corrupted — customers expect correct food.
- Maintainability: franchise software must be supportable by a small team across many locations.
- Usability: kiosk users are general public; high cognitive load is unacceptable.
- Auditability: payment transactions must be traceable for dispute resolution.
Step 3: Identify Composite Characteristics
- Availability decomposes to: uptime SLA for online ordering, graceful degradation for kiosk (offline ordering mode?), recoverability.
- Security decomposes to: payment card data protection (PCI-DSS), authentication for store staff, API security for third-party integration.
Step 4: Prioritize to ~7 Characteristics
Given the business context (a restaurant franchise, not a bank or life-safety system):
| Rank | Characteristic | Rationale |
|---|---|---|
| 1 | Availability | Online and kiosk downtime directly loses revenue |
| 2 | Scalability | National rollout; new stores added regularly |
| 3 | Performance | Slow kiosk ordering frustrates in-store queues |
| 4 | Security | Payment data; PCI-DSS required |
| 5 | Extensibility | Loyalty program is a near-term roadmap item |
| 6 | Interoperability | Payment processor + potential future POS integrations |
| 7 | Reliability | Orders must not be lost |
De-prioritized (but tracked): usability (handled by UX team), auditability (standard logging satisfies requirement), maintainability (addressed through modularity choices).
Step 5: Architectural Implications
The ranked characteristics suggest:
- A cloud-hosted architecture to support elastic scaling.
- Offline-capable kiosk clients (or at minimum graceful degradation) to handle connectivity loss.
- A well-defined API boundary for the payment processor integration.
- A modular backend (not necessarily microservices — the scale may not require full decomposition) that allows the loyalty module to be added without rearchitecting the core.
Trade-offs and Decision Framework
| Option | Pros | Cons | When to Choose |
|---|---|---|---|
| Maximize characteristics (10+) | Covers all bases | Excessive complexity, conflicting requirements, unmaintainable | Never — this is an antipattern |
| Minimize characteristics (1-3) | Simple, focused | Likely to miss critical implicit needs | Only for narrow internal tools with no scalability need |
| 5-7 prioritized characteristics | Balanced, actionable, testable | Requires discipline to maintain; some stakeholders will push back | Standard production systems |
| Use composite labels only (“agility”) | Easy to communicate | Unmeasurable; cannot write fitness functions | Requirements gathering only — must decompose before design |
Common Antipatterns
Wishlist Architecture: Accepting all stakeholder characteristic requests without filtering, leading to an impossible or prohibitively expensive system. Fix: pairwise prioritization and explicit trade-off documentation.
Missing Implicit Characteristics: Building a system that satisfies all stated requirements but violates baseline expectations (e.g., no authentication on an internal tool that later becomes externally accessible). Fix: always run through the standard implicit checklist.
Label-Level Design: Designing for “scalability” without decomposing it into measurable targets (requests per second, data volume, geographic distribution). Fix: every selected characteristic must have at least one measurable fitness function.
Characteristics Inflation Over Time: The initial 7 characteristics grow to 15 as requirements evolve, without retiring outdated ones. Fix: treat the characteristics list as a living document with explicit retirement decisions.
Domain Concern Ignored: Architect maps requirements to characteristics mechanically without understanding the business domain, missing critical implicit characteristics. Fix: engage domain experts; understand what failure looks like from the business perspective.
Key Takeaways
- Domain Translation: The architect’s core skill is translating business domain concerns into measurable architectural characteristics — this is not mechanical; it requires domain knowledge and judgment.
- Explicit vs. Implicit: Explicit characteristics are stated in requirements; implicit characteristics are the unstated baseline expectations that every production system must meet.
- Composite Decomposition: High-level characteristics like “agility” or “reliability” are composites that must be decomposed into measurable sub-characteristics before architectural decisions can be made.
- The Seven Rule: Limit active architectural characteristics to approximately 7 at any decision point to keep trade-offs manageable and design decisions coherent.
- Prioritization is Mandatory: All characteristics have costs; failing to prioritize means failing to make real trade-offs, which defers conflict until implementation or production.
- Conflict is Normal: Characteristics frequently conflict (performance vs. security, agility vs. reliability); the architect’s job is to make the conflict explicit and document the accepted resolution.
- Katas as Practice: The Silicon Sandwiches kata demonstrates that characteristic identification is a learnable skill practiced through deliberate application to realistic scenarios.
- Implicit Characteristics Are Non-Negotiable: Unlike explicit characteristics, implicit ones cannot be traded away without stakeholder agreement — violating them is a professional failure, not a trade-off.
- Sources Are Diverse: Characteristics come from requirements documents, stakeholder conversations, existing system pain points, and domain knowledge — architects must mine all four sources.
- Fitness Functions Require Leaf Nodes: Governance (Chapter 6) operates on specific, measurable characteristics — composites must be decomposed before governance can be applied.
Related Resources
- Chapter 4: Defining Architectural Characteristics (definitions and taxonomy)
- Chapter 6: Measuring and Governing Architectural Characteristics (fitness functions)
- Appendix B: Architecture Kata Descriptions (additional kata practice)
- ISO/IEC 25010 (System and Software Quality Models) — formal taxonomy of quality characteristics
Last Updated: 2026-05-29