Enterprise Architecture in the Public Sector

Public sector EA shares the discipline with private sector EA but operates under different drivers. Where private enterprise optimises for competitive advantage and shareholder value, government optimises for citizen outcomes, public value, equity, and accountability. Where private enterprise can choose its technology freely, government is constrained by sovereignty, open-standards mandates, procurement rules, and the duty to avoid lock-in that would trap public funds.

Public sector EA is also structurally harder: it must integrate across agencies with different mandates, serve citizens equitably (not just profitably), operate with full transparency and accountability, and survive political transitions. The architecture of digital government is as much about governance, interoperability, and procurement as about technology.

This page covers the public sector context, interoperability and shared platforms, data sovereignty, open standards and avoiding lock-in, digital government patterns, and the frameworks (government EA, NIST, national references) that guide public sector practice.

Public sector EA operates under drivers that reshape the discipline. Citizen outcomes, not revenue, define value — a service that reaches underserved populations is valuable even if it is not 'profitable'. Equity matters — digital services must not advantage the digitally literate at the expense of the vulnerable. Accountability and transparency are legal duties, not brand choices — the architecture must be auditable and explainable.

Long horizons are the norm. Government systems outlast the political cycles that commission them; an architecture built for one administration must serve the next. This argues for open standards, portability, and minimal lock-in far more strongly than in the private sector, where vendor relationships can be renegotiated more freely.

Multi-agency integration is structurally central. Citizens interact with government as a whole, not agency by agency; a birth, a move, a business registration touches many agencies. The architecture must enable services that cross agency boundaries, which requires interoperability, shared identity, and shared data foundations that private enterprises rarely need at this scale.

Whole-of-government interoperability is the defining public sector architecture challenge. Citizens expect to interact once — register a business, update an address, apply for a benefit — and have government handle the rest across agencies. This requires shared platforms: a national digital identity, shared data registries, common notification and payment services, and interoperability standards that let agencies integrate.

The reference architecture defines these shared platforms as government-wide capabilities. Agencies consume them rather than build their own; the platform is funded and governed centrally. This avoids the proliferation of agency-specific identity, notification, and payment systems that characterise fragmented digital government.

Interoperability standards — common data models (a citizen, an address, a business), common APIs, common security — are what make the shared platforms usable. Without standards, each agency's integration with a shared platform is bespoke; with standards, integration is consistent and scalable. EA owns these standards, often codified in national interoperability frameworks.

Data sovereignty — the requirement that government data stays within the jurisdiction and under its laws — is a non-negotiable public sector constraint in most countries. This shapes cloud and platform decisions: a government cannot use a cloud whose data may be subject to a foreign jurisdiction's legal access. Sovereign cloud, in-country regions, and on-premises options are often mandated.

Sovereignty extends beyond physical location to legal control — who can access the data under whose law. A cloud operated in-country by a foreign-owned provider may still raise sovereignty concerns if the parent jurisdiction can compel access. EA must understand the legal, not just the physical, sovereignty profile of every platform.

The architecture pattern is often hybrid: sovereign cloud or on-premises for sensitive data, commercial cloud for less sensitive workloads, with clear classification of what goes where. EA defines the data classification, the residency rules per class, and the platform options that satisfy them. Getting this wrong is a legal and political failure, not just a technical one.

Avoiding vendor lock-in is a public duty, not just a commercial preference. Government that locks itself into a proprietary standard traps public funds, limits future choice, and creates dependencies that future administrations must honour. Open standards — documented, vendor-neutral, with multiple implementations — are therefore mandated in most government frameworks.

Lock-in avoidance is architectural, not just contractual. It means choosing open data formats (so data is portable), open APIs (so integrations are replaceable), and open protocols (so platforms are substitutable). It also means ensuring exit paths are designed in — the ability to move to an alternative provider or back in-house — rather than discovered when it is too late.

EA governs this through the standards catalogue, which favours open standards and requires justification for proprietary ones, and through procurement, which evaluates lock-in as a cost. A procurement that selects a proprietary standard because it is cheaper short-term, ignoring the lock-in cost, fails the public duty; EA's role is to make the lock-in cost visible so it is weighed properly.

Mature digital governments converge on common patterns: a national digital identity (for trusted, single sign-on across services), a government services portal (one front door for citizens), shared registries (of citizens, businesses, addresses, property), common payment and notification platforms, and an interoperability layer (APIs and data exchange) that lets agencies integrate.

These patterns are platform investments, not agency projects. They are funded centrally, governed as government capabilities, and consumed by agencies. The EA defines them in the reference architecture and the interoperability framework, and the digital government programme delivers them. An agency that builds its own identity or payment system duplicates what should be shared.

The pattern also includes 'once-only' data principles — citizens should provide information to government once, not repeatedly to each agency. This requires shared data registries agencies can read from, with the citizen's consent, rather than each collecting its own copy. The architecture of once-only is the architecture of interoperability at the data layer.

Several frameworks guide public sector EA. National governments often publish their own EA reference (e.g., the US FEAF, the UK's approach, national reference architectures in the EU and Asia). NIST (US) publishes reference architectures for cloud, security, and identity that are adopted internationally. TOGAF is widely used in government, adapted to the public sector context.

These frameworks matter because they provide the interoperability and standards basis that lets agencies integrate and vendors compete on a level field. A government that defines its own bespoke standards for each programme prevents interoperability and entrenches incumbents; one that adopts and contributes to open frameworks enables integration and competition.

EA's role is to adopt these frameworks, adapt them to the local context, and contribute back where appropriate. The frameworks are not bureaucratic overhead — they are the interoperability and anti-lock-in infrastructure that makes digital government work. Treating them as optional produces the fragmentation and lock-in they exist to prevent.