IBM BCRS offers Self Assessment Tool

by Administrator on March 8, 2007

Take a look here if you are wondering whether your organization is adequately prepared for the possibility of a disaster.  IBM’s Business Continuity and Recovery Service has cobbled together a little DR self assessment.  Good for flashing 12s.  Not sure it is deep enough for real planning, though.

{ 5 comments… read them below or add one }

Aleph Null March 8, 2007 at 3:01 pm

Before I used this tool, I was wondering whether our firm is prepared for disaster (that in itself should say that we are not). After I used this tool, I was still wondering whether our firm is prepared for disaster. This “tool” literally asked me 12 questions and ended with “Here’s what you answered.”

I propose a better tool. For each business function (email, billing, production…) state how much money per minute of downtime you lose. Prioritize the business functions in chronological order for recovery. Then figure out how long it takes you to recover each function from disaster. Simple equation: Recovery Time (minutes) x Downtime cost ($/min) = Total Estimated Loss for Disaster. Then take that worksheet to your boss and ask how he feels about your loss potential.

There’s another equation I’ve heard is quite popular in this field (since most managers don’t really pay attention to the needs of DR): Severity of Disaster + (Time to Recover Resume + Time to Update Resume)^3 = Ease of finding a new job.

Administrator March 8, 2007 at 3:07 pm

My thought exactly, AN. I especially like the last equation.

DR shouldn’t be bolted on, it should be built in.

Aleph Null March 8, 2007 at 3:46 pm

“A rose by any other name would smell as sweet” – Shakespere

Apparently our good friend Romeo has never had a conversation with C-level management. To them, unless that rose has a high level buzzword branded on the stem, carries no smell. Upper management has been inundated with “DR plan, w00t!” and “You need to have a DR plan and DR hardware” to such a degree, that although HA/CA (High Availability and/or Continuous Availability) planning is a much more spectacular flower with a more pleasing smell, they still want the rose. This is where the DR as a separate entity comes from, really. To some degree I agree with the outcome, but not the reasoning.

HA/CA architecture allows business function to continue even through disasters. Clustering services and housing failover boxes in remote locations will ensure that failure is met with fault tolerance. At the same time, DR (as a bolted on feature, like data backup) is an excellent way to simultaneously protect data from operational failure as well as disaster (again, assuming the data protection architecture is also built for HA/CA and offsite replication just like any other business function).

So essentially, I agree that DR should be built in, but I think that to some degree, there is function in attacking the job from the bolted on angle as well. Now all we need to do is sell the CIOs, CFOs, and CEOs on it. I think a high level marketing campaign (maybe similar to the IBM tool) is in order.

Administrator March 8, 2007 at 3:59 pm

AN, to me, DR is a bolt on and has been since IBM announced its BCRS in the late 1980s (making my first book a whopping success by the way). The problem with open systems is that, if you do not design for resiliency and recoverability, you need to create almost a one-for-one replacement of everything on the floor. Most n-tier client server apps are also not designed for recoverability (using message oriented middleware, for example). And of course you don’t want to get me started about the storage layer…

In most shops, there is virtually no management foo to enable you to respond proactively to burgeoning issues before they become disasters.

Hence, I repeat my earlier premise. We need to design resiliency into our software and infrastructure. Then we won’t need to go begging to the front office for funding for bolt-on schemes.

I think data mapping is the most important outcome of a DR/BCP project. Done right, you can map data flows from business processes and their supporting apps back to specific infrastructure and soft cost (labor) components. After I build such a data model, it is incredibly useful in other ways as well: not only does it identify the data protection/DR requirements of my business, but also the security service requirements, and the compliance handling requirements.

Heck, if someone from the front office calls and asks how much money it would cost to support a new widget-making line of business, I can consult the data model, find a comparable business process and see its associated costs, then get back to the guy with a pretty good estimate. Now I am the go-to guy for the front office — a good thing.

If you want my full rant on this, come to one of the DR events I am doing with TechTarget. I will be in Washington DC on the 27th, and Boston (Waltham) on the 29th, and in several more cities around the US thereafter. I am also doing some travel for CDW to multiple cities on this subject. Not as deep a dive though as the TT Storage Decisions events.

Robert Pearson March 10, 2007 at 1:02 pm

RE:
“Hence, I repeat my earlier premise. We need to design resiliency into our software and infrastructure.”

True. Very true.
But we need more.

Simply Designing, purchasing, and Implementing a Backup system does not ensure Recovery. Recovery is the whole purpose of Backup systems. The Recovery phase is generally assumed. It is rarely tested until needed. The same is true for Disaster Recovery. Both of these are “circular” processes. One does not exist without the other.

Just a reminder.
Backup systems are in the Information Integrity Area of Interest.
Disaster Recovery is in the Disaster Recovery Area of Interest.
Two completely different areas.

Anything that will enhance, improve and make these vital processes less of a burden on over-worked staff is much needed.

Automate? Automate what?
Automation was supposed to solve all these problems. It might have if IT management had not seen a way to become “little” millionaires overnight by reducing staff to ridiculous levels.
They got rid of all the people who knew what the proven processes were and how they worked.

When the pioneers were moving West they were forced to lighten their wagons to make it. They threw out the possessions of a lifetime, everything except the seeds to plant crops with.
What are the “seeds” of IT?

Previous post:

Next post: