Business continuity plans continue to often be domiciled in the IT organization.
They also continue, far too often, to focus around the “critical systems”.
What this boils down to, of course, is money. Which business areas think it’s worth taking out the equivalent of an insurance policy on a disaster of some sort interrupting work?
We need to change the terms of the discussion. “Critical system recovery” is a good way to fail — and, in a real emergency, take the enterprise with you.
Focusing on the information needs of the enterprise as it continues its operations under any circumstances is a much better way to come at this.
For instance, in 2012, the enterprise’s email system is an essential. Not only that, it needs to be available from any work location that may be used (most workplace continuity plans call for a sudden shift to telecommuting, or the use of many remote facilities, or the rapid acquisition and outfitting of the necessary office space).
I’d closely couple the enterprise content management system, document management system, and shared storage areas to that list. All are constantly in use; all are filled with information that will be needed in an emergency.
Yes, like email that’s been stored, Sturgeon’s Law is in full effect (90% of it is crud). The problem is knowing where the gems are — and if you depend on people anticipating what will be critical and storing it in a “known location”, things that are needed will fail to be stored there. It only takes, after all, one omission, one situation where someone looks at an innocuous item and fails to see that five years from now in an emergency the seventeenth line contains a critical bit of insight that will be needed then.
Notice I haven’t said “go to the cloud” with these. That’s a decision that your plan should bring forward — or its alternate, how you recover from in-house operations —, not an assumption that you’d make.
Then, of course, the typical portfolio today contains many shared systems, which means their data stores are a mix of “critical” and “non-critical” items. (Same story here about assumptions.)
I’ve seen organizations whose plans for recovery talked about sawing a package like SAP apart during the recovery cycle at a remote recovery facility they’d contracted to use if things went pear-shaped, because they didn’t want to pay for enough capacity to cover their full installation.
There’s a plan that will fail to bring the enterprise back to life. It’s hard enough to get a good recovery when you have a “everything gets backed up every day; everything gets restored just in case” approach: with quarterly recovery tests and 72 hour test windows it can be rare to get one good test a year (good is defined as “we executed the plan and we didn’t have to deviate from it by more than 10%”).
True business continuity planning assumes that you’ll have to deal with a diversity of conditions far beyond your normal “planned” office life — that you’ll be breaking and reforming processes — that the critical and the mundane are always intermixed — and that the decision to continue operations is as much an overhead on every part of the enterprise as is corporate legal, corporate HR, or corporate finance.
In that kind of world, IT recovers everything — and positions information where working with it is most easily done, however it has to be done. The idea of the “critical system” fades into history, where it belongs.
After all, if you can do without it, potentially forever, if an emergency comes — it’s not needed today.