Application Integration
Application integration connects systems so that data moves between them reliably, including when something fails. The integrations that break in production are rarely wrong about the happy path; they are missing the retry, the duplicate check or the owner of the error queue.
Designing for the day it fails
Every integration works in testing. What separates a dependable one is what happens when the target system is down, when a message arrives twice, when a field arrives empty that has never been empty before, and when nobody notices for four days.
So the design work is mostly about failure. Is the operation idempotent, so a retry is safe? Where do messages go when they cannot be processed, and who watches that queue? What is the reconciliation position when two systems disagree about the same record?
The other half is inventory. Most estates cannot produce a list of their interfaces with volumes and owners, and an integration programme that starts without one is guessing at its own scope.
What an integration engagement covers
Six workstreams. The first and the fourth are where the value is.
Interface inventory
Every interface catalogued with source, target, volume, frequency, trigger and a named owner on both sides — which frequently reveals interfaces nobody knew were running.
Contract-first design
API and message contracts agreed before implementation, with schema versioning decided up front so a later change does not require both sides to deploy simultaneously.
Failure handling
Idempotency, retry with backoff, dead-letter queues and poison-message handling specified per interface rather than left to whatever the framework does by default.
Reconciliation
A defined position on how disagreement between two systems is detected and resolved, because eventual consistency without reconciliation is just undetected divergence.
Monitoring and alerting
Per-interface monitoring with a named owner and a response expectation, so a stalled queue produces a person rather than a dashboard nobody opens.
Runbook
Documentation of every failure mode designed for, with the operational response to each — written for whoever is on call at the time.
How an integration engagement runs
Inventory
Interfaces catalogued with volumes, triggers and owners, and the ones nobody can account for flagged for a decision.
Design contracts
Message and API contracts agreed with both sides, including versioning, so implementations can proceed independently.
Design the failures
Idempotency, retries, dead-letter handling and reconciliation specified per interface before code is written.
Build and prove
Implementation with failure paths tested deliberately — target down, duplicate delivery, malformed payload — not only the happy path.
Instrument and hand over
Monitoring wired with named owners, and a runbook covering each designed failure mode.
Integration approaches compared
Choosing between point-to-point, a middleware layer and a platform.
| Dimension | Point-to-point | Middleware layer | SAP CPI / BTP |
|---|---|---|---|
| Right at | Under about 10 interfaces | 20 interfaces upward | SAP-centric estates |
| Initial cost | Low | Moderate to high | Moderate |
| Cost per new interface | Rises | Falls | Falls |
| Visibility | Poor | Central | Central |
| Operational burden | Spread across teams | One team | One team |
| Wrong when | Interface count grows | Interface count is small | The estate is not SAP-centric |
What we will say plainly
Six interfaces do not need an integration platform. The arithmetic favours point-to-point until the interface count and the cost of poor visibility justify a central layer, and we will show that arithmetic rather than recommending the platform because it is a larger engagement.
Integration also cannot resolve a data ownership dispute. Where two systems both consider themselves the system of record for the same field, no amount of synchronisation logic fixes it — it distributes the conflict faster. That decision has to be made by the business, and we will stop and ask for it rather than encoding a guess.
- Design the failure cases first; the happy path is the easy part.
- You cannot scope an integration programme without an interface inventory.
- Idempotency and dead-letter ownership matter more than transport choice.
- Point-to-point until the arithmetic says otherwise, and we will show the arithmetic.
Questions buyers ask about this
Point-to-point or a middleware layer?
Decided on interface count, message volume, and who will operate it. Under roughly ten interfaces, point-to-point is usually cheaper and simpler. Beyond twenty, the lack of central visibility becomes the dominant cost. We will show you the arithmetic for your estate rather than asserting a preference.
What about SAP integration specifically?
We cover SAP Integration Suite and CPI, BTP-based integration, IDoc and OData routes, and direct RFC where appropriate. The route is chosen on your landscape and your team’s ability to operate it, not on our familiarity with a particular one.
How do you handle duplicate messages?
By making operations idempotent wherever possible, so that processing the same message twice produces the same result as processing it once. Where idempotency is genuinely impossible, deduplication with a defined window and a reconciliation check. Retry logic without one of those two is how duplicate orders get created.
Who watches the error queues?
A named person on your side, with monitoring and alerting configured to reach them and a response expectation agreed. Unowned dead-letter queues are the most common cause of an integration failing silently for days, and no technical design compensates for it.
Can you document integrations we already have?
Yes, and it is often the most valuable first engagement. The inventory alone usually surfaces interfaces nobody could account for, unowned error queues, and at least one job whose failure nobody would notice.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.