Technical Considerations for the non-Techie Business Continuity Planner

As you may know from my BIO (see my “About” page) I’m the proud co-founder and current President of the Mid-America Contingency Planning Forum more commonly referred to as the “MCPF”.  We formed the organization about 14 years ago when a previous group folded.  We saw a continuing need to offer business continuity professionals the opportunity to regularly meet and share information.  Fourteen years later we’re still around and working through several strategic initiatives that, once in place, will bring us to a much higher level of professionalism and add greater value to our members.

I share that with you because this month (August 2011) the topic for our MCPF general membership meeting is “Tech Talk: Technology topics and trends BCP professionals need to know”.  We wanted to have a discussion of technology for the non-techie business continuity planner.  As we started to frame the meeting, I used Linked In to solicit several of the Linked In groups that I belong to for discussion ideas.  I proposed the question, “In your opinion, what are three IT DR “technology” issues a non-technology BCP (Business Continuity Plannng) professional should learn or know about?”  The following reflects the feedback I received.

This is a great question for people like me. My focus is mainly on the Business Operations side of the house – This response really speaks to the reason we chose the topic we did.  Typically, in the technology arena we talk about DR (disaster recovery) vs BC (business continuity) which addresses the business operations side.  Unfortunately, when you are on the business side, you don’t often have the opportunity to stay current on computing technology.  During a recent MCPF meeting I asked for a show of hands as to who works in DR vs BC.  At that meeting, approximately 60% of the folks worked in BC.  Now, that’s certainly not a fair representation of the industry, but it reinforced the idea that in this age of specialization, there’s probably a few business continuity professionals that may need to brush up on their technology.

Learn interview skills – Most importantly asking leading questions and then LISTENING.  Overall, the comments received reflected that we are Business Continuity professionals and our job is not necessarily to be “experts” in technology (or any other particular facet of the company), rather we are to be experts in field of business continuity.  Therefore, whether you work in a technology or business operations environment you must have strong interview skills, ask pertinent questions, and then listen.  Your company SME’s (Subject Matter Experts) are paid to know the technology.

As a business continuity professional, our value comes from being able to facilitate discussions and be the liasion between the business and IT groups. We need to be able to bring the right groups together to understand and articulate the business and financial impacts of a disruption.  This type of leadership will enable the development of strong business cases to be built that justify any risk reduction recommendations to management.

We also need to understand how the IT infrastructure aligns with the business requirements and to identify the gaps and implications of those gaps. If there are single points of failure…what are the implications to business operations?  If recovery plans don’t meet business requirements…what are the implications?  IT has the SMEs that can tell what it will take to close the gaps, both in technology and costs. We need to effectively communicate that gap analysis to illustrate the implications and build the justification (a.k.a. BIA (Business Impact Analysis)).

Also, don’t make assumptions…always ask!! – All too often, we assume we know the answer.  Heck, I’ve been married 29 years now, and I still can’t seem to come up with the correct answer!  Ask, research, evaluate, conclude.   Don’t assume.  To help with that, a very basic series of questions might be:

  • What impact will the widget have on the operation?
  • Has anyone looked at the ripple effect of implementing the widget?
  • If the widget fails and effects operations, how long will it take to repair/replace/remove the widget and restore the operation to what it was before – and will all the minimum levels of service to/by the profit center be maintained during the process?
  • What is the widget’s reliability; if hardware, what are the MTTR (Mean Time To Restore) and MTBF (Mean Time Between Failures).

Now, all this said, as business continuity professionals, we should do our homework and maintain a sense of awareness as to what’s taking place in our company, our industry, and in the area of technology.  If you want to understand technology, take the time to schedule some short one-on-one discussions with folks in key IT organizations to understand the architecture and how the failover process would work.  For example, you might consider speaking with someone in the following organizations:  telecommunications, network, server, OS (operating system), middleware, DB (Database), and the application(s).  Having these conversations will help you to understand the feasibility of a failover meeting current RTO (Recovery Time Objective) and RPO (Recovery Point Objective) goals.  The following are some other areas that a non-technical business continuity person might want to explore and ask about:

  • Understand RTO/RPO and high-priority applications and their cross dependencies – Consider that responsibilities within IT are often split along infrastructure and then application lines, and so one person may not be able to give you the entire story on what you need to re-create a given application or database within the stated RTO and RPO.
  • Virtualization and cloud computing – Virtualization has been one of the hottest topics in enterprise IT over the past 10 years. It allows us to take physical servers, and streamline them down to virtual machine(s).  Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location and configuration of the system that delivers the services. An analogy would be the electricity grid, wherein we, end-users, consume power without needing to understand the component devices or infrastructure required to provide the service.
  • Backup – the type and frequency of IT backups that are being produced and where these are being stored. Or, if there is a “high availability” solution in place, where is the failover location. (Note that sometimes local duplication of hardware is considered a “high availability solution.) A basic understanding of this will be essential to understanding whether the stated RTOs and RPOs are even remotely achievable. This is not so much a technical issue as a logistical one. And of course you need to speak with those doing the backups as well as those in charge of the recoveries using these backups.
  • Storage technologies – how and where is your data stored?
  • Data reconstruction/resynchronization post recovery?

Of course, two great resources for information in the world of business continuity and emergency management are the Disaster Recovery Journal and the Disaster Resource Guide.

In the end, part of our job as business continuity planners is to facilitate discussions with various technology and business unit “experts” that will ultimately lead to solutions for real business needs resulting from disruptive events that will impact the organization.

TIP:  Last Week I sat in on a couple of webinars sponsored by SCORE.  The topic of the seminars was “The Five Steps to Social Media Success”… not from a DR or BC perspective but more from a marketing perspective (marketing a product, service, or YOU).  Lon Safko was the presenter and did a terrific job.  Lon has written a book titled “The Social Media Bible” and his website is www.extremedigitalmarketing.com  If you are interested in Social Media and how it can help you, I encourage you to check out Lon’s webinars on SCORE.

Advertisements

So, what do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: