Requirements - Solution Design & Methods
-
SD08 - Patterns
We should select the correct patterns for the use case, and any trade-offs justified and agreed.
Requirement description
This requirement is about selecting appropriate architectural, integration, data and solution design patterns for the business problem being solved.
Architects should demonstrate that alternative approaches have been considered, that the chosen pattern is suitable for functional and non-functional requirements, and that any compromises have been consciously evaluated, documented and agreed.
In simple terms:
Use the right architectural pattern for the problem and be clear about why it was chosen over other options.
Scoring rubric table – Pattern Selection and Trade-off Management
| Score | What it looks like | Typical evidence | Key gaps / risks |
|---|---|---|---|
| 0 | No evidence that architectural patterns have been consciously selected. Design choices appear arbitrary or driven solely by technology preference. | No design rationale, no options analysis, no architectural decisions recorded. | Significant risk that the solution is unsuitable, difficult to maintain, costly to change, or unable to meet requirements. |
| 1 | Limited evidence that patterns have been considered. Selection is largely informal and relies on individual opinion or historical precedent. | Informal discussions, unsupported assumptions, undocumented solution decisions. | High-risk gaps. Alternative approaches have not been assessed and trade-offs are not understood. |
| 2 | Some patterns are identifiable and partially aligned to the use case. Limited assessment of alternatives has been completed. | High-level architecture diagrams, partial design documentation, informal option appraisal. | Significant notable gaps. Non-functional impacts, complexity implications or future constraints are not fully understood. |
| 3 | Appropriate patterns have generally been selected and there is acceptable evidence explaining why. Trade-offs are identified but may not be consistently documented or governed. | Architecture documentation, design reviews, option assessment records, Architecture Decision Records (ADRs), identified risks and dependencies. | Notable gaps remain. Some decisions lack documented rationale, stakeholder agreement, or mitigation of identified compromises. |
| 4 | Pattern selection is clearly linked to user needs, business objectives and non-functional requirements. Trade-offs are documented, reviewed and agreed with appropriate stakeholders. | Maintained ADRs, option assessments with evaluation criteria, governance review records, architecture principles mapping, documented stakeholder approval. | Minor gaps only. Remaining compromises are understood, accepted and subject to monitoring or remediation where necessary. |
| 5 | Comprehensive and exemplar approach to pattern selection. Decision-making is evidence-based, repeatable and consistently applied across the solution. Trade-offs are actively managed throughout the lifecycle. | Structured decision framework, multiple option evaluations, traceability from requirements to design decisions, regularly reviewed ADRs, governance records, lessons learned and continuous improvement activities. | Minimal or no significant gaps identified. |
What assessors should look for
- Appropriate pattern selection – Evidence that the chosen architectural, integration, data or deployment patterns are suitable for the problem being solved.
- Consideration of alternatives – Evidence that realistic options were evaluated before selecting an approach.
- Documented trade-offs – Evidence showing impacts on cost, risk, performance, scalability, security, operability, maintainability or delivery timescales.
- Alignment to requirements – Clear traceability between requirements, non-functional needs and the chosen pattern.
- Stakeholder agreement – Evidence that relevant stakeholders understand and accept the chosen approach and associated compromises.
- Governance – Evidence that significant architectural decisions have been reviewed through appropriate architecture governance processes.
What separates a 3 from a 4 or 5
A score of 3 typically shows that reasonable patterns have been chosen and there is acceptable supporting evidence, but decision-making is not consistently documented, reviewed or governed.
A score of 4 requires clear evidence that architectural choices were evaluated against requirements, that trade-offs were documented, and that stakeholders formally agreed the resulting decisions.
A score of 5 requires a mature and repeatable approach where architectural decisions are traceable, actively reviewed, consistently governed and demonstrably influence delivery outcomes.
Updated: 04 September 2026 (SAF Version 1.1)