Analysis: Mobility Apps

Several potent forces are acting in concert to dramatically expand the ability of mobile workers to access any information, at any time, from anywhere. The implications are far greater than improved productivity: We see companies functioning in completely new ways as they eliminate the unnecessary or redundant steps bogging down business processes. Firms that fully integrate the power of these technologies will become what we call "mobile dynamic enterprises." This metamorphosis occurs when IT starts using mobile computing strategically, not just tactically as is the norm today.

Don't get us wrong: Tactical is a great way to get your feet wet with mobile computing. But if you can go to the next level, the payoff will be immense. It shouldn't be a huge leap--how many of your employees already carry powerful laptops and handheld devices and have access to 3G networks? The missing link: A wide selection of off-the-shelf software applications.

Three factors are causing a shift in the status quo: Faster wireless networks mean improved application responsiveness, and middleware has grown more sophisticated. But most important, vendors are finally getting in sync with their customers' needs and offering built-in support for mobile devices in their enterprise software.

And clearly, mobility is on your mind: Our reader poll for this article showed 70 percent of responding companies adopting mobile/wireless technologies. However, only 17 percent had companywide strategic initiatives, so much work remains to be done. What's the holdup? In a word, complexity. A smorgasbord of mobile platforms and wireless networks means integration challenges.What does it take to overcome? Anticipation of where carriers are headed (hint: IMS, or IP Multimedia Subsystem). Knowing the difference between tactical and strategic adoption--after all, we're moving toward a converged world of multimedia communications and handheld computers that are more powerful than last year's desktop PCs. A grasp of technology trends and drivers. An understanding of what constitutes an effective mobile application and its architecture. And finally, awareness of aspects beyond the app itself, including security, mobile middleware and device management.

Continue Reading This Story...

IMS On The Horizon

One thing to focus on as you make long-term plans: In the next couple of years, mobile operator networks will support a much wider range of services. Today's networks primarily deliver packets or messages. But operators like AT&T, Sprint and Verizon are laying the foundations for more sophisticated communication. IMS, a work-in-progress framework based on SIP (Session Initiation Protocol), for example, supports the dynamic blending of a variety of communications components, including circuit-switched voice, packet-switched voice through VoIP, video, user location information and messaging.

Although operators are likely to use IMS initially for their own services, such as video streaming and push-to-talk over cellular, they also will open up IMS interfaces to third-party apps. The result will be far richer multimedia-oriented apps that will captivate consumers and further enhance enterprise productivity. Imagine an app on a desktop at corporate headquarters that shows the location of an employee in the field and can initiate an IM session simply by clicking on that person. Support personnel could stream video to show a mobile salesperson a new offering that's of interest to the customer at that location. Operators are testing IMS and have services, such as AT&T's "video sharing," planned for later this year.

Trend ReportA number of other technology drivers are accelerating deployment of mobile applications, by which we mean apps that involve communication between a mobile device, including phones, wireless PDAs and laptops, and enterprise servers. Some mobile applications also can operate in a standalone, disconnected fashion, while others, such as most wireless e-mail systems, can operate as islands at times, then synchronize with your or third-party servers when network connections are available. There are also always-connected models of operation, especially for browser-based applications. Of these approaches, the "sometimes" or "usually" connected model is the most common--and generally the most effective. We run down market forces in "What's Driving Adoption," below.

Given today's 3G networks, powerful laptops and handheld devices (which we refer to as smartphones even for PDA form factors), we already have all the computing and networking power needed to extend data to mobile workers. What's been missing has been a wide selection of off-the-shelf software applications. Previously, enterprises may have selected hardware to solve a specific business problem. Now, companies frequently purchase smartphones to address one set of problems, then look to migrate additional applications to the platform, much as in the desktop environment.

However, running applications designed for always-connected, high-speed networks with low latency over wireless links too often results in sluggish and/or unreliable behavior. It's common to experience temporary loss of connectivity, reconnections with different IP addresses and inconsistent throughput levels due to high network load or poor signal conditions, where the wireless link may have to retransmit a large percentage of packets.

Also, older networks, such as GPRS, simply moved packets too slowly (tens of kilobits per second) with too much latency (hundreds of milliseconds). Dealing with the foibles of 2G wireless often meant employing wireless middleware, which could involve rewriting the application or developing custom apps using programming interfaces specific to the middleware. The result: Expensive and cumbersome application deployment, often justifiable only for focused vertical market applications, such as dispatch or field service.

