Solution Architecture Framework
-
Requirements
The SAF is broken down into seven dimensions, the following requirements make up each dimension.
Strategic Alignment, Vision, and roadmap
| Requirement | |
|---|---|
| S01 | The solution should be aligned to stated strategy approved at an executive level. e.g. TD Design Authority, P&P DA etc. |
| S02 | We should be able to demonstrate which capabilities from the NHSE Business Capability Model the solution is realising, and any potential duplication identified. |
| S03 | A well-formed and maintained product vision and roadmap should exist with appropriate detail around architecture elements. |
| S04 | The solution design should be able to meet the stated user needs and overall business objectives/drivers. |
Decision Making & Governance
| Requirement | |
|---|---|
| DM01 |
Where a solution or part of solution is seen as tactical, short term or introduces / persists tech & architecture debt, remediation plans should be in place and agreed with the relevant stakeholders and governance groups. Architecture Debt should be identified with implications, rationale and future mitigation plans (recorded in an Architecture Debt Register) Plans should be realistic and funded. |
| DM02 | Spend control (GaTS) and associated Government Digital Services & Service Design related guidance should be followed whilst developing the solution and be evidenced for service design & spend control reviews. |
| DM03 | Architecture risks and issues should be managed effectively with the appropriate level of visibility and ownership. |
| DM04 | There should be effective and commensurate stakeholder involvement with respect to solution design and architecture decisions. |
| DM05 |
The solution design and architecture decisions should be managed through local programme design authorities and TRG at the appropriate stages of the lifecycle. The relevant Lead Architects and Subject Matter Experts (SMEs) are engaged and are supportive. |
| DM06 | The overall approach to architecture governance should be appropriate and commensurate with the nature of the solution. |
| DM07 |
All Architecture decisions should be documented with a lightweight Architecture Decision Record with options and clear rationale. |
| DM08 | All decision-making should be structured. E.g. identify key strategic drivers, user need assess options against drivers, present rationale, clarity on trade-offs, dependencies, risks and issues understood. |
Solution Design & Methods
| Requirement | |
|---|---|
| SD01 | An appropriate design methodology should be followed e.g. Domain Driven Design and should include NHS/CDDO Service Design and Secure by Design principles and methods. |
| SD02 | The solution should be compliant with NHS England principles, policy, patterns and best practice. |
| SD03 | The solution should be compliant with relevant standards. |
| SD04 |
Solution design should follow good practice design principles. E.g.
|
| SD05 | Solutions should focus on commodity products and services where possible/sensible. |
| SD06 | An API First design methodology should be followed, where APIs are at the forefront of the design process, functionality and data is exposed via APIs and the needs of the API consumer have been considered. |
| SD07 | We should treat internal (NHS England) and external consumers equally. |
| SD08 | We should select the correct patterns for the use case, and any trade-offs justified and agreed. |
| SD09 | We should adopt the right standards for API development, supported by user, consumer, and market / supplier engagement. |
| SD10 | The API follows the lifecycle policy best practice as set out within Sunsetting (deprecation and retirement) policy (Confluence). This should include any enforcement arrangements. |
| SD11 |
Solutions should adhere to:
(Note there are overlaps with the Engineering red lines; ensure a consistent response and do not repeat assessments) |
| SD12 |
The relevant cloud "Well Architected Framework" should be followed, and the solutions assessed against it. (Note there are overlaps with the Engineering Software Quality Framework; ensure a consistent response and do not repeat assessments) |
Technology Choices
| Requirement | |
|---|---|
| T01 |
Technology choices should be made in line with the NHS England Technology Radar, corporate direction and wider industry trends using the associated processes to support decision making. (Note there are overlaps with the Engineering red lines; ensure a consistent response and do not repeat assessments) |
| T02 | Technology choices should be appropriate to the problem and non-functional needs. I.e. we are as equally aware of over-engineering as we are of under-engineering. |
| T03 | An appraisal should be made of any vendor lock considerations and associated risks, and these are understood and accepted/mitigated. |
Non-Functional Profile
| Requirement | |
|---|---|
| NF01 | Solutions should incorporate workload observability and understand service health. |
| NF02 | Reliability & Resilience needs should be defined (in terms of standard NHS England service levels) and solution mechanisms to meet these needs are defined including metrics such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO). |
| NF03 | An overall volume and performance model should exist and includes business-realistic exceptional scenarios. |
| NF04 | Methods to measure sustainability to establish baseline and show improvement should be defined. |
| NF05 |
Audit & logging requirements should be defined, and the solution can support them. NCSC Logging and Protective Monitoring NCSC Principle 13: Audit information and alerting for customers |
| NF06 |
Disaster Recovery & Business Continuity There should be clear requirements (commensurate with service levels) around DR & BC (and a pragmatic approach taken with regards DR/BC events planned for). Continuity plans and supporting documentation should reflect the requirements, technical & architecture constraints etc. |
Reuse Principles and Development of Shared Services
| Requirement | |
|---|---|
| RU01 | If reusing existing capabilities, we should have confidence that any additional functionality required can be sensibly and cost effectively added to the existing service i.e. we are not bending something out of shape. |
| RU02 | For new capabilities we should identify/recognise the potential reuse opportunities which may drive design decisions, benefits etc. |
| RU03 | We should reuse capabilities as defined below. |
| Capability | Reuse |
|---|---|
| Cohorting | CaaS |
| Citizen Messaging | NHS Notify |
| Staff Messaging | GOV.Notify and NHS.net Connect |
| Application Messaging | MESH or alternative as required |
| Demographics/MPI | PDS |
| Eventing | MNS |
| API Management | NHSE API Management Platform (which uses Apigee underneath) |
| Identity | CIS2 Auth/NHS Mail SSO/NHS login |
| Logging & Monitoring | Splunk/Sentinel/Cribl/Grafana (tbc – pending ODIN) |
| Data Analytics | FDP/CDP/DPS - FDP First |
| Public facing web presence | NHS.uk |
| Patient Flags | Flags service |
| Organisational Data | ODS |
Shared Services
| Capability | Reuse |
|---|---|
| Auditing | Standard Audit tools/PARS (when live) |
| Cyber Security Monitoring | CSOC |
| Service Management & Support | ServiceNow |
Documentation
| Requirement | |
|---|---|
| D01 | All architecture documentation should be maintained (with supporting processes and change control) within the appropriate NHS England knowledge store(s) e.g. Aalto, SharePoint, Confluence. |
| D02 | Documentation should be published "open by default" and exceptions handled according to policy i.e. sensitivity etc. |
| D03 |
The architecture documentation should be appropriate in scope and quality for the solution covering (but not exclusively):
|
Help us improve this guidance
Share insights or feedback and take part in the discussion. We use GitHub as a collaboration space. All the information on it is open to the public.
If you have any questions, get in touch with the architecture manual team.
Updated: 21 May 2025 (SAF Version 1.0)