EnterpriseMobileToday WindowsMobileToday

Home | News | Reviews | Features | Tips | Mobile Product Watch | Forums

Trend: Planning For Reliable Mobile Communication

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.

    I¡¯ve already mentioned that a mobile application developed specifically for use by a worker trying to function normally while coping with a disaster should not drain the battery unnecessarily, be based on push technology, and have multiple (alternative) network connection paths available when its primary one fails.

    The mobile application¡¯s small user interface should use checkboxes and radio buttons rather than text fields wherever that makes sense. Doing so can reduce network traffic (and ultimately battery usage) to a certain degree.

    Doing so also can reduce the time required for the user to input or read basic information to a considerable degree. And, selecting a checkbox takes much less time than typing a (possibly imprecise) message into a text box or a text message, using either a real or virtual keyboard.

    Virtual keyboards, tapped serially with a stylus, are available in commercial products, typically in the familiar QWERTY layout. But, stylus keyboarding requires intense visual attention, virtually at every key tap, which prevents the user from focusing attention on text output¡ªa time consuming process.

    For this and one other reason, real keyboards are to be preferred over virtual ones: styluses are easily lost (that¡¯s one of the reasons they¡¯re sold in three-packs).

    Finally, applications used by emergency workers should exploit integration with native handheld device functionality whenever possible. For example, once a newly updated telephone number is pushed out to the user by an application running on a backend server, he or she should be able to click on the phone number and have the phone dial launched automatically.

    IT Policy
    Before discussing the importance of IT policy in emergency situations, I want to stress that you need to build emergency preparedness into the culture of your organization.

    Orientation sessions for new employees should include an overview of the preparedness plan and all employees. Key employees especially should periodically participate in mock exercises. Today, however, many organizations have yet to seriously consider the impact not taking these steps can have on the Net Present Value (NPV) and other financial measures of their operation.

    For the most part, emergency workers will be firemen, policemen, medical personnel and other public safety workers carrying out jobs for which they¡¯re trained. But, IT and other workers trying to preserve their organization¡¯s assets on an ad-hoc basis, sometimes with little or no formal preparedness training, may also be called upon to play an important role.

    Furthermore, as recent events have shown, members of any one of these groups may be physically unable to reach the site(s) where their help is needed. In such cases, it may be desirable, where possible, to add certain mobile computing functionality, normally available only to pre-designated staffers, to those other employees whom random events place at critical sites.

    At the same time, it may be desirable to disable battery-draining applications and functionality that are not needed for emergency work.

    For example, the administrator can turn off power hungry apps that aren¡¯t needed (perhaps GPS) or disable functionality like the extra layers of security that are so important for normal business operations, but which can degrade the performance of applications whose only purpose is the handling of a time-sensitive emergency data.

    These kinds of changes can be achieved rapidly by assigning preconfigured profiles to mobile users or groups using the BlackBerry Enterprise Server (BES). I cite this particular server because of its widespread use by both public and private-sector emergency personnel worldwide.

    Mail Servers
    It is possible that a crisis could render useless a system component such as Microsoft Exchange or Novell GroupWise that the handheld messaging system relies on. To enable you to circumvent these e-mail servers, RIM has introduced PIN-to-PIN messaging that allows one BlackBerry user to exchange messages with another by using the personal identification number (PIN) of the other device instead of the recipient¡¯s e-mail address. The U.S. Federal Emergency Management Agency is one of the agencies exploring the use of this PIN-to-PIN communication.

    Recognizing that administrators need to have 24/7 access to their servers, software publishers like Id¨­korro Mobile have introduced mobile apps where administrators can have complete control of a network and its servers (BES, Active Directory, Lotus Domino, etc.) virtually anytime, anywhere.

    Finally, as things change in the organization ¨C people come, people go, programs fold, programs start ¨C the plan(s) has to be updated to reflect these changes. Good luck!


    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.

    Story Courtesy of CIO Update

    Trend: Planning For Reliable Mobile Communication





    The Network for Technology Professionals

    Search:

    About Internet.com

    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers