Devolution Without Digital Fragmentation: Designing for a Federated Public Sector

We live in a digital world, and the machinery of modern government is increasingly digital by default. Our interactions with public services, the information held about us, the decisions made, the payments processed and the movement of data between organisations are predominantly enabled through digital systems. If responsibility for delivering those services is becoming increasingly decentralised, that decentralisation must therefore be reflected in the underlying digital fabric. Moving organisational responsibility without considering the technology, data and integration architecture that supports it risks decentralising the organisation while leaving behind a fragmented digital estate. The opportunity is to design that digital fabric deliberately: creating shared foundations that allow regional organisations to operate autonomously, while remaining interoperable as part of a coherent public-sector ecosystem. Devolution therefore needs a digital architecture designed for federation from the outset.

As devolution drives public-sector responsibilities to become increasingly distributed across regional organisations, an important technology question emerges: how do you decentralise organisational responsibility without decentralising and duplicating the entire technology estate beneath it?

It is a familiar enterprise architecture problem. Multiple organisations need autonomy to design services around their own users and priorities, while simultaneously depending on many of the same national systems, data sources and enabling capabilities. Without an intentional architecture, the likely result is predictable: duplicated platforms, point-to-point integrations, inconsistent data models and increasingly complex interoperability. The alternative is a federated architecture built around shared digital rails.

The fragmentation problem

Imagine 18 regional authorities, each requiring access to information and services from organisations responsible for employment, taxation, education, health, transport and other national capabilities. A conventional approach allows each organisation to establish those relationships independently. The result quickly becomes a many-to-many integration estate.

The same problem occurs with technology capabilities. Each organisation requires some combination of identity and access management, API management, integration, data platforms, analytics, AI, cyber security, observability, workflow, document management and common citizen-facing services. Allow every organisation to procure and implement these independently and significant amounts of essentially identical technical capability will be recreated.

There is also a less visible form of fragmentation: language. If one organisation describes a citizen as a Person, another as a Customer, another as a Resident and another as a Participant, those differences eventually surface in data models, APIs, integrations and reporting. The technology may technically connect while the organisations still mean different things.

The problem is not decentralisation. The problem is decentralisation without a common architecture.

Shared rails, local services

A better architectural principle is:

Common where common. Local where different. Interoperable everywhere.

Regional organisations should retain the ability to select and design the applications and services that meet their particular needs. The common technology beneath those services must be treated differently.

A shared Devolution Digital Platform could provide reusable capabilities including Identity & Trust, providing federated identity, authentication and policy-based access; Integration, providing API management, event distribution and reusable integration patterns; Data Exchange, providing discoverable data products, common data contracts and metadata; AI & Automation, providing assured access to models, RAG, agent runtimes, document intelligence and AI guardrails; Security, providing common security controls, audit, monitoring and threat detection; Observability, covering operational monitoring, SIEM, performance and cost management; and Common Services, such as notifications, payments and document services.

Underpinning all of these should be another shared capability: a Government Canonical Model defining the common language used across the ecosystem.

Regional organisations innovate above the platform rather than recreating the platform itself.

A Government Canonical Model

Interoperability is not achieved simply because two systems can exchange JSON.

They also need to agree on what the information means.

A Government Canonical Model should therefore establish common definitions for the core entities exchanged between national and regional organisations. Concepts such as Person, Household, Address, Employer, Employment, Skill, Qualification, Business, Property, Service, Intervention, Payment and Outcome should have agreed definitions, identifiers, relationships and core attributes.

The principle should be simple:

If two parts of government (national and/or local) are talking about the same thing, they should call it the same thing and mean the same thing.

That does not mean every organisation needs an identical internal data model. Existing systems can continue to use their own schemas and terminology internally. The canonical model becomes the common language at the organisational boundary.

A regional employment platform might internally use Participant, a local authority system might use Resident, and another system might use Customer. When information crosses the boundary, however, each maps to the canonical concept of Person.

The same applies to events. Across government, different organisations may use different terminology to describe the same real-world change in state. An employment service might publish EmploymentStarted, a housing service TenancyCommenced, a skills provider QualificationCompleted, a transport authority ConcessionIssued, or a planning authority PlanningPermissionGranted. A Government Canonical Model should establish agreed definitions for these events so that AddressChanged, BusinessCreated, EmploymentStarted, QualificationCompleted, BenefitAwarded, TenancyStarted or PlanningPermissionGranted have a consistent meaning wherever they are produced or consumed. The event describes what happened; the organisation that generated it should not determine what it means.

