A distributed commerce and logistics operation depends on physical infrastructure across many locations. How does business continuity planning differ from IT disaster recovery?

The difference

IT disaster recovery restores systems. Business continuity keeps the business operating, which in a physical-world operation includes scenarios where the systems are fine and the business is not: a warehouse inaccessible, a region's transport disrupted, a partner network unavailable, staff unable to travel.

It also includes the reverse, which is the case most relevant to architecture: the physical operation must continue when the systems are unavailable.

What that requires architecturally

• Offline-capable field applications. A delivery or collection agent with no connectivity must still be able to record what happened, with local persistence and reconciliation on reconnection. This is not an edge case in many geographies; it is the normal case for part of the day.
• A documented manual fallback for every critical process, with the data captured in a form that can be entered later. Paper works, and a business that has never rehearsed the paper process will not manage it during an outage.
• Idempotent reconciliation on reconnection, since the same event will be submitted more than once by an agent who is unsure whether it went through.
• Degraded-mode operation defined in advance: what can proceed on stale data, what must wait, and what authority a local operator has to override.

The conflict-resolution requirement

Offline operation means concurrent edits to the same entity from a device and from the central system, and the resolution cannot be "last writer wins" for anything consequential. A collection recorded offline and a cancellation recorded centrally must produce a defined outcome, which usually means an exception queue and a human decision rather than an automatic merge.

The planning discipline

• Identify the critical processes, not the critical systems, and work backwards to what supports them.
• Set recovery objectives per business capability, not one for the organisation, since applying the strictest everywhere makes continuity unaffordable and therefore untested.
• Rehearse with the people who would actually do it, without privileged shortcuts, because a runbook written by an expert and executed by whoever is available is a different artefact.
• Test the dependencies, since what breaks is usually connectivity, credentials or a third party rather than the primary system.