Disaster Recovery is typically years of planning for a major event where pandemic planning is essentially determining which pieces of your business is non-critical so that you may take it down gracefully because you don’t have enough people to run it. How many of you have business processes that are able to facilitate that question?

Years ago, I was responsible for figuring out which databases were critical to an organization I worked at because the century’s biggest flood was coming. What if we had to relocate and run our business else where? Which systems were the most critical and which databases would we need to make available somewhere else? We were situated at the lowest level in the city, and would likely have to move if our core flood prevention methods failed.

Now turn the tables for a minute – if I had a team of ten database resources working everyday to keep the systems supported, two system resources, a security guard and a building maintenance resource, how many could be affected by a pandemic if one should hit my city? Who would decide what needed to move? Or more likely – what database operation or support function didn’t need to get done for some undefinable future?

Now even more likely, if you have a call list, what are the chances that someone on that list would be affected? How would you contact the others to get replacements if the city or area is engolfed in chaos. As the presentation suggested, many wouldn’t want to leave their homes for fear of being affected by others. Do you have a plan in place by your business architecture as to priorities for keeping your minimum technologies running?

Just a few thoughts that got me thinking about what I might suggest to a few of my customers that have been thinking in reverse for years. Business Architectures must be in place and current in order to make such rapid decisions, and the value of these exercises is most often over looked.