NHS England: Solution Architecture Framework (SAF)

Version	v0.0.1
Version Date	2025-06-12
Name
Date
Project

Strategic Alignment, Vision, and Roadmap

Item	Title	Notes	Complete ✅ / ❌	Score (0-5)	Description
S01	Exec Design Authority				The solution SHOULD be aligned to stated strategy approved by the Exec Design Authority
S02	Business Capability Model				We MUST be able to demonstrate which capabilities from the NHSE Business Capability Model the solution is realising, and any potential duplication identified
S03	Roadmap				A well-formed and maintained product vision & roadmap MUST exist with appropriate detail around architecture elements
S04	Objectives				The solution design MUST be able to meet the stated user needs and overall business objectives/drivers

Decision Making & Governance

Item	Title	Notes	Complete ✅ / ❌	Score (0-5)	Description
DM01	Architectural Debt				Where a solution or part of solution is seen as tactical, short term or introduces / persist tech & architecture debt, remediations plans SHOULD be in place and agreed with the relevant stakeholders and governance groups. Architecture Debt MUST be identified with implications, rationale and future mitigations plans (recorded in the Architecture Debt Register) Plans MUST be realistic and funded.
DM02	Spend Control				Relevant spend control and associated CDDO & Service Design related guidance MUST be followed whilst developing the solution and MUST be evidenced for service design & spend control reviews
DM03	Risk Management				Architecture risks and issues MUST be managed effectively with the appropriate level of visibility and ownership
DM04	Stakeholder Involvement				There MUST be effective and commensurate stakeholder involvement with respects to solution design and architecture decisions.
DM05	Design Authorities				The solution design and architecture decisions MUST be managed effectively through local programme related design authorities and TRG processes at the appropriate stages of the lifecycle.
DM06	Architectural Governance				The overall approach to architecture governance MUST be appropriate and commensurate with the nature of the solution, engaging the appropriate Lead Architects and other SMEs.
DM07	Architectural Governance				All Architecture decisions MUST be documented with a lightweight Architecture Decision Record with options and clear rationale.
DM08	Structured Decision Making				All decision-making MUST be structured i.e. identify key strategic drivers, user need assess options against drivers, present rationale, clarity on trade-offs, dependencies, risks and issues understood etc.
DM09	Wider Decision Making				There SHOULD be an appropriate and functioning architecture decision making forum within the delivery team including other SMEs e.g. product, engineering etc.

Solution Design & Methods

Item	Title	Notes	Complete ✅ / ❌	Score (0-5)	Description
SD01	Design Methodology				An appropriate design methodology SHOULD be followed e.g. Domain Driven Design and should include NHS/CDDO Service Design and Secure By Design principles & methods
SD02	Compliance				The solution SHOULD be compliant with NHS England principles, policy, patterns and best practice
SD03	Standards				The solution SHOULD be compliant with relevant standards
SD04	Design Principles				Solution design SHOULD follow good practice design principles as outlined in SD04.
SD05	Reuse				Solutions SHOULD focus on commodity products, services and standards where possible/sensible, avoiding proprietary design decisions.
SD06	API First				An API First design methodology SHOULD be followed, where APIs are at the fore front of the design process, functionality and data is exposed via APIs and the, needs of the API consumer have been considered.
SD07	Equality				We SHOULD treat internal (NHS England) and external consumers equally.
SD08	Patterns				We MUST select the correct (for the use case) patterns, and any trade-offs justified and agreed.
SD09	API Standards				We MUST adopt the right standards for API development, supported by user, consumer, and market / supplier engagement.
SD10	API Lifecycle				An appropriate API lifecycle policy including versioning and deprecation strategy MUST be agreed.
SD11	External Policies				Solutions MUST adhere to policies outlined in SD11. (Aalto needs updating with full list)
SD12	Well Architected Frameworks				The relevant cloud “Well Architected Frameworks” SHOULD be followed, and the solutions assessed against

Technology Choices

Item	Title	Notes	Complete ✅ / ❌	Score (0-5)	Description
T01	Technology Radar				Technology choices MUST be made in line with the NHS England Technology Radar and supporting decision making processes.
T02	Non Functional Needs				Technology choices MUST be appropriate to the problem and non-functional needs i.e. we are as equally aware of over engineering as we are to under engineering.
T03	Vendor Locks				An appraisal MUST be made of any vendor lock considerations and associated risks, and these are understood and accepted/mitigated.
T04	SaaS First				We SHOULD be adopting cloud managed services over IaaS and any exceptions require close governance.

Non-Functional Design

Item	Title	Notes	Complete ✅ / ❌	Score (0-5)	Description
NF01	Observability				Solutions MUST incorporate workload observability, understand service health, and respond to events
NF02	Appropriate				Technology choices MUST be appropriate to the problem and non-functional needs i.e. we are as equally aware of over engineering as we are to under engineering.
NF03	Performance				An overall volume and performance model MUST exist and includes business-realistic exceptional scenarios.
NF04	Sustainability				Methods to measure sustainability to establish baseline and show improvement SHOULD be defined.
NF05	Auditing				Audit & logging requirements MUST be defined and solutions can support them, as defined in NF05.
NF06	Disaster Recovery				There MUST be clear requirements (commensurate with service levels) around DR & BC (and a pragmatic approach taken with regards DR/BC events planned for)
NF07	Accessibility & UX				The architecture MUST support the ability to maximise the UX and supports accessibility needs and legislation.

Re Use Principles and Development of Shared Services

Item	Title	Notes	Complete ✅ / ❌	Score (0-5)	Description
RU1	Square Peg Round Hole				If reusing existing capabilities, we MUST be confident 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
RU2	Reuse Potential				For new capabilities we MUST identify/recognise the potential re use opportunities which may drive design decisions, benefits etc.
RU3	Reuse Services				We SHOULD reuse capabilities as defined in RU03.

Documentation

Item	Title	Notes	Complete ✅ / ❌	Score (0-5)	Description
D01	Documentation Stores				All architecture documentation MUST be maintained within the appropriate NHS England knowledge store e.g. Aalto, SharePoint, Confluence
D02	Open by Default				Documentation SHOULD be published “open by default” and exceptions handled according to policy i.e. sensitivity etc
D03	Documentation Freshness				Controls and processes MUST be in place to ensure architecture documentation is kept current
D04	Change Control				There MUST be an appropriate change control mechanism for architecture documentation
D05	Archimate Models				Relevant Archimate models, layer diagrams and supporting solution metadata MUST be created and approved by the EA team
D06	Documentation Coverage				The architecture documentation SHOULD be appropriate in scope and quality for the solution covering (but not exclusively) as defined in D06.