Architecture and Solution Design
This domain tests whether you can select and justify a solution structure against quality attributes, constraints and trade-offs. The exam rewards explicit reasoning over technology name-dropping.
Views and decisions
- Use multiple views: logical, process, development and deployment. Each answers a different stakeholder question, such as what the system does versus where it runs.
- Record significant decisions as architecture decision records: context, decision, alternatives considered, consequences and status. Record decisions when they are costly to reverse or constrain other teams.
- Reference architectures are starting points, not mandates; adapt them to constraints.
Quality attributes drive tactics
- Availability: redundancy, failover, health checks and graceful degradation.
- Performance: caching, asynchronous processing and partitioning.
- Security: least privilege, encryption in transit and at rest, and explicit trust boundaries.
- Modifiability: stable contracts, clear boundaries and fitness functions that test architectural rules.
Worked example
A requirement states 99.95% monthly availability. A 30-day month has 43,200 minutes, so allowed downtime is 0.0005 x 43,200 = 21.6 minutes. A single component rated at 99.9% cannot meet this, because it alone allows about 43 minutes. The reasoning: the design needs redundancy or rapid failover, and the target must be allocated across components rather than assumed at the whole-system level.
Traps
- Choosing technology before constraints and quality scenarios are known.
- Designing without operational concerns such as backup, monitoring and run cost.
- Ignoring the trade-off rationale, leaving future teams unable to challenge or maintain the design.
- Accepting nonfunctional targets that no component budget can satisfy.