Over the last few years as we’ve talked about mobile app management, one of the questions that has always come up has been about where we actually get these manageable apps. For the most part, the answer has involved 3rd-party EMM/MAM vendors. But what happens to 3rd-party products when the apps we need have their own management features already built in?
When you choose an EMM vendor, you’re also buying into their ecosystem of different MAM options. If you want an app that can plug into your EMM server, you have four basic choices: For in-house or custom apps, you use you EMM vendor’s MAM SDK. Most EMM vendors will also provide some basic apps like sandboxed email clients and browsers. You can use your EMM vendor’s app wrapping tool to wrap apps that you buy directly from ISVs. And finally, many EMM vendors also have partner programs (like Good Dynamics, MobileIron AppConnect, Citrix Worx app store, Symantec Sealed, and several others) so that ISVs can make versions of their apps that can be plugged directly into the EMM platform.
However, even with all these different options, getting your hands on all the apps you need can still be an issue. Most of these partner programs have just a few dozen apps at most. We’ve talked about open standards as a possible solution to the problem, and OS-enabled MAM that rides on top of an MDM protocol is another option, but those are both conversations for another time.
Assuming enterprise customers want MAM-like features in their apps (typical features might be a passcode to launch the app, remote wipe, encryption, sharing controls, or geofencing), then what happens when the app makers respond to this and just start building these features in on their own?
Many of the apps that you would want to control with MAM are client apps for various enterprise software and SaaS products anyway, so for these types of apps, there’s probably already a management interface that’s used to provision users’ access in the first place. If there are MAM features already built into the apps, while you’re provisioning your users, you can also just check the boxes for whatever policies you need—passwords, sharing controls, whatever. This means that there’s no third-party EMM vendor involved, no app wrapping, no special versions of apps, or anything like that.
This sounds like a great alternative to third-party MAM, right? It can be, but one of the main problems is that now all of your apps are in individual silos. On the management end, you know have to go into each separate product and make policy changes individually. Users miss out on integration, too. If all the apps have their own management silos, then users will have to put in individual passcodes for all each one, and sharing between these different apps (say getting a document from a file syncing app into a different office suite app) could be difficult, too. And do you trust every single random ISV to implement all these features, or would you rather they partner with a third-party MAM vendor?
What conclusions can we draw from this? Apps and services with built-in MAM are becoming more of a reality (look at Dropbox for Enterprise, for example), and they’ll be a good option for a lot of use cases. But it’s highly unlikely that these types of apps will make the need for third-party EMM disappear. (Just like iOS 7 MAM didn’t make any anything disappear—it’s just another tool.)
What we can also do is understand that mobile app management is still a fragmented endeavor, and that there will never be one single “right” way to do it. Instead we have three ways to do it: Third-party MAM that plugs into an EMM platform, OS-enabled MAM (like with iOS 7), and what we’ve been talking about here—apps that are manageable on their own, without a third-party EMM product.