Three things have changed to improve this situation dramatically. First, wireless networks have become much faster; applications that ran poorly on 2G often perform well on 3G networks. That SQL database application might refresh a screen in 5 seconds instead of 30.Second, wireless middleware has become much more sophisticated, and can often be deployed without requiring changes to the application. Today's wireless e-mail gateways are good examples, as are current mobile VPNs.

Third, and most important in our view, application vendors are finally delivering versions of their enterprise apps that directly support mobile devices. In other words, the mobile middleware component becomes redundant, vastly simplifying application deployment. You may still want middleware for security, management or mobility features, but increasingly, you won't need it for application data. A highly visible example is Microsoft Exchange Server 2003 with Service Pack 2, which can deliver a push e-mail experience to select smartphones. In the past, you could obtain this capability only using Microsoft Exchange with third-party gateway products.

Now, this does not spell the end for third-party gateways, at least not right away. Some enterprises will always be willing to pay a premium for greater networking efficiency, support for a broader set of target devices, increased security, and better configuration policies and inventory management. What this change does mean for IT, however, is an easier path to initial mobile application deployment. As part of our RFI, we sought to uncover the extent to which major software application vendors have developed support for mobile systems; see their responses at nwcanalytics.com.

This isn't to say there's clear sailing ahead. We see some serious inhibitors impeding mobile application deployment (see "What's Holding Us Back?"). Multiple mobile platforms, wireless networks and complex integration translate to complexity for IT managers and CIOs. And it's this complexity, more than anything else, that's inhibiting broader deployment of applications. However, though there is a long list of considerations and decisions you must make in developing a comprehensive mobile computing policy, there also are good choices every step of the way.

Application AttributesAn optimized mobile app works within the constraints of mobile devices, especially handhelds, and makes effective use of available networks, usually wireless connections.

This is harder than it sounds, and the vendors we spoke with use various approaches to get there. For smartphones, the user interface is particularly important, because entering text is cumbersome and the display is small. Differences in form factor, types of operations and the manner in which users interact with the devices will be inherently different than with larger laptop platforms. A well-designed mobile application, for instance, won't require any more user input than absolutely necessary and should go to the network only for the information it needs. For more detail on mobile app design, see "10 Steps to Mobilization".

Application operation may be fundamentally different on a mobile device than on a desktop. For example, while desktop apps leverage free bandwidth to poll servers for information, in a wireless environment it's more efficient from both network utilization and power management standpoints to deliver data to the mobile system only when there's new information. The most vivid example is today's wireless e-mail systems that push messages in real time, but the concept can apply to any dynamic information that mobile workers need to receive right away. Currently, however, it's only e-mail systems that widely employ this push model. Other mobile applications and middleware generally use time-based polling.

Security requirements also are fundamentally different than on a desktop. People constantly lose their phones, and with the huge amount of storage available on these devices--up to 8 GB with today's Secure Digital cards--as well as their ability to access sensitive data, it's crucial that you protect this data. The big question is whether your app will incorporate security features, or whether you must employ a separate security system.

Features to look for include encryption of data on the device itself and while in transit, user authentication with an inactivity time-out and the ability to remotely wipe data on devices or kill them entirely if lost. Note that VPNs protect data transmission, but typically do nothing to safeguard data on the device. The trend is for mobile applications to incorporate security capabilities. In the RFI responses we received, all the application vendors provided a robust set of security features.Finally, if you're thinking strategically, you shouldn't be mobilizing just one application, but rather a set of apps that address the mobile worker's business processes.

If You Build It ...

Mobility architects can quickly calculate the effectiveness and importance of highly visible items such as a user interface, but determining the optimal mobile application architecture is more complicated. There are a variety of approaches available (see "An Optimal Mobile Application" in the image gallery), so it's important to understand the trade-offs; the desired degree of interaction between the mobile worker and an application may mandate one architecture versus another. Keep in mind that an app vendor may support only one approach.

The first consideration is the type of client software that will run on your mobile system. In a client-server application for a laptop, for example, it may be just the desktop version of the software or a Web-based interface. Things are trickier with smartphones, where approaches include messaging, browser-based, Java and native clients.

