What Is System Integration and Why Does It Matter?
Most companies do not have a software shortage. They have four systems that each hold part of the truth and a person quietly employed to keep them in agreement. System integration is the work of removing that person from the middle.
Published
System integration means connecting separate applications so they exchange data automatically and behave, from the outside, like one system. The e-commerce platform tells the ERP about a new order. The ERP tells the warehouse system to pick it. The warehouse system tells the customer it has shipped. Nobody types anything twice.
The cost of not integrating
Disconnected systems produce four costs, and only the first is visible.
The obvious one is labour: time spent copying data between screens. It is easy to estimate and usually larger than expected once you count every occurrence across the week.
The second is error. Manual transcription has a real error rate, and errors in operational data are expensive — a wrong quantity on a delivery, a wrong price on an invoice, an order that never reaches the warehouse.
The third is delay. If orders are transferred once a day, then for most of the day your fulfilment system does not know about orders that exist. Every decision made in that window is made on stale information.
The fourth is disagreement, and it is the most corrosive. When two systems hold different stock figures, staff learn which one to trust for which purpose, and that knowledge becomes tribal. New employees get it wrong for months. Reports become debatable. Eventually people stop trusting all of the numbers, which quietly removes the value of having systems at all.
What integration work actually involves
The technical connection is rarely the hard part. Three other things are.
Deciding the system of record
For every piece of data, one system must be authoritative. Which system owns the customer credit limit? Which one owns the product price? Without this decision, integrations create loops where each system overwrites the other and the last write wins arbitrarily.
Mapping the fields
Your storefront calls it a SKU. Your ERP calls it an item code, in a different format, with a check digit. Your warehouse system has three variants because duplicates were created years ago. Mapping is the unglamorous work of reconciling these, and it is where most integration projects actually spend their time. It is also where data quality problems surface — usually to everyone’s surprise.
Deciding what happens when it fails
Networks drop. APIs rate-limit. A file arrives malformed. An integration without a defined failure behaviour will eventually create a duplicate invoice or lose a shipment, and it will do so silently. This is the difference between an integration that works in a demo and one that can be relied on for years.
The main integration methods
| Method | Best for | Watch out for |
|---|---|---|
| REST / GraphQL API | Modern systems, near real-time exchange | Rate limits, authentication expiry, version changes |
| Webhooks | Reacting immediately to events | Missed deliveries — always pair with a reconciliation sweep |
| Direct database | Legacy systems with no API | Bypasses business rules; read-only where possible |
| SFTP file exchange | Partners, banks, government systems | Fixed formats, timing windows, partial files |
| CSV / Excel import | Low volume, occasional exchange | Manual step remains; format drift over time |
| Message queue | High volume, bursty traffic | More infrastructure to run and monitor |
A common and reasonable pattern combines two: webhooks for immediacy, plus a scheduled reconciliation that catches anything the webhook missed. Immediacy and completeness are different properties, and serious integrations need both.
Does it need to be real-time?
Less often than people assume, and real-time is meaningfully more expensive to build and operate.
Stock availability shown to a customer at checkout should be current. An order acknowledgement should be immediate. But accounting postings, costing updates and management reporting are perfectly well served by a sync every fifteen minutes, or overnight. Deciding this per data flow, rather than for the whole project, often removes a large share of the cost.
What a well-built integration includes
- A written mapping specification — every field, its format, and what happens when it is missing
- Idempotent writes, so a retry cannot create a duplicate record
- Retry with backoff for transient failures, and a dead-letter queue for the rest
- Validation before writing, with unmappable records held and reported rather than guessed at
- A searchable log of what moved, when, and what it contained
- Alerting to a named person when a flow stops or an error rate rises
- A reconciliation report proving both sides agree
Where to start
Take the pair of systems between which the most re-typing happens, and integrate one direction of one entity — orders in, or invoices out. Prove it, watch it for a month, then extend. Integration programmes that attempt every flow at once tend to discover their data quality problems all at the same time, which is not the moment you want to find them.