You
may find some unexpected challenges in enterprise app deployment.
Greg Hansen has been with Motorola for about 20 years, the
most recent seven years in IT, focused on enterprise apps and strategy.
Greg made a podcast
recently, describing some of our enterprise app deployment experiences
inside Motorola Mobility. This post captures, in blog form, the detailed
knowledge that Greg shared with the developer community.
Greg
explained that over the last year or so, his group within Motorola
Mobility IT has built up a portfolio of over 20 mobile apps.
They’ve tried pretty much all the deployment alternatives, as they
attempted to answer the question “how do you distribute apps securely
and effectively to employees?” Most enterprises can arrive at good
deployment choices by thinking about the answers to these questions:
- where are the apps coming from? Although it’s a natural fit for IT, some apps may be created by sophisticated users, or other developers. You definitely want to encourage this resource pool as it fosters internal innovation. You also want to secure, control, and manage the apps created outside the IT team.
- who is the target audience? If there is a very small number of users, say single digits, you can email the .apk file and ask people to read the email on their device and install the attachment file by hand. You’ll need to provide a good set of instructions and a support hotline. Motorola has an app that measures wifi signal strength as you walk about a building. The app is only used by four specialized IT staff, and it was deployed by email.
- Do you want to limit the distribution of certain apps within your enterprise?
Similar to blacklisting or whitelisting at a domain level, should certain apps be available only to specific groups of users? Some apps may have data that is pertinent to C-level executives, or a sales team, or an engineering team. Most enterprises don’t publish all apps to all employees, so consider the level of granularity you need.
- how many apps do you plan to develop and manage? If there will only be one or two apps, then choose a low overhead way. If you are going to produce a lot of apps with a lot of users (perhaps an app user base in the thousands, as we have at MMI) you need something that scales up appropriately.
- how will you get updates out to the user community? Expect all your apps to need updates and new versions. Most markets, like the Android market, offer this capability. Ad hoc distribution methods force you to adopt time-consuming manual procedures for the inevitable app updates.
That sets the context for deployment choices. Now let’s look at the different approaches available to you. These are listed in the order in which you will likely try them - from the simplest first, up to increasingly elaborate as your number of users scales up.
- direct loading of apps - using a developer tool like MOTODEV studio. This requires a level of technical knowledge that is too much to ask of non-technical users. We started out using this method, but it doesn’t scale up, and has high support costs. There is no support for versioning the app. This approach is good when you are starting out. It gets your apps in use quickly, for a small user base. You will probably want to move onto one of the other approaches as your user base grows.
- side loading of apps - this means emailing the .apk to users, to receive on the mobile device. You can also install by dragging the .apk onto the SD card, after mounting it on your PC (connected to the handset with a USB cable). Again, there is no version management, and people can forward the app around, so you don’t know who has the app or needs to be updated. Also some carriers, like AT&T, disable side-loading, only permitting app installation from a market. Side-loading is a good option for those moving into mobile app development, but again, not a long term solution.
- installing from a web server - there is an Intent that tells Android to install an .apk file. If you host your apps as files on a web server, the device will automatically offer to install an app when you browse or download it. We host this server externally, outside the corporate firewall, on Amazon Web Services. Amazon Web Services supports security and specific user lists for file access. The costs are very low, and the service is reliable. It has worked out well for us. We added more security features, so only authorized people can install the app.
- the Android market run by Google. That has the comfort of familiarity for most users. The app has public visibility, so be careful to avoid inadvertently disclosing anything, even down to the level of choice of app names. (Publishing an app called “next year’s sales leads” invites the wrong kind of attention). The Android market automatically checks for device compatibility before displaying an app. That protects against poor user experiences. The Android market does not have a way to limit distribution to certain users, so you have to build into the app some security to prevent non-employees from using the app. We use the Android account manager to control access to the app, and a separate level of security to restrict access to company data.
- an enterprise market - set up your own enterprise market, with update notifications, and perhaps automatic app updating, if you have the resources to implement it. This is the most elaborate solution, but also the most complete one. Instead of building your own, you may consider one of the ready-made enterprise app stores operated by third parties, such as Mobile Iron’s Enterprise App Storefront.
Greg’s
team did develop our own private enterprise market, once the scale of
use justified the investment. Motorola Mobility’s enterprise
market has a client app, which works with the Amazon web services back
end. The client has a Json configuration file which is used
to load a SQLite database on the device (it holds data like installed
apps and versions). We support group identities and can provision
different versions of an app to different groups.
We
made the decision not to support any devices earlier than Android API
level 5 (Eclair) because that’s when the android.accounts.AccountManager
class support came in. Android 1.x releases are in use on just 2% of
handsets according to this version use chart for December 2011, compiled
from Android Market users.
Google regularly updates that market share chart, and you can find the data here.
Our
most popular app is the mobile employee web portal, followed by the
conference room maps, with the “conference call one click dialler”
bringing up third place. We know this kind of data because our
installer includes an audit trail - each download writes a new line of
detail in a Google cloud spreadsheet. This lets us check that the
right versions of our mobile apps are getting to the right people.
For the future, we want to blend some device management into our
market, and support the capability to push enterprise apps onto devices.
The
bottom line here is that there are many choices for installing apps
onto user devices. Start with something simple, and as you need to
scale, go as far as you need along the path towards running your own
enterprise market. But, to keep costs reasonable, only go as far
as you need to, and no further.
Peter van der Linden
Android Technology Evangelist
