UNDERSTANDING PC SOFTWARE’S ROLE IN DISASTER RECOVERY PLAN DEVELOPMENT

By Jim Mannion

THE ANSWER IS: Any organization implementing a disaster recovery plan should select the appropriate techniques and technologies for collection, report generation and maintenance of the requisite information as a part of the plan development process.
WHAT’S THE QUESTION? It should be, "Is relational database technology appropriate for use in development of a disaster recovery plan?"
It is my opinion that the use of a relational database, or any other technique and supporting technology, should be determined by the organization developing the plan, and not be imbedded in the planning product. The reality of Disaster Recovery Plan Development is that:

1. It should be approached as all other projects, remembering that selecting a technical solution prior to developing the project requirements most often fails.
2. It is a process that lacks “glamour” at best, and for most organizations is done to “get it over with” rather than gaining corporate visibility. To this end, the easier the development and maintenance process, the better it is received by those involved.
3. The personnel involved, along with the technology used in the computer center, will change over time. The recovery plan must “survive” these changes, and therefore should be done in a manner that is as independent of them as possible.

The approach that we have taken in the development of our family of disaster recovery planning products for computer center and business unit environments has been to some extent anti-consultant in nature. By that I mean that our plan development methodologies were developed independent of any PC or mainframe software, and focuses on the processes of developing the plan itself. We have made the process as easy to learn and easy to implement as we possibly could to expedite and simplify the development effort. We believe that with the right planning methodology in use, most end users can plan, manage and implement the recovery plan with minimal outside consulting assistance. We suggest that the user of the planning methodology select the best approach for collecting the information in an automated manner AFTER the development process is understood by all involved in the project. While our planning products have PC support modules available, they are separate from the base product and offer the user just one PC-based option to use among other alternatives that we suggest they evaluate.
We chose to separate the disaster recovery plan development methodology from the PC technology for a number of reasons:

1. The only thing clear about PC hardware and software technology is that it is unclear just what the life of any product is in today’s rapidly evolving world. I am not convinced that any one product will fit a majority of user environments, any more than we know what OS/2 Extended will mean to the databases in use today. Certainly the use of an SQL capability, compatible with the mainframe, is most desirable, but hardly here today. We have chosen, for today, not to complicate the disaster recovery plan development process by forcing a product decision at the outset of the project, when better options may evolve as the project progresses.
2. When an organization makes a commitment to integrate a PC software product in the disaster recovery plan, they are making a number of commitments. If the PC product is already in use by many people in the organization, there is a shorter learning curve as the plan itself becomes one more application. However, that is seldom the case. When a PC product is integral to developing, maintaining, and possibly using the plan, the organization must have a number of people very knowledgeable in the use of the PC product for the disaster recovery application. This requires training, cross-training, and the inevitable problems encountered when software and hardware technology changes.
We recommend that if an organization has already made a commitment to standardizing on a PC database package, that organization should take a hard look at using that product for disaster recovery. With personnel skilled in the applications generating process for most PC database products, the development process of the database structure, screens and reports is not a lengthy process, and leaves the user with a package that can be supported by their own staff. If a PC package is brought in and implemented for disaster recovery only, and if the source code for that application is not available, the end user has created an exposure in the plan development process which for most is unacceptable.

3. People are people, and while some packages have much “gee whiz” about them, reality sets in when the Disaster Recovery Coordinator must get things done. Often the capabilities of a software package are only useful to a proficient programmer, which is not usually a resource to those responsible for the development of the project. Look very carefully beyond the demonstration provided by the salesman and fully understand how the product will work in your environment - i.e. buyer beware!
It is our experience that few of the elements required in the recovery plan benefit from a relational database. Beyond the personnel data (name, address, title, phone number, etc.), not much in the plan really requires the data element management capability of the DBMS. You should understand the actual requirements before committing the entire project to a certain software/hardware solution.

4. Seldom does the end user have the developers of the methodology and/or software available during the project to make customized changes to the recovery plan being developed, and without that ability many organizations must adapt to the software, complicating the development process and compromising the plan’s usability.

In summary, I would reiterate that the best technology available for collecting, reporting, and maintaining a disaster recovery plan is the one selected during the plan development process, after those involved have an understanding of the information and tasks required of them. For most it will be a combination of information already maintained on some automated system(s), possibly in conjunction with some information maintained on a PC. All plans must have some of the information in hardcopy form (contact lists, plan action steps, etc.) for when “the call” comes. At that time you won’t be able to count on the technology to get you started - in reality, it will be information on paper that you will use to initiate the recovery plan. Don’t get tangled up in the technology or you will never get to the real issue - that of having the needed elements in offsite storage and the recovery plan in place, testable and maintainable!

Written by Jim Mannion, M-Plus Consulting Service

This article adapted from Vo. 2, No. 1, p. 52.

Disaster Recovery Worldİ 1999, and Disaster Recovery Journalİ 1999, are copyrighted by Systems Support, Inc. All rights reserved. Reproduction in whole or part is prohibited without the express written permission form Systems Support, Inc.