Connecting Wireless Devices to the Enterprise
While it may be easy to fall in love with the new generation of wireless devices and applications, communication with back-end corporate systems is essential if the investment in wireless technology is going to pay off.
Wireless devices don't automatically communicate with back-end systems, particularly when there are a variety of products such as PDAs, WAP phones and Bluetooth-enabled devices using a combination of CDMA, DSM and TDMA networks to exchange information with SAP, Oracle and other diverse databases. Thus, the latest in middleware solutions must be part of your mobile enterprise project if you hope to untangle myriad front-end and back-end technologies.
Although there are no readily available industry calculations for wireless middleware, it should enjoy fast growth as the $7 billion wired middleware market looks for wireless extensions to the network, says Peter Bright, director of sales and global marketing for PCS Innovations, Montreal.
"The entire wireless market is underdeveloped and is ripe for folks in all types of different areas," says Adam Braunstein, senior research analyst for The Robert Frances Group, a Westport, Conn.-based IT consulting firm, adding that there are many players in the middleware market, from long-time companies such as IBM to much newer firms.
It might be easier for some companies to add middleware than others, says Rob Crigler, vice president of sales and marketing for Modcomp, Ft. Lauderdale, Fla. If a company can control the access to devices, limiting field force workers to PDAs, for example, the middleware wouldn't need to be as complex as it would otherwise be to connect a combination of PDAs, laptops and their wireless modems and WAP phones.
However, in reality the middleware usually needs to connect not only to those devices, but also to a company's disparate back-end system, as well as to third parties involved in supply chain management, says Russ Biender, general manager of core technologies for Epic Data Systems, Richmond, British Columbia.
Companies need to use XML and Java platforms, which provide the versatility necessary to handle different devices. Developing such solutions in-house isn't an option for most companies. A number of companies that have tried to do this are "frozen at the starting gates," says Donald E. Brown, CEO of Interactive Intelligence, Indianapolis. "They haven't started to develop any of their own applications because of the variety of wireless devices."
Similarly, there are a variety of middleware offerings, from off-the-shelf to proprietary solutions. Each company's needs are different, so there is no single, perfect middleware for everyone, Braunstein says.
How to Choose
The experts agree that there are several different considerations for companies that are developing or purchasing middleware. Taking a "Swiss Army knife" approach, with tools to build interactive solutions for various front-end and back-end systems, gives developers the most flexibility, says Dave Vanable, vice president of sales and marketing for Odyssey Software, Rochester, N.Y. This approach also enables developers to customize communications to meet a company's needs. For example, two different companies may have the same handheld devices and back-end systems but may have them customized to provide different reports. So the middleware would need to be customized to handle those differences.
There are two primary models for middleware, according to Mark Willnerd, product manager, mobile data management for Extended Systems, Boise, Idaho: the always-connected model and the semi-connected model. With the always-connected model, the field force worker uses the Internet to connect with and download information from the central database. This model is usually less expensive than the semi-connected model because the applications are on the Internet, so there's no need to have them on front-end or back-end systems. As a result, the company doesn't need to house and maintain middleware.
But this model also has some drawbacks, according to Willnerd. Although broadband wireless is operating in some pilots, those pilots are limited today; therefore, transmission times are slow. If transmission is severed before the communication is complete, the user has to reconnect and start all over again.
In the semi-connected model, on the other hand, some of the processing capability remains on the wireless device, so the user can be connected for a shorter amount of time, then manipulate the data on the wireless device while offline. There's no need to be connected in order for the application to run. Even in this model, however, transmission times are critical, so it's important that the middleware reduce the transmission time from the back end to the handheld devices. Of course, the fine line is finding just how much of the application to put on the device--as the amount on the device increases, so does the cost, because it involves writing separate applications and installing them on each type of device, Brown says.
The middleware handling the wireless communications might be only part of the entire wireless solution. Even though wireless and wired middleware present separate challenges, somewhere the wireless and wired devices need to interface not only with the back-end systems but also with such items as fax and e-mail at the company's contact center, Brown adds.
When data comes from more than one source, it needs to be synchronized to align with the corporate database. For example, if a customer has a contact person, the field service employee can enter this information into his PDA, then have the information added to the corporate database the next time he transmits data.
New information from different sources presents a challenge. If the field force employee is given a new contact and the in-house marketing manager obtains different contact information, the middleware needs to be able to determine which one to add to the corporate database during synchronization, or recognize that there is a conflict and notify the database manager of the problem without making any changes.
Similarly, the middleware needs to include rules for transmission interruption: A failing battery or other glitch can interrupt the communication between the mobile device and the back-end system.
Device Management
"Because different handheld devices have different capabilities, they are likely to have different applications," says Brown. Identical devices may also have different applications and different capabilities (for example, memory and battery life), so middleware should recognize and alert managers to these differences, says Joan Herbig, CEO of XcelleNet, New York.
"Remote systems management is no longer a luxury but a necessity for all corporations wishing to remain competitive. Traditional systems management tools do not offer the ability to effectively manage this new networked environment," Braunstein says.
Crigler cites the following considerations when examining middleware:
The wireless browser content-type (for example, Wall, HTML, Web-clipping)
Configuration of the Web server to deliver appropriate pages
How to access legacy and database data (for example, ViewMax, SQL)
Wireless device ISP requirements (for example, monthly fee)
Amount of concurrent users accessing the wireless application
Wireless connectivity issues (for example, speed, wireless availability in certain areas)
A concise application definition based on wireless device limitations (for example, amount of data returned, type of data)
Slow start?
A robust solution will be the eventual middleware goal for most companies; however, a company initially adding wireless devices and middleware may want to start with "a least common denominator type of approach--a no-brainer application, with integration to a single type of device," Brown suggests.
Not to say that WAP devices should be ignored, but their functionality today is limited, Brown adds. So an organization may do best to develop middleware to connect other handheld devices first and add WAP functionality later as the devices become more reliable and broadband wireless becomes a reality.
Although there are advantages to incorporating wireless devices and middleware into the enterprise, smaller companies may want to continue with more traditional systems. "Time and money are the critical issues," Crigler says. "It may be handy to have the capability to connect to the database, but it may not be practical for some companies."
Larger companies, however, might look to United Kingdom-based One 2 One, the mobile phone and service provider subsidiary of Deutsche Telekom AG, Germany, for an example of how wireless middleware can help them. The company was paying for field marketing information, but by the time they received it, it was already outdated and of little or no use. "Our business needs information no more than a day old so that we can quickly react to moves by the competition," says Ian Fisk, technical manager.
The company's field marketing representatives regularly visit the 6,000 top-producing product outlets each month to:
Cover monthly sales objectives through a corporate PowerPoint presentation
Verify that the outlet is adhering to One 2 One merchandising standards
Order any required point-of-sale materials to ensure that store displays comply with corporate standards
Get information on various data points for the corporate office
Provide any additional product training as needed
Field representatives would get home after eight hours in the field and spend two more hours faxing and filing paperwork. If the field representatives were away for more than a day at a time, it could be days before the information was filed. Then the data needed to be re-entered into corporate back-end systems, which took up to six weeks.
Fisk's development team created a custom SQL database at the corporate headquarters to host customer information. They also created standard forms in Visual CE that were installed on Windows CE-based PDAs for the field reps. The XTNDConnect Server from Extended Systems, connects the front and back ends. Although the field reps were all using Windows CE-based PDAs, a smaller pilot in a different One 2 One department uses a variety of handheld wireless devices, so it was important to use middleware that could connect disparate devices.
Field reps now spend only five minutes entering and transmitting information, rather than the two hours spent previously. "I have become very popular," Fisk says. At the other end, One 2 One uses the system information in daily sales reports. The account managers and channel marketing department are now far more conscious about what has transpired in the field rather than assuming what has happened, which translates into timely and accurate business decisions.
There's more immediate feedback to the field workers as well. Previously, the value of any new information was questioned because changing a presentation meant creating as many as 70 new color presentations that needed to be printed and distributed. Now, the change is made to a centrally located Power-Point presentation that field reps download the next time they connect to the system.
"People are depending on the information and using it rather than accepting it as old, out-of-date information that could be taken with a pinch of salt," Fisk says. With the success to date and the expected increase in use of PDAs within the company, he believes that the company will expand its original 500-user license for the middleware.
No matter the size of the company, then, if there's a need to wirelessly link information to corporate front- and back-end systems, there's a solution out there that should fit its needs. Before picking middleware willy-nilly, a decision-making team should create a budget and examine the relative complexity of the systems and devices already in place in the organization to find a middleware solution that is its closest match.