Most large companies keep a significant portion of their workforce out on the road. After all, you can’t compete if you don’t have your people out generating leads, helping solve clients’ problems, and generally interfacing with the world outside company premises.
To do their jobs well, most mobile workers need information. The sales person needs to know the history of interactions her company has had with the client. She needs to know what products the client has already bought, and she needs to know pricing and configuration information on products the client is likely to buy now or in the near future. The field technician needs a history of equipment repair. He needs access to product specifications and the parts catalog, and he needs to be able to order parts. The inspector needs to view regulations and update forms and have those updates posted to company computers. The delivery driver needs an inventory of what he has in his truck. The traveling executive needs key business metrics.
These are just a few examples of the information needs of mobile workers. Many companies keep this kind of information on their mainframe computers. Applications they purchased or developed years ago still manage this data, and it makes sense to continue using these applications and to keep the data centrally stored. The trick, however, is to develop an appropriate strategy for getting this information to the mobile worker while maintaining data integrity and respecting company IT policies.
In thinking this through, a good place to start is by asking some questions about what is really needed for the mobile worker. Does the mobile worker need immediate access to data or can she synchronize once a day and in the meantime work off data on the mobile device? What happens if two mobile workers update the same data on a given day? Do you keep the data from the last person to make an update or the last person to upload his update? Or, do you bring the conflict to the attention of a line-of-business manager?
Is a given mobile worker going to be able to look at all data or do you need to partition the data so that, for example, John gets to see data concerning only his clients, and Jane sees data from only her clients? You may need to refine this question still further and ask if John should see all fields of all records concerning his clients. For example, he may be visiting Acme Company on the same day his colleague in the accounting department is updating Acme’s credit information. You don’t want their updates to interfere in any way, so you probably have to give John only a subset of data, and that subset may be different from what he would get if he were sitting in front of a desktop computer.
You need to think about data dependencies and transaction integrity. Updates to one table might make sense only when another table is updated at the same time; in such a case, if the synchronization process fails before both tables are updated, you might wind up with consistency problems. This kind of problem might be handled by using transactions during synchronization; and, of course, you have to make sure transactions can be rolled back.
The answers to these questions determine the kind of solution you put in place to get mainframe data to the mobile worker. In many cases, it’s sufficient to unload data from the mainframe in an overnight batch process and then post updates the next night as part of another batch process. The important thing is to not get carried away implementing an overkill solution.
When thinking through your strategy for getting data to mobile workers, make sure you ask the right questions early in the process
Courtesy : http://www.mainframe-exec.com