How To: Get Your Data Anywhere
By Pat Brans
If you are looking to get data from your enterprise's core business applications to the wide array of device types used within most companies today, you have a plethora of choices to make. There are also several concerns to watch out for.
Your first step will be to evaluate what method of data communication best suits the needs of your various user groups. Can simple SMS be effective, or is a more robust option necessary? All of these options bring their own strengths and weaknesses.
Next on the agenda is considering how that critical data will display and function for the user on a mobile device. Important considerations here include determining what level of synchronization with back-end databases your mobile applications will require; how you'll handle multiple mobile users accessing the same data sets; and the myriad viewing options that can change with each device operating system.
Finally, you'll want to consider how your back-end data interface is going to behave for the mobile user. Is the goal to mimic the desktop experience? Is this possible on the form factor they're using? Different devices require different logic, yet the ultimate goal is to interface seamlessly with back-end applications.
As the steps outlined here illustrate, there is no one-size-fits-all solution when it comes to enabling access to your data from anywhere on any device. Knowing your user groups, understanding your business processes, and having a deep understanding of the requirements of your back-end applications are the keys to unlocking a successful mobile data strategy.
1. Thin Client Vs. Thick Client
> Use SMS if you can. The easiest way of getting data out to a mobile device is by sending simple text messages. If your business application lends itself to exchanging short text messages with users, SMS might be the way to go. Example: Dispatch can alert a field technician with a text message; the tech can accept or reject the request by replying with a text message.
Beware: SMS is not always reliable. Messages might be late arriving, or they might not arrive at all. To avoid nasty surprises, check with your service provider to see if they have a Service Level Agreement on text messaging.
> Mobile applications built for the mobile user. If the business processes of your users are elaborate, or if they need a lot of data, consider an app that runs on the handheld. For example, a visiting nurse might need to record visit start/stop times or view patient records to enter details.
Beware: Apps running on the handheld may tie you into a limited number of devices. On the other hand, role-specific apps naturally limit your user base, so you can decide to only support certain handhelds for certain roles.
> A browser-based interface is relatively easy. If your apps are web-centric, consider this approach. Continuing the dispatch example, once at the job site, the tech might use a browser to look up parts availability.
Beware: Browser-based apps need constant connectivity. If your app needs access to core phone features, such as contacts or location, look for other options. A direct HTML interface won't provide a good user experience on a handheld. You need HTML code that accounts for different device types, or middleware to convert the desktop interface to a handheld-friendly UI.
2. Rendering Data On The Device
> The world can be flat. For simple and small data sets that have fixed amounts of data, you can get away with "flat" file representation. For example, if you want to send each sales person a list of clients to visit, that list can be represented in a text file sent to the handheld.
Beware: If you need users to update the data, the synchronization process gets complicated with flat files.
> Complexity demands relational representation. A relational database management system allows you to do powerful things with your data. Data are indexed, so searches are quick. Synchronizing updates is easy, and you can even use transactions to make the updates atomic: if the synchronization process is interupted, the database remains consistent.
Beware: With complex data sets and many mobile users, you will have cases where more than one user updates the same data. Make sure you are clear on how such conflicts are to be resolved.
3. Back-End Application Interfaces
> Sometimes, less structure is more. Unstructured data -- data that are difficult to index and order because they are not in a homogeneous format -- might be helpful to your mobile users. For example, if pricing information is stored in a spreadsheet, downloading this to mobile devices is an easy way to make the information available to a sales force.
Beware: Given the multitude of device types, make sure all handhelds have appropriate tools for viewing unstructured data in the format you send it.
> Mimic the desktop. If you want your mobile users to work off the same application logic as desktop users, mobile access should mimic a desktop client. For example, the field tech might order parts by using the same application he would use in the office. If the application is web-based, he can do this with a browser. In other cases, software on the mobile device might connect to middleware that
uses adaptors to access the same application.
Beware: When applications are used in a mobile environment, a session is much more likely to terminate in a hung state. Make sure your back-end application can tolerate hung sessions.
> Look for the logic. When mobile users have different processes, it's more natural to have them work off the same data set as the back-end application, but to follow their own logic. In the visiting nurse example, the best thing to do is download the data to the mobile device and have the application run independently
of the medical records software used in the office.
Beware: The update process might get interrupted, leaving the data in a state that could cause problems for the back-end application. Make sure you have a reliable synchronization process.