About these principles

Enterprise architecture principles are general rules and guidelines that inform and support decisions on how government should design and deliver services, to align with its vision and objectives. They are intended to be enduring and seldom amended. They reflect a level of consensus across the enterprise and embody the spirit and thinking of the architecture.

Discovery, user research and requirements gathering provide user needs, which inform what a service does. These principles provide guidance on how services should be architected to meet those needs. They should be applied alongside the UK Government Service Standard and the Technology Code of Practice.

People, place and devolution run as a theme through the whole set, signalling that place is a lens on everything government builds, not a separate concern. The principles are intended to be used by senior leaders, architects, product and service owners, commercial teams and assurance bodies to shape decisions consistently across central, regional and local government.

How to use them

  • Use the principles to frame architecture decisions early, not to retrospectively justify them.
  • Treat the mandatory standards as the compliance floor; use these principles to make good choices on top of them.
  • Use the rationale to explain intent to non-technical stakeholders, and the implications to shape design, standards and assurance questions.
  • Where principles conflict in a specific decision, make the trade-off explicit and record it.
  • Exceptions are permitted, but should be time-bound, documented and reviewed.

Relationship to mandatory standards

These principles sit on top of, and require compliance with, the mandatory cross-government standards. They guide how to make good architecture choices within those obligations; they are not an alternative to them.

Mandatory or strongly expected obligations include:

  • the Technology Code of Practice and the Service Standard, assessed through the spend control process;
  • the cross-government Secure by Design approach and the Government Cyber Security Standard, with alignment to the relevant central cyber assessment framework and target profile;
  • the Cloud First policy (default to public cloud), and open source and open standards expectations;
  • data protection, accessibility and records obligations set out in law and cross-government policy.

Where a principle cannot be met because of a mandatory obligation, or an obligation cannot be met because of technology constraints, the trade-off must be made explicit, evidenced and time-bound, with a clear route back to compliance.

The nine principles

Each principle is expressed with a short statement, a rationale (why it matters) and implications (what it means in practice).

Create measurable public value

Every architecture decision must create measurable public value – whether through better outcomes for citizens and businesses, improved efficiency, stronger resilience, reduced risk or greater strategic capability – at a cost the state can sustain across the whole life of the capability, and regardless of where in the country a citizen lives.

Rationale

  • Public money must be spent on outcomes, not activity or novelty.
  • Without measurable value, architecture decisions drift towards local preference and vendor influence.
  • Value framing anchors architecture decisions to policy intent, ministerial priorities and citizen outcomes.
  • Chronic under-investment in ‘run’ is a root cause of ageing technology; funding must cover the whole life, not just build.
  • Value that is concentrated in some places and absent in others is not good value; architecture should help close, not widen, geographic gaps in outcomes.

Implications

  • Every material architecture decision must have a stated outcome, benefit or risk-reduction rationale.
  • Benefits should be measurable through service performance, adoption, cost-to-serve, risk reduction, reuse, user satisfaction or reduced technical debt.
  • Value cases must reflect whole-life cost, including sustainable funding for maintenance and modernisation.
  • Assess value across places, not just at the centre: shared capability should be available to, and adaptable by, every locality so it does not entrench a postcode lottery.
  • Decisions should weigh building and retaining capability in-house against long-term dependence on external contractors.
  • Exceptions may be valid for security, resilience, legal, regulatory or strategic reasons, but must be explicit.
  • Architecture governance should require value framing at the point of decision, not after delivery.

Design around users, outcomes, place and inclusion

Government architecture must start from the needs of users and the outcomes government is trying to achieve, ensuring services are accessible, inclusive and usable across channels, communities and places, and are designed with communities rather than done to them.

Rationale

  • Government services exist to serve people, businesses and public servants, not to serve systems.
  • Whole-journey outcomes cross departmental and tier boundaries, so architecture must too.
  • Most services citizens experience are delivered locally or regionally; design that ignores place will not serve real journeys.
  • Accessibility, inclusion, assisted digital and trust are core public sector obligations.
  • Ignoring user reality is one of the most common causes of failed transformation and stranded technical debt.

