We're living in an age of confluence: the increased likelihood and magnitude of disasters¡ªnatural and man made¡ªand the emergence of mobile technology. Both are world wide.

It is also undeniably clear that our societies are becoming more and more organized around electronic communication; increasingly the cell phone and other multi-purpose, hand-held devices.

Disasters can be localized (e.g., a toxic waste spill at a single plant) or wide spread (e.g., an ocean-wide tsunami). They can occur within walking distance of IT servers or a continent away.

Not surprisingly, major wireless carriers like Cingular are establishing mobile disaster command centers with generators, housing and supplies for dozens of emergency workers, building quick response teams, and more. So, what can your IT organization do to be proactive?

Mobile Business Continuity Planning & You
The responsibility of the senior information officer extends beyond overseeing the development of vital documents such as continuity of operations (COOP) and emergency response (ER) plans for use in the event of a natural disaster or terrorist attack.

Each organization¡¯s circumstances and structures are unique, so a disaster preparedness plan will have to be tailored to suit its needs. It is important to recognize that there is no magic plan that an organization can purchase or create that will provide all the answers. There is no document that will address every situation and circumstance.

These new realities warrant a new analysis; one that studies how different, randomly occurring disasters could load or break a mobile communication system comprised of traditional software applications and the profiles of both users and converged voice and data devices.

The system that you analyze ¨¤ priori may be physically different after disaster strikes. For example, under normal conditions, hip-worn, handheld mobile devices may be ancillary to their power-grid-energized counterparts back at the office.

But, when disaster strikes, desktop PCs and legacy telephones may become less important. In fact, they will be irrelevant if their users are unable to reach them. This is where decision-tree and other multiple-scenario analysis tools such as Palisade Inc.¡¯s Decision Tree Suite can help focus your thinking.

By preparing in advance for any weakness in your overall system that are revealed by such analysis, some of the costs associated with the chaos that often occurs during an emergency may be mitigated.

The usual business metrics associated with a mobile application (e.g., total cost of ownership, extent to which the application contributes to the strategy of the enterprise, etc.) are not directly applicable to an app designed specifically for a catastrophic disaster, when priorities such as saving lives, rescuing critical assets and the like take control and concern for operating costs need to be suspended temporarily.

In preparing for a disaster of unforeseeable timing and severity, a consideration of the following items is particularly important in the design of any mobile system:

Redundant network connections

Extended battery life for mobile devices

Push technology for both email and application data

Emergency IT policies

One or more of your normal network connections may be unavailable during a emergency, catastrophic or other. Radio transceivers (walkie-talkies), on the other hand, available on some converged voice and data devices will work as long as their batteries last.

This means that mobile applications need an infrastructure that provides as many parallel paths as possible so that when one or more fail, there¡¯s still a fallback connection.

At the same time, your applications cannot get too much bandwidth: the best wireless apps use wireless the least. And, when backup connections are needed, switching from your primary to another one should be as seamless as possible.

Battery Life
When used in ordinary service, a nightly or other timely recharging of batteries usually keep roaming handheld devices operational virtually 100 percent of the time. However, in a real emergency, users may be thrown into life-saving or other vital duties and not be able to replace or recharge batteries. At such times, the value of battery life (and redundant network connections) is extremely high.

Emergencies may not end conveniently after you¡¯ve been putting your mobile device to heavy use. And, under emergency conditions, the power lines needed for recharging your batteries may be down.

Aside from the laws of chemistry and physics, battery life is determined by factors under the control of your software development, system design, and IT policy management teams: the amount of time and juice spent supporting the hardware and the software applications that run on handheld devices and the amount of time and juice required to support the transfer of information over and the maintenance of network connections. (I¡¯ll have more to say on this subject, in Part II of this discussion.)

Push Technology
Push technology is an important part of the emergency solution. A medic trying to stop the bleeding of an injured person can¡¯t pause to see whether or not he has received new instructions. But he or she does want to know when it arrives.

Push technology solves this problem. Most people are probably aware that BlackBerry pioneered push e-mail some years ago. Today, a number of other vendors (Microsoft and Nokia) have brought their own push e-mail to market.

Reducing the number of packets exchanged between server and handheld not only reduces latency but directly increases battery life as well.

But, in an emergency, pushing just email out to the end user isn¡¯t necessarily an optimum solution. Timely refreshes of application data also needs to be pushed out to emergency workers and their handheld devices need to notify them when these updates arrive.

With good reason, Blackberry has recently introduced another push solution; this one for updating application data as soon as it becomes available. Research In Motion has a platform called MDS that pushes both email and application data out to the handheld. In contrast, several other vendors can push applications out to a handheld, but that¡¯s not the same as pushing fresh data out to the applications.

Part II: Applications, Mail Servers & IT policies.

---

About the Author
Marcia Gulesian has served as software developer, project manager, CTO, and CIO over an eighteen-year career. She is author of over 100 feature articles on IT, its economics, and its management.