In-Depth

Mobile Applications: Making the Move to Wireless

• By Sam Farraj
• 05/01/2001

In much the same way as the Internet considerably transformed the way companies conducted their business over the past five years, wireless communications will forever change the way a company's employees perform their jobs.

The ability for mobile workers to access data from anywhere, at anytime, is based on the mobile, always-on and convenient nature of wireless communications. This wireless freedom enables mobile workers to always access mission-critical information, which directly translates into an increase in employee productivity. While it seems easy for a corporation to tap into the business benefits of mobile applications, there are a number of challenges that they must face before successfully deploying a wireless solution.

Many organizations are compelled to make the move to wireless. Some organizations are implementing wireless solutions in response to pressure from its employees who have become very comfortable with their personal handheld devices, such as Palm Pilots and cell phones. Other companies recognize that wireless technology can provide a measurable way to increase the productivity of its mobile workforce. The majority of companies that are turning to wireless solutions fall into the former category, not the latter.

An organization that is going to adopt wireless technology must first decide which application they are going to untether, which mobile device(s) they're going to use and which wireless carrier(s) and network(s) they are going to contract with for service. In addition, the issue of network security is an extremely important factor to consider, especially since the worker will probably need access to confidential data and information to perform their job. The organization must keep in mind that the early choices made in this process will clearly impact the other issues involved in developing the mobile business solution.

All these steps may seem rather simple, but the corporate motivation for deploying these mobile solutions will cause quite a significant ramification on the development procedure. If the company is looking at deploying mobile solutions because their employees have become used to their mobile devices, they have to deal with a unique set of challenges related to this existing population of devices. However, a company that independently decides to develop this type of solution does not have to deal with this already existing, heterogeneous population of mobile devices.

When employees already have different devices, it becomes much more difficult and costly to uniformly develop and deploy a mobile application. This is due to the varied network services (e.g., CDMA, CDPD, Mobitex, etc.), different data delivery technologies (e.g. WAP, HDML), varied portable operating systems (e.g., Palm OS, Pocket PC, EPOC, etc.) and different screen sizes being used by these devices. What a company must do is assess what devices are currently being used and develop a plan to address these varied device operating systems and platforms - whether by creating customized applications for each one, or by developing a device exchange program.

Once the company has overcome this issue, they must determine which application to wirelessly enable. Many big enterprises have decided to start with its messaging applications, as this is the way most people in the organization communicate. However, it is easier to justify the cost of these solutions by starting with a revenue-generating application, such as giving salespeople realtime access to inventory and ordering systems, where the measurable return on investment (ROI) is readily apparent.

There are many different mobile devices to use, but these fall into specific categories. There are handheld devices running either on the Palm OS or PocketPC/Windows CE platform (e.g., Palm Pilot, Pocket PCs, Handspring Visor, Sony CLIE, etc.), Web-enabled mobile phones, interactive paging devices (e.g., RIM, Motorola, etc.) and laptop PCs. These devices have varying processing power, screen size/user interface (UI), storage and memory.

However, because the required functionality of the application being deployed is really the determining factor for device selection, the above factors are only relevant insofar as they relate to the application. For example, if the application is a high-powered customer relationship management (CRM) or sales force automation (SFA) solution, then users should be given laptop PCs, since these are currently the only devices with enough processing power to deal with these systems. In addition, with the availability of local storage on these devices, these applications can be run in an "offline" mode and then can be connected to the network to transfer data.

Other devices, like handheld devices and phones are best used in regions where wireless coverage is almost constantly available, as these devices will not store an application and the employees' work. If the connection to the network is lost while in the middle of their work, when they regain the connection, they will have to begin from scratch. That is why Web browsing or access to personal information management (PIM) solutions are ideal applications for these platforms.

Interactive pagers, like RIM devices, have the ability to store some information, which make them ideal for e-mail applications. When in network coverage, the device is continuously connected to the wireless network, allowing workers to be discreetly notified as new e-mail arrives. With outside network coverage, workers can look at their previously received e-mail in an "offline" mode, and can resume looking at new e-mail when the network connection is reestablished.

Another factor to consider is how to wirelessly enable current applications. There are currently three main approaches to developing mobile applications:

1. Point solutions

2. Platform-specific or application-specific middleware

3. Transcoding and/or WAP-based approaches

Point solutions address specific interim needs, but are not scalable infrastructure solutions. They require significant effort to integrate, manage and maintain; therefore, they are not an ideal long-term solution. Many of these are further limited in scope, as they are tailored only for wireless access to enterprise e-mail.

Proprietary platform-specific or application-specific middleware (or application platforms) are either optimized for particular devices or for particular applications (or application servers). Because of their specialization, these platforms generally exhibit higher levels of usability, performance, ease of integration and ease of management than point solutions. However, the pitfall is their extensibility and platform-dependence - it is difficult to develop applications or incorporate new features beyond the goals for which the platform was originally designed.

