.svg)
What a disaster recovery plan usually leaves out
Recovery planning follows the shape of a company's asset register. Servers, databases, applications, and network links all appear on a list, each with an owner and a recovery target. Integrations rarely appear on that list, because nobody bought them as a thing.
A point-to-point connection between an ERP and a warehouse system is a script on a server somewhere, or a scheduled job in a system nobody owns outright. It has no license, no vendor, and often no documentation. When the recovery plan was written, it was not visible enough to include.
The gap shows up as four questions nobody can answer during an incident:
- What was in flight: which orders, shipments, or production instructions had left one system and not arrived at the other when the connection stopped
- Whether anything was lost: whether those records are queued somewhere waiting, or whether they are simply gone
- Who restarts it: which team owns the connection, as opposed to owning the two systems at either end
- What order to restart in: whether the ERP has to be healthy before the warehouse feed resumes, or the reverse
Each of those is answerable in advance. None of them is answerable during an outage if nobody wrote it down, which is why the first hour of an integration incident is usually spent on discovery rather than recovery.
Why do integration failures go unnoticed?
A failed server announces itself. Users cannot log in, dashboards go red, and someone is paged within minutes. A failed integration is quieter, because every system it connects is still running normally.
The storefront still takes orders. The ERP still shows yesterday's stock. The warehouse still picks what it was told to pick an hour ago. Nothing is broken from any single system's point of view, and nothing will be until the data gap grows large enough for a person to notice it.
That is why integration failures are usually reported by customers rather than by monitoring. A buyer asks where their order is, and somebody discovers that the order flow stopped at 02:00. Detecting it earlier is the job of monitoring and logging, which is a different discipline from recovering once the failure is known.
What an hour of integration downtime costs
The cost of integration downtime is not proportional to its length. It is proportional to how much the business depends on the flow and how long the failure goes undetected:
- A production line waiting for work: an MES with no new orders because the ERP connection stopped, and a shift paid for while it waits
- Orders taken against stock that is not there: a storefront selling for four hours against the last figure it received
- Shipments that never reach the carrier: dispatch instructions queued in a system nobody is watching, found the next morning
- Duplicate records after the restart: a flow restarted without knowing what already went through, creating a second copy of every order in the gap
- Reconciliation that takes days: finance comparing two systems by hand to find what moved and what did not
The fourth one is the expensive surprise. Restarting a connection is easy. Restarting it without duplicating or skipping what was in flight requires knowing exactly where it stopped, and most point-to-point connections do not record that.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
