June/July 2003

Middleware is the magic ingredient that links mobile data to corporate systems. But there are many different ways of implementing it, as Marcia MacLeod finds out

No one would deny that mobilising a workforce can bring many benefits. Staff such as delivery drivers, service engineers and sales representatives can obtain all kinds of information whilst out in the field ­ details of jobs, products and customers (including trading history, credit information and service level agreements); and they can send back important data such as parts needed, new orders or proof of delivery, all without going back to the office.

But for a mobile workforce solution to succeed, both mobile workers and their corporate bosses must be confident that the right back-office data reaches the mobile devices, and that the data collected on the road goes into the right application when it gets back to the office.

Which leads us to the biggest barrier to implementing a mobile system: how do you integrate data between mobile device and corporate network?

 

The first hurdle is that organisations usually have to contend with such a wide range of variables ­ multiple types of mobile device, possibly all working on different operating systems; multiple back-office systems, again running on different operating systems; and multiple applications. And since mobile devices are small and cannot display large volumes of data, integration has to be tailored to each individual or group of individuals: there's no point in overloading the device, or its user, with irrelevant, unwanted corporate information.

The most common method of integrating mobile data involves middleware ­ software sitting on a server and acting almost like a broker between the mobile device and corporate network. Basically it collects data from one and delivers it to the other.

Middleware may be supplied by companies like IBM (WebSphere) or Sun (One), which often provide it free of charge in the hope users will buy their integration services on top. Alternatively, you can opt for a range of specialist mobile middleware vendors. These include Telepartner, XCelleNet, iAnywhere, RangeGate, Peramon, Extended Systems, Orsus, Flying Spark and C-Your-Data. There's certainly no shortage of choice.

Using middleware designed for mobile applications makes sense. "You really need middleware that understands mobile devices," maintains Danny Bagge, business development director at RangeGate. "It can then be used to manage devices, too."

Middleware usually works in conjunction with a dedicated mobile application, either written on a bespoke basis or customised from an off-the-shelf package. "Mobile workers need to execute business processes without having to log on to different back office applications," says Nad Nadesan, marketing manager at Peramon. "Companies have to decide what applications, what tasks, they want to mobilise, and what data needs to be provided or collected. That way they can devise an application that gives mobile workers what they need."

RangeGate's Danny Bagge adds: "Every mobile user wants different information ­ or else wants the same information presented differently. You need to create a syntax file which describes how you want to present data, including pictures or even voice, and then a transformation file to explain how you want to transfer and display the data."

Middleware can either store the data from the mobile application or retrieve it from back office systems, or both ­ storing commonly-used data, but retrieving other data as and when needed. Back-office data tends to be retrieved through a series of connectors. Most major application vendors (SAP, Siebel and Oracle, for instance) have developed their own connectors, and mobile middleware vendors have also written standard connectors. Others can be developed for bespoke applications or less common off-the-shelf packages.

Back office interfaces have to be carefully thought out, though. "People often compromise," says Graham Erskine, marketing director of Telepartner Systems. "They connect via a paging interface, a printer or other devices not meant for the job. The typical result is you end up with more data than intended ­ although the middleware can filter this out."

Basing a mobile infrastructure on middleware also enables everything ­ from prioritisation of data to distribution of software to mobile devices, remote maintenance of devices and security ­ to be managed centrally. Middleware also manages the data synchronisation process, ensuring that both mobile clients and back-end servers always have the same versions of data.

"Middleware performs a lot of tasks to manage devices," says Yad Juara, product marketing manager for XCelleNet UK. "If a new product is launched, for example, it can push the new product data out to devices."

There is another way of designing the middleware-based system, though. C-Your-Data pulls data from anywhere in the back office. "It doesn't matter where the data is or whether it is in a particular application or not, our software pulls the data out," explains managing director Michael Giles. "We then present it in a way the device understands. When data is collected by the mobile worker, it is again presented in a way the back-end system can accept, and is transferred to the right location."

C-Your-Data achieves this through inspection and data capture procedures which, Giles claims, can be written in minutes by non-technical employees. "Take a transport company, for example," he says. "Users can devise a data capture format for each task ­ for instance signing for goods or providing customer files for sales staff ­ and hold it on the central server. All procedures are assigned to users; when they dial in, the procedures are sent to them for reading, but not editing. If staff need extra data not already identified and defined, they can use our 'unscheduled' option, which provides access to a full list of inspection/data capture procedures."

Dexterra doesn't use middleware at all. "When you create a new database which, in essence, is what middleware is, you create a synchronisation and integration nightmare," argues Mike Silvey, general manager Europe. "We've patented data routing technology based on schemas, each designed for different applications (field service, sales or whatever). The schemas provide every field a user might ever need on the mobile device, but don't take up the mobile's capacity until data goes into the field.

"Routing table technology tells the device where to go to get the data (Siebel, for instance) without needing middleware or connectors. The device periodically polls the back-end to see if there is any new data it needs to have. We therefore can eliminate the need for data synchronisation and management."

Data synchronisation does present one of the biggest challenges in mobile data integration ­ and the more back office applications there are in the system, the more complex it becomes, as Simon Wood, software manager for Flying Spark, explains. "If data comes from two or more places, it has to be updated in each of those locations, he says." A salesman, for example, could take an order and get stock availability from two different databases ­ only to find the customer has reached his credit limit, so the order can't go through. The system has to stop the order data from being processed and put the inventory back in stock availability.

