Ensuring Business Continuity (Part II)

Untitled Document

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 planning.

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 track.

*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 manner.

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 technology landscape.

More by David A. Kelly

About ebizQ

ebizQ is the insiders 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 BPMs 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.