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.
Map the estate
Document what actually connects to what, which is frequently the first time anyone has had the full picture.
Decide the pattern
Establish whether a shared layer is warranted, and which pattern fits the traffic you actually have.
Migrate a slice
Move a handful of integrations first and prove the approach before committing the estate to it.
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.
The label has fallen out of fashion; the problem has not. Modern equivalents are event brokers and integration platforms, and the underlying question is the same: do you want a shared, monitored layer or a growing set of direct connections?
Longer if attempted as one programme, which is why we would rather migrate a slice first. Moving remaining integrations as they need changing anyway avoids rewriting connections that work perfectly well.
An agreed definition of what a customer or an order means across the estate, so each system maps to one shared shape rather than to every other system. It is the hardest part because it is a business agreement rather than a technical one, and it is where most of the long-term benefit sits.
It becomes a single point of failure, which is the honest cost of centralising. That is why resilience, queuing and failover matter more here than in a point-to-point arrangement, and why a bus is not free once you account for running it.
Usually. Adapters can front systems with no modern interface, using file drops, database views or vendor connectors, which also means the old system can be replaced later without touching everything that talks to it.
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 consultationRelated
Where this usually connects
- Systems integrationMaking the systems you already own talk to each other.
- APIs and microservicesConnecting platforms that were never designed to be connected.
- Operational systemsThe systems that run the day-to-day work of the business.
- Legacy modernisationFor the system nobody wants to touch but everything depends on.
- Cloud servicesMoving to cloud, or making an existing cloud estate behave.
- Data migrationMoving data between systems without losing its history.