Public Sector Digital Service Architecture: [Service name]
Solution architecture for a government digital service: user needs,
the end-to-end service, reuse of shared platforms, accessibility,
identity, data sharing, openness, procurement and the evidence a
service assessment asks for. It maps the design to the reference
frameworks most public bodies use: the 14-point GOV.UK Service
Standard and the 13-point UK Technology Code of Practice, the US
Federal Enterprise Architecture Framework v2 reference models and the
US Web Design System, the European Interoperability Framework and the
Interoperable Europe Act (Regulation (EU) 2024/903), WCAG 2.2 and
EN 301 549, and the European Digital Identity framework (Regulation
(EU) 2024/1183). Keep the sections for your jurisdiction and delete
the others. Replace every [bracketed] value and every row marked
Example. This is a documentation format, not legal advice.
Document control
| Field | Value |
|---|
| Document ID | [PSA-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@service-architect] |
| Approvers/reviewers | [@service-owner], [@technical-architect-lead], [@security-lead], [@data-protection-officer], [@accessibility-lead] |
| Organisation and jurisdiction | [Department or agency], [country, state or EU member state] |
| Delivery phase | [Discovery / Alpha / Beta / Live / Retirement] |
| Assessment route | [Service assessment / spend control / investment review / none] |
| Frameworks applied | [GOV.UK Service Standard and TCoP / FEAF v2 and USWDS / EIF and Regulation (EU) 2024/903 / national framework] |
| Classification | [Official / Internal / Sensitive] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| Service owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief technology or architecture authority | [@name] | [Decision] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Data protection | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for alpha |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved for private beta |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added EU digital identity wallet as a sign-in option |
Contents
1. Service, users and the whole problem
1.1 Service definition
| Item | Value |
|---|
| Service name (verb-led) | [Example: Apply for a disabled parking permit] |
| Users | [Example: Residents with a qualifying condition, carers acting for them, council staff] |
| Outcome for the user | [Example: Permit issued or reasons for refusal, within 10 working days] |
| Channels | [Example: Online, telephone with assisted digital support, in person at libraries] |
| Organisations involved | [Example: Local council, national benefits agency for evidence, permit printer] |
| Volume | [Example: 40,000 applications a year, peak in January] |
| Policy basis | [Legislation or policy that creates the service] |
1.2 User needs
| ID | As a | I need to | So that | Evidence |
|---|
| UN-001 (Example) | Resident with a mobility condition | Apply without sending paper evidence I already gave another agency | I am not asked twice | 18 of 24 research participants |
| UN-002 (Example) | Carer | Apply on behalf of someone else | The person I care for gets the permit | Contact centre data |
| UN-003 (Example) | Screen reader user | Complete the form with assistive technology | I can apply on my own | Accessibility research round 2 |
| UN-004 (Example) | Council caseworker | See the evidence and the eligibility result in one place | I decide quickly and consistently | Contextual inquiry |
| [UN-NNN] | [User] | [Need] | [Outcome] | [Evidence] |
1.3 Service map
Map the whole journey, including the steps that happen outside this service (guidance, other agencies, printing and delivery) and the assisted routes. Dotted lines are assisted digital paths that must reach the same outcome.
1.4 Demand and volumes
Turn the volume in section 1.1 into numbers that size the service and the assisted channels. Replace the worked example with your own data and recompute.
| ID | Quantity | Example value | Derivation | Design consequence |
|---|
| VOL-001 (Example) | Applications a year | 40,000 | Last 3 years of case data | Baseline for cost per transaction |
| VOL-002 (Example) | January share | 15 % = 6,000 | Seasonal pattern from case data | Peak month sizes caseworker staffing and the evidence API quota |
| VOL-003 (Example) | Peak working day | About 286 applications | 6,000 over 21 working days | Trivial load for the platform; the bottleneck is caseworkers, not servers |
| VOL-004 (Example) | Peak hour | About 43 applications | 15 % of the daily total in the busiest hour | Agree an evidence API rate of at least [2] calls a minute, with headroom of 3 times |
| VOL-005 (Example) | Assisted digital share | 25 % = 10,000 a year | Contact centre data | Assisted routes need trained staff and the same API (section 5 design rules) |
| VOL-006 (Example) | Manual review share | 30 % = 12,000 a year | Complement of the REQ-001 target of 70 % automatic | At [20 minutes] per case, 4,000 caseworker hours a year |
2. Requirements and policy constraints
2.1 Functional and quality requirements
| ID | Requirement | Source | Acceptance criterion |
|---|
| REQ-001 (Example) | Reuse evidence already held by government with the user's permission | UN-001, once-only policy | 70 % of applications need no uploaded evidence |
| REQ-002 (Example) | Meet WCAG 2.2 level AA | Accessibility regulations | Independent audit with no open level A or AA failures |
| REQ-003 (Example) | Support applications on behalf of another person | UN-002 | Delegated application journey tested with carers |
| REQ-004 (Example) | Available 99.5 % outside planned maintenance | Service level | Monitoring over 30 days |
| REQ-005 (Example) | Full audit trail of eligibility decisions | Administrative law, appeals | Every decision traceable to rule version and evidence |
| [REQ-NNN] | [Requirement] | [Source] | [Criterion] |
2.2 Legal and policy constraints
| ID | Constraint | Basis (paraphrased) | Design consequence |
|---|
| POL-001 (Example) | Public sector websites and apps must be accessible and publish an accessibility statement | EU Web Accessibility Directive (EU) 2016/2102 as transposed nationally; UK public sector accessibility regulations; US Section 508 | Section 6 |
| POL-002 (Example) | Personal data processed lawfully, with a DPIA for high-risk processing | GDPR Articles 6 and 35 or national equivalent | Section 9, DPIA |
| POL-003 (Example) | Interoperability assessment before deciding on new or substantially modified binding requirements that affect trans-European digital public services | Regulation (EU) 2024/903, Article 3(1), applying from 12 January 2025 | Section 8.3 |
| POL-004 (Example) | Where the service requires electronic identification and authentication, also accept the EU Digital Identity Wallet | Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014, Article 5f(1) | Section 7 |
| [POL-NNN] | [Constraint] | [Basis] | [Consequence] |
3. Reference model mapping
3.1 US Federal Enterprise Architecture Framework v2
FEAF v2 (released January 2013) organises description through six reference models in its Consolidated Reference Model. Record the classification used by your agency's architecture repository.
| Reference model | Classification for this service | Notes |
|---|
| Performance (PRM) (Example) | Goal: [agency strategic goal]; measure: time to decision | Links to section 13 metrics |
| Business (BRM) (Example) | [Mission sector, business function, service] | |
| Data (DRM) (Example) | [Domain, subject, topic] for eligibility and permit records | Data catalogue entry [ID] |
| Application (ARM) (Example) | Case management, forms, notifications | Reused components flagged in section 4 |
| Infrastructure (IRM) (Example) | Government cloud platform, FedRAMP authorised service | |
| Security (SRM) (Example) | Controls per agency security plan | Section 9 |
3.2 UK: Service Standard and Technology Code of Practice
Map the design to the 14 points of the Service Standard in section 12. The Technology Code of Practice (13 points, page updated 7 July 2025) applies to technology spend:
| TCoP point | How this design meets it | Section |
|---|
| 1. Define user needs (Example) | User needs UN-001 to UN-004 from research | 1.2 |
| 2. Make things accessible and inclusive | [Response] | 6 |
| 3. Be open and use open source | [Response] | 10 |
| 4. Make use of open standards | [Response] | 10 |
| 5. Use cloud first | [Response] | 5 |
| 6. Make things secure | [Response] | 9 |
| 7. Make privacy integral | [Response] | 9 |
| 8. Share, reuse and collaborate | [Response] | 4 |
| 9. Integrate and adapt technology | [Response] | 8 |
| 10. Make better use of data | [Response] | 8 |
| 11. Define your purchasing strategy | [Response] | 11 |
| 12. Make your technology sustainable | [Response] | 5, 13 |
| 13. Meet the Service Standard | [Response] | 12 |
3.3 EU: European Interoperability Framework
Describe interoperability in the four EIF layers (legal, organisational, semantic, technical) under integrated public service governance:
| EIF layer | Design for this service |
|---|
| Legal (Example) | Legal basis for data exchange with the benefits agency: [act and article] |
| Organisational (Example) | Service agreement with the benefits agency; joint process for disputes |
| Semantic (Example) | Shared vocabularies for person, address and eligibility (for example the SEMIC core vocabularies) |
| Technical (Example) | REST APIs with OpenAPI descriptions over the national exchange layer |
| Governance (Example) | Interoperability assessment report (section 8.3), catalogue entry on the national portal |
4. Shared platforms and reuse
| Capability | Shared platform or component | Decision | Reason if not reused |
|---|
| Design system (Example) | GOV.UK Design System / US Web Design System (USWDS 3.x) / national design system | Reuse | |
| Identity and sign-in (Example) | [GOV.UK One Login / Login.gov / national eID / EUDI Wallet] | Reuse | |
| Payments (Example) | [Government payment platform] | Reuse | |
| Notifications (email, SMS, letters) (Example) | [Government notification platform] | Reuse | |
| Case management (Example) | [Departmental case platform] | Build on platform | Configuration only |
| Address lookup (Example) | [National address register API] | Reuse | |
| Hosting (Example) | [Government cloud framework or platform] | Reuse | |
| Eligibility rules engine (Example) | None available | Build | No shared component; publish as open source |
| [Capability] | [Component] | [Reuse / Build / Buy] | [Reason] |
5. Service architecture
| Component | Responsibility | Hosting | Build, reuse or buy | Owner |
|---|
| Service front end (Example) | Pages, validation, progressive enhancement | [Cloud platform] | Build on design system | @service-team |
| Service API (Example) | Orchestration, application state | [Cloud platform] | Build | @service-team |
| Eligibility rules (Example) | Versioned rules with explanation for each outcome | [Cloud platform] | Build, open source | @service-team |
| Case management (Example) | Caseworker queue and decisions | [Platform] | Reuse | @case-platform |
| Audit log (Example) | Immutable record of decisions | [Platform] | Reuse | @security-lead |
| [Component] | [Responsibility] | [Hosting] | [Decision] | [@owner] |
- Build the front end so that it works without JavaScript for the core journey and enhances progressively.
- Keep every eligibility rule versioned, with the version stored on each decision for appeals.
- Treat assisted digital channels as clients of the same API so that staff and users see the same state.
5.1 Key design decisions
| ID | Question | Options | Choice and reason |
|---|
| ADR-001 (Example) | How to check evidence held by the benefits agency | A. Real-time API call with user consent; B. Nightly bulk match; C. User uploads proof | A: no copy of another agency's data, answer within the session; C kept as fallback for RSK-001 |
| ADR-002 (Example) | Where eligibility rules live | A. Rules coded in the service API; B. Rules engine product; C. Rules in the case platform | A with rules as versioned, tested code published openly: the rule set is small and appeals need a readable explanation per rule version |
| ADR-003 (Example) | Account or guest journey | A. Account required; B. Guest with a reference number; C. Both | C: an account helps renewals, a guest route avoids excluding people without identity documents (RSK-002) |
| ADR-004 (Example) | How caseworkers see the application | A. New caseworker screens; B. Case platform with configuration | B: reuse the departmental platform (section 4) |
| [ADR-NNN] | [Question] | [Options] | [Choice and reason] |
Record each decision in full in the Architecture Decision Log (architecture/architecture-decision-log).
6. Accessibility and inclusion
| Item | Design and evidence |
|---|
| Conformance target (Example) | WCAG 2.2 level AA; EN 301 549 [edition cited by your jurisdiction; V4.1.1 published by ETSI in September 2026] |
| Components (Example) | Design system components with published accessibility status |
| Testing (Example) | Automated checks in CI, manual expert audit per release, research with disabled users each phase |
| Assistive technology coverage (Example) | Screen readers [names], screen magnification, speech recognition, keyboard only |
| Accessibility statement (Example) | Published at [URL], reviewed every [12 months] |
| Assisted digital (Example) | Telephone and face-to-face support with the same outcome and timescale |
| Language (Example) | Plain language, reading age [9]; [Welsh / official languages] versions |
Use the Accessibility Audit (quality/accessibility-audit) template for the audit report.
7. Identity and access
| Item | Decision |
|---|
| Identity need (Example) | Identity verification needed because the permit is personal and evidence is retrieved from another agency |
| Assurance level (Example) | [UK: medium confidence / US: NIST SP 800-63-4 IAL2 and AAL2 / EU: eIDAS level substantial] |
| Platform (Example) | [Government identity platform]; EU Digital Identity Wallet accepted as an option where the national rules require it |
| Delegation (Example) | Carer acts with recorded consent or legal authority; delegation stored in case management |
| Staff access (Example) | Single sign-on through the departmental identity provider, role-based access, quarterly access review |
| Fallback (Example) | Users who cannot verify online use assisted routes with document checks |
Under Regulation (EU) 2024/1183 each Member State must provide at least one EU Digital Identity Wallet (Commission timeline: by December 2026). Where a public sector body requires electronic identification and authentication for an online service, it must also accept the wallet (Article 5f(1)), so plan wallet acceptance for the date wallets become available. Private relying parties required to use strong user authentication must accept it about a year later (late 2027, Article 5f(2)). Check the consolidated text and the implementing acts for the dates that apply to your service. Detailed design belongs in CIAM Solution Design (security/ciam-solution-design).
8. Data, interoperability and sharing
8.1 Data inventory
| Data | Source or system of record | Legal basis | Retention | Shared with |
|---|
| Application (Example) | This service | Public task | [3 years after expiry] | Case management |
| Benefit entitlement evidence (Example) | Benefits agency | Data sharing agreement under [act] | Not stored; result only | None |
| Permit record (Example) | Case management | Public task | [Duration] | Enforcement officers |
| [Data] | [Source] | [Basis] | [Retention] | [Recipients] |
8.2 Exchanges
| ID | Exchange | Standard | Pattern | Agreement |
|---|
| DX-001 (Example) | Evidence check | REST, OpenAPI 3.1, OAuth 2.0 client credentials over the exchange layer | Request and reply with user consent token | DSA-2026-014 |
| DX-002 (Example) | Permit print file | SFTP, CSV schema v2 | Daily batch | Supplier contract |
| DX-003 (Example) | Statistics publication | Open data, CSV with metadata | Monthly | Open data policy |
| [DX-NNN] | [Exchange] | [Standard] | [Pattern] | [Agreement] |
8.3 Interoperability assessment (EU)
The Interoperable Europe Act (Regulation (EU) 2024/903, in force since 11 April 2024) requires public bodies to carry out an interoperability assessment before deciding on new or substantially modified binding requirements that affect trans-European digital public services (Article 3); the obligation applies from 12 January 2025. Publish the result. Record: [assessment ID], [date], [publication URL], [summary of effects on cross-border interoperability]. Check the consolidated text and the Commission guidelines for the scope.
Assessment triggers to check during design: a new legal or technical requirement in this service that other Member States' services must meet to exchange data with it; a change to a data format, vocabulary or API that cross-border partners consume; and a procurement specification that fixes a technical standard for exchanges. If none applies, record the screening result and the date.
9. Security, privacy and resilience
| Area | Design | Evidence |
|---|
| Threat model (Example) | Fraudulent applications, account takeover, data exfiltration by insiders | Threat Model (security/threat-model) |
| Data protection (Example) | Data minimisation, no evidence stored, DPIA approved | DPIA (compliance/dpia) |
| Security controls (Example) | [National security framework or agency controls]; secure by design review | Security plan [ID] |
| Fraud controls (Example) | Velocity checks, caseworker sampling | Fraud risk assessment |
| Resilience (Example) | Multi-zone hosting, RTO [4 hours], RPO [15 minutes], offline caseworker procedure | Disaster Recovery Plan (ops/disaster-recovery-plan) |
| Hosting and sovereignty (Example) | Data stored in [jurisdiction] | Data Residency and Sovereignty Assessment (compliance/data-residency-sovereignty-assessment) |
10. Openness: code, standards and technology choices
| Item | Decision |
|---|
| Source code (Example) | Published under [MIT / OGL / national licence] at [repository URL]; secrets and fraud rules excluded |
| Open standards (Example) | HTML, OpenAPI 3.1, OAuth 2.0 and OpenID Connect, UTF-8, ISO 8601 dates, [national data standards] |
| Technology choices (Example) | Common languages and managed services; choices recorded in an Architecture Decision Log (architecture/architecture-decision-log) |
| Lock-in avoidance (Example) | Data export in open formats; exit plan in the contract |
| Contributions back (Example) | Improvements to shared components offered upstream |
11. Procurement and commercial approach
| Item | Decision |
|---|
| Sourcing model (Example) | In-house team with a supplier for [capability]; see Build vs Buy Analysis (architecture/build-vs-buy-analysis) |
| Route (Example) | [Government framework / open procedure / dynamic purchasing system] |
| Contract length and break points (Example) | [2 years] with break at end of beta |
| Intellectual property (Example) | Code produced under contract owned by [the authority] and published |
| Exit (Example) | Data, documentation and code handed over; knowledge transfer period of [8 weeks] |
12. Service assessment evidence
| Point | Service Standard point (UK) | Evidence in this design | Status |
|---|
| 1 | Understand users and their needs | Section 1.2, research reports | [Met / Partly / Not yet] |
| 2 | Solve a whole problem for users | Section 1.3 | [Status] |
| 3 | Provide a joined up experience across all channels | Assisted digital design, section 1.3 | [Status] |
| 4 | Make the service simple to use | Usability test results | [Status] |
| 5 | Make sure everyone can use the service | Section 6 | [Status] |
| 6 | Have a multidisciplinary team | Team plan | [Status] |
| 7 | Use agile ways of working | Delivery approach | [Status] |
| 8 | Iterate and improve frequently | Release history | [Status] |
| 9 | Create a secure service which protects users' privacy | Section 9 | [Status] |
| 10 | Define what success looks like and publish performance data | Section 13.1 | [Status] |
| 11 | Choose the right tools and technology | Sections 4, 5, 10 | [Status] |
| 12 | Make new source code open | Section 10 | [Status] |
| 13 | Use and contribute to open standards, common components and patterns | Sections 4, 10 | [Status] |
| 14 | Operate a reliable service | Sections 9, 13 | [Status] |
12.1 Traceability
| User need or requirement | Design element | Evidence |
|---|
| UN-001, REQ-001 (Example) | DX-001, ADR-001, section 8 | Evidence-free application rate against the 70 % target |
| UN-002, REQ-003 (Example) | Section 7 delegation | Carer research round 3 |
| UN-003, REQ-002 (Example) | Section 6 | Accessibility audit |
| REQ-004 (Example) | Section 9 resilience, section 13.2 | 30 days of availability monitoring |
| REQ-005 (Example) | Audit log, rule versioning, ADR-002 | Appeals test |
| UN-004 (Example) | Case management, ADR-004 | Caseworker usability test |
| POL-003 (Example) | Section 8.3 | Published assessment or screening record |
| POL-004 (Example) | Section 7 | Wallet acceptance test |
| [ID] | [Element] | [Evidence] |
13. Operations, performance and risks
13.1 Performance measures
| Measure | Definition | Target | Published |
|---|
| Completion rate (Example) | Applications submitted divided by applications started | [80 %] | Monthly |
| User satisfaction (Example) | Survey after submission | [85 %] | Monthly |
| Cost per transaction (Example) | Total service cost divided by applications, all channels | [Amount] | Yearly |
| Digital take-up (Example) | Share of applications made online | [75 %] | Monthly |
| Time to decision (Example) | Median working days from submission to decision | [5 days] | Monthly |
13.2 Service operations and support
| Item | Design |
|---|
| Service level (Example) | REQ-004 availability; support hours [08:00 to 18:00 on working days] for users, 24 hours a day monitoring for the platform |
| Support tiers (Example) | Tier 1 contact centre, tier 2 service team, tier 3 platform and supplier teams; escalation paths written down and tested |
| Incident handling (Example) | Severity levels agreed with the service owner; a user-facing status message within [30 minutes] of a severity 1 incident |
| Planned maintenance (Example) | Outside peak hours, announced [5 working days] ahead, never in January |
| Monitoring (Example) | Uptime checks, error rates per page, evidence API latency, caseworker queue length against VOL-006 |
| Run cost (Example) | Monthly cost report feeding the cost per transaction measure in 13.1 |
13.3 Delivery phases and gates
| Phase | Purpose | Exit evidence |
|---|
| Discovery (Example) | Understand users, the whole problem and constraints | User needs (1.2), service map (1.3), decision to proceed |
| Alpha (Example) | Test riskiest assumptions with prototypes | ADR-001 to ADR-003 tested, reuse decisions (section 4), alpha assessment passed |
| Private beta (Example) | Real users in a controlled group | Accessibility audit with no open level A or AA failures, DPIA approved, security testing done |
| Public beta (Example) | Open to all users | Performance data published (13.1), support model in place (13.2) |
| Live (Example) | Run and improve | Live assessment passed, legacy route retired or kept as assisted channel |
13.4 Risks
| ID | Risk | Likelihood | Impact | Response | Owner |
|---|
| RSK-001 (Example) | Data sharing agreement with benefits agency delayed | Medium | High | Fallback evidence upload journey | @service-owner |
| RSK-002 (Example) | Identity verification excludes users without documents | Medium | High | Assisted verification route | @service-architect |
| RSK-003 (Example) | Supplier lock-in on case platform | Low | Medium | Open data export, exit clauses | @commercial-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |
14. Glossary and references
14.1 Glossary
| Term | Meaning |
|---|
| Assisted digital | Support for people who cannot use the online service on their own |
| Service assessment | Peer review of a service against the service standard at phase gates |
| Once-only principle | Users give information to government once; agencies reuse it with permission |
| EIF | European Interoperability Framework |
| EUDI Wallet | European Digital Identity Wallet under Regulation (EU) 2024/1183 |
| FEAF | Federal Enterprise Architecture Framework (US) |
| USWDS | US Web Design System |
14.2 References
| Reference | Version or date | Use |
|---|
| GOV.UK Service Standard, gov.uk/service-manual/service-standard | 14 points, checked 2026-10-23 | Section 12 |
| UK Technology Code of Practice, gov.uk | 13 points, page updated 2025-07-07 | Section 3.2 |
| US Federal Enterprise Architecture Framework v2 | January 2013 | Section 3.1 |
| US Web Design System, designsystem.digital.gov | 3.14.0 at time of checking | Section 4 |
| European Interoperability Framework (Commission communication COM(2017) 134) | 2017 | Section 3.3 |
| Regulation (EU) 2024/903 (Interoperable Europe Act) | In force 2024-04-11; check the consolidated text | Section 8.3 |
| Regulation (EU) 2024/1183 (European Digital Identity Framework) | In force 2024-05-20; check the consolidated text | Section 7 |
| WCAG 2.2, W3C Recommendation | October 2023 | Section 6 |
| ETSI EN 301 549 | V4.1.1 (2026-09); check the edition cited in your jurisdiction | Section 6 |
| NIST SP 800-63-4, Digital Identity Guidelines | 2025 | Section 7 |
Standard and licence note
Based on the GOV.UK Service Standard and Technology Code of Practice (Crown copyright, Open Government Licence v3.0; point titles cited, all other text original), the US Federal Enterprise Architecture Framework v2 and US Web Design System (US government works), the European Interoperability Framework, Regulation (EU) 2024/903 and Regulation (EU) 2024/1183 (EU legislative texts, free to reuse), the W3C WCAG 2.2 Recommendation and ETSI EN 301 549. Requirements are summarised in original wording and no legal or standard text is reproduced beyond short titles. Check the current official versions and the consolidated legal texts on EUR-Lex for binding wording and dates. This is a documentation format, not legal advice. Template licence: MIT.