Many solutions today involve some form of transcoding - the process of translating between HTML and WML. WAP, or Wireless Application Protocol, is generally used with WML, a simplified markup language and WMLScript, a minimalistic scripting language for WML. The transcoding process essentially waters down HTML into WML and delivers the WML content to WAP minibrowsers on wireless devices. This approach is very similar to the desktop's Web browser model, in which server content is viewed using a client-side browser.

Many problems of transcoding are the inherent problems of running applications in a browser-based architecture. Browser-based architecture is an inefficient way of running applications (it was originally designed for the purpose of sharing documents). There are noticeable flaws in browser-based applications even on the desktop; trying to run browser-based applications over a wireless network only exacerbates the following performance and usability problems:

• Applications cannot fully utilize client-side resources. WAP browsers have very limited access to local storage resources and PIM functions without special support, so features, such as the synchronization of data between the local storage on the device and the server, are difficult to implement.

• Lack of alert mechanism from the server. In a browser-based model, the server cannot initiate a connection with the client. The client device is required to send an initial request for data, and without client-side application components, such as applets, that can listen to server signals, the server has no way of sending alerts to the client. For example, users must actively refresh Web pages in order to check if they have received a new e-mail on Hotmail; the server has no way of alerting the user upon the receipt of new e-mails.

• WAP applications cannot match traditional client-server applications. Due to the intrinsic overhead required to operate in a browser-based environment, the performance, bandwidth-efficiency and usability of applications is limited. For instance, in order to retrieve a stock quote, an entire WML page must be fetched, as opposed to just the relevant data the user is looking for. WML also contains limited syntax compared to HTML, which makes it more difficult to build sophisticated user interfaces.

• User experience and quality of service is less than adequate. Since the entire application's logic is carried out on the server, and there is little or no offline caching, the user experience and quality of service are heavily dependent on the bandwidth and reliability of the wireless network. Because the bandwidth is low, users are required to wait long periods of time for their data. The lack of an offline caching capability means that if the device is not connected (which, according to GartnerGroup, is the case approximately 50 percent of the time), the application will cease to run.

Future developments in device and application design technology, such as the emergence of Java 2 Micro Edition (J2ME), will begin to better address these issues. J2ME-based technology platforms will extend the ability to work in an "offline" mode to other devices, while also enabling enterprise IT departments to better deal with the logistical management of handheld devices. For example, new applications and or system updates will be able to be installed on the devices, over the air, without needing to involve the end user in the process.

Another benefit that this approach brings is the ability to leverage the millions of Java programmers that are already familiar with this development environment. By harnessing this community to write applications once for any mobile device, the development times for useful mobile applications will be greatly reduced.

Once an organization has settled on the application and device that it will use, it can consider the various network choices. Another factor to consider in this decision is the location and travel habits of the end user, as network availability and coverage is definitely important. In addition, large applications can grind to a halt on a slow network.

The choices are BellSouth's Mobitex or Motient's Artis network (both run at 8 Kbps), Sprint PCS's CDMA network (14.4 Kbps), either Verizon or AT&T Wireless' CDPD network (19.2 Kbps) or Metricom's Ricochet II (128 Kbps). While the Mobitex or Artis networks are excellent for e-mail, other applications would crawl at that speed. Compression techniques can be used to increase the data transfer rates of the Verizon and AT&T Wireless networks to 33.6 Kbps. Finally, the Metricom high-speed network has the bandwidth to support even the most robust application, but is currently only available in eight metropolitan areas.

With mobile workforces spread out across the country, it isn't as simple as choosing a single wireless carrier. Some carriers do not offer service in certain regions of the country. Stitching together a national footprint of coverage may involve having to negotiate with multiple carriers, further complicating this process.

Once these other items have been considered, network security, the number one concern of the enterprise, must be addressed. Depending on the application, there are different levels of security needs. When accessing corporate e-mail, there is less valuable information to protect than can be found in a corporation's SFA application. Moreover, there are new viruses that target handheld devices, so appropriate anti-virus systems must be utilized. The best option to secure the wireless transfer of information is to utilize a wireless Virtual Private Network (VPN). Unlike the traditional VPN, a wireless VPN is designed to strip out much of the overhead to take advantage of the inefficient wireless bandwidth. Another option is to use a mobile device (PC, RIM, CE devices only) that supports client-side encryption to create a secure, end-to-end solution. For e-mail, a secure approach is to use RIM's Blackberry operating system.

The process of developing and deploying mobile business applications is a highly complex one as is evidenced by the multitude of issues that a company must address. Most IT departments must approach these matters with caution and may be better served by seeking a partner who can offer them the knowledge and support that will be needed to deploy a mobile business solution.