👷🚧🏗️👷‍♂️👷‍♀️ This page is under construction. 👷🚧🏗️👷‍♂️👷‍♀️

Framework Requirements

Strategic Alignment, Vision, and Roadmap

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

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

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

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

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

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

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.