Goodbye DR, Hello ResiliencyNo enterprise can afford downtime in today's business climate. To stay always-on, you must create an environment of business resiliency that goes beyond business continuity and disaster recovery.
In today's environment of 24-7-365 global operations and competition, downtime means more than immediate lost revenue and productivity--it can also cause lasting damage to your corporate reputation and erode customer confidence in your brand. Enterprises must be always-on and always available to an extended network of customers, employees, and partners. To enable this, organizations must evolve beyond reactive business continuity and IT disaster recovery (BC/DR) to proactive business technology resiliency.
Resiliency is typically defined as "an occurrence of rebounding or springing back." Thus, business resiliency refers to the ability of a business to spring back from a disruption to its operations. Historically, both business continuity and IT disaster recovery have focused on a business' ability to recover from a disruption. Recovery implies that there was downtime during which business operations were unavailable. Resiliency, on the other hand, implies that an event may have affected a business' operations but the business was never completely unavailable.
All organizations experience failures or other impacts to business operations at some point, so it is critical for all services to be both designed for uptime and prepared for failures. That means that infrastructure and operations (I&O) leaders need resiliency, not recovery. Here's why:
--There is little tolerance for downtime of any kind these days. BC/DR has historically focused on events such as natural disasters, extreme weather, pandemics/epidemics, and other events that have a low probability of occurring but a very high impact to the business. However, in today's climate of global competition, downtime--regardless of whether it's due to a natural disaster, a simple hard drive failure, or a security breach--is unacceptable. The business doesn't care what caused the downtime; it simply wants service restored as quickly as possible with as little data loss as possible--regardless of which groups are responsible for the execution.
--More business processes are technology-dependent. For years, businesses made every effort possible to move BC management out of IT because for too long, most BC programs were about business continuity in name only--in reality, they were IT DR programs. However, most businesses have overcompensated to the point where there is minimal integration between BC and IT DR groups. Given that the majority of business processes are technology-enabled--or in many cases technology-dependent--this is untenable. In fact, many processes are so technology-dependent there are no longer manual procedures to fall back on if IT services are unavailable.
--The perceived and actual risks are increasing. According to a joint Forrester and Disaster Recovery Journal survey, 82% of BC decision makers and influencers feel that their organization's risk level is increasing. The top reasons for this include an increasing reliance on technology; greater business complexity; increasing frequency and intensity of natural disasters; and increasing reliance on third parties. These perceptions are not misguided: In the past five years, more than 60% of companies invoked BC plans at least once, and more than 25% invoked these plans three or more times.
[ Is your enterprise prepared in the event of a zero-day attack? Read Zero-Day Attacks Can Impact Business Continuity. ]
Unfortunately, most enterprises treat BC, IT DR, backup, high availability, and security as silos. BC often reports outside of IT to the chief risk officer, chief operations officer, or another executive. The VP of IT operations is often in charge of IT DR and operational recovery (i.e., backup), and the chief information security officer (or equivalent) is responsible for risks such as denial-of-service attacks, breaches, or data leaks.
While each of these separate disciplines requires specialized expertise and its own well-documented response plan, they also have a lot in common. For example, they are inevitably linked together through common processes (e.g., business impact analysis, risk assessments); important points of integration (e.g., joint testing, links between response plans, etc.); and a requirement to see high availability and security embedded into business technology strategy and enterprise architecture. The more these silos come together, the more an organization can achieve business technology resiliency, or spring back from any kind of disruption in a coordinated fashion.
According to Forrester's Business Technology Resiliency Playbook, evolving toward business technology resiliency helps you:
--Streamline redundant processes across risk disciplines. Business owners routinely complain that operational risk and IT managers bombard them with surveys and in-person interviews that ask the same questions over and over again. There is a great opportunity to consolidate separate business impact assessments (BIAs) and risk assessments across BC, IT DR, backup, information security, and other operational risk disciplines. In addition, there is an opportunity to merge incident management and escalation processes as well as the alphabet soup of response plans into a common repository (e.g., business continuity planning, disaster recovery planning, and incident response plans).
--Build resiliency into business process, app dev, and enterprise architecture. One reason resiliency is so often expensive and ineffective is that it's generally bolted on after the fact. Many companies assess the resiliency of the process only after a line-of-business owner designs the business process and recruits partners and IT deploys applications and systems in production. When you have a well-established business technology resiliency program with an appropriate strategy, a road map, and stated stakeholders and influencers, you have a better opportunity to ensure that resiliency is built-in from the start, and that all business processes have documented workarounds.
--Ensure ongoing funding and commitment. Resiliency is not a one-time planning event; it's an ongoing process that requires ongoing resources and funding commitments. Once you conduct your BIA and risk assessment and develop specific strategies and response plans, you need to test and maintain your plans. Additionally, at some point (perhaps annually or biennially) you must repeat the BIA and risk assessments.
Establishing a resiliency culture is also an ongoing effort. In many cases, the most challenging task is sustaining change and maintaining a culture of commitment to embedding resiliency into everything your firm does. When you have a well-defined program with appropriate key performance indicators, you are in a better position to sustain the funding necessary to maintain the program and nurture the culture.
You may feel that resiliency is just a rebranding of BC/DR, to make it appear sexier and allow vendors to creatively sell more of their existing products and services. Forrester contends that it is more than this. Resiliency is tightly aligned to business strategy. It takes a more holistic approach to risk management silos, and it strives to minimize downtime by embedding resiliency and workarounds into everything the organization does--from business processes to corporate and data center site selection to enterprise architecture and application development. A resilient organization is like a spring: It absorbs the impact and bounces back.
Cloud services can play a role in any BC/DR plan. Yet just 23% of 414 business technology pros responding to our 2011 Business Continuity/Disaster Recovery Survey use services as part of their application and data resiliency strategies, even though half (correctly) say it would reduce overall recovery times. Our The Cloud's Role In BC/DR report shows how the combination of cloud backup and IaaS offerings can be a beneficial part of a "DR 2.0" plan. (Free registration required.)