Implications

  • Architecture should support whole user journeys and life events, not just individual departmental systems.
  • Internal users, operational teams, policy teams, local delivery partners, suppliers and AI agents should also be treated as users.
  • Treat local government, Strategic Authorities / mayoral bodies and the wider public sector (health, police, transport, housing, skills) as first-class users and delivery partners, not afterthoughts.
  • Support joined-up journeys around a place and a person across the central–regional–local boundary.
  • Accessibility, inclusion, language, channel choice and continuity must be considered early.
  • Work with communities, not to them: make relevant decisions and performance visible to local citizens and leaders.
  • Architecture must not optimise back-office convenience at the expense of user outcomes.
  • Service, product, policy and architecture teams should co-design, not sequence handoffs.

Know your estate

Government must maintain a shared, evidence-based and continuously updated view of its systems, services, data, dependencies, contracts and modernisation risk – at departmental, regional, local and cross-government level.

Rationale

  • You cannot rewire, reuse or modernise what you cannot see; visibility is the precondition for firmer foundations.
  • Modernisation risk can only be prioritised and funded when ageing and legacy systems are discovered, classified and made visible.
  • Duplication and concentration risk are invisible without a portfolio-level view across departments and tiers.
  • Local government reorganisation and coterminous boundaries create both disruption and a once-in-a-generation chance to rationalise systems and data – which needs a clear estate picture.
  • Evidence-based spend control and reuse depend on an authoritative, queryable record of what already exists.

Implications

  • Departments and local bodies should maintain current asset and dependency registers, with ageing and legacy systems risk-classified.
  • Automated discovery and scanning should be preferred over point-in-time manual returns where practical.
  • Capability, application, data and contract information should feed a federated view that spans central, regional and local government.
  • Critical dependencies should be identifiable, with a published register and clear escalation paths.
  • Estate data should be good enough to support reuse-before-build checks and portfolio heat-mapping.
  • Estate visibility should be treated as a shared capability, not a one-off audit.

Reuse, share and connect – build once, use many

Government must reuse and share existing capabilities, platforms, patterns and data before buying or building new, and must build capabilities that are interoperable, composable and machine-consumable so they can be safely connected and reused by other services, departments, tiers of government, partners and AI agents. Apply subsidiarity: provide common capability as shared national rails, while keeping delivery, configuration and decision rights as close to the place as is effective.

Rationale

  • Duplication across departments and localities creates cost, complexity, inconsistency and risk.
  • A ‘build once, use many’ model creates the shared building blocks and data-sharing rails that let services, departments and tiers reuse capability safely.
  • Interoperability is the foundation of cross-government journeys and of technology modernisation via strangler patterns.
  • Well-designed common rails let places make the right choices for themselves; over-centralised, single-instance designs impose the wrong choices on places.
  • Cloud is the default delivery model under the Cloud First policy; the strategic question is which shared platform, and how to retain exit and portability.
  • Open standards and well-designed interfaces protect long-term flexibility and portability.

Implications

  • ‘Reuse and share first’ should be the default; new build must have a clear justification.
  • Common capabilities (identity, notifications, payments, exchange, registers) should be treated as national assets, consumable by local and regional government and the wider public sector, not only central departments.
  • Every capability should be assessed as commodity, common, differentiating or place-specific, with different treatment for each; commodity and common capabilities should be offered as shared rails.
  • Apply subsidiarity: default to the lowest effective level for delivery and configuration, while sharing common building blocks nationally.
  • Avoid designs that lock delivery into a single central instance where a place-configurable or federated model would better serve local accountability.
  • Support local government reorganisation with reusable patterns for merging, separating and rationalising systems, data and contracts.
  • Consistent with Cloud First, default to public cloud and SaaS; the order of preference is shared government platform, then SaaS, then configured COTS, then PaaS, then IaaS, then bespoke build.
  • COTS and SaaS should be configured and integrated, not heavily customised; build is reserved for differentiating capability.
  • APIs, events and schemas should be designed as products, with discoverable catalogues and open standards.
  • Critical services should retain explicit exit strategies, portability plans and data repatriation routes, and open standards should be used to keep options open.
  • Services should be safely exposable to authorised systems and AI agents through controlled, auditable interfaces.
  • Point-to-point integration should be avoided where shared patterns or platforms exist; retirement and decommissioning should be planned from the start.

