Disaster Recovery Journal- Volume 19, Issue 4 - Fall 2006 Issue -Business Continuity vs Protecting Data

Business Continuity vs Protecting Data

By JOHN GLENN, MBCI

Business continuity is, if we are honest, the child of disaster recovery.
Some people use the terms interchangeably.
They should not.
Disaster recovery, which I consider a “sub-set” of business continuity along with business continuation, conjures up a “restore the computer room” image that I believe is detrimental to the organization.
By this scrivener, focusing on the data center exposes the reasons the data center exists to all manner of risks.
Consider this: in most instances, an organization’s data center is overhead. Information technology usually is not the reason an organization was created.
Information technology is a critical part of the operation.
Information technology, properly used, brings economies and efficiencies which today can be obtained from no other source.
But information technology is “only” a resource for the business function.
We know this is true because all of our business continuity plans include “work arounds” for the times when technology is unavailable.
A “more critical” resource might be the facility. It’s harder to “work around” the absence of a facility than to “work around” the absence of a data center; it is easier to find paper and pencil than it is to pitch a tent.

Narrow Focus Plans
Business continuity plans that focus on only one segment of an organization must be, by their very nature, incomplete plans.
A technology-driven plan typically is concerned only with meeting technology’s service level agreements (SLAs). In a worst-case scenario, and I suspect a “most-case” scenario, the planner has little, if any, idea what the business units really need from the technology operation or the priority of the technological resources.
On the other side of the coin, a plan which begins and ends with the business unit likewise has short-comings.
Risks to the business unit will – at least should – be uncovered in the business impact analysis, but the discovered risks are little more than finger-pointing exercises.

“If technology fails, we can’t meet our SLAs.”
“If the facility can’t be used, where do we go?”
“If the mail room is locked, how do we get our orders/checks/whatever?”

The answer for the business unit planner is, “That’s their (technology, facility, mail room) problem. We identified a risk to our (business) function, but we can’t tell ‘those guys’ what to do.”
By the way, if you think the mail room is less than a critical part of the business, ask the folks who depend upon it – start with the board room. (In the world of Sarbanes-Oxley, it turns out the mail room can be a critical control point.)
For the record, I have worked on both business-unit-only and technology-specific plans. Communication between functions suffers with “focused” plans.
Do technology gurus really know what the business units need? Do they understand and work with business units to identify needs versus wants or do they, as one former manager believed, “have to work with what we (technology) give them?”
To be fair, the business side often has little or no conception of what goes on behind the doors guarding the servers. The accountants need XYZ software up and running to do their job; never mind that three other programs have to be functioning in order to run XYZ, and in any case, there really are higher priority functions.

Enterprise Plan to the Rescue
In military language, both the business units and the support units – technology, facilities, mail room, human resources, finance, and all others required for an organization to effectively function – look at their roles on a tactical level.
Senior management, the few at the VP level and above, should have a strategic view which has as its bottom line the bottom line. About the only other person privy to this view is the enterprise business continuity planner.
The enterprise business continuity planner needs carte blanc authority (not merely “permission”) to look at every business function’s processes and to follow the trails wherever they lead.
For example, while it is a “given” information technology will impact almost all business functions, the flow of information from one group to another may be overlooked, especially if it is not electronic.
The enterprise business continuity planner is mandated to follow a process from its inception to its completion. That road may have the planner crossing several business unit boundaries while encountering support activities all along the way.

Consider the processes involved in ordering a widget:

Client contacts sales.
Sales checks inventory.
Sales takes order.
Sales takes payment.
Order is sent to order entry.
Payment is sent to accounts receivable.
Order entry tells shipping to ship the widget.
Shipping tells inventory to pull the widget off the shelf and stage it for shipping.
Inventory decrements its inventory for widgets.
Inventory alerts production that the widget inventory has been reduced.
Production schedules a widget run.
Production tells materials to order product from vendors.

And that’s just the beginning. The Widget Wizard Works still has to receive and pay for the raw materials, make the product, get it on the shelf and into inventory, and ...
Most of the processes require support from a number of resources in addition to the one most frequently associated with disaster recovery.
Business continuity plans cannot be created in a vacuum. Business continuity plans should not be vacuum plans.
The difference? Business continuity planners need guidance from organization subject matter experts (SMEs) and their own SME network. I have never met a planner who could create a plan without leaving his or her office. Planning in a vacuum always overlooks something.
Vacuum plans are, by my definition, plans focused on one area of interest (ie. key business units, facilities, information technology, etc.).

On the Other Hand
Having, I hope, made the case that the enterprise plan is the only plan which can really protect the organization, I will suggest that the enterprise plan really is not one plan but many plans “rolled up” into the umbrella I call the enterprise.
Each unique business unit and support group needs an independent plan, a plan which will let its personnel respond to “local” events before they become “global” events.
Some “local event” examples include a leaking pipe, which can lead to flooding, which can lead to structural damage, which can lead to facility evacuation. It’s like the “finger in the dike” tale many of us learned in our childhood.
As long as facilities can fix the leak before the flood, the event is limited to facilities. Once the event extends beyond minor flooding, the enterprise plan is invoked.
The same holds true for information technology. A bad board in a server could cause the local plan to be invoked, but as long as information technology has the ability to troubleshoot the problem, the documentation to eliminate the problem, a known-good spare part, and the tools to swap parts, the event may be kept behind the closed doors.
However, if the problem prevents information technology from meeting its SLAs then the enterprise plan must be invoked.

It’s in the Name
We, planners, have changed the name of what we do from disaster recovery to business continuity. Now we must change the focus of what we do from “restore the computers” to reflect the new name: business continuity.
There is nothing wrong with disaster recovery; it remains an integral part of business continuity. But disaster recovery is only one part of a true business continuity plan, and, I contend, only an enterprise plan is a true business continuity plan.

John Glenn, MBCI, has been helping organizations of all types avoid or mitigate risks to their operations since 1994. Comments about this article, or others at http://JohnGlennMBCI.com, may be sent to JGlennCRP@yahoo.com

«BACK to the Articles Index