Core Idea
Explicit architecture characteristics are non-functional requirements directly stated in requirements documents, stakeholder interviews, or business specifications. These are the “-ilities” that stakeholders articulate, such as “the system must handle 10,000 concurrent users” (scalability) or “downtime costs $X per minute” (availability).
Understanding Explicit Characteristics
Explicit architecture characteristics emerge directly from requirements gathering processes:
- When stakeholders say “the system must respond within 2 seconds,” they’re explicitly stating a performance characteristic
- When business owners specify “we need 99.9% uptime,” they’re declaring an availability requirement
- These characteristics are visible, documented, and traceable to specific business needs
The identification process for explicit characteristics:
- Involves systematic review of requirements documents, user stories, business cases, and stakeholder interviews
- Architects translate business language into architectural characteristics
- Example: “users must be able to access the system from mobile devices” translates to portability and accessibility characteristics
- Example: “the system must comply with GDPR” translates to security, privacy, and auditability characteristics
Explicit characteristics provide clear, measurable targets:
- “Must support 100,000 transactions per day” gives architects concrete scalability and performance thresholds
- “Must deploy new features weekly” establishes deployability requirements
- These specific targets enable architects to make informed trade-offs during architecture selection and design
Why This Matters
Explicit characteristics create accountability between business stakeholders and technical teams:
- When requirements documents specify performance targets, both sides understand success criteria
- This prevents the common failure mode where systems are built without clear non-functional requirements
- Avoids architectures that meet functional needs but fail to satisfy operational or business constraints
However, explicit characteristics alone are insufficient for architecture design:
- Many critical characteristics remain unstated
- Stakeholders rarely explicitly specify “we need maintainability” or “the codebase should be testable”
- These implicit characteristics require architects to extract them from domain knowledge and business context
- Complementing the explicit requirements with architectural expertise
Related Concepts
- Architecture-Characteristics-Categories — The taxonomy of operational, structural, and cross-cutting characteristics
- Implicit-Architecture-Characteristics — Characteristics derived from domain knowledge rather than explicit requirements
- Architecture-Characteristics-Extraction-Process — The systematic process for identifying both explicit and implicit characteristics
- Trade-Offs-and-Least-Worst-Architecture — How identified characteristics drive architecture decisions
- Measuring-Architecture-Characteristics — Converting explicit requirements into measurable fitness functions
Sources
- Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Chapter 5: Identifying Architecture Characteristics
- Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
Note
This note was researched and drafted with AI. How these notes are written →