Home Affairs Integration Architecture Strategy

GoSource designed a domain-based integration strategy to reduce complexity across the Home Affairs portfolio and enable more autonomous service delivery.

Challenge

Home Affairs covers immigration, customs, policing and intelligence. Behind that sat more than 200 IT systems, over 1,000 distinct integrations between them, and 30,000 users.

The integrations were the problem. Systems were tightly coupled, so a change in one rippled into others, and nobody could move quickly. Worse, much of the integration ran on database change-data-capture, which left every consuming system doing its own ETL work to decipher another system’s internals.

The portfolio’s 2020 strategy asked for two things that look contradictory: autonomy for individual business domains, and high-quality centralised intelligence for border risk decisions. Integration was where both were won or lost.

Solution

The old model was a central ESB team building whatever each project asked for. That produces a patchwork, because every integration is designed for one consumer and reused by none.

The hard part was never technical. It was getting a large number of system teams and their executives to stop asking “how do we connect A to B for this project?” and start asking “what does my business unit do, and how should it expose that for anyone to use?” That is a change in how people think about their own work.

So the architecture came top-down and the delivery went bottom-up. We defined a portfolio-wide domain and resource architecture, setting microservice granularity across 35 business domains. Inside that governed frame, each domain designed and built its own RESTful services and events.

Getting there needed selling as much as designing. A sharp why-what-how deck won executive support and capital funding. Real examples and working prototypes, shown rather than described, brought the business domains and system owners along. And a capability building programme gave the IT teams the skills the decentralised model assumed they already had.

Outcomes

700 ESB transformations became 16 resources across 5 domains.

30 business domains now run autonomously, joined by simple APIs and events. The architecture was approved at executive level and written into the capital plan, with shared platforms including an API gateway and an enterprise event hub designed and prototyped.

The documentation went further than documentation usually does. A one-page poster version ended up on walls across the portfolio, which is a better measure of adoption than a sign-off.

Beyond that: a transformation plan covering 200+ systems and services, sold through more than 20 business areas, and a capability programme running to support the teams delivering it.

Technologies

Domain-driven design. RESTful microservice APIs. Event-driven architecture with an enterprise event hub. AWS API Gateway and Apache Kafka in prototype. OpenAPI. OAuth 2.0. Scaled agile principles, and organisational change management alongside the architecture.

Team: three people. One senior architect, a modeller and an API developer.