April/May 2002

Whether you're sending delivery details to truck drivers or catalogue lists to reps, mobile data can open up new horizons for you. But there are various decisions to make before you start, and an array of new technologies to get your mind round. Marcia MacLeod offers a fascinating introduction

One of the great attractions of wireless networks and mobile data is that by harnessing these technologies, you or your staff can take corporate data with you wherever you go ­ or at least access it as if you had it with you. In some cases there may be no need to go the office at all.

But the ability to exploit mobile data brings its own problems. How, for example, do you ensure that data used by your mobile workforce is consistent with data held on your main corporate network?

The secret of avoiding possible discrepancies, in a lot of cases, is data synchronisation ­ or what is known in the industry as "data sync". But what is it? How does it work? Is it as easy to set up as some of the suppliers would have you believe?

 

"Data synchronisation is the black magic art of taking data from two sources and making sure it is the same on both sides at all times, regardless of any changes or additions." That's how it's summed up by David Hofacker, UK country manager of Extended Systems, which is one of a growing number of specialists in this field.

Basically there are two approaches to synchronising data: browser-based and true data sync. The browser-based method involves using a Web-enabled device ­ normally a phone ­ to access the corporate network over the Internet. You're not actually carrying the information with you all the time ­ you're downloading it from the server or uploading from your mobile device when you need it. A field engineer, for example, could download his or her next job and upload data on the action they've taken.

Data sync, on the other hand, involves downloading a sub-set of data on to the mobile device ­ this time usually a PDA or laptop ­ and then accessing and manipulating it offline. At certain regular times, any changes made on the client (mobile device) or server (for instance Web server or mainframe) are synchronised so that data is consistent to all users.

"PIM", or Personal Information Management, is the " killer application" for data sync, since users need to keep calendar, email and address lists synchronised at all times; but clearly it can handle much more sophisticated and complex functions as well.

Each method has its advantages and disadvantages. In some cases, an individual ­ certainly an enterprise ­ will need both. "Whether you need true synchronisation or browser-based connectivity depends on the person and application," says David Hofacker of Extended Systems. Miles Powell, director business development for mobile business at Aspective, agrees. "Who are the people using the mobile devices?" he asks. "That's what you have to ask. What are their requirements? What data do they need, when and how often?"

Three main criteria have to be examined before you decide which to use: reliability, cost and convenience. Although revolutionary in its day, GSM digital phone technology has come to be regarded as somewhat unreliable and expensive to use. Suffering a dropped connection in the middle of checking stock availability, for example, will annoy both salesman and customer, while the cost of using a GSM device to configure products, check stock availability, place orders and so on could well wipe out any profit made from the sale. Coverage of GSM networks is prone to gaps, too (some commentators unkindly describe it as "full of holes"), meaning that employees could find themselves with no connection on some occasions.

These shortcomings have pushed some users towards data sync instead of browser-based systems, but GPRS will bring new opportunities for the browser approach. "Browsing comes into its own with GPRS," says Chris Oswald, managing director of Equisys. "With GPRS, you can have a handheld permanently connected to the Internet, and hence to back office. Users are charged by data transmitted, not by time, whereas with data sync, users pay whether they are looking at the data or not."

Chris Wilton, managing director of Red Tower, adds a note of caution, though. "GPRS is a staging post to 3G, and will therefore never be perfected," he warns. "3G needs new networks ­ and we won't get a convergence with 3G for at least ten years."

And no one knows for sure how cost- effective GPRS or 3G will be. "In the last year, people have become very confused by the '3G word'," believes Christine Rickets, marketing manger of Synchrologic. "They think once they get it, they will benefit from an always-on connection. But this won't happen for a while; you can still lose GPRS connections in the London tube, for instance. And when it does come, few will be able to afford it, as data transmission charges are likely to be high."

The cost of the mobile devices themselves is an issue, too. PDAs need more memory and more power than a phone and can cost several hundred pounds more.

If the mobile worker needs some data available at all times, then true data sync is essential. If, however, lack of coverage or dropped connection is not too big an issue, or if the mobile worker needs to be able to access a wider range of data than can easily be held on a PDA, then browser-based connections will be more suitable.

A travelling manager, for example, might not want the bulk or expense of a PDA; nor does he or she want two devices. The manager is also unlikely to need to carry around substantial amounts of data ­ but could need to obtain information on any number of business functions from time to time. Such an employee would find a browser-based system most useful.

However, the same company's sales representatives need to have product information, customer data, inventory, price and so on for their accounts or territory. This is too much data to try to access by browser and, because the reps need to have that data at all times, they don't want to risk being marooned without it. For them, data sync will bring more benefits.

A browser-based phone could also be used to provide voice connection and to enable the reps to access extra information that's not held on their PDAs. An engineer could have details of that day's jobs on a PDA, but still need browser access to the service history of a particular customer or a manufacturer's handbook to resolve a difficult problem. Handset manufacturers are addressing this issue; the Nokia 9210, for example, combines phone and PDA.

Whichever solution is chosen, some alignment between back office and mobile devices will be required. Browser-based systems may seem the simpler option, but are not necessarily as easy to set up as you might think: modem settings have to be configured, as do the browsers themselves. Different versions of XML may cause problems; users must ensure that any new software uses the same version of XML as the other applications used by mobile workers.

