Handheld Devices Need HandholdingHandheld Devices Need Handholding

My commentary last week referred to data-related issues in identifying Iraqi insurgents for allied soldiers on the move. An obvious solution would be for the soldiers to carry mobile devices (e.g. laptops, PDAs) to verify identity on-the-spot. The trouble is, application and data synchronization for widely distributed mobile devices is still an imperfect science. It all boils down to the question: What's your poison?As many of you know, there are several challenges to creating a custom solution for mobile users - the weight/size of the unit, the operating system, networking options, the degree of hardening, the cost, and more. From an architectural and ROI standpoint, perhaps the greatest challenge is designing the application & data layers to work seamlessly in the distributed environment, and the cost in supporting this over time.

There is a spectrum of options for application and data synchronization on hand-held devices, but in broad terms these reduce to basically two options: design for "constantly connected" mode, whereby the application is always connected to the server and to the central database, or for "constantly disconnected" mode, where you cannot rely on network connectivity.

The advantages of being connected to a central application server & database (e.g. bar-code and RFID readers, hand-helds used for car rental return) are obvious and immediate: You can create a single application for networked devices (e.g. office desktops) and mobile devices (e.g. laptops, PDAs). Application architecture is simplified, data architecture even more so. In essence (and over-simplifying it somewhat), the application and database need not be mobile-aware. It is cheaper to design, build and deploy the application, and it takes less ongoing support and infrastructure for application/data synchronization. Unfortunately, the drawback to this approach is also significant: the mobile device must, at all times, be connected to the network. This limits the solution to "localized mobility," e.g. car rental locations, and has other implications. There are alternatives - devices that offer local caching facilities can tolerate short-term network discontinuity for "mostly connected" environments, and satellite-based communications offer more extensive and continuous mobility - but these have their own problems. The other option - one that is widely prevalent - is to take away the need for the device to be continuously connected. A separate, mobile version of the application working alongside a mobile/embedded database (e.g. Microsoft SQL Server Mobile or Sybase SQL Anywhere) offers first-class application and data capabilities for complex business requirements. Unfortunately, this comes at a huge price in terms of application and data synchronization, leading to more complex application and database design/development and significantly higher support infrastructure for application/data synchronization…all of which lead to longer time-frames and higher costs. For example, would you want to spend the time and money for a custom mobile solution for only 20 mobile users? Probably not.

The fact is, your choices in mobile solutions are more limited than they might appear.

Rajan Chandras is a consultant with a global IT consulting, systems integration and outsourcing firm, and can be reached at [email protected].My commentary last week referred to data-related issues in identifying Iraqi insurgents for allied soldiers on the move. An obvious solution would be for the soldiers to carry mobile devices (e.g. laptops, PDAs) to verify identity on-the-spot. The trouble is, application and data synchronization for widely distributed mobile devices is still an imperfect science. It all boils down to the question: What's your poison?