Disaster Recovery planning has seen a resurgence of interest lately.  I like to think it’s because people are becoming more responsible and diligent, but I also realize it might be due to the fact that that we’ve had more large-scale disruption scenarios in the past five years than in any time in modern history.  This, coupled with greater government, customer and shareholder regulation and interest into company operations means your Disaster Recovery plans are likely to receive more scrutiny, testing, and unfortunately, use than in past generations.

One of the main areas that has received a lot of attention after recent events is the efficacy of the plans themselves. 

The established model for DR has been pretty solid for the past 20 or so years:

1. IT Leaders determine critical systems & data
2. Determine threats
3. Identify critical applications
    -  Consensus estimate, usually done with 10% business and 90% IT participation
4. Draft continuity & recovery plan
    -  Technologists hurry to produce 1:1 recovery plans for each system in isolation
5. Archive plan until needed

There are several major weaknesses with this approach:

• Too high a system-focus, not enough focus on the services delivered; value protected.
• Threat identification is not thorough enough.  Addresses only limited types of disaster scenarios.  Often, prior experiences take a front-seat.
• It does not weigh the business value of applications and prioritize their recovery accordingly.
• Often, does not address third-party dependencies (WAN, backup services, outsourcers, etc.)

This type of planning is designed to recover systems, not business processes and services.  But will that be enough to resume your business?

The concept of a Business Services Recovery approach has grown in popularity and interest with the wider adoption of ITSM.  ITSM’s services-oriented approach to cataloging and managing services  can be extended to Disaster Recovery and will provide a more cohesive, thorough and effective approach.

Step 1:  Document your Business Services Catalog.  Solicit input from business leaders (who know them best), and enlist their sponsorship of specific services.

Step 2:  Catalog outage scenarios.  It is more effective to think about service outages rather than individual threats, at the end of the day, it doesn’t matter if it was a flood, fire, or natural disaster that took out your data center, only that the facility is inoperable and the systems it houses inaccessible.  Your recovery strategy needs to begin with that premise.  Your focus should be on the impact to your business services, not incident types. 

Step 3:  Map and prioritize Business Services.  Theoretically, everything in your environment should be mappable to a business service.  You’ll want to be thorough here.  This is not to say you’ll want to forecast recovery of every link in the chain, but you’ll want at least have thought about how it affects your ability to provide Business Services in making the decision whether to recover it or not.

Step 4:  Define Recovery Steps:  This part will vary widely based on your environment and how you’ve prioritized your recovery.

Step 5:  Develop regular testing and refine your plan each time your environment changes.  The only way to ensure your plan will work is to exercise and test it regularly.  There are different types of testing programs (enough to fill their own article) ranging from a very unobtrusive boardroom walkthrough of procedures and scripts (don’t discount the value of getting your top minds in the room and running through a recovery drill step-by-step…it can be very revealing) to a full scale shutdown and recovery drill using your backup site and operations.  The exact type of testing that is right for your organization will depend on the criticality of the systems you’re recovering.  Disaster Recovery should also take a seat at the Change Management table.  You don’t want to go to recover and find out your backup servers are all an OS patch level or two behind.  A good practice is to incorporate your recovery plans into Change Management process.  For every production change processed, there should be at least one evaluation event to assess the impact on in-place DR plans or environments.

These steps are a broad starting point, but by following these guidelines and learning from the experiences of others, you’ll have a great shot at developing a world-class plan.

About the Author:
Christopher Rafter is Vice President of Consulting Services at Logicalis and an industry-recognized expert on use of technology in enterprise computing environments. He has more than 14 years experience working with Fortune 500 clients designing and building enterprise systems in areas including financial services business process management, business intelligence, operations workflow management, and B2B electronic commerce. Rafter is a BEA Certified J2EE Integration Architect and a member of the Worldwide Association of Software Architects. He holds an MBA in Finance and Management from New York University’s Stern School of Business.

Previous Article | Next Article