An emergency plan is a sequence, not a list
A recovery plan that merely lists what has to run again helps little in an emergency. Because nothing starts at once: the application needs the database, which needs the network, which needs power. Why sequence and the critical path decide the real recovery time, and why an estimated RTO rarely holds when it counts.
Most emergency plans answer the question "what has to run again?" properly. The question that trips them up in an emergency is a different one: in what order? Because nothing starts at once. The business application needs its database, the database the network, the network the power supply. A plan that only lists the building blocks but not their dependencies is, in the moment of crisis, a collection of correct parts without assembly instructions.
The recovery time sits in the dependencies
How long a recovery really takes depends not on the sum of all steps but on their longest chain. That is exactly the critical path: the sequence of interdependent sub-steps that cannot be parallelized. Much else can run alongside, but this chain sets the minimum. Whoever estimates their recovery time without this path almost always estimates too optimistically, and notices only when the clock is running for real.
A plan rarely stands on its own
On top of that, recovery plans do not stand in isolation. The plan for the business application assumes that the plan for the base infrastructure is already done. In practice that means one plan becomes a sub-step of another. Whoever does not model this plans each layer for itself and overlooks that the times add up instead of overlapping.
How isidaten computes recovery
Emergency management in isidaten builds recovery plans from sub-steps with durations and dependencies, not as a flat list. Plans can be embedded as a sub-step in other plans, so the base infrastructure comes before the business application. From this the module computes the critical path and the actual recovery time, and an RTO consistency checker shows where this time breaks the specified RTO before reality does. It is rehearsed not first in an emergency but in tabletop exercises with an inject timeline, and whatever surfaces there becomes a measure in the system.
More is shown on the emergency management module page. Where the dependencies between application, system and physical foundation come from is covered by DCIM.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.