In reference to the title of this blog, if you have DR objectives you’re already well ahead of game. That assumes, of course, that your objectives are based on a DR strategy that aligns with your business plan, incorporates the needs of application users, properly tiers your applications, has the support of top management, is funded and tested regularly. If that is the case, then you already know what the cost is of failing to meet your DR objectives because you can’t have an effective plan without knowing that.
This is not intended to be circular logic. Many mid-size and smaller organizations believe that they have an effective DR plan in place. Still, ask them what the cost to their business would be if they were down for an hour or a day. Maybe one out of fifty can give you an answer. That doesn’t mean the answer is correct, or even that they have an effective DR plan in the first place.
A business – business, not just IT – must know what its cost of downtime is. Knowing that is what drives executive support, establishes recovery priorities, determines risk and pinpoints key areas for recovery investment. In light of that, only then can IT design a DR plan that not only aligns with the business but also with the computing and network infrastructure – the way stuff gets done – to make a timely and seamless recovery happen.
“DR is more than a check box; it’s hard work,” said Steve Hasselbach, Peak 10 solutions engineer. “People don’t believe that doing it right is less costly to a business than doing it wrong or haphazardly.”
A great many factors contribute to the true cost of downtime, too many to examine here in sufficient depth. Loss of productivity and wage expense can actually be the least of it in the long run. However, all too frequently cost calculations begin and end there.
The loss of one application or one server can ripple through an organization with serious consequences. Integration and interdependencies between computer-based functions can affect people and departments throughout an organization, as well as up and down the value chain.
For example, order entry goes down and stays down for half a day. That leaves the warehouse picking operation sitting idle too, as well as the trucks and drivers. Meanwhile your suppliers’ deliveries are stacking up on your loading dock. The customer waits and waits for near-real time delivery of supplies that don’t come. Now you have violated your SLA with the customer, resulting in costly penalties and a customer-service black eye. Unable to wait, the customer calls a secondary source who jumps at the chance to make you look bad and themselves responsive. Before you know it your volume with that customer is halved – if you’re lucky – and they ask you to remove their testimonial from your web site. Meanwhile, the secondary source is bad-mouthing you to other accounts and your reputation starts unraveling.
That’s some of the hard and soft costs of failing to meet DR objectives.
Two other critical factors in establishing effective DR plan objectives are determining how long you can tolerate being without that application (recovery time objective or RTO), and how much data can you risk to lose (recovery point objective or RPO) before causing major business issues. If your answer is that you can tolerate no downtime or data loss then prepare to be separated from large amounts of cash.
Each application or class of applications varies in importance. Some are critical and can seriously hurt your business if they’re out of commission for a few minutes, a half-hour or an hour. Many other applications are important and some not so much. The critical ones will have the shortest RTO (meaning they need to recover quickly) and warrant an investment in recovery commensurate with their criticality. Establishing RPO will help determine your data replication and back-up requirements. Regulated and critical operations data may need near-continuous replication, as data loss would be painful. Twelve-to-36-hour RPO may be completely acceptable for other data, allowing less frequent and less costly backup and restore technologies to be applied.
“The challenges are endless when it comes to creating, implementing and maintaining a truly effective and cost-efficient DR plan,” said Hasslebach. “It’s also a business necessity. It gets even more complicated when disaster recovery is assumed to be a business continuity plan, or vice versa. They are not the same. If anything, DR is a component of a BC plan, but each has its own objectives.”
We’ll save that one for another blog.