However data is integrated, there are still other issues to address. A more serious problem stems from integrating data without integrating the application which contains that data. If a salesman's mobile device collects customer data that is usually held in a CRM package, but is able to do so without dedicated connectors to that package, the data may not contain any of the business rules contained within the application ­ for instance, relationships to other data.

"If data is pulled out from underneath the CRM package (or ERP, financials or whatever) it is not presented in the format it should be in, and has no constraints applied by the package," explains Jan Mietle, mobile data management technical support manager for Extended Systems. "The problem is even worse when data is returned to the back office. If it's not put into the right application, it could go anywhere."

One way round this is to install purpose-designed applications on the mobile device. But how much data and how many business rules do you want on a small device? How much local intelligence do you want the mobile worker's system to have? And do you want to 'push' data at the mobile workforce or let them 'pull' down the data they need ­ or a bit of both?

Alison Henderson, UK operations director of iAnywhere, takes a pragmatic line. "You can set up a system without middleware," she acknowledges, "but the more complex it gets (in terms of back office applications and types of mobile device), the more sensible it becomes to install mobile middleware."

Recent developments in mobile technology have improved data integration. For a start, all good system vendors are "agnostic" in terms of device and operating system. In other words, they can connect to any mobile device using any operating system. Most develop their systems using "soft" rather than "hard" coding, which makes them easier to change.

And developments in communications, such as XML and Microsoft's .Net, greatly improve interconnectivity. "XML is an important piece," says Danny Bagge of RangeGate. "It creates the syntax file we need to present data in the right way."

"XML is just one way of doing it, although it is our preferred way," adds Nad Nadesan of Peramon. "It pre-defines certain constraints. But you can use other software, such as Microsoft's Pocket PC tool, to connect clients with servers."

Microsoft's .Net environment has also made it easier to deal with various mobile communication technologies, including 802.11, GSM, GPRS and Bluetooth. "Dot-Net differs in the way programmers access back end systems through XML and Web services," explains Yad Juara of XCelleNet. "It lets you make calls to the system from anywhere in the enterprise; it makes mobile connectivity much more straightforward."

Easier, maybe; easy, no. While vendors will try to tell you it's a simple thing to set up a system in only a few weeks, the reality can be a lot different. Dexterra's quote of a minimum of five days for a pilot seems extraordinary, and probably is unusual, but other vendors claim it can take anything from a few weeks to a few months, depending on the complexity of the system; and we all know how fluid "complexity" is.

Cost is hard to quantify, too, especially as most integration requires at least some bespoke element, but vendors quote a range from £90 per user plus implementation costs ­ and again, we all know what implementation costs can mean. Extended Systems offers an SMB pack, for up to 50 users, of £10,000, including server, while Dexterra, since it doesn't use middleware, provides its system either on a licensed basis (895 euros per user for a sales application, 1,200 euros for field service) or as a hosted service, with a sample price running at £85 per user per month for field service engineers.

As always with new technology, the best thing to do is estimate a cost and implementation time, and double it. But don't let that put you off. Get the integration right from the beginning, and you can rest assured that your mobile workers always have the right data, and the data they bring back can be of real value to the business.

Case study: High-flying integration at Britannia

Britannia Airways transformed its business with the installation of an iAnywhere application for cabin crew and pilots. Instead of having to download and print off information on flights, aircraft manuals, take-off performance, staff rosters, passenger meals, duty free sales and so on before boarding the plane, they now have mobile devices to access that data at any time.

Cabin crew use ruggedised Casio PDAs to access information for all on-board routines, including safety briefings and other notices. They go to a desktop terminal at one of Britannia's 12 airports, identify which flight they are on, and download the necessary data. The device also knows when safety and other notices have been opened (and presumably read). There are now plans to collect various other kinds of data, for example on disruptive passengers.

Pilots are given IBM Thinkpad laptops, as they need to deal with larger amounts of data. They can even access email on board.

"We use Mobilink synchronisation from iAnywhere, ASA Database, Manage Anywhere for distribution of software, and Mail Anywhere for email," says Ian Callicott, project manager. "We also have the Jaguar server, but aren't using it yet. We will use it to integrate more complex data, but we only went live in May."

Case study: Real-time links keep reps in touch

Westcoast, a UK computer distributor, needed a way to ensure mobile sales reps had the most up-to-date information at all times. "By having better access to corporate information, the sales force would be able to deliver a better-quality service and become more efficient in closing sales deals," reasoned IT director Richard Jones.

Closing deals presented difficulties when there was no real-time information on issues such as the number of outstanding orders, customer credit status and stock availability. Sales reps took a stock list with them each day, but because the information changes so frequently, it could be out of date without their knowing it. To ensure accuracy, they would have to call head office from every customer's premises.

The answer was a Peramon mobile application based on GPRS-enabled Pocket PC devices, using Peramon's theMobilizer application generator to link to several JBA ERP modules running on an IBM AS/400. Peramon's theMobilizer SMSserver provides order and shipment summaries via SMS alerts to each sales staff member to keep them abreast of constantly changing situations.

The system, which took just two weeks to implement, also enables mobile workers to access emails, calendars and job lists.