Integration & Orchestration
Make the systems you already own behave like one system — without replacing them, and without another decade of point-to-point scripts.
What enterprise systems integration is
Enterprise systems integration is the practice of connecting separate business systems — ERP, CRM, finance, warehouse, HR, customer-facing applications — so that data and events move between them automatically, in a defined format, without a person copying anything. Modern integration does this through an event-driven architecture and an API layer rather than direct database access or file transfers, so each system can change internally without breaking the others.
The legacy middleware problem
Most organisations reach us with one of two architectures, and both fail the same way.
The first is point-to-point. Every system talks directly to every other system it needs, through a script, a scheduled export, a database link or a vendor connector. It works for the first three systems. At ten systems there are up to forty-five possible connections, nobody has a complete inventory of which ones exist, and the person who wrote half of them has left. Any change is a risk because no one can say with confidence what depends on the thing being changed.
The second is a central enterprise service bus bought in the 2010s. The topology is cleaner, but the bus becomes a bottleneck: routing logic and business rules accumulate inside proprietary configuration, the licence renews at a number nobody can justify, changes queue behind a single integration team, and the vendor's roadmap sets your pace. When the bus is down, everything is down.
Both architectures fail because they couple systems to each other. The fix is to couple systems to events instead — a durable record of what happened, which any system can consume without the publisher knowing or caring who is listening.
Point-to-point and ESB versus event-driven integration
| Dimension | Point-to-point / legacy ESB | Event-driven architecture |
|---|---|---|
| Coupling | Systems know about each other; a change ripples outward | Systems publish and subscribe to events; publishers do not know consumers |
| Adding a system | A new connector per existing system it must reach | One subscription to the events it needs |
| Failure behaviour | A downstream outage blocks or loses the message | Events are durable and replayable; consumers catch up when they return |
| Auditability | State is reconstructed from logs, if they exist | The event log is the audit trail, with ordering and retention |
| Change control | Changes queue behind one integration team | Teams own their own consumers against a published contract |
| Cost shape | Licence renewal plus per-connector build | Infrastructure plus schema governance |
Event-driven architecture with Apache Kafka
We build the integration backbone on Apache Kafka. Systems publish domain events — an order was placed, a payment cleared, a customer record changed — to durable, ordered topics. Anything that needs to react subscribes. The publisher does not know what consumes its events, which is precisely what allows you to add a data warehouse, a reporting tool or a new customer-facing application later without touching the system of record.
Three properties make this worth the migration. Events are durable, so a consumer that is offline for two hours processes the backlog rather than losing it. Events are replayable, so a new system can be built against the last twelve months of history instead of waiting for fresh data to accumulate. And events are ordered per key, so a sequence of changes to the same record arrives in the order it happened — the failure mode that quietly corrupts data in batch-file integrations.
The work is mostly design, not plumbing. We define the domain events, the schema for each, the compatibility rules for changing them, and the ownership of each topic. Getting that right is what stops the event log becoming the next unmaintainable mess.
The AI-powered integration layer
Once events flow through a single backbone, two capabilities become practical that are not worth building over point-to-point links.
Predictive data routing. The integration layer learns the normal shape of traffic — which events arrive when, in what volume, in what sequence — and routes or prioritises accordingly. Reconciliation events that always precede month-end close can be given headroom before finance asks for it, and an unusual spike can be shed to a slower path rather than taking a downstream system with it.
Automated compliance monitoring. Every event crossing the backbone is inspectable. Rules run continuously: personal information leaving a defined boundary, a record changing outside an approved process, a transaction pattern that matches a fraud signature, a data-retention window elapsing. Under POPIA the ability to demonstrate what happened to personal information — not merely assert it — is a control worth having, and an event log makes it a query rather than a project.
Data and analytics. The same backbone is what makes business intelligence tractable. Rather than each report reaching into a production database on its own schedule, analytics consumes the event stream, which means one definition of what "an order" is and no reporting load on operational systems.
iPaaS orchestration with MuleSoft and Workato
Events move data. Orchestration decides what a business process does with it, in what order, with what approvals, and what happens when a step fails. For that layer we work with integration platform-as-a-service tools — MuleSoft and Workato most often — rather than writing every workflow as bespoke code.
The reason is ownership. A process that lives in an iPaaS recipe can be read, audited and frequently changed by an analyst who understands the business rule, rather than queuing behind an engineering sprint. Approvals, retries, error queues, human-in-the-loop steps and connector maintenance come with the platform.
We are deliberately not a single-vendor shop. Which platform fits depends on the estate: MuleSoft where API management and governance across a large estate is the primary concern, Workato where business-user automation and breadth of SaaS connectors matter more, and custom services where a workload is high-volume, latency-sensitive or too specific to justify licence cost. Part of the assessment is telling you which of the three a given process belongs in — including the cases where the honest answer is that you do not need a platform at all.
API-led integration
Between the event backbone and the orchestration layer sits an API layer, designed in three tiers: system APIs that expose each underlying platform in a stable form, process APIs that compose them into business capabilities, and experience APIs shaped for a specific consumer such as a mobile app or a partner portal. This is the API-led pattern, and its value is that changing an underlying system means rewriting one system API rather than every consumer that touched it.
How we deliver
Integration work fails more often on sequencing than on technology. The order below is deliberate: understand the estate before designing events, prove one process in production before migrating the rest, and hand over ownership before the engagement ends rather than after it.
How an integration engagement runs
-
1
Architecture assessment (2–3 weeks)
We inventory the systems, the integrations that already exist — including the undocumented ones — the data that moves, and the manual work filling the gaps. Output: a current-state diagram, a target architecture, and the integration points ranked by the cost they carry today.
-
2
Event and contract design
We define the domain events, their schemas, compatibility rules and topic ownership before any code is written. This is the step most often skipped, and skipping it is why event backbones become as unmaintainable as the point-to-point mess they replaced.
-
3
First slice to production
One real business process goes live end to end, with monitoring and rollback. A narrow slice in production tells you more about your estate than a six-month design phase, and it gives the business something to judge before committing further.
-
4
Strangler migration
Existing integrations move onto the backbone one at a time, each with the old path still available until the new one has run clean through a full business cycle. Nothing is switched off on a date; things are switched off when their replacement has proven itself.
-
5
Orchestration and self-service
Business processes move into the iPaaS layer, with the people who own each process trained to change their own workflows. The measure of success is that your team stops needing us for routine changes.
-
6
Handover and operation
Runbooks, schema registry, monitoring dashboards and on-call procedure transfer to your team, or we operate the backbone under an agreed service level. Both are available; neither is assumed.
Integration questions
- When should we replace an enterprise service bus with event-driven architecture?
- When change is queuing. The technical signals are a licence renewal you cannot justify, routing and business logic that only lives in vendor configuration, and an integration team that has become a bottleneck for every other team. The commercial signal is simpler: if adding a system takes months rather than weeks, the bus is costing more than it saves. Migration is incremental — the bus keeps running while processes move off it one at a time.
- Do you use MuleSoft, Workato, or build custom integrations?
- All three, chosen per workload. MuleSoft where API management and governance across a large estate is the priority. Workato where business-user automation and SaaS connector breadth matter more. Custom services where volume, latency or specificity make licence cost indefensible. Deciding which is part of the assessment, and we will tell you when the answer is that no platform is needed.
- How long before the first integration is live in production?
- The architecture assessment runs two to three weeks. A first production slice — one real business process, monitored, with rollback — typically follows within four to eight weeks of the assessment, depending on how much access to source systems is available and how clean their data is. Full migration off an existing bus is measured in quarters, and runs alongside the old path rather than replacing it on a date.
- How do you handle POPIA and data residency in an integration?
- Personal information is classified during event design, not after. Events carrying personal data are marked, their consumers are enumerated, retention windows are set per topic, and rules run continuously to flag personal information crossing a boundary it should not. Where residency is required, the backbone and its storage are deployed in-region. The event log doubles as the evidence a regulator or auditor asks for.
- What happens to the integrations we already have?
- They keep running. Migration follows the strangler pattern: each existing integration moves to the backbone individually, with the old path live until the new one has completed a full business cycle without variance. Undocumented integrations are inventoried during the assessment, which is frequently the first complete list an organisation has had.
- Can our own developers work on the integration layer?
- Yes, and that is the intended end state. Topic ownership, schema governance and consumer development are designed to be handed to the teams that own each domain. We run the first slices, pair through the next, and hand over runbooks, the schema registry and monitoring. Retaining us for operations afterwards is an option, not a dependency.
Book an integration assessment
Two to three weeks, ending in a current-state diagram, a target architecture and a ranked list of the integration points costing you the most.
Start the assessment