1. Sell a disaster recovery program by doing a risk assessment or a business impact analysis.

Such an analysis will focus the plan on the features that are most critical, thus saving money. "You can't focus on everything, given the economic constraints," said Bill Hughes, director of consulting services at SunGard Availability Services LP. Do you really need to have a clustered environment in your recovery environment? Or 10 Web servers? A risk assessment will help CIOs focus on what they absolutely need to mitigate the core risk and, if necessary, defer the rest. Hurricanes sound scary, Hughes said, but if you have certain preventive risk controls, what is the chance of the hurricane impacting you? Business resiliency is a preventive risk control. (See Tip 4.)

"Maybe your biggest vulnerability is change control and the software release process. Focus more on those pains more often," Hughes said.

2. Stop talking about disaster recovery and business continuity as an IT program or in terms of IT's underlying recovery objectives.

"The business doesn't care about technologies," said SunGard's Hughes. Focus on business objectives. He gave the example of a retailer moving more of its business online and to call centers to save on real estate and sales representatives at its stores.

"People will accept BC/DR as another part of that project if you present it as such. Whereas if you are just talking about networks and systems, it is easy for the business to separate DR from their business objectives," Hughes said.

The DR program must be linked to overall corporate strategy, said Pat Corcoran, global client solutions executive at IBM, and 32-year veteran in the disaster recovery/business continuity field. "If you can't demonstrate that, you've got a gap."

Building the program

3. BC/DR should really be integrated into an organization's normal change processes, ideally at the architectural stage.

This is a tough one, Hughes said. Even CIOs may not have full knowledge of where a business project is going, and business owners may not want them to layer BC/DR costs onto their project. But it is critical for CIOs to get their DR experts involved at the earliest possible stage of the project.

The alternative is worse. "You get something built and at the last minute you bring the DR person in, who says 'this isn't going to work,' and there goes your ROI," Hughes said.

People will accept BC/DR as another part of that project if you present it as such. Bill Hughesdirector of consulting servicesSunGard Availability Services LP

SunGard sits down with clients and reviews processes to see where it can hook into existing processes to make them more resilient. The fix is especially hard when clients have a reference architecture they're building toward but have not taken into account disaster recovery. "That takes a tremendous amount of sell to reverse engineer that."

At most companies DR is bolted on, not built into the IT systems and business processes a company depends upon, agreed Jon Toigo, CEO of Toigo Partners International, a technology advisory based in Dunedin, Fla. Toigo said that makes the DR planner's job that much tougher.

"The DR guys are handed a set of cards and have to play the cards [they] were dealt. They didn't get a vote in how the application is designed [or] how the data is hosted. They're just being handed this mess and being told it's their job to protect it," Toigo said.

Coming up with strategies to inculcate DR into the business at the get-go is critical.

In fact, Toigo goes a step farther. "Disaster recovery needs to go away. We shouldn't be doing it anymore," he said. "At this point, it should be part and parcel of the business processes, as the way we design and manage our infrastructure. It shouldn't be a standalone effort anymore."

4. Focus on business process resiliency.

Technology solutions are easier to put in place than changing people and processes to add resiliency. Technology solutions are expensive too.

"One thing we're doing right now with a few customers who have to put off their technology solution but are worried about their overall recovery is to focus on the business side," Hughes said. "We're wringing every bit of resilience out these business processes and we're actually finding unmined areas."

Sometimes it's a matter of shifting work to another process to take out risk or working with an organization's existing manual controls.

For example, SunGard is advising a hospital with limited funds for DR to beef up its required clinical workaround procedures to, first off, ensure the procedures actually work and then can provide a solid level of care for at least 12 hours in the event of a disaster. It's not an ideal fix, Hughes said, but the new process will mitigate risk.

A fresh look at business metrics can bolster DR. A manufacturing company is analyzing historical information on inventories to anticipate what it would need to continue running the business for up to 48 hours, as opposed to the 12 hours its disaster recovery program covers now.

Testing strategies

5. Lay out a five-year plan that shows improvement over time by, for example, taking additional risks out, or by better supporting a business need, or speeding the recovery time, or reducing error rates.

Because of the nature of disaster recovery contracts, many DR programs have been in place for a long time and have never gotten any better, "as far as business value added," Hughes said.

Disaster recovery, like any other business process, needs to show improvement.

"If you launch a program and have the same recovery times for the next five years, even if you are aligned with the business side, you're not delivering value," Hughes said. "Even if the only improvement is that you are driving the recovery time objectives down, that is removing risk from the business."

Keep in mind that test recovery times need to beat the RTO. "So for a 24-hour RTO, if you can make the test in half of that time, you can make 24 hours in reality," Hughes said.

Part of improving a plan is reducing error rates. "Even if you can make your recovery times and keep decreasing those RTOs, if you still have the same sort of errors, you still have risk," he said.

Track errors in testing, reexamine repeat errors for the root cause and set up programs to remove the errors.

6. Make sure DR is dependent on more than a few trained individuals.

Even if all goes well in a test, if the same people are always performing the recovery, [then] "you're not as ready as you should be," Hughes said.

In keeping with continuous improvement over the course of a five-year plan, DR planners might use their primary resources for the first two years. He said, "By the third year, you need to be testing with your secondaries and have the tertiaries join the program in the fourth year. "You need to be able to do it with the C team."

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy