Skip to content
Alpha

This site is an alpha version and is still being developed in the open - your feedback will help us improve it. See the roadmap. Last updated: 14 October 2026.

Version in force: 0.3.0 (6 October 2026).

Deliver a service

What architecture your team needs at each stage of delivery: the guardrails that apply, the artefacts to produce, who to talk to and the evidence to bring to an assessment.

Prototype - testing with users

This section is an early prototype that we are testing with users. It may change a lot, and some of it may be wrong. Check with your solution design authority before relying on it, and tell us what works and what does not through the feedback link above.

This section is for delivery team leads, product managers, architects and delivery partners. It covers the architecture evidence only. The Defra Digital Service Manual is the place for how Defra delivers services, and we link to it rather than repeat it:

For Use the Defra Digital Service Manual
When services are assessed (after alpha, private beta and public beta), and how to book Service assessments and book an assessment
What assessors ask Assessment questions
Getting ready to run a live service, including the operational service design review board at the start of beta Operational service readiness
Recording and approving spend Spend control
Who decides what in a delivery group Governance model
Designing, researching and writing content Design, user research and content design
Building on Defra's common tools and approved technologies Architecture and software development

This site adds what is specific to architecture: the guardrails, the decisions to record and the architecture evidence for each phase.

flowchart LR
    accTitle: The delivery lifecycle
    accDescr: A service moves from discovery to alpha, beta and live. A live service can go through significant change, which loops back through design, and is eventually retired.
    D["Discovery"] --> A["Alpha"] --> B["Beta"] --> L["Live"]
    L -->|"significant change"| C["Significant change"]
    C --> L
    L --> R["Retire"]

Phases and events

Phase Guardrails Must Key artefacts Checklist
Discovery 24 9 Architecture decision record (ADR) log, C4 system context diagram, Service tier, Data protection impact assessment (DPIA) Checklist
Alpha 73 18 Architecture decision record (ADR) log, C4 system context diagram, C4 container diagram, Threat model Checklist
Beta 84 25 Architecture decision record (ADR) log, C4 container diagram, Threat model, Data protection impact assessment (DPIA) Checklist
Live 77 25 Architecture decision record (ADR) log, C4 container diagram, Threat model, Runbooks and support model Checklist
Significant change 12 7 Architecture decision record (ADR) log, C4 container diagram, Threat model, Data protection impact assessment (DPIA) Checklist
Retire a service 9 5 Architecture decision record (ADR) log, Exit plan, Runbooks and support model, Data protection impact assessment (DPIA) Checklist

Each phase has a printable assessment evidence checklist, built from the same guardrail data as the guardrail library, so they never disagree.

Before you start

The architecture artefacts

The same small set of artefacts carries through every phase. Start them light and keep them current. Assessors, solution design authorities and security teams all ask for them, so prepare them once.

Artefact Why
Architecture decision record (ADR) log Shows what you decided and why (GR-DEV-09)
C4 context and container diagrams Show the service, its users, dependencies and building blocks. See the C4 model.
Threat model Shows what can go wrong and what you are doing about it (GR-SEC-02)
Data protection impact assessment (DPIA) Shows personal data is handled lawfully (GR-DATA-06)
Service tier and NFRs Set how reliable, fast and recoverable the service must be
Exit plan Shows how Defra could change product or supplier (GR-TECH-03)
Runbooks and support model Show the service can be run by people who did not build it (GR-OPS-05)