Systems integration
Business systems integration connects applications, databases, APIs and workflows so information can move reliably between the systems a company uses to operate. In practice that means information is entered once and appears everywhere it is needed — correctly, and without a person in the middle.
Moving data between two systems is the easy part, and it is the part most integration projects mistake for the whole job. When three applications each hold a version of order state, the system also needs a source of truth, synchronisation rules, failure handling, idempotency and reconciliation. The work below is mostly those five things.
What it looks like before it is fixed
Most people do not arrive asking for integration. They arrive with one of these.
The same information gets typed into three systems, by hand, every time.
Two systems report different numbers and meetings are spent deciding which to believe.
Orders are moved between systems by a person copying fields.
Reporting is assembled manually because nothing agrees on the source.
An integration exists but breaks often enough that nobody trusts it.
Staff reconcile between tools as a routine part of the week.
The eight ways integrations fail
These are the failure modes we plan against, in the order they tend to bite. If you are evaluating anyone to do this work — us or otherwise — asking which of these they design for is a faster filter than any proposal. Three of them link to a published account of the real diagnosis.
Nothing owns the field
- Symptom:
- The same customer has a different address in two systems and nobody can say which is right.
- Cause:
- Both systems accept writes to the same field, so the last one to write wins. Nothing is broken, which is why it survives for years.
- What fixes it:
- Decide the system of record per field — not per system — and make every other copy read-only or derived.
The retry is the bug
- Symptom:
- Duplicate orders, duplicate invoices, duplicate emails to a customer.
- Cause:
- A write that is not idempotent, plus a network that occasionally times out after the work succeeded. The sender never learns it worked and sends again.
- What fixes it:
- Give every operation a key the receiver can deduplicate on, so a replay is a no-op instead of a second record.
Success means the call worked, not the work
- Symptom:
- The integration reports green for weeks while data quietly stops arriving.
- Cause:
- The check asserts an HTTP 200, not that a record exists on the other side with the values it should have.
- What fixes it:
- Assert the outcome, not the transport. A sync that cannot state what it wrote is not monitored.
Nothing ever reconciles
- Symptom:
- A customer finds the discrepancy before you do.
- Cause:
- Every individual message succeeded, so no error was ever raised — but the two sides have drifted, and nothing compares them.
- What fixes it:
- Run a periodic comparison of both sides and alert on divergence. Drift is normal; not noticing is the defect.
The integration can do far more than its job
- Symptom:
- A third-party tool takes an action nobody authorised, and the audit trail says it was you.
- Cause:
- The integration authenticates as an administrator because that was the fastest way to make it work, so its blast radius is the whole system.
- What fixes it:
- Scope credentials to the operations the integration actually performs, and log what it did under its own identity.
The record is right and the screen is wrong
- Symptom:
- A customer is looking at something alarming that the underlying data does not say.
- Cause:
- A second component renders a cached or recomputed view of the same information and disagrees with the source.
- What fixes it:
- Find which layer is lying before changing any data. The instinct to correct the record first is how a display bug becomes a data bug.
The transport changed the payload
- Symptom:
- An integration that nobody touched stops working.
- Cause:
- Something between the two systems — a proxy, a CDN, a security layer — rewrote or duplicated a header the receiver validates.
- What fixes it:
- Verify what the receiver actually received, not what the sender believes it sent. The change is often in infrastructure, not code.
The exceptions were left to a person
- Symptom:
- The automation handles most cases and someone still checks a queue every morning.
- Cause:
- The happy path was automated and everything else routes to a human, so the manual work moved rather than reduced.
- What fixes it:
- Design the exception path deliberately: what retries, what waits, what escalates, and what a person genuinely needs to decide.
Buy, then configure, then integrate, then build
In that order, on economics. Custom integration is the third option, not the first, and a recommendation to write code should show why the cheaper ones lose.
A native integration already exists
Use it. It is maintained by someone else and it survives their upgrades. The question worth asking is only whether it covers your exception cases.
A connector platform covers it
Reasonable for low volume and simple mappings. It becomes expensive when the logic grows conditional, when volume is high, or when failures need handling more specific than a retry.
Custom integration
Warranted when the logic is genuinely yours, when the exception path matters, or when reliability requirements exceed what a generic connector will commit to.
Middleware between several systems
Justified once several systems must agree, and one place has to own the rules. Before that it is usually a layer that adds a failure point without removing one.
When you do not need this
The process is not agreed. If two people do the same job differently, integration will encode whichever one we happen to watch. Settle the process first — that is cheaper and it is not our invoice.
The manual step takes minutes a week. Automating it is a project, and a project has to be worth more than the thing it removes.
Sometimes the honest answer is that you own one system too many, and connecting them preserves a problem you could remove instead.
Integration work we have published
De-identified accounts of real diagnoses. Client, vendor, product and industry details are removed, as are any figures belonging to a client.
Integration risk · API access · log forensics
A third-party integration was cancelling paid orders
Read the case →Related
Architecture
Deciding what the system should be, and which one owns the truth, before anything is connected.
Architecture →Automation
Once information moves reliably, the repetitive work built on top of it can stop needing a person.
Automation →What we fix
The operational problems these services are bought to solve, in the terms people actually describe them.
What we fix →Start with what is actually breaking.
The Systems Assessment maps how the work runs today, identifies where information is being re-entered or lost between systems, and comes back with a ranked roadmap. Integration is one possible answer in it, and sometimes it is not the right one.