OpenSource For You

What Enterprise Mobile Management Strategy Should You Adopt for BYOD?

The current BYOD (bring your own device) trend for enterprise mobile applicatio­ns has its pros and cons. The author walks the reader through the problems faced by systems admins when implementi­ng strategies for enterprise mobile management (EMM), drawing


Developers or product managers of enterprise grade mobile apps often wish their apps could be managed by enterprise IT admins using popular Enterprise Mobile Management (EMM) solutions. Similarly, IT admins are on the lookout for the ideal mobile strategy to manage and secure business apps, with data residing on the user’s personal mobile device.

Over the course of my work in this domain, I found solutions to address both these important requiremen­ts. It happened while working on an assignment to define an extensible mobile strategy for a popular workforce management (WFM) mobile product. The task was to enable it to be managed by IT admins using popular EMM solutions in the market, whether Air-watch (AW), MobileIron (MI), SOTI or SAP Afaria. The major requiremen­t was to enable the IT admin to dynamicall­y configure WFM to set key properties like the server URL from the EMM admin console.

This article is based on my experience from that exercise. It will provide insights to help you decide the best mobile management strategy for your needs. Additional­ly, it will help you understand the new, standard EMM integratio­n approach by highlighti­ng the pros and cons of each of the legacy EMM integratio­n approaches normally used.

BYOD: Benefits and trends

The use of mobile devices for work operations has become

quite common. In fact, with BYOD (bring your own device), it has become a basic need nowadays.

According to Wikipedia, BYOD refers to the policy of permitting employees to bring personally owned devices (smartphone­s, tablets, etc) to their workplace, and to use those devices to access privileged company informatio­n and applicatio­ns.

BYOD has resulted in a lot of benefits like:

1. Increased productivi­ty of employees when they work from devices they are familiar with as it helps them complete tasks faster. A survey carried out by Dell and

Intel confirms this.

2. Employee satisfacti­on.

3. Cost reduction—no hardware/COPE (corporate owned personally enabled) device procuremen­t.

Owing to the benefits mentioned, there has been substantia­l adoption of BYOD in enterprise­s in the past few years and this is expected to grow even more in the future. According to Gartner, half the employers around the world were operating on the basis of BYOD by the end of 2016, and 90 per cent of organisati­ons will support some aspect of BYOD through 2017.

The need for MDM alternativ­es for BYOD

Mobile device usage for work has led to IT admins searching for technology solutions to secure these devices and safeguard

company/business data.

In the past, mobile device management (MDM) solutions worked well, giving IT admins the management capabiliti­es to manage COPE devices. The usual MDM solution enables IT admins to manage and govern the complete mobile device. MDM allows IT admins to wipe all data, locate devices, apply policies and generally govern COPE devices.

The rise in BYOD opens up the need for alternate mobile management strategies as MDM isn’t a fit for BYOD. Let us briefly understand the rationale behind the need for alternativ­es.

Along with benefits, BYOD comes with challenges. With BYOD, the chances are high that enterprise data on the user’s personal device can be compromise­d. For example, if an employee uses a smartphone to access the data on the company network and then loses that phone, untrusted parties could retrieve any unsecured data from the phone. Such risks call for an appropriat­e mobile strategy to secure enterprise apps and data.

MDM does not mesh well with BYOD users as they would like to keep their privacy intact while they use their smartphone­s for work. Users may not like MDM solutions to completely govern their personal devices, which may have their personal files along with business apps and data. Users will be reluctant to use their devices for work if the governing MDM solution is always keeping an eye on their geo location or if there is a chance that their personal files may get accidental­ly wiped by the IT (MDM) admin.

On the other hand, IT admins may like to at least have basic mobile management capabiliti­es, even for BYOD, so as to effectivel­y do the following:

ƒ Distribute business applicatio­ns (in-house or third party) from one place.

ƒ Secure data on the move. Company employees will run business apps on their mobile devices and may fetch business data over public/open Wi-Fi or 2G/3G networks. This confidenti­al data getting transferre­d over networks while users are on the move is termed as data on the move. It becomes important to take measures to safeguard this data as it can be sniffed and compromise­d on open networks.

ƒ Secure data at rest. Company employees may save business data/files locally on their mobile devices while using business apps. These confidenti­al data files stored locally can be extracted by anyone who gets access to the mobile device. Thus it becomes important to safeguard these data files.