Messaging architectures are the simplest, albeit normally the least interactive. Here, your central site application simply sends text messages to mobile phones using the cellular operator's SMS (Short Message Service.) Alternatively, operators have SMS gateways where, under a contractual agreement, you can dispatch messages via your application in a more controlled fashion through a well-defined interface. The advantage here is, you don't need to install anything on the mobile system.Browser-based approaches leverage the browsers now found on most phones. Today, your users' phones are likely to run XHTML Mobile Profile, a subset of XHTML optimized for mobile devices. Smartphones also support regular HTML and XHTML. Using a mobile browser for an application is relatively straightforward so long as the application takes into account reduced screen size, which varies depending on the device; minimizes the amount of data presented; and can tolerate inconsistent network connectivity. Applications should facilitate interaction by, for example, allowing the user to fill out a couple of fields on each screen, hitting Next after each one, as opposed to scrolling awkwardly across a large form.

Over today's 3G networks, browser operations are fairly snappy. But on slower 2.5G systems they can be quite sluggish, with users often having to wait tens of seconds for screen updates. Like SMS, the advantage of a browser-based approach is that you don't need application-specific client code, and you can support a wide range of devices, independent of the underlying OS. Also, there's no local data store, minimizing synchronization and security issues. The same application will work equally well on BlackBerry, Symbian, Treo and Windows Mobile devices. However, mobile browsers cannot support advanced Web technologies, such as ActiveX and JavaScript. In our RFI response, most application vendors provided some form of browser-based support.

A browser is OK for occasional data access, but it's not well-suited for frequent use; here a local client operation provides a much better experience. Moreover, the browser approach requires constant network connectivity.

For local client code, a Java client works across the greatest number of mobile devices. One common Java approach uses J2ME (Java 2 Micro Edition), in conjunction with MIDP (Mobile Information Device Profile) and CLDC (Connected Limited Device Configuration). These specifications define a complete mobile application runtime environment for mobile systems. The attraction of a J2ME approach is that this environment is available on a large number of devices, including mid-tier mobile phones, as well as all smartphone platforms.

J2ME has seen its greatest success with consumer applications, such as games, but it's increasingly viable for enterprise apps as well. Another Java approach, supported by IBM and SAP, is the RCP (Rich Client Platform), based on work by the Eclipse Foundation.Due to variations in implementations, Java-based apps won't work on every device, so it's likely that your vendor will specify which platforms or phones the app runs on. Further, there are limitations to J2ME. It won't support multitasking until MIDP 3 is available, likely in 2008, and the overhead of the Java environment can make applications respond slower than their kin developed for the native environment. However, performance will generally be much better than with a browser approach. Overall, we expect Java on the mobile device to become dominant for mobile apps, especially because it allows vendors to address a wide variety of devices with one client version.

Finally, the most effective mobile apps are those developed for the native environment. They can leverage all the capabilities of the platform with the least amount of processing overhead. However, developing native applications requires a substantial level of expertise; it's no small feat to become familiar with all the development tools and debugging approaches required. It's therefore not uncommon for app developers to target just one mobile platform, most commonly the Windows Mobile environment in the United States and Symbian in Europe.

While these are the dominant approaches, others will play an increasing role. Adobe Flash is gaining popularity, and just as SOAs are becoming the networking architecture of choice for many apps, SOA/Web services approaches are also finding their way onto mobile platforms. For example, Microsoft's .Net Compact Framework runs on the Windows Mobile platform. Similarly, there are Web services APIs being defined for Java and Symbian.

The Device Conundrum

Despite all the attention lavished on handheld devices, let's not forget the laptop. In our reader poll, 75 percent said mobile applications are deployed on notebooks; Windows Mobile devices came in second, at 39 percent.While Windows dominates laptop platforms, your choices for handheld platforms are much greater. Mobile Linux isn't quite ready to join Palm OS, RIM BlackBerry, Symbian and Windows Mobile in the enterprise lineup, however, this platform will likely be a contender with smartphone devices emerging this year and becoming more widely available next year (for more information,).

For now, RIM BlackBerry dominates wireless e-mail, and is increasingly being used for other types of enterprise data, via the BlackBerry push architecture or Java clients. Windows Mobile is the platform most widely supported by mobile application developers, making it the top choice for many enterprises.

Symbian has seen very little adoption in the United States--in our poll, only 7 percent reported using this platform. Palm OS (now Garnet OS) has done well with wireless e-mail, but given the OS's limitations, including its lack of support for multithreaded multitasking, we don't see a lot of developers working on native applications.

Looking ahead to the rest of the decade, we expect mobile Linux, RIM BlackBerry, Symbian and Windows Mobile to be the major supported mobile OS platforms for enterprise applications. Palm already supports Windows Mobile and has announced plans to use mobile Linux as the migration path for its Garnet OS. At a layer above the OS, the key software platforms are likely to be Microsoft .Net and Java.

