|
Original analysis by Peter Rysavy, summary by Art Wittmann
We’re on the cusp of a revolution in mobile computing and application deployment. That’s the primary finding of our research on mobile applications. The question is, are you ready to keep your mobile workers competitive?
We don’t use the ‘r’ word lightly. But in an industry that tends to advance by evolution, this is something different. Several potent forces are acting in concert to dramatically expand the ability of mobile workers to access any information, at any time, from anywhere. Companies will function in completely new ways by streamlining business processes and extending them to a highly mobile workforce.
The challenge for IT will be to transition from tactical use of mobile computing to strategic deployments. Two of the three necessary pieces are rapidly falling into place: the latest 3G networks being built by carriers will have the reliability and bandwidth to support critical applications, and mobile workers now commonly carry 3G-connected (or easily connectable) laptops and handheld devices. What’s missing is a wide selection of off-the-shelf applications as well as the mechanisms to easily create mobile versions of existing enterprise apps. Our survey results bear this out: While 70 percent of respondents said they were adopting mobile technologies, only 17 percent said they were doing it with companywide strategic initiatives.
While the game-changing value proposition for mobile applications is hard to dispute, there are also significant obstacles, notably complexity, and the need for carriers to provide services over their 3G networks. With a little luck, advances in the latter may significantly help with the former, but until that happens, developing mobile applications is not for the faint of heart.
Carrier services will come in the form of the IP Multimedia Subsystem, or IMS. Today’s networks primarily deliver packets or messages, but operators such as AT&T, Sprint and Verizon are laying the foundation for more sophisticated communication. IMS is a (frame)work in progress based on the Session Initiation Protocol. It will support the dynamic blending of a variety of communication components, including circuit-switched voice, packet-switched voice through VoIP, video, user location information, and messaging.
The first use will be providers creating their own services, such as video streaming and push-to-talk over cellular, but they also will open up IMS interfaces to third-party apps. The result will be rich, multimedia-oriented applications that will captivate consumers and, presumably, enhance enterprise productivity. Imagine an app on a desktop at corporate headquarters that graphically shows the location of an employee in the field and can initiate an IM session simply by clicking on that person’s icon.
Given today’s 3G networks, powerful laptops, and handheld devices, we already have the systems and infrastructure to extend data to mobile workers. However, running applications designed for always-connected, high-speed networks with low latency over wireless links usually results in sluggish and unreliable behavior. It’s common to experience temporary loss of connectivity, reconnections with different IP addresses, and inconsistent throughput levels because of high network load or poor signal conditions. All of these will flummox today’s desktop applications.
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 factors are working to improve the situation. First, 3G networks are much faster than their predecessors. Second, wireless middleware has become much more sophisticated and can often be deployed without changing the overlying application. Third and most important, application and software-as-a-service vendors are finally delivering versions of their enterprise apps that directly support mobile devices. Effectively eliminating the mobile middleware component makes IT’s job much easier. In some cases, you may still want middleware to provide security, management, or mobility features, but the good news is that increasingly, you won’t need it.
This doesn’t 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 request for information, we sought to uncover the extent to which major software application vendors have developed support for mobile systems.
While the situation is getting better, serious impediments to mobile application deployment still exist. Multiple mobile platforms, wireless network foibles, and challenging integration translate into complexity for IT managers and CIOs. It’s this complexity, more than anything else, that’s inhibiting broader deployment of optimized mobile applications.
Application attributes An optimized mobile app works within the constraints of mobile devices, especially handhelds, and makes effective use of available wireless networks. 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 won’t require any more user input than absolutely necessary, and should go to the network only for the information it needs.
Applications should operate rather differently on a mobile device. For example, desktop applications leverage free bandwidth to poll servers for information, but in a wireless environment, it’s more efficient from both the network utilization and power management standpoints to dispatch data to the mobile system only when there’s new information. The most vivid example is wireless e-mail, where today’s systems 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 are also fundamentally different from those of a desktop. People constantly lose their mobile phones, and that’s bad news for IT given the huge amount of storage available on these devices combined with their ability to access sensitive data. The big question is, should your app incorporate native security features, or will you employ a separate security system? 
Features to look for when deciding 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 do nothing to safeguard information on the device. The trend is for mobile applications to incorporate security capabilities.
For enterprises willing to take on the development task, there are numerous architectures for mobile applications. The simplest use Short Message Service, or SMS, to send text messages to the mobile device. Cellular operators also offer 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 is that the system will work with almost any cell phone.
Browser-based applications make for a better user interface. Using a mobile browser for an application is relatively straightforward so long as the application takes into account screen size—and minimizes the amount of data presented. Over 3G networks, browser operations are fairly snappy, but on slower 2.5G systems they can be quite sluggish, with users often waiting tens of seconds for screen refreshes. Like SMS, the advantage of using a browser is that you can support a wide range of devices independent of the underlying operating system.
For local code, a Java client works across the greatest number of mobile devices. One common Java approach uses Java 2 Micro Edition in conjunction with specifications that define a complete mobile application run-time environment for mobile systems. J2ME has seen its greatest success with consumer applications, but it’s increasingly viable for enterprise apps. Another Java approach is the RCP (rich client platform) based on work by the Eclipse Foundation. Performance tends to be significantly better than for browser-based applications, but on some devices the Java environment itself is sluggish.
The most effective mobile applications are those developed for the native environment. They can leverage all the capabilities of the platform with the least processing overhead. However, developing native apps requires substantial expertise; it’s no small feat to become familiar with all the development tools and debugging approaches required. It’s therefore not uncommon for developers to target just one mobile platform, most often Windows Mobile in the United States and Symbian in Europe.
|