Requirements - Reuse Principles and Development of Shared Services
-
RU02 - Identification
For new capabilities we should identify/recognise the potential reuse opportunities which may drive design decisions, benefits etc.
Requirement description
This requirement is concerned with ensuring that new capabilities are designed with future reuse in mind.
When developing a new capability, teams should consider whether the functionality, services, APIs, components, data products or patterns being created could be reused elsewhere across NHS England or the wider NHS ecosystem.
Reuse opportunities should be identified early enough to influence architecture decisions. This may affect solution boundaries, API design, data models, deployment patterns, funding decisions and ownership models.
The objective is to maximise the value of investments by creating capabilities that can be reused where appropriate, rather than repeatedly building similar functionality.
In simple terms:
When creating something new, teams should think about whether other services could benefit from using it in the future.
Scoring rubric table – RU02 Identification of Reuse Opportunities
| Score | What it looks like | Typical evidence | Key gaps / risks |
|---|---|---|---|
| 0 | No evidence that future reuse opportunities have been considered during design or delivery. |
No reuse assessment. No architecture rationale regarding reuse. No consideration of wider organisational needs. |
Significant service risk. Duplicate capabilities may be created, increasing cost, complexity and inconsistency across the estate. |
| 1 | Limited awareness of reuse opportunities. Reuse is discussed informally but does not influence architecture decisions. |
Informal discussions. Unstructured meeting notes. Undocumented assumptions about future reuse. |
High-risk gaps. Potential reuse opportunities may be missed and design decisions may lock in service-specific approaches. |
| 2 | Some consideration has been given to potential reuse opportunities, but assessments are incomplete or inconsistently applied. |
Partial reuse analysis. Early architecture discussions. Some documentation identifying possible consumers or future use cases. |
Significant notable gaps. Reuse potential is not fully understood and may not influence key design decisions. |
| 3 | Much of the capability's reuse potential has been assessed. Architecture decisions demonstrate consideration of future consumers and wider organisational benefit. |
Documented reuse assessment. Architecture Decision Records. Solution design documents identifying reusable components. Stakeholder engagement regarding reuse opportunities. |
Notable gaps remain. Future adoption, ownership, funding or governance of reusable capabilities may not yet be fully defined. |
| 4 | Most significant reuse opportunities have been identified and have influenced architecture design decisions where appropriate. |
Comprehensive reuse assessment. Documented reusable services, APIs or components. Evidence of architecture decisions made to support reuse. Stakeholder agreement on reuse potential. Governance consideration of cross-service value. |
Minor gaps only. Remaining uncertainties are low risk and unlikely to affect future reuse significantly. |
| 5 | Comprehensive and exemplar identification of reuse opportunities. Reuse considerations are embedded in architecture design and actively influence strategic decisions. |
Formal reuse strategy. Cross-organisational engagement. Documented reusable capability models. Evidence that services are designed for potential future adoption. Governance support for shared capability development. Clear demonstration of organisational value from reuse-focused design. |
Minimal or no significant gaps. Reuse opportunities are proactively identified and translated into architecture and investment decisions. |
What assessors should look for
- Reuse identification – Has the team actively assessed whether new capabilities could be reused elsewhere?
- Design influence – Have reuse opportunities influenced solution structure, APIs, services, data models or architecture decisions?
- Organisational perspective – Has the team considered needs beyond the immediate project or programme?
- Evidence of analysis – Is there documented reasoning explaining why capabilities are or are not suitable for reuse?
- Stakeholder engagement – Have architects, service owners or potential consumers been involved where appropriate?
- Future sustainability – Is there evidence that reuse opportunities could realistically be adopted and maintained?
What separates a 3 from a 4 or 5
A score of 3 generally means reuse opportunities have been recognised and documented, but there is limited evidence that they have materially influenced architecture decisions or wider organisational planning.
A score of 4 requires clear evidence that identified reuse opportunities have driven design choices and that stakeholders understand the potential value of the capability beyond the immediate service.
A score of 5 requires reuse thinking to be embedded within the architecture process. The organisation actively designs capabilities with future consumers in mind and can demonstrate how reuse considerations shape governance, investment and architecture decisions.
Suggested evidence examples (not SAF-mandated artefacts)
- Reuse assessments or reuse opportunity analyses
- Architecture Decision Records (ADRs)
- Solution Design Overview documents
- Capability models highlighting reusable services
- API design documentation
- Cross-programme architecture reviews
- Business case documentation discussing reuse benefits
- Governance papers evaluating shared capability opportunities
- Architecture roadmaps showing future consumers
- Stakeholder workshops discussing reuse potential
Updated: 04 September 2026 (SAF Version 1.1)