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. E.g. SEQF Any Decision Record Template (GitHub)
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. Separation of concerns Encapsulation / Modularisation Loose coupling High cohesion / single responsibility Design for flexibility/change
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: Government "Secure by Design" policy NCSC CAF Access Control Guidelines Policy - Strong Auth/MFA Storage and Processing of Data Outside of the UK - Information Governance Policy NHS England's API strategy and policy statements. E.g. API Landscape policy document (Word, Aalto.digital.nhs.uk) (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. AWS \| Azure (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.

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.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): Architecture Vision Architecture Roadmap Layer Diagrams Capability Model and Solution Mapping Non functional requirements Conceptual Architecture Logical Architecture Physical (including network, infrastructure etc.) Solution Architecture Overview (SDO) Key Architecture Decisions (KADs) Data Models Data Flows API Specifications Volume and Performance Models Architecture Decision Records Assumption, Risks, Issues and Dependencies Cyber Assessment Framework compliance

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):

Architecture Vision
Architecture Roadmap
Layer Diagrams
Capability Model and Solution Mapping
Non functional requirements
Conceptual Architecture
Logical Architecture
Physical (including network, infrastructure etc.)
Solution Architecture Overview (SDO)
Key Architecture Decisions (KADs)
Data Models
Data Flows
API Specifications
Volume and Performance Models
Architecture Decision Records
Assumption, Risks, Issues and Dependencies
Cyber Assessment Framework compliance

Updated: 21 May 2025 (SAF Version 1.0)