The White Space between Business Continuity Planning And Technology Decision Making
During the e-commerce boom of the 1990's, the IT vendor message related 'high availability for critical web services' to just about every type of product available. By the time the e-commerce boom imploded in the frame of 'a web year', the technology industry scrambled to re-brand, re-tool, and re-hype the product lineup for the next major industry buzz. After the tragic events of 2001, the passé 'high availability' message was quickly reframed as 'business continuance'. We are now assured that these 'high availability' IT products, including networks components, servers, systems management software, disk storage, & backup software now provide business continuance. In addition to this, we are now bombarded by best practices, methodologies, and master techniques from vendors, old and new, who have supposed expert knowledge in the discipline of business continuity. This article will seek to identify the logical flow of technology decision making for disaster recovery, versus the technology vendor tendency to follow a backward process of mapping technology gadgetry to perceived business continuity goals.
In an ideal world, an organization identifies business continuance goals, risk, and priorities, based on a formal business continuity-planning program (subsets of which include Business Impact Analysis (BIA) and Disaster Recovery Planning (DRP)). The business continuance requirements are then mapped to technology infrastructure decisions and deployments to insure the availability and recoverability of critical and non-critical application services. The recovery plans merge technology processes with recovery processes for a seamless and well-run disaster recovery operation. In fact, the plans would be so well built; they provide general-purpose support for any type of unplanned production downtime.
But in reality, most organizations are faced with budgetary constraints, existing infrastructure, complex decision making processes, and a good deal of white space between business continuity goals and technology management directives. Vendors of all types have capitalized in this space, by helping to identify both business continuance needs and technology solutions to enhance system availability. So as soon as the vendor has rallied management, corralled financial management into believing this is the only feasible way to protect the business (essentially convincing financial management to make an IT decision), the decision to buy is made, in many cases by people who have limited knowledge of business continuity planning or technology.
A product driven business continuance solution does nothing to validate actual business requirements for continuity. Loosing data is frightening, but so is establishing a false sense of security in a vendor's roadmap for strategic technology planning. The 'enlightenment process' places technology choices ahead of business goals. In fact, following this path can lead an organization into a product centric and sometimes problematic path for meeting naturally evolving business continuity requirements. Logically, no organization would implement a new technology to meet business continuance goals, which are being defined only by the vendor selling a specialized product.
One of the most incredible cases of the 'enlightenment process' was when a disk manufacturer presented a business continuance proposal for a mission critical application environment. Geared perfectly for a non-technical audience, the proposal went into great detail about the cost of downtime, outlying risks, and why the proposed technologies provided the only solution: mirror data three times onsite, and replicate data to a hot-site. This is the only way to maintain continuity of operations according to a disk vendor, but in a data center that relies on people, process, network infrastructure, application processes, and systems infrastructure, disk is only one piece of the continuity puzzle. The unsettling part of the solution was that the vendor had no quantifiable data to justify the terabytes of disk proposed, no network information, very little platform or application information, and drove the proposal purely from an emotional point of view. And the amazing part is that the proposal was slated for the financial decision makers of the business.
Unless the vendor architect is defining detailed disaster recovery procedures and has performed business impact analysis studies for the organization, the justifying information is likely to be based on broad-stroke emotionally driven data. Bear in mind, the same procedure leads companies into poorly planned and non-strategic infrastructure decisions for business continuity.
The logical process follows the exact opposite procedure: define business continuity objectives first, and select technologies to meet near/long term goals second. Otherwise, you can bet that if a disk vendor is performing a BCP study, the only viable solution to meet the BCP needs will be a disk centric solution. The same will apply to disaster recovery collocation vendors, tape vendors, software vendors, networking vendors, and any other vendor touting 'business continuance' as part of a pre-sales technology product pitch.
Current infrastructure and new technologies can most certainly be used to meet business continuity goals, but the first step to establish this connection, and to eliminate the white space, is to formalize a business continuity planning process, wherein critical systems and processes are identified. Otherwise, the end result will be a perpetual acquisition of products that meet vendor defined business continuance goals, as opposed to your own.
John Merryman Boston, MA October 25, 2002