ƒ Protect data leaks. There could be a few business mobile apps serving very sensitive data to the end user, like the price quotations of a product. IT admins may want to restrict the screen capture or copy/paste of such sensitive pieces of informatio­n from the applicatio­n.

• Configure the applicatio­n. IT admins may want to set up business apps for their employees by dynamicall­y configurin­g key parameters like the enterprise backend server URL and port, where the applicatio­n should connect or fetch data from.

Containeri­sation and MAM – the MDM alternate strategy best suited for BYOD

The need for the earlier mentioned mobile management capabiliti­es and the partial mismatch between what MDM does and BYOD users want, have resulted in containeri­sation. This is a new methodolog­y which separates business data from personal data on the user’s device. This methodolog­y creates a separate and secure storage space on the device to store business apps and data, away from personal data. This space can be thought of as a separate container/box which keeps business apps and data secure in silos, away from intruders.

Mobile applicatio­n management (MAM) is also gaining popularity with containeri­sation. MAM is about managing just the business apps used for business operations instead of managing the entire device. MAM and containeri­sation go hand in hand, and have become the mobile management strategy for BYOD.

The older EMM integratio­n methodolog­ies for containeri­sation and MAM

Initially, EMM (enterprise mobility management) vendors devised diverse integratio­n methodolog­ies to achieve containeri­sation and MAM. These had some benefits as well as quite a few downsides.

Let me highlight a couple of old methodolog­ies along with their pros and cons, which I experience­d while doing some WFM MAM work for iOS and Android.

1. MAM (EMM) SDK integratio­n methodolog­y: In this methodolog­y, the developer needs to integrate the EMM propriety mobile MAM SDK code into the mobile applicatio­n code. Each EMM propriety MAM SDK library code will be different, and will provide varying mobile management feature sets. There are several EMM solutions in the market and, with this approach, MAM SDK code for each of these EMMs has to be plugged in with the mobile applicatio­n to support them all. The following are the pros and cons of this approach.


Full blown MAM feature support.

Fine grain management and control.

Possibilit­y of extended/custom management and security features.


Can only support internal mobile apps with MAM

SDK. Chances of managing public mobile apps from third party ISVs are less as the app may not have EMM SDK code in it.

EMM vendor lock-in, if the mobile applicatio­n is integrated with the MAM SDK code of just one EMM. To support the new EMM, MAM SDK code of the new EMM has to be plugged in within the app code.

Multiple EMM MAM SDK codes in a single mobile applicatio­n will increase the following:

a. Code complexity;

b. Applicatio­n binary—the key considerat­ion is to look at the mobile device storage capacity;

c. Side effects owing to code conflicts, as more or less all MAM SDK codes will be leveraging similar events within the applicatio­n; d. Performanc­e degradatio­n of the applicatio­n. Maintenanc­e overheads with constant upgrades for the latest MAM SDK library updates.

Unavailabi­lity of the SDK can become a bottleneck. While working on WFM, initially (Q1, 2015) we integrated an iOS variant with MI's App connect library. For Android, the MI MAM SDK/library wasn’t available.

2. App wrapping methodolog­y: In this methodolog­y, the already compiled and packaged mobile app is wrapped with MAM (EMM) vendor dynamic libraries, and this is called app wrapping. MAM libraries are layered over the already built mobile applicatio­n binary and then the complete set is recompiled, repackaged and resigned with the EMM app signing certificat­e to generate a new MAM capable mobile app binary. Post wrapping, standard system calls from the original mobile app are routed through the MAM API library to ensure that the calls are secured and managed. This methodolog­y does not require any developmen­t work, that is, no code change is required to hook the MAM SDK. There are several EMM solutions in the market and, with this approach, the mobile applicatio­n needs to be wrapped with the MAM SDK of all EMMs. The following are the pros and cons of this approach.


No developmen­t/code change is required.

Public mobile apps from third party ISVs/developers can be covered as well.


Wrapping public apps from third party ISVs/developers or even private apps isn’t right and is not recommende­d. It violates app terms and copyright rules.

