# Government Digital Services — Capability-Led Transformation Case

## Context
A public-sector organisation operated more than 70 citizen-facing services across separate departments. Users repeated identity checks, case data was duplicated, and each service funded its own workflow and notification technology.

## Architecture challenge
- Fragmented citizen journeys and inconsistent service levels
- Duplicate identity, payment, document, case, and notification capabilities
- Ageing departmental applications with unclear ownership
- Transformation initiatives prioritised by system age rather than public value

## Capability assessment
The baseline mapped business capabilities to services, applications, information, owners, cost, risk, and strategic importance. Heat mapping identified five shared capabilities for enterprise investment: identity and consent, case management, payments, document exchange, and notifications.

## Target architecture
A composable digital-service platform provides shared capabilities through governed APIs and events. Departmental products retain policy-specific workflows while consuming common identity, payment, document, and notification services. A federated data model separates authoritative records from analytical products.

## Key decisions
1. Organise investment around business capabilities and citizen journeys, not application replacement alone.
2. Build shared capabilities as products with accountable owners, roadmaps, and service levels.
3. Use a strangler transition pattern to migrate journeys incrementally.
4. Require privacy impact assessments and consent controls at service-design gates.
5. Track architecture outcomes through reuse, journey completion, lead time, and cost-to-serve.

## Roadmap
- **0–90 days:** capability baseline, application linkage, pain-point heat map
- **3–6 months:** identity and notification foundations; first journey pilot
- **6–12 months:** shared case and document services; retire duplicate components
- **12–24 months:** scale platform adoption; modernise highest-risk systems by domain

## Governance
A cross-department design authority owns principles and exceptions. Product councils govern shared capabilities. Quarterly portfolio reviews use capability health, technical risk, service performance, and public value to rebalance investment.

*This is a representative, anonymised EAOT reference case. Figures and system names illustrate a realistic enterprise scenario rather than a named client engagement.*