Efficiency in store

As part of the larger consumerisation trend, the movement towards bring-your-own-device (BYOD) is forcing IT departments to look for new ways of managing mobile computers and supporting business systems on a wider set of platforms.

Take this together with a growing preference among consumers for the app store model, and you can see why many organisations are having a close look at the new enterprise app store (EAS) model as a way of serving up a large number of applications to an employee base running a variety of devices.

It’s been clear for quite some time that some kind of platform is needed for wide-scale deployment of mobile software in an enterprise.

It’s relatively easy to manage the initial deployment of a single application, and the first users are eager to download the software.

But over time, users lose track of versions and fail to install upgrades. As soon as the company wants to deploy other mobile applications, the task of managing the software becomes complicated.

While mobile device management (MDM) platforms or mobile application management (MAM) systems have been used in the past to solve these problems, the app store model offers greater flexibility in supporting a variety of devices and software.

Vishal Jain, mobile services analyst at 451 Research, says that 43.5 per cent of enterprises it surveyed were deploying a corporate app store, and a segment of about a dozen vendors is developing around the approach.

Gartner has placed EAS at number five on its list of the top 10 global IT trends for 2012.

EAS of deployment The app store model, invented by Apple as a way of distributing applications, lets subscribers browse a catalogue of applications and download the ones they want.

Download and installation are easy, as is the payment process.

Apple’s original App Store was released in 2008 as a modified version of iTunes. Since then, Google, Microsoft, Nokia, and other vendors have developed their own app stores and millions of applications have been deployed.

App stores allow users to download off-the-shelf business applications, but consumer app stores don’t work well for enterprises, since IT departments can’t control the software, which might contain malware that threatens other business applications running on the device or that reads company-sensitive information.

There’s also no way, using a standard consumer model, for companies to buy site licenses and track compliance. Moreover, a public app store isn’t a suitable channel for delivering custom software to a closed population.

To address these problems, several vendors (including Apple) have developed a similar model to help companies manage software for internal business users.

Instead of having workers pay for each download, enterprise app stores check user profiles for permissions to download applications, and verify compliance with company-wide license agreements; they might also provide variations on software versions depending on who the user is.

Sales managers could get a different version of an application than sales reps, for example.

As the market for enterprise app stores has grown, so has the variety of offerings. The best ones support different devices, providing services for Android, iOS, BlackBerry and Windows mobiles.

Leading systems also manage all the applications you might need: those developed in house, those purchased under a company-wide license, and those available to the general public.

The advantage of offering public applications through an enterprise app store is that a company can retain tight control over what goes on devices by restricting the set of applications available to those that have been vetted by the IT department.

Organisations can set up and operate their own enterprise app stores either in house, by buying a platform which they customise or by subscribing to a cloud service which they can configure to offer a unique set of applications serving a limited user population.

Strategy before silo Something to avoid when setting up an enterprise app store is the silo trap.

If a particular business unit is the first to express a need for mobile application management, the IT department might select an enterprise app store based on the needs of that business unit.

When another business unit then wants to deploy a different application, they might have a different set of needs that calls for a different kind of app server, so either they have to defer to the choices of the first business unit, or they set up their own independent app server.

A similar trap is what Andrew Borg, research director at Aberdeen Group, refers to as the ad-hoc approach.

“Enterprise mobility is evergreen, and there is a constant refresh as new products and product versions come onboard. Before selecting platforms for any one aspect of mobility, you need to look at the entire lifecycle of mobility in the enterprise, from provisioning to decommissioning,” he explains.

“A comprehensive platform includes functions for device management, application cataloguing, application management, data loss protection and content management. Implementing such a system, which we call an enterprise mobility management (EMM) platform, is the way to go, but many companies are using bits and pieces here and there.”

Because any one platform can only supports a limited set of devices, an organisation can get stuck supporting a set of devices that’s inconsistent with what they would have chosen had they sat down and planned.

“It has to start with policy,” says Borg. “What’s your corporate policy on the platforms, the versions of operating systems, and the device manufacturers you support? If you don’t start with strategic policy decisions, you quickly find yourself on a very slippery slope.”

Jain at 451 Research stresses that an EAS is only really justifiable as part of a long-term software delivery strategy.

“In our view, enterprise app stores serve a purpose only when enterprises are thinking beyond one-time application development, and are actively looking at managing the entire deployment cycle of several applications,” he says.

Permit and prohibit When a company chooses an EAS platform, one thing they should look for is how well the platform allows them to manage white lists (lists of applications that are sanctioned) and black lists (lists of applications that are forbidden).

According to Aberdeen Group’s Borg, you have to regard everything with suspicion.

“In the modern era, you have to take the stance that an unknown app has the potential to have an unknown threat. Given that, as your baseline, the strategy should be to have both the technology and the expertise to deal with applications that are being developed and propagated at an accelerated rate,” says Borg.

“You might declare that anything that’s not on the white list is on the black list. Or your policy might be that anything that’s not on the black list is on a grey list, consisting of applications that are suspect and held in a sort of quarantine.”

Companies can also use EAS to help track downloads. This information can serve as input to a charge-back model, says Jain.

“When combined with an access and identity management system, all application access can be charged to the respective organisational units.

Once the hierarchical views of who works in what department have been defined, it is not difficult to provide a charging and billing mechanism,” he says.

One final word of advice to companies is that they select a platform that supports the devices of their choosing, not the other way around.

You don’t want to fall into the trap of making your device choices based on what the platform vendor has chosen to serve.

“We recommend drawing a line in the sand on which devices you support, keeping it down to three or four platforms if possible, and maybe several versions of operating systems within those platforms,” says Borg.

“You’re still going to wind up with 10 or 12 profiles you’ll have to support, but that’s better than 40 or 80, or an unknown number.”