PC Based Software (7)
The increase in client/server computing and distributed systems is causing an explosion in LAN disk capacity. Growing companies typically add 30 to 50% more storage to their networks each year, and newer image-based applications will accelerate this trend.
The cost of storing magnetic data is gaining the network limelight, as is the potential cost of lost data. Organizations without a backup and recovery plan for what may be their most precious asset are susceptible to the ravages of disaster, both natural and man made. Major catastrophes over the past few years like Hurricane Andrew, the Midwest Flood of ‘93, Los Angeles earthquake, and World Trade Center bombing have been front-page reminders that valuable information should be protected.
Concern is usually generated at the highest level of the corporation. The corporate officers of public companies could be held liable if their negligence resulted in data lose that affected profits.
Few sizeable companies are without some kind of data backup and recovery plan. However, there are plans and there are plans. At the weak end of the planning spectrum is the company whose management simply feels that a pinch on staff resources precludes developing and implementing a full-blown program. As a result, this type of company may issue a policy that employees must perform regular backups. But without documentation and accountability, this plan doesn’t have much chance of saving the corporate jewels. The sad fact is that failure of this plan will not be identified until significant data loss occurs.
Unfortunately, this “independent” approach also increases the workload of every employee who is responsible for their own backup. And without an administrator to control the process or be responsible for an ongoing strategy, the backup process is often at risk and backup media is not protected. An employee’s idea of safeguarding backup media could be storage in the trunk of a car or in a closet at home, where it is subject to many other kinds of all-too-familiar disaster.
In the middle of the plan continuum is management that directs a committee comprised of various departments to devise a plan. Documented procedures are essential. The people who devise the plan may not be present when the recovery portion is executed.
Documentation doesn’t guarantee data recovery. Most solutions today entail data backup on site and most are not as automatic as they should be. When deciding on a location for housing data to protect for recovery, companies should not forget that disaster can strike anywhere, including data centers. That’s why a hotsite should be considered. If a hotsite is not a viable alternative, an onsite storage vault should be as secure as possible.
Companies at the strong end of the planning spectrum usually have a network backup and recovery plan with centralized backup ownership and administration. In the past, companies thought that the volumes of backup tapes they created would preserve their data. They learned too late that those piles of tapes couldn’t be read. Therefore, it’s a good idea to verify that tapes are readable. Beyond readability, restoration is the most critical part of the plan. The only way to insure that recovery will work when needed is to test the process.
Tape verifications is one aspect of the “fire drill” approach. In any procedure, practice is essential for insuring that the documented process does what it’s supposed to do and employees have been trained properly. There are various degrees of fire drills, some with warning and some without. But the organization must build its expertise in executing the network backup and recovery plan through practice.
Some organizations are looking for ways to simplify and improve control of network backup and recovery. They want to centralize both planning and administration but support distributed backup using a variety of different backup strategies, systems and media in different parts of the organization. A centralized body develops standards and implements them across the entire organization. A small centralized staff can cost-effectively manage the network backup requirement and restrict the number of qualified products on the market today.
Although standardizing a level of service may simplify initial planning and documentation, a uniform minimum requirement does not address diverse departmental and workgroup needs. A system that can be tailored to different departments within the organization best serves its diverse user.
Custom handling of applications on the client end and backup data on the server end are two areas where versatility of service are important. The concept that a system should offer the flexibility to handle data on PCs within one department differently from PCs in other departments may be expanded to vary data backup from application to application on PCs. A database application may need to be either shut down or placed in a special state prior to backup of the database file. After backup is complete, the application must be restarted. The process should be automated along with the actual backup.
On the server side, it is advantageous for the system to offer customized handling of data backup files. This would allow mounting and dismounting of special media for specific departments or projects.
Consideration should also be given to the amount of flexibility in how the system backs up data, including full and incremental options, when and how frequently it does so, what data may be selected for backup, and options regarding storage media, tape rotation, and storage locations.
A single enterprise network with distributed subnet-networks is likely to include a variety of hardware platforms: VAXs and midrange computers in manufacturing, OS/2 and DOS in administration, Macs and UNIX workstations for various user groups. Add a variety of different departments with varying functions, procedures, and of course backup requirements, and you can begin to see why companies are overwhelmed by the ubiquitous task of developing a backup and recovery plan.
The determination of where to store backup data is a major issue impacted by the physical nature of the organization. Remote locations with lots of data to backup could make the process quite tedious and time consuming if transmitted over a WAN to a centralized managed backup program is an alternative that would eliminate the need for a resource at the remote office to oversee the process, and eliminate the need to move backup data over the WAN. This alternative may come in handy when today’s plan falls short in six months as backup data volume exceeds capacity.
The experts point to a few key criteria that a backup and recovery solution should meet. First of all, it must be an automated, multi-vendor, multi-protocol network backup and recovery solution in order to support a variety of operating systems and platforms (including proprietary and UNIX) that comprise current client systems and adapt to the computing environment as it changes. These factors eliminate quite a few solutions.
Automation is crucial for optimal reliability and efficiency. Automated synthesized backup is the initial backup procedure which entails a complete image copy of all data in the organization. After the original image copy is complete, the system is programmed to automatically produce backup tapes of only the changes made to the imaged data. The original image copy is merged with backups of all changed data sets on a regular basis to recreate an image of the current environment.
The process is likely to take several days or weeks, so the system should offer backup that is interruptible and restartable in order to accommodate daily use of the network. The trade-off to this process is its inability to restore data at any given point in time. For instance, engineering could not restore a CAD drawing to its status as of a particular day to eliminate an error and subsequent unusable data. The drawing as it appeared that day would have to be recreated from scratch.
Another issue for consideration is that network transmission for backup uses alot of bandwidth. An intelligent product can implement more efficient movement using compression. A caution: compression algorithms that run on an average server PC lengthen the backup process by adding compression time to transmission time. However, compression does work if the computers performing the compression are powerful.
Although the requirement may sound trite, ease of use for both users restoring data and for network backup and recovery administrators is imperative. The system cannot live by a point-and-click graphical interface alone. The system must be easy to instal, administer and monitor through comprehensive reporting. It must define concrete parameters--the who, what, where, when and how--of data handling and adapt easily to a wide range of disaster recovery procedures.
Karen Winner is a consultant for Winners Marketing Communications in Minneapolis, Minn.
The allure of client/server architecture is very strong for those who want to downsize from a mainframe environment. It promises, among other things, local ownership of local data and distributed processing. Unfortunately, the client/server model introduces complexities in data administration and protection.
Mission critical data must be protected, whether it is stored locally or centrally. Unlike the mainframe environment with its centralized operations staff, sophisticated tools and standardized procedures, client/server applications reside in an open, often fluid, environment. The very aspects that make it so attractive (heterogeneous environments, smaller IS staff, distributed computers) can make administering and securing data a nightmare.
Even in a centralized IS environment, client/server databases typically lack the sophisticated backup and recovery tools taken for granted on the mainframe system. Wherever backups are inadequate or not consistently performed, valuable data is at risk. In the case of Oracle, a leading relational database management system (RDBMS), existing backup and recovery procedures are complex to learn, deploy and maintain, leaving core applications vulnerable to failures or long outages.
With the growing number of client/server applications maturing and supporting vital corporate functions, ever increasing amounts of critical data is being put at risk.
Oracle Backup/Recovery Today
Current backup and recovery methods for production Oracle databases not only take a great deal of time, they also demand a high level of expertise from database administrators (DBAs).
To carry out successful backup and recovery using traditional methods, DBAs first need a comprehensive understanding of the structure of the database and the relationships between the files. They need to write, or have written, robust scripts for backing up all of the necessary database components. They need to maintain these scripts consistently as database files are added or changed.
Once the system is in place and running, DBAs need to perform and carefully track database backups and exports, which requires a good system for identifying and locating the actual backup tapes and files. In practice, this tracking system may be maintained by the DBA, the system administrator (SA) or some combination of the two.
Database recovery relies even more heavily on the DBA not only correctly retrieving the files, but understanding the nature of the failure, identifying the correct files to retrieve and performing the appropriate actions to recover the database. The heavy reliance on the DBA's presence and expertise leaves some institutions vulnerable to failure because they cannot reach the right person, or because they are experiencing turnover in the DBA group.
The risks to data can be classified as five key areas in the development and implementation of a backup/recovery strategy:
- establishing the backup procedure
- maintaining the backup procedure
- recovering data
- adjusting for growth
- cross-system interaction
The three mainstays of a comprehensive backup and recovery plan are:
- physical backups (usually a combination of cold and hot backups)
- archivelog management
- regular database exports
If one of these is missing, it may not be possible to recover from some failures. The human component is of such importance here that obtaining the services of a well qualified DBA is often critical. However, as the range of Oracle applications continues to expand, good DBAs are harder to find.
Organizations with experienced DBAs are always at risk of losing them; turnover rates are high. Isolated departments in organizations that are beginning to hold mission-critical data may not have the expertise locally to set up or adhere to standard backup procedures - they may not even recognize that they need to do this.
Most Oracle DBAs have heard the story of the DBA who added a data file but forgot to modify the backup script and found after a failure that there were no backups. It may just be a DBA legend, but it does highlight a basic flaw in the process - ongoing vigilance is required to keep the backups up to date.
Also, it is often the case that the people who write the backup scripts are not involved in the maintenance process; they may even work for a different company. As one manager at a major financial institution told us, "We're okay as long as those consultants who set it up are still around."
Setting up the backup procedure is often the task of the consultants or developers who build the application and who move on to other projects, departments or companies when the project is complete.
If the scripts themselves are not easily maintainable, the DBA responsible for the database may ultimately have to create a new backup procedure from scratch.
Like the backup process, Oracle database recovery requires a detailed understanding of the nature of the failure, exact information about what data is required to be recovered and a comprehensive understanding of the Oracle database structure and recovery processes.The inevitability of failure occurring at a supremely inconvenient time simply adds to the pressure under which DBAs must work.
It is possible to have all the right pieces available for a recovery, and still not put them together correctly for a consistent database recovery.
In some sites, a system administrator is responsible for writing to tape the actual files that comprise the database, and for recovering them from tape. In this case, the DBA cannot perform a recovery alone.
It now depends not only on the DBA's expertise and time, but also the system administrator's expedience in finding and recovering specific files. Inefficient communication between the two will delay a complete recovery and may result in a key application being unavailable for a prolonged period.
Adjusting for Growth
Even with a devoted and knowledgeable DBA, flawless scripts, fast tape drives and happy users, there is no assurance that a current backup system will continue to work as the database grows.A backup system that's fine for a 2G database may be unacceptable for one of 20G and impossible for one of 200G.
Many DBAs anticipate significant growth in both database size and usage requirements for the applications they maintain. Very few have determined how they will work with those growth requirements.
Most are optimistically counting on the database vendors supplying something before the problem becomes critical.
Database vendors often provide no tools or guidance on backup and recovery issues, and any administrative tools they will supply are for their own databases. Sites with more than one vendor's database in-house must either maintain separate, different procedures for each type of database, or look for an integrated solution that uses common procedures for all mission-critical databases.
The problems, therefore, are manifold. They occur with staffing, with the supply of tools, and the complexities of creating an efficient backup system and of recovering from a failure.
The likelihood that databases will continue to increase in size simply compounds the problems outlined above. There is clearly a requirement for tools that are specifically designed to manage large databases, though it is often beyond the scope of database vendors to develop such software.
The future lies in backup and recovery tools that look at the complete scope of backup and recovery tasks that DBAs face in the Oracle environment, including maintaining backup configurations and performing complex recoveries. These tools should address all five areas described earlier in which problems occur to be truly successful solutions for complex client/server environments.
Anne Janzer is a Product Marketing Manager for DataTools, Inc.
This is the first of a two-part series that describes the process for selecting a PC-based disaster recovery planning system and the important features, functions and capabilities of the software.
Most organizations depend heavily on technology and automated systems, and their disruption for even a few days could cause severe financial loss and threaten survival. The continued operations of an organization depend on management’s awareness of potential disasters, their ability to develop a plan to minimize disruptions of critical functions, and the capability to recover operations expediently and successfully.
Organizations have experienced various degrees of success in developing disaster recovery plans. A particular problem is that the individuals assigned to the project may not have the experience and most importantly, the time to dedicate to such an effort. A rule of thumb is that the planning process requires approximately a one-person year to complete. Using a good PC-based Disaster Recovery Planning system can reduce the time and effort in the planning and development process to only a few months. Other benefits include:
- A systematic approach to the planning process
- Predesigned methodologies
- An effective method for maintenance
- A proven technique
There are several PC-based products on the market; however, a careful selection and implementation process is necessary to achieve the benefits described above. Major areas to consider include:
- General functions
- Disaster recovery plan development
- Database management
This article explains the various features, functions and capabilities of PC-based software
Many organizations seeking to improve their business recovery programs have opted to utilize software to assist them in plan development and maintenance.
These organizations seek out software suppliers offering tools that assist in the management of the overall recovery program. Each organization establishes specific criteria the resumption planning software tool must incorporate to meet its needs. Most organizations rank ease of use as a high priority on their list of criteria.
One of the most compelling reasons one software package is selected over competing products is the ease-of-use issue. This is true because many people with varying skill levels throughout the organization must use the planning tool.
As a vendor of software, we are confronted with the ease-of-use issue every time we talk with people involved in selecting software for their organization. When software purchasers make their final decision, we often hear, “we selected your product because for us it was the easiest to use,” or “we selected their product because it looked easier to use”.
Nonetheless, ease of use is a very broad term, encompassing a variety of more specific definitions. If you ask several people to describe ease of use you will get different answers depending on each person’s specific area of concern. What then does ease of use really mean? How does ease of use rank in the selection process, and more importantly, how should it rank?
EASE OF USE: An Explanation
Employing an easy-to-use software tool does not require that the user possess a great deal of specialized knowledge nor training to produce the end product. That is to say, ease of use is a characteristic attributable to the process of using a software tool. The tool is graded on the simplicity of its use. Therefore, ease of use is a process issue.
Ease of use is not an end product issue. The end product produced by the software tool cannot be attributed the characteristic, ease of use. A product issue focuses on the end result, the plan, not how the plan was processed.
For example, suppose I wanted to become a world class golfer. First, I would have to practice my golf game on some challenging courses. The process is practicing and playing golf, the product is becoming a better golfer.
This analogy holds true with software. The purpose of recovery planning software is to complete and maintain an effective business recovery plan. This plan is the product. How the product is produced is the process.
Depending on the software, the process of producing a business resumption plan entails varying degrees of difficulty. Regardless of how easy the process (or software) is, the end product (or the business resumption plan) still must be measured on its own merits. Therefore, when evaluating recovery planning software, ease of use should refer only to the process of producing the plan, it should not refer to the end product, the plan itself, or the quality of that plan.
With regard to business resumption planning tools, this process/product differentiation becomes critical. In order to resolve this issue, an organization must ask an important question: Are we using a planning tool to get some information into the tool, or are we using it to produce a high quality plan? More specifically: Are we looking for the easiest to use software, or are we looking for a tool that allows us to meet our planning objectives in the most efficient manner? While the answer to these fundamental questions may seem self-evident, it is easy to overlook during the initial phases of the software selection process.
In keeping with the golfing analogy, I have several options open to me. The first is to jump in my car and drive to a local public golf course. The other options open to me all involve some travel, planning efforts, and cost. For example, I could make travel arrangements to fly to northern California and play Pebble Beach. Both of these options meet the basic definition of playing some golf.
On the surface, the local golf course option seems to have the edge in the ease-of-use category. Obviously hopping in my car and driving a few miles is easier than making travel arrangements and taking the time and incurring the expense to travel to play Pebble Beach. Remember, however, my goal was not to just play golf, but to play the most challenging courses to truly improve my game. In order to achieve improvement on my local municipal course, I would have to get out bulldozers and cranes and create a course that would challenge me like Pebble Beach. Clearly, what appears to be the easiest option when judging only the process, becomes unacceptable if it does not lead to the desired end product.
This illustration applies to the ease-of-use issue when selecting a business resumption planning tool. If the end product, namely the plan itself, does not meet your business resumption objectives, the process used to produce the product becomes an unacceptable alternative, no matter how easy it is to use.
Through the years, a number of planning tools have appeared on the market to meet a simplified definition of easy to use. These products are easy to use because the process they follow involves filling in some blanks and printing out a pre-formatted plan. By any definition, this “cookie-cutter” or “one size fits all” approach is easy to use.
By increasing the perceived ease of use in a planning tool, the user’s flexibility and control over the end product is decreased. In other words, when a user is denied options, a product will appear easier to use.
If you do not have the choice of customizing reports and screens, or recording information specific to your business or industry, the planning process seems easy. However, when the user’s flexibility and control over the process is limited, it is prudent to examine what effects this will have on the end product.
Realizing your goal means producing complete, accurate, maintainable, and viable business resumption plans.
EASE OF USE:A Definition
A truly easy-to-use business planning tool allows you to:
1) efficiently enter all of your vital information
2) easily maintain that data as your business changes
3) quickly extract the vital information in a usable format
4) produce a complete plan that meets your business’s unique requirements.
Efficiently Enter Data
A software tool built on a relational database platform, allowing any user to take advantage of the database structure through all phases of the planning process, from data entry to reporting to plan production, is desirable.
The planning tool should have a database which sets up relationships between different bits of information. In other words, data entry in a relational database entails simply entering a piece of information once, and then relating it to all other appropriate pieces of information. This concept reduces data entry time and virtually eliminates data inconsistency.
Easily Maintain Your Data As Your Business Changes
If plan maintenance becomes difficult, it will be ignored. If maintenance is ignored, the information will quickly become obsolete. Obsolete information leads to an ineffective plan. An ineffective plan is equivalent to no plan at all.
When any portion of your plan changes, be it a phone number, serial number, or action item, the change should only need to be made once and then be automatically propagated through your entire plan.
Quickly Extract Vital information
Comprehensive reporting capabilities is a crucial element of a truly easy-to-use tool. If it is difficult to get the information out of the tool, especially in a meaningful format, the tool is not easy to use. Business resumption planning must include many areas of a business; therefore, it is critical to extract the information in multiple formats. It is not uncommon to need information regarding personnel, business functions, inventory requirements, and recovery steps on a single report.
Produce A Complete Plan That Meets Your Unique Requirements
The real purpose of a resumption planning tool is to create a plan that meets your needs. A tool that is perceived to be easy to use becomes an unacceptable option if the output does not meet your needs.
Revisiting the golf analogy, I can play golf on my local course everyday and technically meet my objective of improving my golf game. However, if I want to meet the true purpose of my goal to become a world class golfer, I will have to play the best courses like Pebble Beach.
So it is with business resumption planning. If you want to use any tool because it is perceived as easy to use, you can technically meet your goal of doing disaster recovery planning. But if you want to meet the true purpose of the planning project, you will use a planning tool that helps you build complete, effective plans, in the most efficient, functional manner possible.
Functionality and efficiency are the true determinants of an easy-to-use planning tool.
Michael Gomoll is a Marketing Executive with CHI/COR Information Management, a disaster recovery software and consulting firm in Chicago. Prior to joining CHI/COR, he was a marketing representative with IBM. He holds an undergraduate degree from the University of Wisconsin and an MBA from DePaul University.
This article adapted from Vol. 5 #4.
One of the most important aspects of Business Continuity Planning is designing & maintaining the plan document. This seemingly simple task is not only important, but all too often it is very time consuming. By selecting the right product before you start designing your plan, you can save yourself a lot of time and headaches. The biggest confusion when evaluating software tools is that they all seem to do the same thing, or that one product seems to be just as good as another. This checklist will help you identify key areas for consideration when evaluating Business Continuity Planning software.
PRODUCTS: PLAN DESIGN:
1. Can unit plans be rolled-up into a master plan in an orderly structure? (i.e., there’s a fire in the building and you need to relocate affected areas...can you get summations of equipment, chairs, desks, PCs, phones, etc., for the affected areas only?)
2. Can unit plans be individually printed during a test or disruption? (i.e., there’s a telecommunications event that disrupts your Customer Service department in various states...can only your Customer Service DRP be printed, regardless of location?)
3. Will all subordinate plans be included in a single plan execution? (i.e., the building is inaccessible; you execute the “building plan” and get all “subordinate” plans, instead of being forced to execute each plan individually.)
4. Is the software database driven? (i.e., plan development is accomplished primarily through data entry screens, and data is stored in a database, instead of word processor.)
5. Can the product be populated with data resident on another system? (i.e., you want to enter employees from the HR system, and your vendors from Purchasing system; is there an import capability so you don’t have to perform data entry?)
6. Will imported data be reflected in the product’s audit-history sub-system?
7. Does system prevent accidental import duplication?
8. Can the import function handle changes and deletions as well as additions?
9. Are “exception” reports provided to tell you about any data import errors?
10. Can field names be easily customized to fit your terminology? (i.e., say a field name is “Alternate Phone” and you want it to read “Beeper” or “Cellular”; can the field name be easily changed?)
11. Can the tool bar icon description be customized?
12. Can the order of the plan output be customized for execution? (i.e., if you’ve determined you want your call list first, your list of critical applications by priority second, tasks and procedures third, etc., can you customize order of output?)
13. Is there a single-user version of the product that can operate on either a stand-alone PC or on a file server?
14. Is there a multi-user LAN version available?
15. In the multi-user LAN version, can multiple people access the same data table/file simultaneously? (i.e., does the system perform record level locking so that users A, B,
and C can all be in the employee database editing and/or printing at the same time?)
16. Does the LAN version operate in a number of LAN environments? (i.e., Novell, Banyon, Lan Manager, etc.)
17. Does the system have multiple levels of security?
18. Does the system require user ID/login security?
19. Does the system have recovery plan level security? (i.e., Finance can’t edit MIS’ plan.)
20. Does the system offer access security into different areas/functions of the tool? (i.e., can you can lock out some users from editing or printing plans, from performing any customization to product, from accessing administrative tools, etc.)
21. Can security profiles for various users be easily duplicated? (i.e., Users on the LAN have the same level of security, the only difference is the plan each can edit—one security profile can be created once and duplicated as necessary.)
22. Can a user be denied access to major data editing capabilities? (i.e., Move, Replace, Global Delete.)
23. Can an individual user change his/her password without requiring access to Security?
24. Does the system have an audit-history subsystem?
25. Does audit-history provide a before-and-after image of transaction performed? (i.e., does it show if this transaction was an add, a change or a deletion; if it was a change, does it show how the record looked before and after the transaction.)
26. Does audit-history identify/track the user performing the transaction?
27. Does audit-history stamp a date and time on every transaction?
28. Can the audit reports be printed?
29. Can you restore data from the audit-history subsystem?
WORD PROCESSING INTERFACE:
30. Does the system interface to any Windows or DOS-based word processor? (i.e., you may or may not have standardized on a particular word processor - can the system be adapted to fit your needs?)
31. Can you use your own text documents instead of those included with the system?
32. Does the system come with standard reports?
33. Can you edit standard reports? (i.e., change the contents, style, and typeface.)
34. Are custom reporting capabilities available?
35. Can summations of equipment, supplies, employees, etc., be performed?
36. Can recovery plan data be sorted in any order? (i.e., alphabetically, numerically, ascending/descending, by zip code, etc.?)
37. Can you determine the search criteria for each report?
38. Can only portions of the plan be printed? (i.e., allows for the generation and printing of individual plan reports.)
39. Can reports be printed to the screen for online viewing before printing?
40. Can reports be printed or exported to a file?
41. If reports can be exported to a file, can the type of file be specified? (i.e., WordPerfect, Word, Lotus 1-2-3, Excel.)
42. If the type of file is specified, will the report be placed in the correct format? (i.e., will headers be placed in the header section of the word processing document.)
43. Can reports be sent directly through your MAPI e-mail system? (i.e., if you have the report on your screen, can you click a button and have it sent directly through your mail system?
44. Can previously created charts and diagrams be linked into your plan using OLE 2.0?
45. Is there hypertext help with the system? (i.e., can the user “jump” from one help topic to another.)
46. Is there context-sensitive help with the system? (i.e., when the user hits the Help key, does the system bring up help that is pertinent to the section or feature that was being used?)
47. Is there a “search” shortcut option under the Help menu bar so you can go directly to the help you need?
48. Is there an on-line “How To” Guide on building a recovery plan?
49. If yes, can this recovery planning guide be printed by each user?
50. Does the system offer flexibility in plan design? (i.e., even if system is based on a specific methodology...does it allow for variation and flexibility instead of rigid adherence to the plan’s methodology?)
51. Does the system have the ability to move information from one plan to another? (i.e., when employees change departments; can you easily move them into different plans?)
52. Does the system have the ability to “selectively” replace one employee’s team assignments and management positions with another’s? (i.e., if employee A is laid off or promoted, can employee B be easily assigned employee A’s responsibilities?)
53. When performing a global delete, are all relationships associated with that record also removed? (i.e., if a department is eliminated and you want to delete that plan, can you do a global delete of everything associated with that plan?)
54. Is the first year of maintenance services included with software?
55. Is the maintenance fee 15% or less thereafter?
56. Does vendor provide toll-free technical support within the U.S.?
57. Is toll-free technical support available 24 hours a day, 7 days a week to all users?
58. Is free training included with software?
59. Is free “hands-on” training available during evaluation stages?
60. Does vendor provide training for unlimited personnel at no charge?
61. Are product updates and enhancements free under active maintenance?
62. Can the vendor provide at least ten (10) references with contact names and phone number?
63. Does the vendor staff include Certified Business Recovery Planning consultants?
64. Is Business Recovery Planning software the Vendor’s principal line of business?
Dora Riano is employed with Strohl Systems.
The past few years have seen many companies addressing disaster recovery and contingency planning. The recent rash of natural disasters and the bombing of the World Trade Center highlighted the need for such planning, and has gotten the attention of CEOs and corporate directors.
Unfortunately, during the process of assembling the pieces to the contingency plan puzzle, and especially during the search for disaster recovery planning software, many planners disregard certain industry specifics that may merit special consideration. This article describes the typical planning process, including the software search, and highlights certain considerations specific to specialized industries. Included are:
- Disaster Recovery Plan Development Steps;
- Software Search Basics;
- Examples of Specific Industry Considerations;
- Sources of Industry Information and Recommendations.
DISASTER RECOVERY PLAN DEVELOPMENT
Once the support of upper management is enlisted, and the proper resources are dedicated to the project, the assembly of a disaster recovery plan can follow a fairly routine format. A typical plan includes:
- Executive Summary--This summary details the purpose and scope of the plan, any relevant definitions or assumptions made in its formation, a general description of high priority tasks, an organization chart of personnel assigned to disaster recovery teams, and any other summary information.
- Identification of Possible Contingencies--These contingencies include potential business interruptions which limit access to operating facilities, as well as, interruptions specific only to computer and telecommunication systems. Keep an eye open for preventative measures that can be implemented when performing this step.
- Departmental Operating Procedures--These procedures include identification of high priority tasks which must continue to be performed, special considerations for manual processing in the event automated systems are inaccessible, and location and accessibility of alternate sites.
- Equipment and Software Inventories--These inventories include replacement plans for short, mid, and long-term outages and processing capacity with physical space requirements for all equipment. The software includes database management features which are typically useful for this process.
- Personnel Inventory and Recovery Team Assignment--This is a most important section which provides detail on how to contact personnel (i.e. home telephone numbers, etc.) and advises each employee of their assignments in the event of a disaster.
- Plan Testing Provisions and Maintenance--This is a description of the methods that will be used to test the plan, including a timetable and details of required documentation.
SOFTWARE SEARCH BASICS
There are many software choices available to assist a company in automating its disaster recovery plan. The following basic procedures should be followed when conducting a search.
Appoint a project coordinator and a Review Committee who will be responsible for prioritizing the departmental recovery, attending software demonstrations, and ultimately, selecting the software. While some might argue that a committee might slow the process, the difficult decisions to be made in prioritizing operations deserves the consideration of more than one employee or consultant. In fact, it is wise to include members of upper management or the audit department on the Review Committee.
Formalize a Business Impact Analysis document which describes the organization’s critical functions and ranks the priority that departments and functional areas must address in the event of a business interruption.
Document the needs of each critical department in terms of office equipment, including computer and communications equipment, office supplies, and minimum personnel requirements. It is a good idea to document these needs in terms of the amount of time an outage may last. Critical needs, especially personnel, may vary drastically for an outage that incapacitates a computer system for a week versus a month.
Consider any specific requirements related to your industry or constraints that your geographic location may impose. These considerations may change the requirements of the disaster recovery software.
Prepare a formal Request For Proposal, or a more informal questionnaire to distribute among potential vendors. This document should describe the critical needs and desired functionality of the software, and will serve as a uniform and objective basis to evaluate potential vendors.
Research potential software vendors and distribute the RFP to those that fit a basic criteria. Research questions to ask potential candidates include years of experience, size of support staff, number of installations, training techniques used, financial strength, experience in your industry, and reference list of users. It is also reasonable to inquire as to whether clients of the vendor have ever had to implement their disaster recovery plan, and further information regarding the results of the plan.
Evaluate proposals from vendors by having the Review Committee rank each candidate numerically. This process can be somewhat simplified by weighing each requirement listed in the RFP, assigning a value to the vendor’s response for each requirement, and aggregating the total responses by vendor.
Software demonstrations should be required by the top three ranking vendors. The Review Committee, along with any other necessary personnel should attend these sessions. Remember to inquire about the security features of a particular software package. Contingency plans often include sensitive information that should be kept confidential.
Select a vendor and carefully negotiate any necessary terms and arrangements to avoid misunderstandings regarding the responsibilities of the parties involved, ownership rights of software/licences, confidentiality issues, etc.
Install the software, provide for training of operating personnel, and assign a timetable for the project coordinator to implement the system.
EXAMPLES OF SPECIFIC INDUSTRY CONSIDERATIONS
Historically, much of the impetus for disaster recovery planning has centered around the corporate data processing department. Electrical power interruptions and less than reliable computer equipment have heightened the awareness of data center management to the need for contingency planning.
Today, contingency planning is a much broader field. Corporations are interested in organization-wide planning that covers all aspects of daily operations including provisions for client relations, key vendor relationships and other third party service providers.
Unfortunately, not all disaster recovery planning software is written with these broad needs in mind. Many offer an acceptable array of “generic” features some which can be tailored to the needs of your specific industry. The keyword to remember when evaluating DRP software is flexibility.
The following illustrates the varying needs of different industries and work environments:
- Financial Services Institutions--Banks, Brokerage Houses, and Investment Companies (Mutual Funds) are typically characterized by large computer systems with high transaction processing volumes. Mainframe or minicomputers are the most common platform for these backoffice systems and often the disaster recovery plans in these organizations revolves around these systems and the main data center where they are housed. These companies may, however, use outside service providers or rely on third party data to a great extent.
As an example, investment companies must price securities held in a mutual fund daily in order to calculate the net asset value of the fund, i.e. the price at which shares can be bought and sold.
Prices are often received through data communication lines from stock exchanges or security pricing services. These data feeds are critical to the investment company’s capability to operate and should be explicitly addressed in the disaster recovery plan.
Accordingly, DRP software used by such institutions should allow for the customization of various sections covering these third party service providers.
- Hospitals and Large Heath Care Providers--Many hospitals and related organizations have contingency plans in place which directly address electrical power requirements and communication line redundancy, widely viewed as the most critical needs of these institutions. In the event that evacuation of a facility is necessary due to fire, flood, etc. precise timing and definite alternate locations are essential to a successful recovery. DRP software in this case must be able to address precise scheduling issues, contain an alternate location database (including adequate directions to each location), and provide a detail contact list (for doctors, technicians, etc.).
- Professional Services Firms--Many professional services firms (e.g. law and accounting firms) have a multitude of documentation and work-paper files concerning client matters. These documents are often difficult to recreate yet often leave the office with staff members or are left in file rooms that are not protected from fire or water damage. Microfiche copies (or optical scanning) of critical documentation can mitigate the potential damage caused by loss of the original hard copies.
In these instances, a valuable feature of disaster recovery software is the ability to maintain a built-in index of where the backup documents are stored and the procedures necessary to access them.
SOURCES OF INDUSTRY INFORMATION AND RECOMMENDATIONS
If you are about to implement or revisit a disaster recovery plan, take a moment to consider specific needs pertaining to your industry. If you are not comfortable that you have covered all the bases, try these additional sources of information.
- An Industry or Trade Association--These groups often meet to discuss business issues and provide good contacts.
- Your Current Software Vendors and Third Party Service Providers --These vendors may often have relationships with disaster recovery software and service providers, and typically understand your industry needs.
- Disaster Recovery Software/Service Providers and Consultants--These contacts are often willing to share ideas and experiences, especially if you are willing to endure a sales pitch.
- “Friendly” Competitors --Companies in the same or similar industry which don’t directly compete with you due to product line, geographic location, etc. are also particularly good sources of information. This is especially the case if they were provided to you as a reference by a potential DRP software vendor.
Well-chosen software can often make the process of implementing a disaster recovery plan a much less daunting task, however, choosing software that doesn’t meet critical requirements will frustrate and delay the process.
In evaluating the needs of your organization, take a moment to reflect on your industry and its peculiarities in order to formulate specific requirements. This bit of research can go a long way toward helping you select the right software and successfully implement your disaster recovery plan.
Michael A. Natoli is a Senior Manager in the consulting services division of McGladrey & Pullen, in New York, NY.
Just as a carpenter needs the right tools to build a house, a contingency planner needs the right tools to build a business recovery plan. Sure, a carpenter could probably build a house using a rock for a hammer, but it would take an immensely long time. A contingency planner might be able to create an entire recovery plan using a pencil and a pad of paper, but that too would take to long. Fortunately, there are numerous business recovery planning systems available for you to choose from. Picking the right tool set to support your organization, now and in the future, is the critical issue. Here are a few tips to help you make the right choice.
Kick The Tires
Before you go looking for your tool kit, you should know that there are literally dozens of disaster recovery planning "systems" on the market today. There weren't always this many, but recovery planning has become a hot area and when opportunity knocks many answer. Don't jump at the first shiny looking planning system that you come across, and don't buy a plan just because it's offered by your backup site vendor. It may be right for you, but it may not be. You've got to be careful because business recovery planning is hard work and any plan you choose you'll have to live with for a long, long time to come. So Kick The Tires!
Here's a list of factors to compare when you go shopping for a system. Not all of these may apply to you.
Is it a database product or a word processor-based system, or both? Both is better. And, a relational database is better than other database schemes such as flat file. A relational database provides you with a single point of data entry and update, making it easier to manage and easier to secure.
Can you modify the plan to meet your unique requirements? For instance, some plans assume you'll include a section on each department, while others may be based on business units or some other structure. Be sure the disaster planning system you license is flexible enough to accommodate your intended plan structure.
Does the system support only information systems recovery or recovery of your entire business? Some will say, "but, IS is my business!"
This may be true in some cases; however, in the vast majority of businesses today, there remain a large number of manual or paper-based systems that help support the organization. We haven't yet, and may never, reach the Holy Grail of business: a paperless office. So, while we're waiting, you should consider whether your disaster plan must cover everything or just the information system.
What do you get for your money? Is the vendor selling a comprehensive, all-in-one kind of system or a modular, buy-what-you-think-you-may-need sort of approach. Does one licensing fee cover everything or will you have to repeatedly go back to the vendor to buy new components and sign new agreements? Is the software used by the vendor as a vehicle for selling consulting services?
There are a lot of new faces in the disaster recovery planning software field these days. How much experience does a vendor have? How long have they been in business? Who are their customers? What is the vendor's reputation among your peers and among the vendor's customers? A respectable vendor should be willing to provide you with customer references. This is a major purchase, so make that call and check those references-- you may be glad you did.
Product Development and Support
View your purchase as a marriage; a long term commitment till death (or a new job) do us part. Not only should your vendor be experienced, but your vendor should be able to show a steady progression of product development and improvement. In addition, the vendor should offer user support groups or conferences where users can provide formal input into the product development process.
Take Advantage Of Training Programs
When the contingency planner acquires a planning system one of the first issues after installing it, is understanding how to use it. If you were diligent in the evaluation process, you looked at a number of products. From your short list you selected a product that met your objectives and requirements and also seemed to be the easiest to use.
The products that dominate the industry walk a fine line between providing functionality and being easy to use. Training, therefore, is strongly recommended. This training may be just to learn the product layout and technical features. It may go further to help provide a method for using the tool. Even computer games can be learned more quickly if someone shows you how to fire the missile that kills the bad guy.
Some vendors will provide training classes at their facility; some will provide training at your site. Some do both types of training. Both methods have distinct tradeoffs.
Classes at the vendor's facility provide a fixed structure for learning the system and provide a vehicle for networking as well. However, be careful! Find out in advance if non-customers are allowed to attend these "classes." If so, the "training" could quickly deteriorate into a sales seminar.
On-site training tends to be more focused on your specific needs and progresses at the pace that best meets those needs. This isn't always the case with training at the vendor's site. Of course, with an on-site class, you won't be networking with other planners; however, a larger number of employees can benefit from the training since there's usually no additional cost for travel or expenses.
Regardless of where you get it, training will shorten your learning curve and allow you to spend more time building a quality plan. New users should not postpone training in order to "get more out of it." Don't forget, recovery planning is frequently a high profile endeavor and you'll want to get off to a fast start with a well-prepared game plan.
Bone Up On Methodology
Now that you’ve got the system installed and you've been trained how to use it, now what? Most products have a methodology, an underlying planning philosophy. If it's built into the system, print it out and read it. The methodology will provide a road map for building the plan. Good methodologies will start at ground zero and tell you what to do every step of the way, up to and including testing and plan maintenance. Many systems will also include a project plan. "Hot" Tip: when you read the methodology have a pot of coffee nearby--this is true non-fiction! Refine the project plan to accommodate your specific goals.
To get started make sure that the terminology in the product matches your environment. As an example, if you will build plans by business unit rather than department, change the product accordingly. Clearly define the goal of the plan. This prevents the project from going off on a tangent. This also lets everyone know, up front, what the plan is supposed to accomplish.
A plan is a combination of the work you as the planner accomplish, as well as input from critical business units. Decide how you will collect data.
There will be different data collection methods available depending on the product you select. All should be able to create paper collection forms. Some offer multi-user platforms with the ability to collect data in a client server environment. Still other products have data collection utilities that allow you to give a disk with forms and get a disk from the business unit with the data.
Whatever method you select for collecting data, you should use for maintaining data. This second issue, maintenance, is often overlooked. Products that use relational databases are designed to ease this maintenance burden by providing single-point entry/update.
Coordination Is Critical
In addition to collecting data from the business units, you as a planner need to work on coordination. This coordination includes setting up a command center, establishing a team structure to support the business units and even documenting how the plan gets activated. Naturally, as a coordinator, you will ensure that the business units are not all planning to use the same resource. This is another place where a database can be of value. By querying the tables you can see if any resource, like a recovery location, is over utilized.
Once your efforts and those of the business units are completed, the software should be able to produce workable, easily readable plans, specific to the recipient. This is a place that products that integrate database and text processing shine. The database helps to collect and maintain resource information. The text processor helps to publish the procedures. You will want to modify the plan (output from the system) to reflect the standards that your company has in place regarding documentation. Do all page numbers follow a particular methodology (e.g. section X page Y)? Do you put a revision date on every page? Where is the revision date on the page? Etc.
Vendor Support Is Vital
As you live with a system you will have questions. Ensure that the vendor offers telephone or on-line support services. The vendors with true staying power are the ones that provide regular maintenance releases. If a product is several years old and still carries the Rev. 1.XX designation, you should find out why there have been no major revisions. Keep your product current.
The best systems offer full graphical control over your final plan document. After all, you want your plan to look its best when you roll it out for all to see! The contingency planning software industry is now nearly 15 years old. There's a lot riding on your decision, so choose your tools with care!
Mark W. Avery is co-founder and vice president of Recovery Management, Inc.