This significantly reduces the translation, transformation and ambiguity that otherwise accumulates across a large integration estate.

Importantly, the canonical model should be extensible rather than restrictive. Regional organisations can add attributes and concepts required by their services, but the shared core remains consistent.

Extend the model. Don't redefine the meaning.

Publish once, consume many

Integration provides one of the clearest opportunities. Without a shared architecture, every regional organisation potentially creates its own interfaces with every national organisation. Instead, national systems expose reusable APIs, events and data products through a common integration fabric, using the Government Canonical Model as the common language of exchange.

A national organisation publishes a capability once. Authorised organisations consume it many times. The architectural principle becomes:

Publish once. Govern once. Consume many.

This changes integration from a collection of individual projects into a reusable ecosystem.

Federated data rather than another data lake

Shared architecture does not require all public-sector data to be moved into a single central repository. A federated data model is potentially much more powerful. Information remains mastered by the organisation responsible for it while becoming discoverable through a common data catalogue and consumable through governed data products.

A consuming organisation should be able to determine what information exists, who owns it, what it means, who can access it, for what purpose and how it is consumed.

The Government Canonical Model provides the semantic layer underneath this. A data product describing an Employer, Qualification or Outcome should mean the same thing regardless of whether it originates nationally or regionally. This allows data to remain federated while its meaning remains consistent.

Identity once, authorisation locally

Identity demonstrates how shared capability and organisational autonomy can coexist. A citizen should not require a completely separate digital identity for every public organisation they interact with.

A federated identity capability can establish who someone is, while individual organisations can determine what that person is permitted or entitled to access within their services. Identity becomes shared infrastructure while authorisation remains within the relevant service boundary.

The same architectural pattern can be applied repeatedly:

Common platform. Local decision.

Move from interfaces to events

There is also an opportunity to rethink how public-sector systems interact. Traditional integrations frequently operate by one system repeatedly requesting information from another. An event-driven architecture provides another model.

Canonical events such as EmploymentStarted, EmploymentEnded, QualificationCompleted, ApprenticeshipStarted, BusinessCreated, AddressChanged, PlanningPermissionGranted and PropertyCompleted could be published by authoritative systems. Where governance and information-sharing rules permit it, authorised services can subscribe to relevant events rather than repeatedly querying source systems.

Crucially, every organisation understands those events in the same way because their definitions form part of the Government Canonical Model. The result is a more responsive ecosystem with considerably less point-to-point coupling and semantic translation.

Avoid creating multiple AI platforms

AI makes the need for shared architecture particularly visible. Every organisation exploring AI potentially requires model gateways, retrieval infrastructure, document intelligence, agent runtimes, prompt management, evaluation, PII protection, guardrails, audit and cost management. There is little value in recreating all of that infrastructure independently.

A common assured AI platform could provide these capabilities while allowing organisations to build their own use cases above it. A common information model also becomes increasingly important as AI and autonomous agents begin interacting across organisational boundaries: agents need a consistent understanding of the entities, events and services they are reasoning about.

The distinction is important: share the expensive plumbing. Decentralise the innovation.

The Devolution Digital Landing Zone

The architecture can ultimately be turned into something tangible. Rather than every regional organisation beginning with technology procurement and infrastructure design, provide a standard Digital Landing Zone.

From day one, an organisation could have access to identity federation, secure cloud foundations, government APIs, event services, the Government Canonical Model, the data catalogue, secure data workspaces, AI services, observability, SIEM, DevSecOps tooling and reusable common components.

The proposition becomes extremely simple:

Here are the rails. Build what your region needs.

Standards become executable architecture rather than documents.

Designing for federation

This is ultimately not a technology standardisation exercise. It is about defining where standardisation stops. Standardise identity protocols, interfaces, events, information semantics, security and interoperability. Don't unnecessarily standardise the applications and services that need to respond to different regional requirements.

That creates a very different architecture: shared digital foundations + a common government language + interoperable national systems + autonomous regional services. It allows individual organisations to evolve independently without progressively disconnecting from the wider ecosystem.

That is the architectural opportunity. Because decentralisation does not inherently create fragmentation. Decentralisation without architecture does.

EI Digital — Enterprise Architecture | Digital Transformation | Fractional CTO