Chapter 4 — Architecture Characteristics Defined

Why it matters

Names the actual subject matter of architecture. This is the chapter people cite most.

Core ideas — a characteristic must meet three criteria

1. It specifies a non-domain design consideration (it’s not a feature/requirement).
2. It influences some structural aspect of the design.
3. It is critical or important to application success.

Categories

• Operational characteristics: availability, performance, scalability, elasticity, reliability, recoverability, etc.
• Structural characteristics: modularity, extensibility, configurability, maintainability, etc.
• Cross-cutting characteristics: security, accessibility, usability, privacy, etc.
• Distinction between implicit (assumed, e.g. security, availability) and explicit (stated in requirements) characteristics.
• Watch the “-ility” trap: don’t over-specify. Every characteristic you add makes the design more complex and can conflict with others. Prefer the fewest characteristics that make the system succeed.
• Beware synonyms and overloaded terms (e.g., “interoperability” vs. “compatibility”; “performance” hides latency/throughput/etc.). ISO categories (functional suitability, performance efficiency, compatibility, usability/interaction, reliability, security, maintainability, portability, plus flexibility) are referenced in the 2nd edition.

Trade-offs to argue

Characteristics conflict — e.g., high security often hurts performance; high scalability may complicate consistency. “Never shoot for the best architecture, but rather the least worst architecture.” More characteristics ≠ better system.

Terms to own

operational/structural/cross-cutting, implicit vs. explicit, “-ility,” least-worst architecture.