Continue in 2 seconds

Always, Almost Always or Occasionally: The Adjectives of Mobile Computing Architectures

  • March 14 2003, 1:00am EST

Is it rude to walk into a crowded elevator with your cell phone attached to your ear and continue your conversation to your destination floor?

I think I’ll defer questions of etiquette to Miss Manners. However, I believe I am qualified to say that if you are going to have an elevator cell phone conversation, it is a best practice to let the person on the other end of the line know that your about to get on an elevator. As most of us have experienced, your cell phone connection will noticeably degrade and depending on your cell phone, service and the elevator itself, you can easily lose your connection mid-sentence.

The idea of an “always on” interconnected world with wireless service available on every inch of the planet is often mentioned as one of the necessary precursors to truly pervasive computing. While such a world will more than likely become a reality one day, it may take a while to get there. For the foreseeable future, we live in an “almost always on” or an “occasionally connected” world. This reality, unfortunately, does not just mean poor cell phone service in elevators, rural areas and cold spots between large skyscrapers, it means mobile computing needs to adopt different architectures depending on the mobile application’s function and its user base.

I am using the term mobile computing in a very broad sense here. The diversity of mobile devices is increasing exponentially. For the purposes of this discussion, I’ll define mobile computing as the entire spectrum of current mobile capabilities – from the laptop that many of us lug home at night to the PDAs that are occasionally tethered to our PCs down to wireless PDAs and Web phones.

In this context, mobile computing is not defined as wireless computing. Mobile computing does not require a wireless connection. Having a wireless connection is just one of the architectural choices of mobile computing and the persistence and recoverability of that wireless connection is the crux of this discussion.

The adjectives, always, almost always and occasionally, speak volumes on the underlying mobile architectures. In an always-on implementation, you may be mobile and untethered but your system’s wireless connection is providing your application a lifeline back to its source. This lifeline cannot be broken. If it is broken, your system does not function. This allows a true thin-client implementation. This is the current implementation for most wireless applications today.

While today many mobile applications assume an always-on world, that world does not yet exist. Users of wireless applications have become complacent to lost connections, application restarts and lack of service in different locales.  This limits wireless adoptions to true technophiles who sympathize with wireless complexity and don’t mind redoing a little work as their application has to restart when their mobile device moves from one hot spot to another and attempts to switch subnets.

While a truly always-on interconnected world still alludes us, an “almost always-on” world is a reality today at least in some locales. The addition of this one word, almost, to the application requirements changes it architecture significantly. The application cannot blindly assume connectivity. It must sense its connection and be able to re-establish a connection dynamically and provide some level of application functionality and information persistency when the connection is not available. This may seem like a tall order but the advent of Web services holds great promise for the almost-always connected app. A Web service architecture of loosely coupled, asynchronous communication fits well into an environment that is almost always connected. This architecture implies a not-so-thin client that has some application functionality in a non-connected mode and can also queue up work and re-establish connectivity dynamically when the connection becomes available again.

The occasionally connected application, one that thrives equally well in a connected or non-connected mode, will for the foreseeable future be the mainstay of mobile applications that require a rich feature and functionality set. Occasionally connected applications can differ widely in implementation but typically have both a thicker client as well as a local data store. The best example of an occasionally connected application is e-mail itself. Most e-mail applications have the capability to work offline, allowing you to get work done while on the road or late at night at your kitchen table after the family is in bed.

The occasionally connected application does deliver rich functionality but not necessarily seamless functionality. You can be productive with something like e-mail in a disconnected mode, but if you forget to sync your local mail store before leaving the office you could be missing the key e-mails you had hoped to respond to that evening. You could more than likely dial in and attempt to retrieve them, but the 8MB PowerPoint presentation a colleague of yours e- mailed you that afternoon may turn your dial-in attempt into a lengthy waiting game. Clearly even the occasionally connected application could benefit from dynamic connection detection and improved automated actions based on the connection.

The overriding reason to develop mobile applications in the first place is to take advantage of the “dead time” when out of the office or on the road. Assuming you have any outside interests at all away from work, time away from the office isn’t dead time by any stretch, however, from an organization’s perspective it is.

The key design requirements for mobile computing applications are real-time data access, application richness and speed. How these factors are weighted depends on the application’s function. For real-time stock trading systems or any wireless messaging systems, real-time connectivity and speed are key. However, for other applications such as CRM systems built for the mobile sales force, it is richness that is king.

Siebel Systems understood this when they released their first thin client implementation back in 2001. Siebel 7 is a browser-based zero footprint client with a brand new Web layer providing the rich feature and functionality set that their users had grown to expect. With Siebel 7 being now a Web-based thin client, what did Siebel do for the true road warrior? Siebel could have asked their users to dial in from their home or hotels at night. However, they knew they needed to deliver a truly rich client and take advantage of all available dead time regardless of whether or not a network connection was available. To accomplish this, they delivered a reincarnation of their traditional mobile client but now as a mobile Web client. The Siebel 7 mobile client is still Web-based, has the same code set as their thin client, but runs off of the client PC’s personal Web server and accesses a local replicated database. It allows complete untethered functionality and queues local changes into an outbox for replication the next time the user is connected.

Selecting the appropriate architecture for your mobile application is not a black or white choice between thick or thin. Both heroin-chic and obesity are out. A healthy AMA-approved weight is the appropriate choice for most mobile computing implementations in our current occasionally or almost but not quite always connected world.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access