a blog about innovation and solutions
mobile, opinions

Mobile deployment options for the enterprise world

Like it or not mobility is central part of our life, we as a species are designed with mobility in mind, we move each day between our homes and our offices, between our desks to various meeting rooms and project premises to perform our duties. As evolution, we are in the information age, we left the industrial revolution long behind and we are mostly producing value and wealth based on information, we are in the middle of the informational revolution.

So what we are witnessing, in the last years with the evolution of mobile phones, mobile devices like tables and the mobile applications that make them useful is just normal evolution. As technology evolves, the way we interact with it becomes closer and more natural to the way we interact with the world. We need to be able to communicate and process information no matter where we are and what we are doing.

Certainly we had mobile phones for quite some time what changed is the accessibility of the Internet and Intranet related information’s on the mobile devices and the multitude of the mobile applications that gave a new dimension to the mobile world.

The traditional lifecycle of the consumer mobile applications is that once procured or developed and provisioned by the company that wants to distribute them it gets into the standard flow of the app store that is being used, being that Apple ITunes or Android Play (Market) for distribution. In some distributions channels like the Apple ITunes the applications will go through a review process and if the application is successfully approved it gets distributed to the end users. Each new version then goes through the same process.

Apart from the fact that the applications are provided by a central store, this model resembles very much how software was distributed in the era of fat applications, where each software vendor had its online software market where he sold software that got downloaded and installed by the end user.

Fortunately we have lots of experience with the traditional application distribution model and by now we know that it might have been appropriated for the end users it does not answers all the needs of an enterprise where there are plus issues that need to be addressed.

To cope with the specific enterprise issues a whole new concept was created with the Application Service Providers (ASP) and later Software As A Service (SAAS) concept that allowed enterprises all over the world to start using software with no large upfront investment, no maintenance headaches, no outdated solutions.

Unfortunately when we are talking about mobile applications in enterprises we are in most of the situations in pre ASP/SAAS era.

While the end users can decide themselves about what applications to install and upgrade and what level of sensitivity their information have, businesses usually are stricter with these requirements. Enterprises will most often have to face at least the following questions:

  • User authorization and license management. How is user access controlled to which applications? What if users change roles? What if the applications need to be licensed per user, how are licenses enforced and tracked for the purchased applications?
  • Application and data security. How is integrity assured? What happens with the data and application access if a device is stolen, lost or hacked?
  • Application distribution. How can the application be distributed to multiple device types? How different policies as mandatory installs and / or mandatory upgrades are handled?
  • Application and device tracking. How can corporate and legal compliance be established? What is the method to inventory and audit the mobile devices

As can already be seen the lifecycle of a mobile applications dedicated for the business can be quite complicated.

Procurement. Given the limitations in displaying and interaction of the mobile devices, mobile applications are most effective when they serve a very specific function, rather than the broad range of functions most enterprise software offers. In the end, what are needed are enterprise-class controls with consumer app store convenience. While more companies are looking to bring mobile app development expertise in-house, many often look to outside developers to source these specialized applications. This often makes sense considering that most companies are dealing with a myriad of mobile operating systems and device types.

Provisioning. To be able to run any kind of mobile application on a mobile most of the time the application needs to be signed with a certificate. While in some platforms like Android these certificates can be self-signed and generated, on other platforms like IOS there certificates are provided by Apple based on a yearly developer or enterprise license. If on Android a development subscription or license is only needed for applications that need to be deployed trough the mainstream Android Play market, on IOS any application that is installed on an IOS devices needs to be signed with a provisioning certificate.

