Disaster Recovery: Recovery Time ObjectivesBy Ericka Chickowski | Posted 2008-07-22 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
After years of progress in disaster recovery and business continuity, advances are beginning to unravel in planning, communication and will. Is your company's risk management plan in line with the best practices in disaster recovery?
Not Meeting Recovery-Time Objectives
As the Grolsch example makes clear, integrating IT disaster-recovery and business-continuity planning is critical. So why is the gap between the two widening?
Business-continuity experts say the tightening economy is partly to blame. However, they believe bridging the divide between technical and business expertise is also a matter of motivation.
“I think the consistent problem is that the folks who are tasked with developing business-continuity management programs often have little to no technical skills,” Deloitte & Touche’s Sarabacha says. “The person in charge of disaster recovery just gets tired of explaining and discussing technical aspects with that person and kind of gives up.”
No matter what the reason, the biggest way the gap can negatively affect an organization is by skewing RTOs (recovery-time objectives). According to Sarabacha, many enterprises are falling short when it comes to meeting RTOs. This is partly due to a lack of realistic expectations that stems from scarcity of communication between IT and business-side managers.
Often, a business will base its RTOs solely on the capabilities of its IT department to get things back up and running after disruption. These organizations fail to consider the logistics of resuming other business processes and operations, setting unrealistic objectives and failing to prioritize based on realistic expectations, notes Pelant, the disaster-recovery consultant.
“We’re finding that recovery-time objectives now have gotten so short that only IT can meet them. The business side can’t meet them,“ he says, explaining that some businesses might set a recovery objective of one hour for a certain business function. “But if you think about an hour’s lapsed time, the time interruption evacuating the building, collecting your thoughts, and then relocating to an alternate site and then setting up and starting to renew operations, it’s hard if you’ve only got an hour to do that. There’s a real lag there on the business side in that if you really are going to effectively do that, you really have to have some type of an alternate operation in place─not an alternate site, but an alternate operation that can pick up the workload in that time frame, and that’s not happening.”
Sometimes, it isn’t just the business side that lags, either. According to Sarabacha, business leaders who are out of the loop might also set unrealistic expectations that IT staffers cannot meet.
“We have several clients we help with testing of their disaster-recovery plans, and almost without exception, the results come out to be three, four and five times the duration expected,” he says. “For example, we’ve got one where they [estimated a] 12-hour RTO for their critical ERP [enterprise resource planning] application, and it took 66 hours to bring it back up. That’s something a business can understand. They might not understand why it took 66 hours, but they can understand that now they have got a problem.”