Resources

hub-and-spoke-integration

Hub and Spoke Integration Pattern

Pattern Name: Hub and Spoke Integration Category: Integration Architecture Complexity: Medium Stability: High: well-established pattern with broad applicability


Context

Most organizations accumulate applications over time rather than by design. Each application solves a specific problem; each integration solves a point-to-point connection need. The result, left unmanaged, is a mesh of direct integrations between systems: sometimes called “spaghetti architecture”: where every application must know the details of every other application it communicates with. As the application count grows, the number of point-to-point integrations grows as a square function of that count, becoming unmanageable.


Problem

How do you connect a large number of applications to each other and to external partners without creating an unmanageable web of point-to-point integrations?

Point-to-point integrations create tight coupling: when a source system changes its API or data format, every downstream system that consumes it must change too. Security and access control must be implemented separately in each integration. Monitoring is fragmented: there is no single place to see what is flowing where. New applications joining the ecosystem must integrate with every existing application they need to talk to, individually. The cost and complexity of maintenance grows non-linearly with scale.


Solution

Introduce a central integration broker: the hub: that all applications (the spokes) connect to. Applications send messages to the hub and receive messages from the hub. The hub handles routing, protocol translation, data transformation, orchestration, and monitoring. No spoke needs to know the details of any other spoke.

The hub typically takes one of two forms:

Enterprise Service Bus (ESB): A message-oriented middleware layer that routes, transforms, and orchestrates messages between applications using a publish-subscribe or point-to-point messaging model. ESBs are synchronous or asynchronous, with rich transformation capabilities.

API Gateway: A centralized entry point for API traffic that handles authentication, authorisation, rate limiting, protocol translation, and routing. API gateways are primarily synchronous and request-response oriented.

Modern implementations often combine both: an API gateway for external-facing and synchronous traffic, and a message broker (such as MuleSoft, Azure Service Bus, or AWS EventBridge) for internal, asynchronous, and event-driven traffic.

Key benefits: N integrations instead of N(N-1)/2; single point for monitoring, security, and transformation; spoke applications are decoupled from each other; new applications only need to integrate with the hub.


Sparx EA Implementation Notes

Element types to use:

Diagram types: ArchiMate Application Layer diagram for the overall topology; UML Sequence diagrams for individual integration flows; UML Component diagram for interface contracts

MDG considerations: Define a custom stereotype «IntegrationHub» and «Spoke» to tag elements consistently. Add tagged values for: protocol (REST, AMQP, SOAP, Kafka), synchrony (sync/async), SLA, and owner. This makes hub-and-spoke elements queryable across the repository: a critical requirement for integration governance reporting.

Package structure: Group integration patterns in a dedicated Integration Architecture package, with sub-packages per integration domain. Maintain a Pattern Library package containing the canonical hub-and-spoke reference that project implementations link back to.

EA GraphLink and AI integration: With EA GraphLink connected, queries like “show me all applications connected to the integration hub” or “which applications have direct point-to-point integrations that bypass the hub?” become answerable in natural language by AI tools querying the MCP endpoint. This is particularly valuable for governance: identifying integrations that bypass the hub is a common compliance question that typically requires manual repository interrogation. AI-assisted querying via Kernaro or Copilot dramatically reduces the effort.


When to Use

When Not to Use


Related Patterns

Ready to make your EA investment work harder?

Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.