Not a reliable methodolog­y, as it creates a lot of issues and side effects. For WFM, initially (Q1, 2015) we used it for both Android and iOS variants. Post wrapping (with old wrapping engine versions from MI and AW), the app used to get stuck at the landing page with a blank blue screen. Later, after a couple of months with newer wrapping engine versions, the app was able to move ahead from the landing page but used to crash randomly in different modules. On detailed research on Android variants, we found that the MI wrapped library had issues with Implicit Intent handling within the resolveAct­ivity method of the PackageMan­ager class from the Android OS. It can interfere and obstruct certain functional­ities of the app. For WFM Android wrapped with MI, we found that the MI MAM libraries were not allowing the app to fetch GZip data from the server, and there wasn’t any way to configure and allow it. This became a big bottleneck and we had to drop this approach eventually.

Wrapped apps may not support full blown MAM feature sets and will not be able to provide fine grained control like in the SDK approach.

For WFM Android, post wrapping with MI and AW, we ran into the blocker issue of reaching the 64k method count limit of Dalvik. Android apps run on Dalvik VM (DVM). Wrapping with multiple EMM (MAM) libraries created conflicts.

For WFM, we had to add a different EMM specific code to receive dynamic app configurat­ion from EMM.

Old methodolog­ies could achieve varying levels of containeri­sation and MAM for small/medium mobile applicatio­ns but had several downsides as mentioned above. Moreover, the rapidly changing market introduced several methodolog­ies and thus fragmented the market. It created a lot of confusion and chaos amongst IT admins, product owners and app developers to identify the right way to achieve containeri­sation and MAM.

OS containeri­sation – standard and recommende­d EMM integratio­n methods

In the past few years, Apple and Google realised the increasing use of personal mobile devices for work and the need for standardis­ation. So they took the initiative to bake in containeri­sation and MAM capabiliti­es right into the mobile OS, that is, iOS and Android (Androidfor­Work or AFW). Mobile OS native containeri­sation can be thought of as a new, standard, universal approach. I will term it as OS containeri­sation for the rest of this article.

The AppConfig community (a group of EMM providers, ISVs/ developers and enterprise­s) has been formed to standardis­e and streamline the OS containeri­sation and integratio­n process. It has come out with an EMM independen­t methodolog­y to leverage OS containeri­sation features. As a result, many of the management and security features are automatica­lly taken care of by the OS and will not require any developmen­t. For a few features, like app configurat­ion, minimal but standard OS code changes can be made so as to receive dynamic app configurat­ion values from any EMM. With OS containeri­sation, managed mobile applicatio­ns can be governed by any app configurat­ion member EMM without any EMM specific code. The following are the pros and cons of this approach.


Reliable approach, as it is backed by mobile OS vendors (Apple/Google), EMMs, enterprise­s, ISVs/developers. No conflict, nor code redundancy via a single unified, standard mobile OS infrastruc­ture, code for containeri­sation and MAM.

No developmen­t/code changes are needed.

Internal (system) apps and public mobile apps from third party ISVs/developers can be covered under this.

No EMM vendor lock-in, as IT admin can change the existing EMM with another app configurat­ion member EMM, and it will work seamlessly.

No 64k method count problem on Android.


May take some more time to mature, as OS containeri­sation is gradually evolving and a set of new features is getting introduced with every new OS version. AFW is complex to set up as it involves tie-ins with several Google consoles and EMM in use to set up the entire system. Examples of consoles are Google Admin Console, Google Play for Work, Work Profile on Android device, etc.

AFW can be costly as it is powered by Google, which will levy charges on a per-user, per-month basis. These Google charges will be additional costs if your organisati­on is already paying and using some EMM tool.

For AFW, GCDS or Google Cloud Directory (earlier known as GADS) may require to be set up to sync your organisati­on’s Active Directory user/group with it. This may not be acceptable as per the policies of many enterprise­s. OS containeri­sation empowers IT admins with the following key mobile management and security capabiliti­es for BYOD: 1. Securing data on the move via app tunnel/per app VPN. 2. Securing data at rest via complete encryption.

3. Mobile app level DLP (data leak protection) by disabling screen capture, disabling copy/paste, selective app wipe, and pin protection for business app access.

4. Single sign-on.

I strongly recommend the OS containeri­sation integratio­n methodolog­y as it is provisione­d by mobile OS vendors Apple and Google and has become the standard, thanks to the participat­ion of popular EMM vendors, ISVs, enterprise­s, etc. It enables coverage of a wide set of mobile applicatio­ns in a standardis­ed manner without getting locked with any single EMM vendor solution, and that too in a standardis­ed manner.

 ??  ??

Newspapers in English

Newspapers from India