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.