They have purchased extremely expensive systems, dedicated almost wholly to the securing of data, without paying...
attention to the development of the operational and procedural processes that are required to effectively implement them. Again, when it comes to disaster recovery, data is only one aspect of the entire business continuity framework.
First, once the demands of the business have been identified, the technical requirements for the design of a disaster recovery environment should be formulated. Whilst the former may well be unfeasible and wholly unrealistic, the negotiation between what is desired and what is technically achievable is best arrived at through commercial attrition. In this manner the business is both enlightened and forced to establish the operational criteria for business continuance after a catastrophic event.
It is then the IT division's responsibility to deliver it. This approach avoids the implementation of a technical solution that is over- or underscoped. In arriving at a practicable set of requirements informed by the business, technicians are able to implement an environment that is neither wasteful nor inadequate. In this manner, the first mistake of the Emperor – accepting information from a fundamentally flawed source -- is avoided.
The technical teams that would be required to deliver, activate and maintain the environment in the event of a disaster are often disparate groups in large enterprise organisations who find it difficult to communicate effectively during normal operations, let alone in the conditions that would follow a catastrophe. Yet little focus is placed on formulating procedures related to how personnel should behave when a disaster scenario is declared. This ranges from how they should make their way to the alternate site(s) to how they should communicate with their colleagues and the order in which they should implement their respective tasks. Each technical team often has its own set of documentation that exists in isolation.
A framework for business continuity should consolidate and standardise this heterogeneous set of material and bind it with a set of procedures. A working group with representatives from each area (technical as well as non-technical) can help to ensure that a holistic view is developed. Also, this group will greatly assist in forming a timeline of the chronological activities that the organisation should undertake after a disaster.
This framework is also imperative for the fabrication of effective disaster test plans. During testing, technical teams often make assumptions regarding conditions subsequent to a catastrophic failure. For example, the erroneous supposition that access to specific systems is ensured, when they have in fact perished in the disaster. A procedural framework forged through the mutual endeavour of all concerned stakeholders will prevent this.
In this manner the Emperor remains clothed.
About the author: Atiek Arian is a is a senior consultant at Glasshouse Technologies (UK), a global provider of IT infrastructure services, with eight years experience in IT systems, storage, disaster recovery and high availability. He has significant experience in architecture, implementation and operational support within complex enterprise environments with a primary focus on technical and procedural best practice. Previously, he was a senior SAN, storage and Unix specialist at Centrica Information Systems. Atiek has a degree in Law from the London School of Economics and Political Science.