Thanks for sharing your feedback! If your feedback doesn't appear right away, please be patient as it may take a few minutes to publish - or longer if the blogger is moderating comments.
One of the issues that comes up with mobile app management (MAM) is that everyone wants to know where all these manageable apps are supposed to come from. The standard answer is that there are four sources:
- Basic apps created by MAM vendors, like email clients, browsers, and file syncing clients.
- In-house apps, developed with a vendor’s MAM SDK.
- Using app wrapping tools to modify app binaries acquired directly from ISVs.
- Apps in public app store that are built using a MAM SDK.
But here’s the problem: while there are standard APIs for managing mobile devices, there aren’t any standards for app management. This means that an app has to be specifically created or modified to work with a particular MAM platform. With at least a dozen different mobile app management SDKs out there, things are a fragmented mess.
But what if the industry could get together around a common standard for mobile app management, so that an app could be managed by any vendor? I’m definitely not the the first person to have this idea—in this case, credit goes to past article comments by Dan Shappir, Gabe, App Detective, and Shawn Bass (here)—but I wanted to take another look.
Benefits for all
The first and most obvious beneficiary to this is enterprise IT. It would give a much wider range of publicly-available, managed applications to choose from. That wide range of apps is also more consumerization friendly: more choices for apps means users are less likely to say FUIT.
A standard would be great for the industry, too. Right now there are several MAM vendors that can each boast a handful of compatible public apps, but it imagine if there were hundreds or thousands of compatible apps available. Vendors would then compete the same way they compete around MDM—on being able to scale and integrate management, and offer additional value.
But what will it actually take to get all of the parties to the table to adopt some standards? I can’t even begin to know—but we can start by asking and suggesting. It seems more likely that a standard could emerge if some vendors were to begin licensing MAM SDKs from other vendors. AT&T and BlackBerry are both white-labeling OpenPeak’s MAM, and several companies use Mocana for app wrapping, but I haven’t heard about any inter-compatibility in either of these cases.
A standard MAM SDK would have to include provisions to ensure that only one stakeholder could manage an app at a time, but we already have this issue figured out out for mobile device management, so it shouldn’t be insurmountable.
An alternative approach
An alternative would be to build a MAM service that didn’t have its own SDK or app wrapping tool, but instead supported apps created by other vendors—in essence, a universal mobile app management tool. This idea is still in the “thought experiment” phase for me.
Proponents of mobile virtualization, Samsung KNOX, and BlackBerry 10 will no doubt point out that these all avoid the MAM interoperability issue. However, this is at the expense of being smaller, niche platforms.
Should we cross our fingers?
So what are the chances that a mobile app management standard could emerge? As Gabe suggested, some vendors might want to protect IP invested in their MAM SDKs and app wrapping tools. But there’s already a lot of overlap between many vendors' feature lists, and by moving to an open standard, most of them would only loose the edge on one or two features.
Even though a MAM standard would be good for the industry, with all the diverse vendors it could be hard to get a lot of them around the table together. There’s a better chance that two or three de facto standards could emerge through smaller agreements, mergers, or the changing fortunes of the industry, and that would still put us in a better place than we are right now.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.