How To Handle Device Diversity

By  Pat Brans — April 29, 2010

With so many kinds of smartphones, how can any organization integrate more than just a relatively small set? Check out our step-by-step guide.

Left to their own devices, most employees will carry around one smartphone for both business and personal use. It's much easier than carrying around two separate handhelds; and it's less confusing than managing two different phone numbers.

Many organizations just accept this fact and let workers use company-provided phones for personal use. The cost is relatively small, and it shows the company appreciates its employees. Besides, fighting this trend is like trying to push water uphill. Forward-thinking companies go with the flow and actually make it work in their favor.

Some enterprises take it from the opposite angle: they let people use the personal device they already have for work. Or they might give employees an allowance and let them go to the store and buy the handset they like.

Often the features you get on the consumer-purchased device surpass those on hardware intended for enterprise use. And employees frequently find consumer software that is better than that provided by the enterprise. This means employees become "prosumers" (professional users who buy like consumers) -- a fact that's not lost on device manufacturers, who actually identify prosumers as a market segment.

With so many kinds of devices, how can any organization commit to supporting more than just a relatively small set? After all, there are different form factors, which means input is different and the screen is different. There are different operating systems, and several versions of each. The challenge is daunting.

Here are three key guidelines to help companies tackle these challenges.


1. Find Simple Ways To Support Basic Apps

> Basic Email and PIM are among the easiest functions to support across different device types. Virtually all smartphones come with a local email client, and whether you are using Microsoft Exchange or Lotus Notes, you can easily switch on options on your email servers to make mail accessible to mobile users.

Beware: As soon as you start allowing company email on mobile devices, you have to think about data encryption. And if you want more sophisticated features, such as the ability to download and view attachments or access to more advanced calendar functions, you'll need more specialized client software.


> Job-specific applications are less easy to support across device types. While you'll want to be open to supporting a large number of device types for email, for employees requiring specific applications, such as CRM, you need more control over which handsets can be used.

Beware: Java does a good job of allowing basic applications to run on multiple platforms, but is not a cure all. Handsets still have different screen sizes and input features. And anytime you have an application that needs to invoke device-specific functions (such as getting location information), it cannot be completely platform independent. Java can be slow, so you should check carefully to make sure any Java-based application runs fast enough for you.


> Accessing all mobile applications through a browser is an attractive idea, but there are many pitfalls. Making your applications web centric is one of the first approaches companies think of to become device agnostic. It's not that easy.

Beware: Browsers require ubiquitous network coverage, which you won't get, and the user experience for apps needing constant connectivity can be painful. Even on a desktop, every browser renders content differently. On a handheld, the variation is wilder because there are so many form factors.



2. Be Realistic About Your Mission-Critical Apps

> For mission-critical mobile applications, you'll need automatic backup and restore functions and you'll need to be able to quickly provision devices. Make a clear distinction between users of mission-critical mobile applications and the rest of the company.

Beware: You'll want to limit the acceptable device types to a very small number. It would be costly to keep a lot of different types of replacement handhelds in inventory and maintain the expertise to support them all in the field.


> Specialized devices should be the exception to the rule allowing employees to use the same handset for business and personal use. Some mobile apps require specialized hardware. For example, people working in rough environments need ruggedized devices. It makes no sense to allow personal use of these handhelds.

Beware: You'll want to allow some email functions for dispatches or other notifications. Make distinct email accounts accessible on such hardware.



3. Never, Ever Underestimate Security

> Security functions need to run on all devices where private data will be stored. Don't allow data to be stored on any handheld that doesn't provide data encryption.

Beware: You don't need to encrypt everything. Doing so would slow down the handset and use the battery more quickly. You need to be able to configure what gets encyrpted, but don't leave configuration of such features to the user.


> You'll need a device management platform to enforce security policy and set up configuration so users don't have to. If you expect users to set up the proper security on their handhelds, you're in for a nasty surprise. For users doing anything more than making phone calls and performing simple data operations that don't require security, you need to manage their devices.

Beware: The device management platform you choose will limit the kinds of handhelds you support. To support a wide range of handsets, consider using more than one kind of device management platform.


For More on this Topic
Read our four-part series, "Device Wars," at


comments powered by Disqus

RATE THIS CONTENT (5 Being the Best)

Current rating: 0 (0 ratings)



Must See


What Enterprise Apps Need Now

Mobile Enterprise explores how companies across all segments are increasingly leveraging mobile apps to enhance productivity for everyone, from field service workers to C-level executives.