How To Mobilize Your Legacy Applications
By by Pat Brans
In most companies, there is some need to make legacy applications available to mobile workers.
In virtually all cases, road warriors only need a part of the data or functionality of these software packages. You don't want to give them everything they would get in the office for three reasons: first, it's cumbersome, or even impossible, to send all the data over the air and have a big application run on a constrained computer, such as a smartphone; second, access control is more critical when applications designed to be operated inside company walls are being used out in the open, so you have to limit the data sent to the device to just what that user needs; and finally, mobile workers have different business processes and don't want to run through the application logic in the same way as a worker behind a desk. You want mobile applications to fit naturally into the work day of the employee who's away from the office.
The term mobile enterprise application platform (MEAP) loosely designates a category of products providing services to help make legacy applications available on mobile devices. Such a platform may provide functions to help in software development, and it may provide functions to help deploy and run the applications. Each platform vendor has a different strategy for providing access, and no single MEAP can provide access to all applications.
Furthermore, you might think a given platform is a good choice for one set of users in a given job category and in a given geography, but it might be totally inappropriate for another set of users. Don't make the mistake by thinking that you can just buy a MEAP and then "automagically" plug in all your applications.
When considering a platform, take a close look under the hood. Here are three dimensions to consider when it comes time to provide mobile access to your legacy applications:
1) Online, offline, or occasionally connected
Online: The advantage to an online solution is you can get away with having little (or even no) logic running on the handheld.
Beware: Although networks have improved and you might get coverage in the areas you expect your mobile users to be, you still won't get the response time you'd get in the office. So unless your application limits exchanges to occasional short queries and responses, you might think twice about implementing a solution requiring constant connectivity.
Offline: The advantage to an offline solution is the user gets good response time and doesn't have to worry about finding network coverage when in remote locations. You just download the necessary data to the device in the morning and then upload any changes in the evening. Synchronization between the handset and enterprise servers might be through a wireline connection or it could be over wireless. The point is you don't connect the rest of the day.
Beware: In cases where data can be updated by mobile users, you have to work out how to handle conflicts--that is, situations where the same data is modified on more than one device. Also you have to be careful to partition the data, so you don't just push everything to every device. Otherwise, you'll expose confidential information to the wrong user.
Occasionally connected: Between the two extremes (fully online and fully offline solutions) there are different mixes of the two. For example, you can have major downloads and uploads occur in the morning and evening, but throughout the day--where there is coverage and when application logic dictates an exchange--the device can connect to an enterprise server.
Beware: Your poor mobile users might find application behavior inconsistent. The program might ignore the user while it's trying to exchange with a server. Response time from the user's point of view may be highly variable and the worker will have no idea why.
2) Browser interface versus bespoke application on the device
Browser interface: If your legacy application is Web-centric, and the functions carried out by mobile workers are simple and light on data, you might get away with giving them access through a standard browser. Your biggest concern in this case is reformatting the content so it fits nicely on the handset. To do this you can either use the appropriate tags in the .html files or you can have an intermediate server read in the pages and arrange the fields to be more mobile friendly.
Beware: Although this idea is seductive, complex application logic can turn the user experience into a nightmare when presented through a browser.
Bespoke application on the device:
You can provide a more natural interface to the mobile user if you develop an application designed for his or her business processes and work environment. Unless your user population likes to tinker with technology, you can make their day run more smoothly by tailoring the application to their needs.
Beware: Any time you have an application designed for a relatively small user base, you pay a relatively high price for development, support, and any new releases.
3) Flat file versus relational database
Flat file: Some applications only require use of simple data sets, such as product lists. In these cases, the communication between the legacy package and the mobile program can consist of file exchanges. It's easy to dump the appropriate list to a file and send it to the device where it's used by an application on the handset. The same system can be used to send changes upstream.
Beware: If you have a lot of data and mobile users make updates, managing flat files becomes a lot of trouble. Any time you add information, you either add it to the end of the file or you re-sort everything else to maintain order. When you delete something you encounter a similar problem.
Relational database: With large or complicated data, you're better off using the relational model. Advantages include easy updates, quick searches, minimal data redundancy, transactional integrity, and relatively easy conflict resolution.
Beware: A relational database management system is more expensive and requires higher levels of skill to configure and administer.