Searching for Holy Grails: Interview with Jon Toigo (Continued)

How to Begin Planning
FTPOnline: Did the events of September 11th spur greater management support for DR planning, or are many IT managers still trying to get support in this area?

Jon Toigo: There was certainly an uptick in interest in DR planning immediately following 9/11. A recent survey from Imation says that 56 percent of the surveyed companies with DR plans implemented regular testing for the first time. While 43 percent moved data off-site, 42 percent established regular update procedures, 39 percent increased budgets, and 26 percent implemented a formal DR plan for the first time. Of course, the survey also revealed the sad truth that only one in three of the companies surveyed actually had a plan that was tested on a regular basis.

Post-9/11, there was also the continuation of a downward economic trend that militated against spending any money whatsoever on DR in many firms. In lean economic times, it's tough to get senior management to approve expenditures on capabilities that in the best of possible circumstances would never be used.

FTPOnline: If a company has no disaster recovery plan, where should it begin? Are there common elements regardless of company size?

Jon Toigo:: If you have limited resources, you need to spend what you have on three things—data protection, disaster avoidance, and awareness building. The first two have obvious value: fire detection, alarm, and suppression, and similar disaster avoidance technologies, both help to prevent avoidable disasters and enable you to protect your most precious asset, people. Next to trained staff, the second thing you need to make a recovery is data, which is irreplaceable. Without these two assets, personnel and data, it doesn't matter how well you've planned logistics for server, network, or end user computing environment recovery.

Awareness building is the third key area in which effort should be placed. Many n-tier client/server applications and hosting platforms are being built today that defy cost-effective recovery because of faulty design decisions from a disaster recovery perspective. You ask the systems designer why he or she chose this middleware, which depends on hard-coded remote-procedure calls, over that middleware, which dynamically discovers app components and would enable expeditious system recovery without 1-for-1 platform replacement in a disaster, and most of the time he or she will simply respond, "Because nobody told me to." DR needs to become a consideration at every stage of application development and platform architecture. It can no longer be cost-effectively delivered as a bolt-on after systems have been rolled into production.

Introduction

Challenges and Costs