Solution Architecture Framework - Usage

How will the NHS England SAF be used?

Day to Day Usage

As part of the BAU activities of Solution Architects working within delivery teams we will expect them to use the SAF to help structure their activities, their approach to solutions design, documentation and decision making. The SAF will act as an "aide memoir" for Solution Architects to drive a consistent approach, regardless of whether they are permanent, contract or supplier colleague.

The SAF isn't a set of hard and fast rules but is intended to guide architects and product teams make the right decisions, drive up quality and to be able to provide rationale for the trade offs we ultimately have to make.

Further information and guidance will be developed on the specifics of the framework e.g. best practice document templates, non-functional requirement sets, good practice governance. We will expect and positively encourage Solution Architects to actively contribute back into the framework and wider community of practice by developing supporting collateral.

Architecture Fitness Assessment

Alongside day to day use we will require architects to perform periodic reviews of existing products plus those in development

1. Solution Architects will be required to undertake a review of maturity/compliance against the requirements for each of the key products within their portfolios.
2. Any review should not be done in isolation and should be done with the product owner and wider product team.
3. The review must be positioned as a helpful tool to highlight risks, issues and areas for improvement.
4. The outcome of the assessments will be an architecture remediation plan. Depending on the risks, the remediation plan may be managed by the product team themselves as part of BAU or, for high-risk assessments, will be tracked by the appropriate governance group. This needs to be agreed collectively by the product team.
5. Architecture assessment should be presented alongside wider dimensions including the software quality framework and the engineering redlines (SharePoint).
6. We should not rank or compare products based on their SAF assessment i.e. a 55 in one product for a SAF dimension does not translate to higher quality, less risk etc than a product which scores 61. Judgement should be applied based on the product and the associated risk (and lifecycle stage).

Overall Guidance

The assessment mechanism described below is intended to be risk based and several factors should be considered whilst undertaking a review:

1. Consider the service level and business criticality. i.e. Simple noncritical applications which may be poorly designed or have poor architecture processes may present a low impact of failure to users and therefore remediation actions should be considered appropriately.
2. Measuring adherence to the requirement is not binary and will have an unavoidable level of subjectivity. A product may achieve one requirement well in some places and not in others. Exercise cautious pragmatism and team judgement when undertaking a review.
3. When doing reviews consider the solution, but also as a set of individual components. For example, the overall solution may be considered well architected however a single critical component maybe very weak and therefore present significant risk to the overall solution.
4. Ensure the right people are involved in the review.
5. Don't see the assessment as a one off exercise or a gate review – it should be a continuous process, particularly for new and emerging products.
6. Use the continuous review process to inform product backlogs and team ways of working, building into standard ceremonies (e.g. sprint planning and retros).

Requirements & Outcomes

For each requirement statement the architect needs to assess how well the architecture and supporting processes meet the objective of the requirement and the overall dimension of the SAF.

There may be different ways a requirement can be met. We should focus on the outcome and satisfy ourselves that the evidence provided can meet it.

The assessment can be made via interviews, document reviews, cloud provider Well Architected Framework reviews, delivery team meetings and ceremonies etc. It is not a "one size fits all" and will vary depending on the team make up etc. At all times we will be risk based.

An assessment spreadsheet (NHSE SharePoint) has been created which allows for a score based on the criteria below. Each requirement is some form of weighting to ensure more significant or complex requirements are accounted for. (Note: The weighting will be subject to change and review.)

Score	Compliance Criteria
0	No evidence that the requirement is supported and as such presents significant service risk.
1	Limited evidence that the requirement is supported with high risks gaps.
2	Some elements of the requirement are met with an acceptable level of evidence, but significant number of notable gaps.
3	Much of the requirement is met with an acceptable level of evidence, but there are notable gaps which present risk which require mitigating action.
4	Most of the requirement is met with good levels of evidence, there are some gaps but are not thought to present significant risk.
5	Comprehensive evidence that the requirements is met and exceeds expectations in several areas. We would consider this an exemplar.

This is not an exact science and in many cases it will be challenging to judge particularly where underpinning material such as strategies, principles, polices etc are not in place. Within the requirements spreadsheet there will be some guidance to help give a sense.

For example:

• 5 = A strategy paper has been produced, openly published, well socialised, approved at executive level and is widely accepted and baked into governance.
• 3 = Some form of strategy has been written down and generally seems well accepted at a directorate level, but may not be openly published. Teams outside of a directorate might not consistently recognise it as a formal strategy.
• 1 = Nothing recognisable as a strategy, written down or otherwise.

Based on the assessment the architect and product team should agree a remediation plan for those areas considered more significant e.g. where one of the dimensions has an "AMBER" or "RED" score OR where there is one specific area the team are concerned about. Whilst the RAG rating is more important than the specific scores, care should be taken that significant issues and risks are not lost as scores get weighted and averaged out.

Remediation planning should be tracked via an appropriate mechanism depending on the risks and issues identified. For instance live services which have significant amber and red ratings might be tracked at an executive level such as the Design Authority, less significant via TRG or within the delivery team as part of BAU processes.

We need to be able to reflect the health of our solution architectures in a simple and digestible form. The example below demonstrates a simple dashboard view for each product. This view will be enhanced as we undertake the initial review exercises and gather stakeholder feedback.

We will be making use of the EA tooling capability to capture this data and make available via automated dashboards etc.

Updated: 21 May 2025 (SAF Version 1.0)