Enterprise Integration

Definition

Enterprise integration is the problem of connecting many applications that were not designed to work together, owned by different teams, on different lifecycles.

The topology question, which decides everything

Point-to-point integrations grow with roughly the product of the systems rather than their sum. Twenty systems each needing data from five others is a hundred integrations, each with its own authentication, error handling, retry logic and owner. The estate becomes unchangeable — nobody can alter a system because nobody can enumerate what depends on it.

Hub-based approaches — an integration bus or platform — centralise the connections. The number of integrations becomes linear, and there is one place to apply monitoring and policy. The cost is a central component that becomes a bottleneck and, in the worst versions, accumulates business logic until it is a third system nobody owns.

Event-based approaches invert the dependency: producers publish facts and do not know their consumers. A new consumer requires no change to any producer, which is the property that actually matters at enterprise scale. The cost is eventual consistency everywhere downstream and schema governance as a permanent obligation.

The canonical model trap

The recurring enterprise failure is a single canonical data model for the whole organisation. It is intuitive and it does not work:

• The same word means different things in different contexts. "Customer" in sales, fulfilment and finance are genuinely different concepts sharing a name.
• The model must serve everyone, so it serves nobody well — a Customer with sixty fields of which each consumer uses eight.
• Nobody can change it without coordinating with every consumer, so it freezes.

The alternative is explicit translation at boundaries: each context keeps its own model, with mapping where they meet. More mapping code, and each context can evolve independently — which is the whole point.

What to standardise instead of the model

Not the shape of the data, but the mechanics: transport, authentication, error semantics, retry behaviour, schema evolution rules, and observability. Those genuinely benefit from consistency and do not constrain any domain's model.

Failure scenarios

• Point-to-point sprawl, so the estate cannot change.
• A canonical model that freezes and satisfies nobody.
• Business logic in the integration layer, creating an unowned third system.
• A hub as a single point of failure for the whole estate.
• Integrations without ownership, so nobody maintains them and nobody can safely remove them.

Interview question

"An estate has 140 point-to-point integrations. What is the problem and what would you do about it?"