On iOS there are three sorts of distribution profile:

  • Developer / Ad-Hoc. iOS Developers enrolled in the Standard program have the opportunity to distribute their application outside of the App Store on up to 100 different devices.
  • Developer / App Store, allowing the applications to be uploaded to the App Store after review by Apple
  • Enterprise / Ad-Hoc. iOS Developers enrolled in the Enterprise program have the opportunity to distribute their application outside of the App Store but for internal use and without the 100 devices limit. The “Enterprise” provisioning profile is created to allow applications to be distributed inside/internally to a company. The enrollment is linked to a company’s DUNS number (https://iupdate.dnb.com). The certificate has to be updated each year and so are the applications that where signed with the certificates.

Review and Authorization. After the mobile applications is sourced or developed it is subject of an approval process. Depending on the company, this step may require different levels of trials, reviews, and sign offs. For instance, testing with limited deployment to small groups might be a first step. Then, the app may need to move through other approval workflows, such as technical, security, financial, and legal reviews, before widespread deployment.

Deployment. Once the mobile applications are approved they must be deployed to the right set of users. If a company is large enough or if there are many existing mobile applications, this is not a trivial matter. Most companies have multiple departments with differing application needs. Users may need access to applications based not only on department but also by their role and level within the company. To simplify management and access for mobile apps, mobile application management systems should be integrated with a company’s existing directory services. As an employee changes roles, their access to applications should be automatically revoked or granted based on that change.

Also with the multitude of mobile OS platforms and versions, a company needs to make it simple for users to get the right apps for the right devices.

Usage tracking. Companies purchasing enterprise mobile apps want to understand which of their employees have downloaded their applications and which ones haven’t. This is especially true for any required or featured applications within the company. This information can be used both for license tracking and auditing capabilities, as well as to track compliance with corporate application policies. If an employee has not yet downloaded a required application, department managers should have visibility in order to contact that user and ensure compliance.

Updating. Any application that provides any kind of useful service usually evolves either because business process changes or underlying data changes. Application updates must be made available to users as simply as possible. Also it is important to understand which versions of applications are deployed throughout the enterprise. Sometimes it is necessary to push updates to users such as when security vulnerabilities are discovered. In other cases, older versions of apps become unusable as backend system applications evolve. By setting up a clear and enforceable policy for app versioning in the enterprise, IT’s role in distributing and enforcing application updates can be dramatically simplified.

Decommissioning. When an employee leaves or their device is lost or stolen, it is critical that the company’s sensitive application data is not put in danger. IT teams must have the ability to remotely lock and wipe application data. With different security needs for different applications, it is important to have app-level security profiles, independent of any device policies in place.

Given that the nonfunctional requirements are clarified let’s go over the major deployment methods that are generally available to Android and IOS based mobile applications.

There are four major ways to deploy mobile applications on IOS or Android smart phones today: consumer app stores, side loading, web based applications and MXM based solutions

Consumer App Stores

The easiest and most cost effective deployment methods for mobile applications are trough the dedicated consumer deployment channels as the: Apple’s App Store and Google’s Android Market are. While the initial investment is very low, these app stores do come at a significant cost. First, their use requires giving up any meaningful control of the release cycle, as companies must wind their way through vendor approvals for the initial submission as well as for all subsequent updates.

If the mobile application provides a generic service and uses maybe one backend system no matter what companies or users are using the application (just like we can see in the bellow image) then it may make sense to have the enterprise application being delivered over a regular consumer app store.

Most of the times, however, the mobile applications are a front end to a subset of already existing software solution from the repertoire of an software vendor, solution that might have an on premise or cloud based deployment.

Having a per customer deployment of the backend solution or a dependency on such a backend poses a serious limitation to a single app based deployment.

There are however ways to deal with these scenarios. One would be to create / configure a different application for each customer with different backend access address and maybe some different branding mechanism.

In case the number of customers are manageable, the number of deployments are well kept under control especially in conditions where deployment costs are important might prove as a conveyable method.

If the number of customers could potentially create a logistic problem then another alternative solution to these problems would be to have one application delivered in the store that would allow / configure access to different backend services based on a pin code mechanism and a central dispatching server.

When the application would be installed or at first start the application would request a pin code that would be used for requesting from the central dispatching server the proper backend URL. This would allow for one mobile application deployment to function with an indefinite number of backend deployments and all this in ways that would protect the identity of the corporate customers if that is sensible.

Perhaps the most important aspect is that companies must give up control of the app itself, as it becomes publically available on these consumer application stores, there are no “private” applications.

These generic app stores provide very limited auditing capabilities, without the ability to see specific users and versions. There is no usage tracking to help developers understand what features are being used and user feedback is diluted by irrelevant public comment and use. Critical to security, the decommissioning of an app is not possible for individual users when they leave the company or misplace a device with a public app store.

Side Loading

Some companies bypass consumer app stores and manually side-load applications directly onto devices.

This approach offers significant control and addresses several of the issues with consumer app stores, but it comes at a very high cost and effort. The burdens introduced by side-loading limits the frequency of releases and updates as every device must be touched every time a new app is installed or updated. While this approach may work for small group testing, it is not scalable beyond a handful of users. In addition, side-loading fails to provide critical enterprise features and controls, such as app usage monitoring or decommissioning.

Web Based Applications

The technology stack used to build the application can have a major impact over the deployment options.

Under iOS and Android there is are easy ways to create shortcuts of web pages or web applications on the home screen of the smartphones just like native applications have thus providing easy access to these applications in conventional manners.

In the special cases when offline mode is not desired or required a mobile web application provides the extra feature that can be deployed as a regular web application so no more upgrade or installation problems. The users will always benefit of the latest version of the software with no upgrade problems.

While web based applications tend to scale very well and benefit from all the advantages that SAAS or Cloud based applications offer, just like all the above methods, web based mobile applications also pose problems as fails to provide critical enterprise features and controls, such as app usage monitoring and inventory.

On top of that on iOS version 4 and bellow there is great performance penalty when a web application is being started from the home screen as opposed from the web browser as the JavaScript engine does not run in its most performant mode. While this issue was addressed (http://www.guypo.com/mobile/ios5-top10-performance-changes/) with iOS version 5, there are still small differences in performance between a web page lunched in the browser of the smart phone and from the home screen.

MDM, MAM,  EAS Based Solutions

It becomes harder to believe, each passing day that a policy that would enforce employees to use a standard corporate device in order to control access and mobile equipment would have any success in the future. The whole BYOD (Bring Your Own Device) is so widespread in the corporate environment that at least half of the business had to considerate as given according to a 2011 survey.

Some organizations, especially those in the government and health care face new legal questions. Who actually needs to own the device? There is no universal and clear answer but at least there are 3 major directions:

  • Shared management. Basically the employee owns the devices but if he needs to access corporate resources from a personal device then the employee grants the company the right to manage the device or parts of the device (like certain applications) and sometimes even to lock and wipe the device even if there will be personal data lost
  • Corporate ownership. The organization buys and owns the device allowing or not non business use of the device. Employee who don’t like the device or services can carry their own devices which will not have any corporate access
  • Legal transfer. Basically the organization buys the device from the user while keeping control and managing the device just like the above methods while it commits to selling it back to the user when the employee leaves the company.

Organizations that find themselves trying to answer the ownership questions or are in need to address the extended lifecycle of the enterprise mobile applications have quite a substantial toolset from three sometimes confusing market segments:

  • Mobile Device Management software, also known as MDM
  • Mobile Application Management software, also known as MAM
  • Enterpise Aplication Stores, known as EAS

Mobile Device Management, MDM solutions are device centric. The focus is on the device and what happens to the apps and data on the device in case of an event: temporary or permanent access restrictions, data plan restrictions, rooming restrictions, loss or theft. Most MDM solutions have a level of application management, most of the time involving creating an inventory of applications on the devices and an enforcement model for installing and removing files and data.

Mobile Application Management (MAM) focuses on the applications and the users of the applications, therefore MAM supports license management, application updates, complex application life-cycle and protects the end-users privacy. MAM is also linked to the Application Store by checking in code during the publishing of the app in the store and by managing application provisioning. MAM is enforcing policies at the application level: provisioning, deployment, roll back installation, data security and configuration managements.

An Enterprise App Store is a company internal marketplace for shopping, categorizing and installing applications. Strictly speaking, an enterprise app store may or may not provide the functionality provided in a Mobile Application Management solution. Enterprise App Stores can be provided either as an application installed on a device or as a web-service providing a similar catalogue.  An Enterprise App Store should allow end-users to be able to install applications from a listing of available applications.

There are many players in the field each with it’s own competitive advantage and attacking different zones of the MDM, MAM or EAS segment. Just some of them are:

Some of the MAM providers

Some EAS providers


There does not seem to be a universal solution or silver bullet when it comes to deploying mobile applications in the enterprise. The complexity of the deployment depends very much on the technology chosen: native versus web, on the specifics of the application (like: need for enforceable updates when a new backend version is deployed) and on the specific needs of the customers (core needs for the management of the decommissioning and tracking of the application usage).

Generic applications deployable trough the regular channels (iTunes & App stores) and mobile web solutions would tend to be the easiest to manage as usually enterprises that already need and employ a MDM or MAM solution will be able to easily integrate them into their existing workflow and track the usage if needed.

Custom mobile solutions individualized with different backend per deployment and enterprise would probably require investigating and investing into an Enterprise Application Store solution so a new version can be easily provisioned, pushed and monitored through multiple enterprise customers that do not yet employ or require any MDM or MAM solution. In the same time software vendors would need to be prepared and able to also push the same applications through the customers MDM or MAM solutions where those are in use.

The provisioning rules imposed on some platforms as IOS aggravate the matter a lot as in this circumstances the enterprises would need to be enrolled into the IOS Developer Enterprise Program and the software vendors would need to provision the applications with the customers provisioning at each release and even worst at each customer yearly licensing renewal.

Leave a Reply