Jack’s 2015 MAM recap: The more things change, the more they stay the same... (Part 1 of 2)

MAM that's built into devices.

What happened in mobile app management this year? Did MAM get any easier or any more straightforward? Is one type of MAM going to win?

This is what I’m addressing for my last article of 2015. Part 1 covers MAM that’s built into devices; I’ll cover MAM that’s built into apps tomorrow in Part 2.

How I think about MAM

Before we dive in, let me explain how I think about MAM. (If you read a lot of my articles about MAM you’ve probably heard this before and can skip to the next section, but I wanted to include this boilerplate to get everyone on the same page.)

Despite all the different terms (“containerization,” “dual persona,” “BYOD,” “native containers,” “app wrapping,” “SDKs,” “proprietary,” “sandboxing,” “third-party,” “self-defending” and so on), all mobile app management falls into two categories.

The first category is what I call app-level MAM. This means that enterprise security and management features are built directly into the app package itself. This category includes apps created with MAM SDKs, app wrapping, most apps that come from EMM vendors, and other apps that happen to have various security and management features built in. The advantages of app-level MAM are that you don’t have to manage devices, the security of apps isn’t dependent on the security of devices, and you can build in as many security and management features as you want. The disadvantages are that this is limited to apps that are specially created or modified to have MAM, and that there are many proprietary app-level MAM frameworks in the EMM industry.

The other category is device-level MAM. This means that the ability to enforce granular, app-specific policies is built directly into the mobile device and operating system. Device-level MAM is present in iOS, Android for Work, Samsung Knox, Windows 10, and many other enterprise-specific devices that never actually became very popular. The advantages of device-level MAM are that you can manage any app, no matter what, and you can avoid non-interoperable proprietary app-level MAM frameworks. The disadvantages are that you have to be able to manage the device with MDM, you’re limited to whatever management features the device happens to have, and you have to put all of your trust in the device.

You can see that both types of MAM have their own inherent strengths and weaknesses, and that different use cases will call for different types of MAM. Over time, these use cases and attributes will certainly evolve, but in the near term, we need both types of MAM. I believe that it’s wise to avoid being dogmatically devoted to a single type of MAM.

Device-level MAM in 2015

2015 has been yet another big year for device-level MAM.

Apple iOS 9 brought the expected round of improvements, touching on the Device Enrollment Program, the Volume Purchase Program, Supervised Mode, and app management.

Android 6.0 Marshmallow built on Android 5.0 Lollipop with more Android for Work features dedicated to single-use corporate devices (kiosks, signage, embedded devices, etc.). The Android for Work hardware compatibility list is still a limitation, but it at least covers many flagship devices. The number of supporting EMM vendors continued to grow, too.

There’s not much Android for Work usage out in the wild yet, but remember we’re still talking about Android—it will take a while. Everyone I talk to in the industry is still excited about it, and the thing I hear people say again and again is that Google got it right.

With Android for Work spreading (albeit slowly) what’s becoming clear is that Samsung Knox will be somewhat of a specialty product for high-security and regulated deployments (the BlackBerry replacement, if you will) along with other corporate-issued device use cases. The high-security and regulated use cases make sense because Knox has various hardware-based security features along with government certifications that have to be OEM and model-specific. Android for Work is just a software framework, so it would be difficult for it to get that level of trust on its own.

VMware and AirWatch have been bullish about their App Configuration for Enterprise (ACE) effort, which is their way of marketing and promoting all of these device-level MAM improvements. This is fine—the improvements are very important—it’s just that the ACE marketing can be a bit confusing at times. They talk about ACE as if it’s a new standards effort, when it really just promotes what Apple and Google are already doing.

Finally, I’ll note that as always, there are many vendors that just utilize device-level MAM and don’t have their own app-level MAM efforts. Some of the ones that I’ve written about include Okta, Centrify, Pulse Secure (though they do have their awesome Android “app virtualization” technology), and Cortado.

I’ve said many times that we need both types of MAM, but as device-level MAM keeps advancing, these vendors can cover more use cases, and this is a very sensible approach. There are still plenty of independent app-level MAM vendors out there that would be great to partner with. (More on this tomorrow...)

To be continued

Come back tomorrow for Part 2. Besides app-level MAM, I’ll talk about app wrapping, “extended enterprise,” and email clients.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

"The advantages of app-level MAM are that you don’t have to manage devices,"

App wrapping/SDK is done with Airwatch, Intune, MobileIiron, etc.. No way of enforcing app policies to these wrapped apps, without enrolling into MDM?


In general, app wrapping and SDKs do allow you to enforce policies in the app without enrolling the host device into MDM.

(The exception was with Intune, which up until a month ago also required the device to be managed. However now Intune also supports managed apps on unmanaged devices.)


Device-level MAM is an important use case that applies to a small subset of devices (<20%) that IT can own and manage. PC Lifecycle Management tools allowed IT to do exactly this for corporate PCs, but not home PCs.

In my opinion, App-level MAM is what end users want and probably applies to the majority of devices in the world - personal phone/tablet/PC/Mac, contractor phone/tablet/PC/Mac, etc.

The latest iteration of Intune that allows IT to manage Outlook, Powerpoint, Excel, and Word (the four most important productivity applications on the device) without having to manage the device is a game-changer. This changes the conversation going forward - the focus is going to be on apps and data, and not the device.