We derive the order of disaster recovery from the dependency graph of your systems, so that what is restored first is what everything else needs, and the plan is as current as the model it is read from.
Runbooks written for the estate of last year
A recovery runbook is a list of steps in an order somebody worked out. It is correct on the day it is written. Every subsequent change to the estate that adds a dependency, moves a database or introduces a new identity service makes it a little less correct, silently, until the day it is needed.
The order is in the graph
If the dependency graph is maintained, the recovery order is a property of it: a topological order over the “depends on” edges, starting from the components with no dependencies of their own. We compute the order from the graph at the moment of recovery, and the plan cannot be stale, because it was not stored.
Orchestration, not instruction
We drive the recovery from that order automatically where the platform allows and present it as a checklist where it does not. Each step records its completion in the model, so the state of the recovery is visible to everyone working it, and a step that fails is reported against the component it concerns, with what depends on it listed.
Recovery objectives as model properties
Each component carries its recovery time and recovery point objectives as properties in the model, and the graph makes the consequences visible: a component with a strict objective that depends on one with a loose objective is a finding, before any disaster tests it. Your resilience is then designed in, and measured against the business capabilities the components serve.
