Business Continuity Planning for Mathematicians...

There's a mathematician's joke (yes, mathematicians do actually have jokes) which goes like this:

1. Given an empty kettle, running water, a teapot, and a tea bag, how does a mathematician make tea? He fills the kettle with cold water, boils the kettle, pours the boiling water into the teapot, adds a tea bag, waits three-and-a-half minutes, then pours the tea.
2. Given an kettle full of boiling water, a teapot, and a tea bag, how does a mathematician make tea? He empties the kettle, thus reducing the problem to one that has already been solved. QED.
   

I'm reminded of this joke when I read some business continuity plans. A common recommendation in the industry is to plan for the worst possible case. You should, so the advice goes, plan for the worst thing that could happen (your building being totally destroyed) and plan for it happening at the worst time of year (during the Christmas rush, or just before an SEC filing).

It sounds like a good idea: if you can survive the worst possible disaster, then you must be able to survive a lesser (but more probable) disaster. But it's potentially an expensive one.

If the plan only deals with the worst possible case, then it is rather like the mathematician making tea. The only course of action open is to pretend that the worst possible case has occurred, resulting in an expensive and possibly time-consuming response and recovery.

A good plan should have the flexibility to be useful in a variety of circumstances. No incident will exactly happen as planned and some types of incident are more likely than others.

A good plan should provide the information required to react to the situation as it is, rather than the worst possible incident that might have occurred.

The Risks of SaaS (Software as a Service)

It looks like reality is finally destroying some of the software developers' Utopia that was Google.

Along with the recently announced layoffs, we learn that a number of Google services are being axed, including Google Video.

It's a reminder that a significant risk of Software as a Service (SaaS) is supplier viability.

While reliability may be an issue (for example, SalesForce.com has had some well publicized outages), it's important remember that a SaaS supplier's reliability must be compared with the potential reliability of services from the company's own in-house IT department. Often it is simply be too costly to provide the same degree of availability, support, and redundancy that a SaaS supplier could provide.

However, loss of a SaaS supplier is a more serious risk. If a software supplier fails, you can protect yourself with a software escrow agreement and continue as usual until software or hardware changes force the application to be replaced.

But if a SaaS vendor fails, even if you had a software escrow agreement and kept your own backups, could you replicate the necessary features of their data center in the necessary amount of time?

It is supplier viability as much as supplier reliability that is the risk with using Software as a Service.

Better check their books as well as their business continuity plan.