Treat data as shared national infrastructure

Data must be designed, governed, shared and protected as shared national infrastructure – across central, regional and local government – with quality, meaning, lineage, access and reuse considered from the start.

Rationale

  • Modern public services, analytics, AI and automation all depend on high-quality, well-governed data.
  • Data trapped inside departmental or local systems, or proprietary products, limits transformation and creates risk.
  • Joining services up around a place and a person requires data to flow safely across the central–regional–local boundary and the wider public service family.
  • Data sharing is a policy, legal and ethical challenge as much as a technical one.
  • Treating data as shared infrastructure that can be safely shared and reused aligns UK government with global thinking (Estonia, Singapore, India, New Zealand).

Implications

  • Data models, metadata, ownership, quality and lineage must be part of architecture decisions from the start.
  • Data should be shared by default where lawful, ethical, secure and proportionate.
  • Design for coterminosity and interoperability so data can be joined up across central, regional, local and wider public-service boundaries.
  • Enable place-based data sharing (aligned to structures such as a Mayoral Data Council) with the same governance, security and privacy expectations as national data.
  • Access should be granular, auditable and policy-driven, supported by consent and trust frameworks.
  • Registers, exchanges and canonical data sources should be treated as strategic capabilities.
  • Departments and local bodies should avoid locking critical data inside proprietary formats.
  • Data readiness for AI and automation should be an explicit architectural consideration.

Be open and transparent

Government should work in the open by default: publishing source code, using and contributing to open source and open standards, and making architecture decisions and service performance visible – nationally and locally – unless there is a clear and justified reason not to.

Rationale

  • Public services are built with public money, so their code should be available to reuse and build on unless there is good reason not to (Service Standard point 12).
  • Openness improves quality, security and accountability, and reduces duplication and supplier lock-in (Technology Code of Practice point 3).
  • Open standards let government technology interoperate, upgrade and expand, and are a practical enabler of portability across tiers (Technology Code of Practice point 4).
  • Transparency of decisions and performance builds public trust and sharpens accountability – nationally and locally.

Implications

  • New source code should be open and reusable by default, under appropriate licences, with a convincing explanation where specific code must stay closed.
  • It remains appropriate to keep some code or data closed – for example keys and credentials, fraud-detection algorithms and unannounced policy.
  • Teams should use and contribute to open standards, common components and patterns, and give equal consideration to open source when choosing technology.
  • Architecture decisions should be recorded and shareable (for example via an ADR framework), so decision context is not lost.
  • Success measures and performance data should be defined and, where appropriate, published – including at place level so local leaders and citizens can see them.
  • Reusable artefacts, patterns and guidance should be published to a common front door and kept current.

Secure, private and resilient by design

Security, privacy, resilience and operational continuity must be designed in from the start and continually assured, proportionate to the criticality, risk and public trust implications of the service, in line with the mandatory cross-government Secure by Design approach.

Rationale

  • Public trust depends on services being safe, private and reliable, especially as government adopts AI and shared platforms.
  • Security and privacy problems are exponentially more expensive to fix after delivery.
  • Resilience is a national and local concern: many government and local public services are effectively critical national infrastructure.
  • Recent incidents show that supply-chain and third-party weaknesses can disrupt essential public services.
  • AI, automation and agentic systems introduce new risks that traditional assurance was not designed for.

Implications

  • Services must follow the mandatory cross-government Secure by Design approach and the Government Cyber Security Standard, evidenced through spend controls.
  • Security and resilience should be aligned to the relevant central cyber assessment framework and target profile, set proportionate to the service’s criticality.
  • Move from point-in-time accreditation to continual assurance across the whole service lifecycle.
  • Threat modelling, privacy assessment, resilience assessment and operational readiness must happen early and iteratively.
  • Systems should be observable and recoverable, with explicit RTO, RPO, failover, incident response and continuity patterns for critical services.
  • Secure by design, zero-trust, identity, least privilege and strong audit should be default, not aspirational.
  • Supply-chain and third-party security must be assessed and managed, including supplier and platform concentration and single-point-of-failure risk.
  • AI-specific risks (prompt injection, data leakage, model misuse, hallucination, autonomous action) must be explicitly addressed, with human control preserved for high-impact decisions.

