Developing DR/BCM Strategies: IT as a Diplomat?

I’ve been catching up on some reading, which I’m way behind on, and came across the Editorial in the Winter 2011 Disaster Recovery Journal (DRJ).  I came across and article about “Tiering Applications for…DR/BC.”  Basically, ensuring that applications are restored and recovered in priority order to ensure they support approved RTO’s and the right services (and systems) become available when expected.  Nothing wrong with that…  However, there was a comment within the article that did catch my attention and I thought I’d write about it. 

The comment revolved around the point that IT should be the facilitator or diplomat when discussing what applications are required.  I would go so far as to say it was heading in the general direction that IT should be managing the overall program and any BCP/DR discussions.  I’m all for IT being involved but I don’t think IT should be the overall facilitator.  I’m speculating of course, as the last comment wasn’t written into the article – it was just my interpretation (respect to the author). 

It got me thinking about a few things that weren’t addressed in the article and what it alluded to.  Quite possibly there were part of an original article but removed due to space/wording constraints.

  1. Bringing IT in as a Diplomat – IT as a diplomat for who?  There are two half’s of the organization; IT and Business (FYI, in my view everyone is part of the business but for arguments sake I’m making the two distinctions.)  If IT is to be the diplomat then it means there are more sides involved; IT, Business and….who?  if not, then it may seem as though the Business or someone else, isn’t being diplomatic – they’re bing difficult.  IT can’t be the diplomat and the other side – business – not be diplomatic as well.  IT has a vested interest in the outcome of any discussions but they must be on equal footing with other partners.  If not, one side is going to loose out or feel as though they are being lead down a path they may not want to go (not in all cases of course).   Sure, IT can represent everything IT related but it can’t be representing areas it doesn’t already have authority/involvement over.  I think it should really say that IT behave as diplomatic as can be when discussing the technology needs of the organization, which is set by the business (or executive management).  And if IT is being diplomatic and listening to what the business has to say, so too should business units and executives listen to what IT has to say.  Diplimacy must be on the side of all parties involved, not just one: IT (in the case of the article anyway).  
  2. IT Leads Critical Application Discussions – Well, I agree to a point.  It’s up to IT to identify the critical applications needed to support the recovery priority of the services required as soon as possible, as determined by the business.  The business determines what services they have that are most critical and when they need to become available after any sort of outage (disaster, power outage etc) but they don’t choose the applications.  The applications are matched up to the services and their priority order and then IT states what applications are required to support the recovery priority.  This approach must be taken if the restoration and recovery efforts are to meet the needs of the organization.  If IT doesn’t do this exercise and work in partnership with Business Units, you’ll have applications (and their related components like servers etc) available but no people or reason to have them available.  The services you do need up and running won’t be available.  Don’t just think the service/application with the most users is the most critical – you might get a rude awakening one day. 
  3. IT Defines RTO’s – No!  No, no no and no again.  It don’t agree with this comment at all.  The RTO’s are defined by three things: 1-Business desire/need/want; 2-IT capability/ability and 3-Executive vision/expectations.  Let me explain.  When a Business Impact Analysis (BIA) is performed, the question is usually posed to the business of what their desired RTO should be for the processes/services that have been identified.  I’m sure you’re all aware that most of the time the answer of 24hrs (or less) crops up.  OK, so that’s their desired RTO as they see it.  The BCM/DR professional documents these RTO (and services) in order of the RTO and presents this to Executives.  The Executives in turn should ensure that what the business says is critical for recovery (in sequential order and in RTO) actually meets the needs of the organization.  If telecommunications can be down for 12 hours it might not make sense to make sure that Marketing is up and running in 3hrs (after a disruption/disaster).  I’ve seen it myself where an executive was ‘embarrassed’ to see that the service priority listing didn’t reflect the vision of the executives.  After some discussions, rework and negotiations (and re-prioritizing the list), a new list can then be approved and provided to IT.  IT in turn now matches up systems/applications with the organizational need and identifies deficiencies.  The capability may not be available to do what is required and now IT may make various proposals to make it happen: suggest changes to the list, seek financial resources or seek external partners for assistance.  But in general, IT does not decide what the RTO will be for any service.  It must be a joint discussion between Business, IT and Executives. 
  4. 3rd Party Involvement – The problem with 3rd party involvement, is that if the consultants represent a corporation that sells other services or has established partnership, you can bet that the strategy you’re developing is going to be directed to support them…no you.  It would be like auditing audit or policing the police or having a fox watch the hen house.  You get the point.  3rd party vendors are great to help corporations – I’ve seen and experienced the good things they’ve done for companies – but they want to sell services and floor space (i.e. DR sites) because that’s how they make money.  Be fully aware that if you have a 3rd party consultant come in from ABCinc – and ABCinc is a DR service provider – the recommended strategy is going to lean towards you buying their services, rather than fully investigating the potential of your own in-house capabilities. 

 Overall, I agreed with the article and support the idea of teiring application recovery – hey, it only make sense.  If all you need is a Mini Austin to get you moving right away, why pay for a limousine?


 “Heads in the Sand: What Stops Corporations From Seeing Business Continuity as a Social Responsibility” and

“Made Again Volume 1 – Practical Advice for Business Continuity Programs”

by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3

Available at, &


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s