Integration & API Strategy
Integration & API Strategy
Status: Draft
Date: 19 March 2026
Author: Nicky Carr — Chief Architect
Purpose and Context
The Ministry of Justice (MoJ) operates a complex landscape of legacy systems, SaaS platforms, and modern digital services across agencies such as HMPPS, HMCTS, LAA and OPG. To support operational efficiency, data-driven decision making, and cross-agency collaboration, the MoJ requires a modern, coherent approach to integration.
This strategy sets out a high-level direction for how APIs and integration services will be designed, delivered, and governed across the department. It aligns with:
- UK Government Technology Code of Practice (especially on interoperability, reuse, and data APIs)
- GDS' cross-government API and integration standards
- GDS' guidance on Data as a Service and API-first architecture
- MoJ's strategic aims for coherent, simplified, secure, and reusable digital platforms
Strategic Principles
1. Use APIs for Everything (API-First by Default)
We will adopt an API-First approach in all new digital services and major changes or upgrades. This ensures:
- Interoperability between systems across MoJ and wider government
- Encapsulation of legacy systems behind modern interfaces
- Consistent and secure ways of accessing, updating, and sharing data
- Enabling reuse by internal teams and partners
- Accelerated delivery by decoupling frontend and backend systems
Key policy positions:
- All new systems must expose their key capabilities via well-documented APIs
- APIs must be published to a central API catalogue to support discoverability
- APIs must follow common security standards (MoJ Zero Trust, OIDC, OAuth2, mTLS where needed)
- APIs must meet CDDO's design standards (RESTful, resource-oriented, versioning, consistent naming)
2. Use the Integration Hub to Deliver Live, Trusted Data
MoJ's Integration Hub is the strategic mechanism for real-time data movement. Its role is to:
- Provide a single, secure, scalable integration backbone
- Enable publish/subscribe data flows across MoJ agencies
- Reduce the proliferation of point-to-point connections
- Provide event-driven patterns to support operational and analytical workloads
- Enforce consistent monitoring, logging, and reliability patterns
- Support Zero Trust controls and governance in one place
Policy positions:
- All real-time and near-real-time integrations must run through the Integration Hub unless formally exempted by the Technical Design Authority (TDA)
- Legacy batch or ETL pipelines should be migrated to event-driven or API-based flows where feasible
- The Integration Hub becomes the system of integration, not the system of record
3. Use the Federated Data Mesh for Analytics and Reporting
Where data is required for analytical, reporting, or insight purposes, it must be managed within the federated data mesh, aligned to business domains. This ensures:
- Clear ownership of data within domain boundaries
- Consistent, trusted data models for analysis and reporting
- Reduced duplication and fragmentation of analytical data
- Scalable access to data for cross-MoJ insights
Policy positions:
- Data must be modelled and exposed in line with federated data architecture principles
- Data ownership and stewardship must sit with the relevant business domain
- Cross-domain data sharing must use governed interfaces and agreed standards
- Data must be published on the central Data Catalogue and accessed using the Justice Data Platform
4. APIs Based on Clear, Shared Data Objects
Data in government is often duplicated or inconsistent because systems define their own internal representations. To address this, APIs must be grounded in canonical data objects defined across MoJ domains.
Policy positions:
- Each major domain (Offenders, Cases, People, Locations, Assets, Documents, etc.) will define canonical data objects, aligned with cross-government models
- APIs must expose and consume these objects rather than bespoke formats
- Canonical objects are to be published in a shared MoJ Data Model Repository
Target Architecture Overview
The target architecture is built around the following core pattern:
Front-end services → Domain microservices → API Gateway → Integration Hub → Legacy and SaaS systems
With event-driven (publish/subscribe) as the default pattern for data movement.
Front-end services
Front-end applications provide user-facing interfaces for staff, citizens, partners, or internal teams. They communicate with domain microservices using REST/JSON APIs and are decoupled from backend systems through the API Gateway.
Domain microservices
Domain microservices encapsulate specific business capabilities, following the principle of independently deployable, loosely coupled services. They use canonical data objects for interoperability, publish and consume events from the Event Broker, and provide synchronous REST endpoints via the API Gateway.
API Gateway / API Management Platform
The API Gateway sits at the heart of synchronous interactions and provides:
- Authentication and authorisation (OIDC, OAuth2, mTLS where required)
- Request/response transformation
- Rate limiting, throttling, and OWASP-aligned security controls
- Support for API versioning, documentation publishing, and service discovery via OpenAPI specs
Integration Hub (iPaaS)
The Integration Hub is the enterprise backbone for data interchange. Its purpose is to:
- Provide a single, scalable integration entry point across the organisation
- Reduce point-to-point integrations
- Support synchronous APIs, event-driven patterns, and file-based transfers where unavoidable
- Enable real-time or near-real-time publish/subscribe data sharing
- Serve as the strategic enabler for MoJ-wide integration modernisation
Event Broker
The Event Broker (Kafka, EventBridge, or equivalent) enables event-driven architecture as the default pattern. It allows systems to publish and subscribe to domain events, removes tight coupling between producers and consumers, and supports real-time integration for operational and analytical workloads.
Legacy and SaaS systems
These are existing systems — both on-premise and cloud SaaS — that continue to hold critical business capabilities. Integrating them through the Integration Hub encapsulates their complexity behind clean APIs, supports coexistence during modernisation, and reduces reliance on fragile point-to-point links.
Governance and Standards
API Governance
- API-First Requirement: All new digital services must design and expose APIs for core capabilities
- Common API Design Guidelines: APIs must follow MoJ's RESTful design standards including consistent naming, clear versioning, resource orientation, and adherence to HTTP semantics
- Security Standards: All APIs must adopt MoJ Zero Trust principles
- Documentation & Discoverability: Every API must provide OpenAPI/Swagger documentation and be published to the central API Catalogue
- Versioning & Backwards Compatibility: Breaking changes require a new major version; deprecation timelines must be communicated and managed
- Performance & Availability: APIs must define and monitor SLOs for latency, throughput, and uptime
Integration Governance
- Integration Hub as Default: All real-time and near-real-time integrations must use the Integration Hub. Point-to-point connections are prohibited unless a formal waiver is approved by the TDA
- Reusable Integration Patterns: Teams must select from standard MoJ patterns (e.g., Request/Response API, Event Notification, Event Carried State Transfer, Bulk Load API)
- Observability: All integrations must emit structured logs, metrics, and trace data to central monitoring
- Security and Connectivity: All connections must follow approved network controls, encryption in transit, and access requirements
Data Governance
- Data Ownership: Every dataset must have a clearly defined Data Owner (accountable for quality, access, and lifecycle) and Data Steward (responsible for day-to-day management)
- Domain-Oriented Data Model: Data must be organised and governed by business domains, with each domain responsible for defining and maintaining its canonical data models
- Authoritative Data Sources: For each core data entity (e.g. person, case, sentence), a single authoritative source system must be defined
- Central Data Governance Account: All production data assets must be registered in the central data governance account, including metadata, lineage, and access policies
- Data Lifecycle & Retention: Data must have defined retention, archival, and deletion policies in line with legal and regulatory requirements
Benefits for MoJ
- Faster delivery of digital services through decoupling and reuse
- Better data sharing across agencies, supporting safer decision making
- Greater resilience through event-driven architecture
- Reduction in technical debt by modernising access to legacy systems
- Improved security with consistent API and identity controls
- Lower cost by reducing bespoke integrations and batch infrastructure
- Improved interoperability across MoJ and wider government through standardised APIs and shared data objects
Implementation Roadmap
The roadmap breaks down into four streams:
Stream 1: Standards and Patterns
Establishes the foundation that everything else depends on — a clear API standard and reusable patterns that create a consistent way for services to expose, consume, and manage data.
| Milestone | Timeline |
|---|---|
| Establish API Standard | Mar/Apr 2026 |
| Establish API Patterns | Aug/Sep 2026 |
Stream 2: Integration Hub Delivery
Incrementally scales the Integration Hub from a synergy-only footprint to a core enterprise capability.
| Milestone | Timeline |
|---|---|
| Synergy-only delivery | Oct 2026 |
| Internal workloads | Nov–Dec 2026 |
| Cross-government workloads | 2027 |
Stream 3: Organisational Change
Embeds the new standards, patterns, and the Integration Hub into governance so that teams naturally choose them as the default way of working.
| Milestone | Timeline |
|---|---|
| Embed in governance | May/Jun 2026 |
| Drive usage across teams | Q4 2026 |
| Remove legacy API / batch | 2027 onwards |
Stream 4: AI Outcomes
As standards mature and the Integration Hub becomes the default integration pathway, AI can consume trusted, canonical data in a controlled, auditable way.
| Milestone | Timeline |
|---|---|
| AI starts to use canonical data | Sep/Nov 2026 |
| AI consumes data from the Integration Hub | Q4 2026 |
| Integration Hub consumes from AI | 2027 onwards |
Was this page useful?