Skip to main content

Professional services

Enterprise service bus, when point-to-point has stopped scaling

A shared integration layer instead of a growing web of direct connections — worth it once you have enough systems, and premature before that.

The situation

The integration diagram nobody can read

Point-to-point connections are the right answer at first. The trouble is that each new system adds connections to every system it touches, and the total grows faster than the estate.

  • Dozens of direct connections, each built at a different time
  • One system changing and breaking three others
  • No single view of what data moves where
  • The same transformation implemented separately in several places
  • Failures visible only in the system that happened to log them
  • Nobody able to say what would break if a system were replaced

What it covers

What this work covers

  • Integration assessment

    What connects to what today, and whether a shared layer is genuinely justified. Often it is not, and we will say so.

  • Architecture

    Choosing between a bus, a broker, an event backbone or better-organised direct connections — they are not interchangeable.

  • Canonical models

    Agreeing what a customer or an order means across the estate, which is the hard part and the part that pays off.

  • Routing and transformation

    Message routing, mapping and enrichment implemented once rather than repeated per connection.

  • Reliability

    Retries, dead-letter handling and guaranteed delivery, so a downstream outage delays messages rather than losing them.

  • Monitoring

    One place to see what is flowing, what has failed and what is stuck.

How we work

How the work runs

Incrementally. Routing every integration through a new bus in one programme is how these projects acquire a reputation for taking two years.

  1. Map the estate

    Document what actually connects to what, which is frequently the first time anyone has had the full picture.

  2. Decide the pattern

    Establish whether a shared layer is warranted, and which pattern fits the traffic you actually have.

  3. Migrate a slice

    Move a handful of integrations first and prove the approach before committing the estate to it.

  4. Extend and operate

    Move further integrations as they change anyway, rather than rewriting working connections for consistency alone.

Outcomes

What you are left with

  • One place to see what data moves where
  • Transformation logic implemented once rather than per connection
  • A downstream outage that delays messages instead of losing them
  • Systems replaceable without rewriting every connection to them
  • Failures visible centrally rather than in one system's log
  • New integrations that are configuration rather than projects

Platforms and tooling

What we work with

Messaging

  • Azure Service Bus
  • RabbitMQ
  • Kafka
  • MSMQ
  • IBM MQ

Integration

  • Azure Integration Services
  • MuleSoft
  • BizTalk
  • Apache Camel

Patterns

  • Publish and subscribe
  • Request and reply
  • Event sourcing
  • Canonical models

Named as platforms we work with, not as formal partnerships.

Common questions

Questions we are usually asked

  • Below about five or six integrated systems, almost certainly not — a bus adds infrastructure, a skill requirement and a new single point of failure. It starts to pay for itself when the number of point-to-point connections has become the maintenance problem in its own right.

Talk to someone who has built this

Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.

Book a free consultation

Tell us what you need

No obligation, and nothing is shared outside Geecon Global.

Not sure where to start?

We will use these details only to reply to you. See our privacy policy.

Related

Where this usually connects