Requirements - Solution Design & Methods - SD04 - Good Practice

Solution design should follow good practice design principles.

Requirement

SD04 : Solution design should follow good practice design principles. E.g.

  • Separation of concerns
  • Encapsulation / Modularisation
  • Loose coupling
  • High cohesion / single responsibility
  • Design for flexibility/change
  • Etc.

Requirement description

This requirement is concerned with ensuring that solutions are built using recognised software and architecture design principles that improve maintainability, scalability, resilience and adaptability.

The solution should be structured in a way that reduces unnecessary dependencies, clearly separates responsibilities and enables change to be made safely and efficiently. The SAF provides examples including separation of concerns, modularisation, loose coupling, high cohesion and designing for future change.

The objective is to avoid tightly coupled, fragile architectures that are difficult to maintain, extend or support.

In simple terms:
The solution should be designed using recognised engineering and architecture principles that make it easier to understand, operate and evolve over time.

Scoring rubric table – SD04 Application of Good Design Principles

Score What it looks like Typical evidence Key gaps / risks
0 No evidence that recognised design principles have been considered. The solution appears tightly coupled, difficult to understand or highly dependent on specific components. No architecture rationale.
No design documentation.
No evidence of design review activity. 		Significant service risk. The solution may be difficult to maintain, scale, test or modify safely.
1 Limited evidence of good design practices. Some principles may be discussed, but they are not consistently reflected in the architecture. Informal design discussions.
Basic architecture diagrams.
Undocumented design assumptions. 		High-risk gaps. Architecture decisions may create unnecessary dependencies, complexity or technical debt.
2 Some recognised design principles are evident, but their application is incomplete or inconsistent across the solution. Partial architecture documentation.
Some modularisation.
Limited design reviews.
Evidence of good practice in selected areas only. 		Significant notable gaps. Poor separation of responsibilities or excessive coupling may remain in parts of the solution.
3 Much of the solution demonstrates recognised design principles and architectural reasoning. Most major components are structured appropriately. Architecture diagrams.
Solution Design Overview documentation.
Architecture review outputs.
Documented design rationale.
Evidence of modularisation and separation of concerns. 		Notable gaps remain. Some components may still be tightly coupled or difficult to change without wider impact.
4 Most of the solution demonstrates consistent application of good design principles. Architecture decisions support maintainability, scalability and future change. Comprehensive architecture documentation.
Clear component boundaries.
Documented design principles.
Architecture review evidence.
Evidence of loose coupling and high cohesion.
Design patterns applied appropriately. 		Minor gaps only. Remaining weaknesses present limited operational or architectural risk.
5 Comprehensive and exemplar application of good design principles. The architecture is clearly structured, maintainable and adaptable, with strong evidence that principles actively influence design decisions. Well-defined architecture principles.
Consistent modular design.
Documented architecture rationale.
Governance review evidence.
Low dependency between services and components.
Evidence that architecture evolves cleanly in response to changing requirements. 		Minimal or no significant gaps. The architecture demonstrates high quality engineering and long-term sustainability.

What assessors should look for

  1. Separation of concerns – Are responsibilities clearly separated between services, components and layers?
  2. Modularity – Does the solution have well-defined components that can evolve independently?
  3. Loose coupling – Are dependencies minimised and managed appropriately?
  4. High cohesion – Does each component have a clear and focused responsibility?
  5. Design for change – Can the architecture accommodate future requirements without major redesign?
  6. Architecture rationale – Is there evidence that design principles have consciously influenced architecture decisions?

What separates a 3 from a 4 or 5

A score of 3 generally indicates that recognised design principles are visible across much of the solution, but there are still notable areas of complexity, coupling or maintainability concern that require mitigation.

A score of 4 requires evidence that good design principles are consistently applied across the architecture and that most major components are structured in a maintainable and scalable manner.

A score of 5 requires design principles to be deeply embedded within architecture practices. The solution demonstrates a high degree of modularity, adaptability and maintainability, with architecture decisions consistently driven by recognised engineering principles.

Suggested evidence examples (not SAF-mandated artefacts)

  • Conceptual, logical and physical architecture diagrams
  • Solution Design Overview (SDO) documents
  • Architecture Decision Records (ADRs)
  • Domain models and bounded context diagrams
  • Application and service decomposition diagrams
  • Architecture governance reviews
  • Design principles documentation
  • API and integration specifications
  • Code or solution structure reviews
  • Technical debt and remediation assessments

Updated: 04 September 2026 (SAF Version 1.1)