Chapter 5 — Identifying Architectural Characteristics

Why it matters

Moves from knowing the vocabulary to deriving the right characteristics for a real system.

Core ideas

• Characteristics come from three sources: domain concerns (translate stakeholder priorities), requirements (explicit statements), and implicit domain knowledge (things nobody writes down but that matter).
• Translating fuzzy business/domain language into architecture characteristics: e.g., “mergers & acquisitions” → interoperability, scalability, adaptability, extensibility; “time to market” → agility (= maintainability + testability + deployability).
• Composite characteristics: some business goals map to combinations (agility is really testability + deployability + maintainability).
• Discipline: limit the “final” list. A useful workshop technique is to have stakeholders pick the top 3 characteristics — forcing prioritization surfaces disagreement.

Trade-offs to argue

Over-collecting characteristics from every stakeholder produces an unbuildable system. The skill is prioritization and translation, not accumulation.

Terms to own

domain concerns, composite/derived characteristics, agility = maintainability + testability + deployability, “top 3.”