Mobility In The MiddlewareThe final decisions for a mobile application deployment include device management, security and whether to employ some sort of mobile middleware. Yes, mobile middleware adds cost, but payoffs include increased security; mobility across networks, such as between Wi-Fi and 3G; support for additional handheld platforms; wireless network optimization; mobile computing policy enforcement; and access to a wider variety of enterprise data. Our advice: See how far you can get with your primary application vendor, then augment as needed.

Take device management. Key features include over-the-air (OTA) provisioning, downloads/updates, policy control, document distribution and mobile inventory control. Many vendors provide mobile device management, including Altiris (which Symantec is in the process of acquiring), BMC, CA, HP, IBM/Tivoli, Nokia Intellisync, iPass, Avocent LANDesk, ManageSoft, Microsoft, Novell, Pervacio, Sybase, Symantec and Wavelink. Our reader poll was split between those who think it's vital for the application vendor to provide device management functions, and those saying this was unimportant. In our RFI response, all the application vendors provided some degree of device management. Whether to use a third-party tool depends on how many devices and applications you're supporting. The greater the number, the more likely you'll need a separate management system. In "Management On the Move", we review mobile device management systems from Avocent LANDesk, Nokia Intellisync, Novell and Sybase iAnywhere as well as RIM's BlackBerry Enterprise Server and hosted device-management products from Perlego and iPass.

As for security, similarly, if you're supporting a large number of devices and apps, you may need a separate system. The app vendors we surveyed have good security offerings, so you may be able to get started with their capabilities before invoking third parties. For instance, nearly all the products authenticated users, encrypted data communications, encrypted data on the device and had provisions to neutralize lost/stolen devices.

Finally, even though many application vendors now support mobile devices, this does not mean the demise of mobile middleware, especially if the number of companies providing it is any indication. Consider middleware when you need greater automatic mobility across different types of networks, say, Wi-Fi to 3G; more efficient network utilization; and support for a variety of mobile devices. Some of the vendors here include BEA, IBM, Motorola Good, NetMotion Wireless, Nokia Intellisync, Oracle, RIM, SAP, Seven Networks, Sun, Sybase, TCS Mobile, Visto and Wavelink.

There's no question that mobile computing will become pervasive, with today's wireless e-mail a precursor for developments to come. Devices will grow ever more powerful, user interfaces will evolve through developments such as improved voice recognition, and enterprise applications will become much more agile in the range of mobile user devices they support. Plot a strategy now, or be left at a disadvantage.

Tactical Or Strategic: What's Your Plan?When your company adopts mobile computing technologies on a widespread basis across a large number of job functions and multiple business units, your program becomes strategic rather than tactical.

Most companies begin mobile app deployments tactically, with wireless e-mail and related functions. More than 70 percent of North American firms had deployed e-mail as of 2006, according to Forrester; 64 percent had personalized contacts and calendars, and more than one-third offered mobile access to internal information for employees. Less widespread apps include SMS alerts; IM; inventory management; and field service, sales force, customer-facing and logistics apps. Our reader poll showed e-mail dominating mobile apps, with 69 percent of respondents indicating adoption, a rate more than twice as high as the next category, collaboration.

Most mobile sales-force and field-force automation apps are still relatively tactical, in that they involve only select departments. Mobility initiatives become strategic when the scope expands to applications such as enterprise resource planning, business intelligence, helpdesk and supply management; fortunately, our RFI and research show that most major enterprise application vendors directly support a variety of mobile computing devices. At a strategic level, that means providing dynamic, easy and secure access to important information that mobile workers need, whatever their job setting. But it's more than just employees. This access means your organization can communicate with partners, suppliers and customers, regardless of location, while having complete information about assets and systems.

And clearly this is the trend. The number of mobile applications enterprises deploy to their employees will continue to grow by 30 percent per year through 2011, Gartner estimates.

Sounds good, but how do you get there? By making mobility a key part of your IT infrastructure and building a mobile policy that fully defines and manages all the broad technical aspects, namely devices and their OSs, access networks, mobile middleware, applications, security, and management. Our emphasis here may be on the actual applications, but you can't deploy an application until all these other items are considered. We do acknowledge that mobility will benefit some industries and businesses more than others, but ignoring mobile/wireless computing would be about as smart as ignoring PCs 20 years ago.Peter Rysavy is president of Rysavy Research, a consulting firm specializing in wireless networking.