Recently I had a chance to sit down with with Bitzer Mobile’s product management VP Andy Smith. Bitzer is one of the smaller and younger companies to be offering dual-persona mobile app management. Over the last year we’ve seen a lot of growth with this type of MAM (interconnected corporate apps—if you’re not familiar you can read more here), and Bitzer has some good ideas about it. Let’s dig in!
Bitzer Mobile is just a little over two years old, with about 40 employees. They started with an idea to create apps that would get corporate data to mobile devices (think of something like a template or Framehawk or the XenApp Mobility pack). Their first real win, however, was figuring out how to do mobile Sharepoint access with Kerberos authentication for a few Fortune 50 companies. They’re bringing that technology more mid-market now, but after that the next logical step was PIM apps, intranet browsers apps, and dual-persona MAM (they happen to use the term container).
Bitzer’s MAM product
Bitzer offers a “core” app that includes the PIM client and a document editor (those are both OEMed), as well as a browser and file-syncing app; other apps are incorporated via app wrapping. The core app can be customized with corporate branding and it contains links to the all the other apps. The other apps can be broken out and deployed independently if desired, but Andy said that most of their customers so far have been deploying everything together, so that the user just has one big managed “work” app (though the third-party wrapped apps that don’t come from Bitzer will be accessible outside of the main app).
All the expected management hooks are there—remote wiping, authentication, app-level VPN, encryption, manageable data sharing—and the policies can be changed at any time. The Bitzer apps are MDM-agnostic, so you can do whatever you want at the device level. Bitzer Mobile is available for both Android and iOS, and it’s all licensed by user, not device.
What’s special about their approach
While a lot of MDM vendors are working to partner with ISVs to have MAM-compatible apps available in the Apple App Store or Google Play, Bitzer Mobile’s approach is to have all of the apps be signed and deployed with private corporate certificates. This is an interesting for a few reasons.
First, on a technical level, this means that the apps have more ways to communicate with each other. Apps signed with the same enterprise certificate can share authentication information for single sign-on, and all of the apps can use the main core app as a network access controller. Instead of each app having its own VPN connection there’s just one for the whole set of apps, lowering the impact on the VPN host. (Of course you could use MDM to do that, but we’re talking about MAM here.) When it comes to Android, even though there are more ways for the apps to communicate with each other, they designed everything to work in the restrictions of the iOS environment, so there was no need to reinvent the wheel.
Second, using enterprise certificates to bypass the Apple App Store offers a whole host of advantages for ISVs and customers. For licensing, ISVs can offer more advanced schemes and not have to worry about Apple taking a cut, and for customers there’s no need to track Apple Volume Purchasing Program redemption codes. And instead of an ISV publically offering a different version of their app for each MAM platform, they only have one version. Each customer takes the app binary and wraps and distributes it on their own, internally. It’s definitely a different approach from the MAM vendors that are promoting partner programs and publicly-available compatible apps. (We’ll take a deeper look at this idea soon.)
2013 is going to be an interesting year as the MAM space begins to sort itself, and the public app store versus enterprise distribution idea gives us even more to think about.
(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.