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.