None of these challenges is insurmountable, though; and the benefits are becoming more and more attractive as the technology becomes more familiar, and users' experience with it grows. Clearly there's already a vast body of knowledge out there, along with a remarkable range of products. If you've hesitated to explore it so far, now's probably the time to start.

Case study

Schering-Plough, a pharmaceutical company known for its Clarityn antihistamine and a range of animal health products, used to have its 30 reps dialling up to the corporate intranet to access and upload data. This year it started using an offline data synchronisation system, choosing iAnywhere's Mobilink.

"Sales reps hold details of each of their customers on their laptops. They can make changes to order and customer information, plan and manage the calls in their territory, look at previous calls, see their notes on any customer, and so on," explains Nimesh Vadgama, application developer. "They synchronise their laptops with our corporate network, which is based at Uxbridge, at least once a day. Responses are instant, whereas the old system was slow and didn't work in the car.

"Sometimes the reps make an unplanned call on a customer if they are in the area. They can obtain a profile of the customer before they visit. And management can see what they are doing through the system, too."

Vadgama says the new system is more expensive and requires more time and effort to manage centrally, but the benefits far outweigh the disadvantages. "We haven't had the system long, but so far the reps like it. It's faster and more reliable."

Setting up your mobile system ­ and the issue of standards

To implement true data sync, an organisation must first decide which data the mobile worker needs. A sub-set of that data is then created and held on the client (the mobile device). You also decide how often synchronisation must take place: daily, hourly, every 10 minutes, whenever the device connects to base, when something has changed, at a set time and so on.

The best systems only synchronise changes to the data, not the entire sub-set. Some "poll" the mobile clients at pre-determined times. The system goes to the mobile device ­ say every hour ­ to upload any changes made by the employee, and at the same time download any changes made back at base. If the system fails to find a connection, it waits until the next time it is due to poll. Some mainstream software products such as Lotus Notes and Microsoft Exchange already incorporate data sync ­ but this could raise more problems than it solves, as we will see later.

Data mapping

Successful data sync depends on the effectiveness of underlying functions such as data mapping and compression. The good news for the end user is that these tasks are normally the responsibility of the software developer. If the enterprise systems are bespoke, however, the organisation may need to map and compress its own data.

These tasks aren't rocket science for a switched-on IT department, but they do have to be done properly. Take data mapping; each part of a system ­ for instance each "cell" in Excel ­ becomes a field. The data mapper selects which fields need to be made available to the mobile worker, and then (with modern software) drags and drops these fields on to the client device's fields. Rules can be set up ­ specifying, for instance, that only a certain number of characters can be used per field, or only a certain amount of data can be used on each type of client. And, says Nad Nadeson, marketing director of Peramon, if data mapping is done correctly, data compression won't be necessary.

Architecture

The type of device being used will affect the way in which data sync is added. Each client operating system supports a limited number of data standards, so some data sync engines or some mobile applications may not work on all the devices an organisation wants to use. Most data sync vendors support the main operating systems: Pocket PC, Palm and Symbian 7 (formerly Epoc). Connecting any of these to legacy systems is not really an issue; the data sync system identifies which device is connecting and formats the data accordingly.

But with different vendors creating different synchronisation architecture, and applications like Lotus Notes containing their own sync engines, the end user faces an even bigger challenge. Every time an organisation wishes to add a new mobile application, it may have to use a different synchronisation tool.

"There are too many technologies out there, all using a proprietary approach to data sync." That's the view of Peter George, co-founder and director of Wheatstone Consulting and an executive director of the Mobile Data Association. "If a company provides three different mobile applications for its workforce, it could build up three different conduits for data sync. In addition, while sync vendors try to support as broad a range of devices as possible, they have to make a commercial decision on which ones to support, and not all will be covered. Can you get synchronisation on Mac clients, for example?"

The MDA and Mobile Management Forum want vendors to create a common, open architecture which would allow any piece of software to be written to any mobile device ­ provided that device supports the common standard that is created. Vendors and major users such as Boeing are working on this open architecture standard now.

Security

Whichever data sync system is chosen, security has to be addressed, too. Data sync users don't have the same worries about unauthorised access to data being transferred over the Internet that browser based systems generate, but they do have to be more careful about security of their PDAs and laptops, since if they are stolen, the thief could access sensitive data stored on the device.

When data sync is actually taking place, data needs to be encrypted to 128 bit standard. For PDAs this could mean secure socket layer (SSL) encryption; for GSM or GPRS phones, private WAP gateways will ensure data is encrypted at all stages of transfer. Other security measures include the use of PKI digital signatures, which iAnywhere uses in its Mobilink, and strong authentication, as supported by Peramon. This includes a screen identification on a separate token containing random numbers which change every 30 seconds; people need the token, as well as the device, to access the corporate network.

Choice of security, like choice of synchronisation method, comes down to a business decision. "You have to work out how you want people to work in the field, which will be different from working at a PC," emphasises Anton du Preez, managing director at RangeGate. "What will the mobile employees be doing? What data will they use, and how?"

And, as Andy Rapley, UK country manager for Orsus Solutions, adds, "an organisation needs to know that mobile transactions have been completed and data gets delivered." Without that confidence, there's no point in going mobile in the first place.