Solution Architecture Framework - Start Here

Where to begin when producing the artefacts needed to satisfy the Solution Architecture Framework. Establish the fundamentals before focusing on assessment scores.

Getting value from the Solution Architecture Framework (SAF)

The Solution Architecture Framework (SAF) is intended to help teams and Solution Architects design better solutions, make better decisions, reduce risk, and improve architectural consistency across NHS England services.

If you are new to the SAF, focus on establishing the fundamentals before worrying about assessment scores or complete compliance. The strongest SAF assessments are usually achieved by teams that have a clear understanding of user needs, make deliberate architecture decisions, understand their non-functional requirements, and maintain a small set of high-quality architecture artefacts.

The SAF should be viewed as a practical framework for good architecture rather than a compliance exercise.

High impact activities

A small number of activities provide evidence across most SAF dimensions. Before investing time in detailed diagrams, extensive documentation, or governance processes, ensure you have the following foundations in place.

Activity / artefact Why it matters Primary SAF dimensions
Solution Design Overview (SDO) Creates a shared understanding of the service and its architecture Strategic Alignment, Documentation
Product Vision & Roadmap Demonstrates direction, outcomes and alignment to strategy Strategic Alignment
Architecture Decision Records (ADRs) Shows structured decision making and governance Governance, Technology Choices
Information Model & API Design Defines interoperability and service boundaries Solution Design, Documentation
Non-Functional Requirements (NFRs) Drives architecture decisions and operational readiness Non-Functional Profile
Risks, Assumptions and Technical Debt Demonstrates active management of architecture risk Governance
Reuse Assessment Ensures existing NHS capabilities are considered first Reuse Principles

Collectively these artefacts influence almost every SAF dimension.

Recommended starting sequence

1. Understand the problem first

Before discussing technology, ensure you can clearly articulate:

  • User needs
  • Business objectives
  • Desired outcomes
  • Strategic drivers
  • Success measures
  • Scope and boundaries

Many architecture issues originate from misunderstandings of the problem rather than weaknesses in the solution.

A concise problem statement and scope definition often provides more value than several pages of architecture diagrams.

2. Create a Solution Design Overview (SDO)

The SDO should be the primary architecture document for the service.

A good SDO provides:

  • Service purpose
  • User needs and objectives
  • Scope and exclusions
  • Context diagram
  • High-level architecture
  • Key dependencies
  • Risks and assumptions
  • Links to supporting artefacts

Think of the SDO as the front door to the architecture.

A stakeholder who is unfamiliar with the service should be able to understand the solution within ten minutes of reading it.

An SDO template is available on the Technical Review Group (TRG) submission page (NHSE SharePoint) to help you get started.

3. Define the information model and APIs early

For many NHS digital services, information and interoperability are more important than individual technical components.

Focus on:

  • Core business concepts
  • Information ownership
  • Consumer interactions
  • System boundaries
  • API responsibilities
  • Data flows

The goal is to establish a shared understanding of what information exists, where it comes from, who owns it, and how it moves between services.

For API-led products, contract-first thinking should be encouraged wherever practical.

4. Establish non-functional requirements early

Many architecture decisions are ultimately driven by non-functional requirements rather than functional requirements.

Ensure the team understands:

  • Availability targets
  • Performance expectations
  • Scalability requirements
  • Security requirements
  • Audit requirements
  • Recovery objectives
  • Operational support expectations

For every major design decision, ask which non-functional requirement is driving the choice. If the answer is unclear, revisit the requirement before progressing with the design.

5. Capture decisions as they happen

Important decisions should be recorded at the point they are made.

Architecture Decision Records (ADRs) do not need to be lengthy.

A simple ADR should capture:

  • The problem being solved
  • The options considered
  • Decision drivers
  • Trade-offs
  • Final decision
  • Consequences

A ready-made Any Decision Record template is available as part of the NHS England Software Engineering Quality Framework.

Good ADRs create transparency, reduce future rework, and significantly strengthen governance evidence.

6. Understand what can be reused

A common architecture anti-pattern is designing new capabilities before understanding what already exists.

For every major capability, ask whether it could be provided by an existing NHS England service or platform. Examples may include:

  • NHS API Management Platform
  • NHS Login
  • CIS2
  • PDS
  • MNS
  • NHS Notify
  • ServiceNow
  • Enterprise monitoring and logging services

Reuse should be a deliberate consideration rather than an afterthought.

Common mistakes

Starting with technology

Technology choices are rarely the hardest architecture problem.

User needs, operating models, governance, integration patterns and non-functional requirements are usually more significant drivers.

Creating architecture diagrams too early

Diagrams are valuable, but they should communicate architectural thinking rather than replace it.

Understand the problem first.

Ignoring non-functional requirements

Many service failures can be traced back to poorly understood performance, resilience, security or operational requirements.

Document them early.

Failing to capture decisions

A decision without recorded rationale quickly becomes architecture debt.

Future teams need to understand why decisions were made, what alternatives were considered, and what assumptions existed at the time.

Producing documentation nobody uses

Prefer:

  • Short documents
  • Clear ownership
  • Living artefacts
  • Consistent structure
  • Strong cross-linking

The objective is to help delivery teams make good decisions, not to create documentation for its own sake.

A strong foundation checklist

Before focusing on SAF assessment scores, ensure you can answer "yes" to the following:

Strategy & alignment

  • ☐ Clear problem statement exists
  • ☐ User needs are understood
  • ☐ Product vision is documented
  • ☐ Roadmap exists and is maintained

Solution design

  • ☐ SDO has been completed
  • ☐ Scope and boundaries are understood
  • ☐ Information model exists
  • ☐ API design approach is defined

Governance

  • ☐ Key architecture decisions are documented
  • ☐ Risks and issues are understood
  • ☐ Technical debt is visible and managed

Non-functional architecture

  • ☐ Service levels are defined
  • ☐ Performance expectations are understood
  • ☐ Resilience and recovery requirements exist
  • ☐ Security and audit requirements are captured

Reuse & documentation

  • ☐ Existing NHS capabilities have been assessed
  • ☐ Core architecture artefacts are published
  • ☐ Documentation is maintained and accessible

Account for the service lifecycle

Lifecycle stage affects the fidelity of evidence, not the effort or quality expected.

A private-beta pilot should be production grade and documented. Earlier artefacts will simply carry more assumptions and lower-fidelity detail, becoming more complete and better evidenced as the service matures.

Updated: 19 September 2025 (SAF Version 1.1)