Is a Relational Database Necessary?
- Published on October 26, 2007
Ease of Maintenance
Ease of maintenance is perhaps the most valuable characteristic of Disaster Recovery Plans developed with relational databases. Once a plan is developed, organizations are faces with the formidable and never-ending task of keeping the information in their plans current. I have seen many companies re-develop existing Disaster Recovery Plans from “scratch” every two or three years because their old, typically word-processing-based plan had grown hopelessly obsolete. An easy-to-maintain approach can prevent these costly projects.
Disaster Recovery Plans developed with relational databases are easier to maintain for two reasons. First, information items in your plan are kept in only one place in the database. If that item changes, the Plan Coordinator only needs to change the data once, and the change is automatically and instantaneously reflected throughout the database and the Disaster Recovery Plan.
As an example, Mary Smith may be a vital person to be contacted at several stages of your recovery process. You may choose to insert her phone number directly into the eighteen action plan steps that require her presence, in lieu of having to look up her number in an appendix. With a relational database approach, you only need to change her number once, and that change is reflected automatically wherever it appears in your Plan, provided that your database is properly defined.
My second reason is that recovery information already being maintained elsewhere can easily be included in your database. Through an “importing” function, you can routinely and automatically update your personal computer or word processing system plan with data that exists on your mainframe computer. Since you don’t have to key that data separately into different systems, your maintenance task is smaller and you will know that your systems are synchronized.
Ease of Access
Ease of access is important during plan development, maintenance, testing, and actual recovery. Due to the information interrelationships that characterize relational databases systems, your plan data is easily and instantaneously available online, providing your plan includes the online feature. If those database relationships have been sensibly established, you can reach important information from any terminal accessing your mainframe system, providing your system is operational.
For example, you may be looking at data pertaining to an item of equipment. You realize that you need the telephone number of your equipment vendor for that item. As you dial the number, you want to know the vendor’s account representative who deals with your company. You also may want to know the recovery team to which that person has been assigned. The database “paths” that you may want to explore can be nearly endless.
Reporting flexibility will allow you to produce Disaster Recovery Plans (or individual reports) for different situations, audiences, and locations.
Relational database systems permit you to easily sort and select pertinent information and include only that information relevant to your plan. With some packages, you can maintain different recovery plans with the same or different contents, and you can quickly and easily tailor the data in those plans to be relevant to the immediate circumstances. A relational database plan can also allow you to send specific information or your entire plan to other systems. You can “export” your plan to your mainframe computer system to permit broader access to it or to take advantage of high speed printing capabilities.
Support During Recovery
You can use your relational database plan to support your recovery (or testing) process. Systems that are easiest to use have a sophisticated project management system built right into the database structure. As you proceed through the recovery process, you will enter actual completion information into the database, and use the system to determine the impact of your actual performance on your recovery time.
You can use a relational database system to track both planned progress and unexpected events. A properly-designed system can provide a complete chronology of the recovery or testing exercise. And the reporting flexibility mentioned earlier provides an unlimited variety of reports to highlight desired plan enhancements, to support a “post mortem” evaluation, and to answer any questions that may be posed by auditors.
If your disaster recovery planning system is useful for purposes other than disaster recovery, your disaster recovery planning efforts will be easier to cost-justify. And if your system is valuable for more than just disaster recovery, maintenance of your plan is more probable.
A relational database system should be a valuable resource management tool for three reasons. First, the system provides a comprehensive database for information about your resources (equipment, communications, applications, processes, vital records, software, miscellaneous items, vendor suppliers, customer/users, staff, preprinted forms), all of which is relevant to recovery. Second, the system provides a convenient way to document procedures, with a sophisticated project manager built right in. And finally, the reporting flexibility makes it easy to generate ad hoc reports that highlight areas requiring management attention.
Ease of Use and Installation
If your disaster recovery planning system only requires database management software, it will be much easier to use and install, tending to minimize or eliminate the need for consulting assistance. When needed, consulting can be focused on the more analytical processes of business impact analyses, organizing your disaster recovery planning program, protecting your vital records, selecting an alternate site, and reviewing your completed plan.
This last benefit is perhaps a bit more technical than the others. To support disaster recovery, organizations need access to information items that are naturally interrelated. For example, vital records are related to the application systems and processes that use them. Application systems are related to equipment configurations required to support them. Equipment is related to vendors. Vendors are related to vendor representatives and telephone numbers. The list of possible relationships can be quite long.
A relational database makes establishing and using those relationships easy and natural. Trying to impose that complex structure of relationships with a different approach is difficult or impossible.
Jeffery E. Gardiner is Vice President of CHI/COR Information Management, Inc.
This article adapted from Vol. 1 No. 4, p. 32.