Editor's note: For Part I of this article, click here.
What happens when everything you do is critical? Increasingly, for many organizations,
that's the situation when they sit down to do disaster recovery or business continuity
Unlike a few years ago, it was easy to isolate a few specific IT systems and
applications as critical resources that needed to be protected in event of a
natural or man-made disaster. However, most organizations and business processes
have evolved to a point where almost every IT application, database and system
is critical to the smooth operation of the business. Like it or not, people
become dependant on the applications they use every day and getting a business
back up and running after a disruption often requires planning to replicate
to reproduce all an organizations important applications. For example, even
though email was considered an ancillary communication tool in some organizations
as recently as five or six years ago, it's probably a critical intra- and extra-company
communication mechanism for almost all companies these days.
To help companies plan for overcoming problems or disasters and ensuring the
continuity of business processes and IT applications, I've assembled a few tips
and recommendations that organizations should consider when doing strategic
recovery and continuity planning. I recommend that organizations:
* Take a process approach - Many organizations approach DR or BC as a project-something
that they need to do once, and then assume it's completed. With rapid change
in both IT and business environments, it's important to use a process approach
for strategic business continuity planning-it needs to be continually updated
and revised as business requirements change or dictate.
*Set the right expectations - An important part of a good DR or BC approach
is to make sure to set expectations correctly. Working with business managers
and corporate management to prioritize, decide, and communicate how long it
will take to restore specific systems after a problem. Let them know whether
it will take 5 minutes or 5 hours to get their email back.
*Make sure to do adequate testing - Once you have plans, it's important to
make sure that they're tested-both initially and on an on-going basis. Some
organizations combine disaster recovery testing with their audit requirements,
to both demonstrate and test their processes and people.
*Do the right kind of testing - Testing alone isn't enough. You have to make
sure you're not just testing, but testing for a wide range of potential problems
and scenarios. If you're completing 100% of your tests correctly, you're not
testing enough. Instead, to do it right, organizations should probably plan
for approximately 25% failure of their tests if they're really stretching the
limits of potential disruptions.
*Make sure you've documented what you have - Just as it's important to document
application code to make modifications in the future easier, or business processes
to make audits easier, it's critical for an organization to document not only
its disaster recovery plan, but the assumptions that went into it-otherwise,
it's difficult to know exactly needs to be changed as business conditions change.
Good documentation should include not just the business processes but a wide
range of details, including the roles and responsibilities that different employees
are expected to play in a disaster.
*Create a plan - Perhaps it doesn't need to be said, but organizations need
a disaster recovery and business continuity plan. Implementing a backup and
recovery product or replication product is not a disaster recovery plan. A good
plan needs to include the processes and people required to get things back on
*Question assumptions - Unfortunately for my parents, teachers and bosses,
I've always had a strong knack for questioning authority. Even though I know
that a few of those questions I've asked may have (occasionally) irritated people,
such an approach is critical for a good disaster recovery plan. Just because
something has always been done a certain way, don't assume that it's the right
thing to do. When you're developing, testing and revising a strategic disaster
recovery plan, make sure to question authority and conventional (read: 'we've
always done it that way' or 'that would never happen') thinking.
Like security planning, disaster recovery and business continuity planning
is a potentially never-ending process that could suck up all an organization's
resources and money. On the other hand, organizations that fail to make appropriate
and adequate plans risk potential large-scale negative business implications
when something does go wrong. I believe that organizations should instead find
a reasonable middle ground-an approach to disaster recovery that provides security
and assurance that an business will be able to continue doing business after
potential problems, while keeping in mind the day-to-day priorities of business
requirements and IT services that need to be fulfilled in an efficient and effective
About the Author
David Kelly - With twenty years at the cutting edge of enterprise infrastructure,
David A. Kelly is ebizQ's Community Manager for Optimizing Business/IT Management. This category includes IT governance, SOA governance,and compliance, risk management, ITIL, business service management,registries and more.
As Community Manager, David will blog and podcast to keep the ebizQ
community fully informed on all the important news and breakthroughs
relevant to enterprise governance. David will also be responsible for
publishing press releases, taking briefings, and overseeing vendor
submitted feature articles to run on ebizQ. In addition, each week,
David will compile the week's most important news and views in a
newsletter emailed out to ebizQ's ever-growing Governance community.
David Kelly is ideally suited to be ebizQ's Governing the
Infrastructure Community Manager as he has been involved with
application development, project management, and product development
for over twenty years. As a technology and business analyst, David has
been researching, writing and speaking on governance-related topics
for over a decade.
David is an expert in Web services, application development, and
enterprise infrastructures. As the former Senior VP of Analyst
Services at Hurwitz Group, he has extensive experience in translating
the implications of new application development, deployment, and
management technologies into practical recommendations for enterprise
customers. He's written articles for Computerworld, Software Magazine,
the New York Times, and other publications, and spoken at conferences
such as Comdex, Software Development, and Internet World. With
expertise ranging from application development to enterprise
management to integration/B2B services to IP networking and VPNs,
Kelly can help companies profit from the diversity of a changing
ebizQ is the insiderís guide to next-generation business process management. We offer a growing collection of independent editorial articles on BPM trends, issues, challenges and solutions, all targeted to business and IT BPM professionals.
We cover BPM standards, governance, technology and continuous process improvement, as well as process discovery, modeling, simulation and optimization, among many other areas. We follow case management, decision management, business rules management, operational intelligence, complex event processing and other related topics. We closely track important trends such as the rise of social BPM, mobile BPM and BPM in the cloud. We also explore BPMís use in functional areas, such as supply chain and customer management, and in key verticals, such as financial services, health care, insurance and government.
ebizQ's other BPM-oriented content includes podcasts, webcasts, webinars, white papers, a variety of expert blogs, a lively online forum and much more.