Make government AI-ready, agent-ready and adaptable by design

Government architecture must actively create the conditions for AI, automation and agentic services to operate safely, lawfully, transparently and under meaningful human control – and must stay adaptable, so government can change cloud provider, substitute technology components and rework integrations where this makes sense and adds future-proofing.

Rationale

  • AI and agentic systems will be part of how government delivers services within this decade, and the technology is moving fast, so architecture must stay adaptable rather than locked to today’s choices.
  • Without deliberate architecture, AI risks amplifying ageing technology, security weaknesses and data quality issues.
  • Agent-ready architecture (APIs, identity, permissions, audit, metadata, catalogues) is the same architecture that supports firmer foundations, data sharing and place-based delivery.
  • Flexibility – the ability to change cloud provider, substitute components and re-point integrations – protects value, manages concentration risk and keeps future options open as the market and models evolve.
  • Flexibility is a means, not an end: it should be pursued where it makes sense and adds future-proofing, not gold-plated everywhere at disproportionate cost.
  • The AI Playbook sets policy expectations; architecture must translate them into practical design.

Implications

  • AI use cases must have a clear public value case, not just novelty.
  • Agentic AI must operate within defined permissions, audit trails, policy constraints and human escalation routes.
  • Design for portability and avoid deep lock-in to a single cloud provider, model or vendor where a portable or multi-vendor option is viable; use open standards and clean interfaces so components can be substituted.
  • Favour modular, loosely coupled designs so cloud services, models, technology components and integrations can be replaced without re-engineering the whole service.
  • Apply flexibility proportionately: weigh the cost of keeping options open against the value and future-proofing it delivers, and record the trade-off.
  • Government services should be discoverable, described and safely consumable by authorised agents.
  • Underlying data must be good enough, lawful and appropriate for the intended AI use.
  • Model choice, hosting, provenance, evaluation and assurance must be explicit design decisions, kept reviewable as the market and technology evolve.
  • Accountability must remain with public servants; AI augments, it does not replace, accountable decision-making.

Govern, assure and continuously improve the estate

Architecture must be governed through proportionate standards, patterns, assurance and feedback loops, must comply with the mandatory cross-government standards, and the estate – its people and its environmental footprint – must continuously improve through measurement, learning, skills investment and decommissioning, across central, regional and local government.

Rationale

  • Principles only create value if they influence spend controls, service assessments, design authorities and operational reviews.
  • Compliance with mandatory standards is the floor; proportionate governance must enable delivery, not obstruct it.
  • Firmer foundations, technology modernisation and place-based reform are long-term programmes that require sustained assurance and improvement.
  • Sustainability (environmental, financial, operational and skills) is an architectural concern, not an afterthought.
  • A skilled, multidisciplinary workforce – in the centre and in local delivery – is a foundation in its own right; over-reliance on external contractors weakens the state.

Implications

  • Principles and mandatory standards must be embedded in spend controls, service assessments, design authorities and architecture review boards.
  • Standards, patterns and reference architectures must be discoverable, reusable and kept current.
  • Exceptions must be transparent, time-bound and reviewed, with a clear route back to compliance.
  • Portfolio-level architecture views should be maintained across central, regional and local government to see duplication, risk and modernisation need across the whole system.
  • Governance should include local and regional government and the wider public sector as participants, not just subjects of central assurance.
  • Environmental sustainability, operational cost and skills sustainability should be part of architecture decisions.
  • Multidisciplinary team capability and in-house skills should be built deliberately – nationally and locally – reducing avoidable contractor dependency.
  • Learning loops should feed back into principles, standards and patterns as government, technology and policy evolve.

Contribute and feedback

These principles are a working draft and are developed in the open. Suggestions and pull requests are welcome via the repository, or contact the enterprise architecture team.

publicsector.architecture@dsit.gov.uk

Back to top