Mobile Device Management and Enterprise Application Development
With Gartner reporting that the top three technology agendas for CIOs globally are analytics, mobile, and the cloud, Tech Republic reporting that iOS is now as secure as Blackberry, and Forbes saying “the sin of ignoring mobile will not go unpunished” if you aren’t considering how to roll out mobile devices and apps for your cloud services, you’re missing the boat.
Apart from what you want your workforce to do with their mobile devices, the most important thing you should be considering is how they can do it without compromising secure company information. Enter Mobile Device Management (MDM) providers and Mobile Application Development Platforms (MADP), but the wide array of MDM providers can be dizzying. Gartner has a Magic Quadrant for Mobile Device Management Software that can be helpful, but the reality is that there is an industry-wide commoditization of MDM occurring. The core MDM functions are controlled by device manufacturers (Apple, Google, Samsung, HTC, etc.), so MDM vendors aren’t able to do much that sets them apart with core device security features. Where they have distinguished themselves is with add-ons like MADP, application management (enterprise app stores), cloud services, analytics, automation of compliance measures, file/content sharing, and PC management combined with mobile management.
“Wrapper” MDM
There are two basic models for Enterprise MDM in the marketplace today: “wrapper” based and full device security through manufacturer-provided APIs. The best known example of the former model is that of Good Technology. Good’s core offering provides access to corporate email, calendar, contacts, and a secure browser within an encrypted container app. This is beneficial in Bring Your Own Device (BYOD) scenarios because users are able to use their personal devices unrestricted as they normally would, with all corporate information being locked into the container app. Where this doesn’t work so well is that the replacements for standard apps on devices lack functionality and integration with other device features and with apps that aren’t developed using Good’s MADP, Good Dynamics. That is by design, but can still limit worker productivity. Another limitation is that Good’s device-level security offering, Good Mobile Manager isn’t as feature rich as that of other MDM vendors who have focused entirely on that strategy.
Device Security MDM
With a few exceptions, most of the rest of the MDM vendors on the market have focused on using the device manufacturers’ MDM APIs in order to manage security at the device level. This is a solid approach, because it follows the best practices set by the manufacturers, and secures the entire device. However, with BYOD programs, you may find your users are unhappy about having their personal devices locked down, which may limit the security policies that you can realistically deploy without your users getting out their pitchforks. Some of the most prominent examples of this type of MDM are MobileIron, AirWatch, Zenprise, and Fiberlink MaaS360. I can say that the majority of clients that I’ve worked with have typically either implemented Good Technology or MobileIron. MobileIron is well known for good reporting and automation capabilities, but doesn’t offer a MADP. Airwatch is probably the most mature cloud-based offering, and does include an SDK to embed security features into custom apps. Fiberlink includes PC management, which is a direction Gartner predicts most MDM vendors will be moving toward in the future. Zenprise has solid reporting capabilities, and a strong mobile VPN solution.
Mobile Application Development Platforms
What about application development? Some MDM vendors offer a MADP, some don’t, and some MADP vendors don’t offer an MDM. So, if you are developing custom apps for your enterprise, how do you decide which MADP vendor to choose? First, I think it’s helpful to come up with some criteria for evaluation:
- It should be Standards Based. Architectures based on broad industry standards like those created by Apple, Google, or the W3C are more flexible, more scalable, and less tied to proprietary 3rd-party capabilities that may meet your needs today but not in the future.
- It should have both Native and Hybrid development options available. Native is often better for single-device deployments where apps need to perform well, look good, have a high degree of sophistication, or get to market quickly. Hybrid can be good for multi-device deployments, but development times often increase substantially
- It should have an Encrypted Application Container. Many mobile devices offer device-level encryption. Some don’t, most notably Android phones running the Gingerbread version of the OS (which is most of them right now, unfortunately). Even so, as I showed at a recent Dreamforce Session, hardware encryption isn’t foolproof. Many iOS apps that rely on hardware encryption are leaving their data easily accessible to anyone who gets ahold of the device. An encrypted application container keeps the data for your application locked away, even if the device encryption is compromised.
- It should have a Strong Developer Ecosystem. Developer and Consumer ecosystems feed on each other. The more consumers are using a technology, the more interested developers are in making apps for it. The more apps there are, the more consumers will be interested in using the technology. Looking at developer interest in a platform is a strong indicator of how well it’s doing, and how well it will continue to do in the future. This is a core reason for why iOS and Android are doing well, while Blackberry and Symbian aren’t, and why Microsoft is paying prominent developers to build apps for Windows Phone.
- It should be Open Source. Open Source technologies avoid dead ends. They also allow 3rd parties to improve and build upon them, and to search for security holes. If you have the source for the platform you’re building upon, you’ll never have an instance where it’s impossible to meet a key business requirement because the technology doesn’t support it and the source is proprietary.
- It should have Immediate Support for new OS Features. The next time Apple or Google release some awesome new feature as a part of their mobile OS, you should be able to take advantage of it without waiting for a 3rd party to add support for it.
- It should Integrate with your MDM. You’ll be rolling this app out to your workforce, so you want to make sure you can keep it secure and available to the users who need it.
- It should Integrate with the Cloud. Mobile apps need access to data, and secure integrations with Cloud services are a key component for providing that data.
So, here’s where some of the MADP leaders stack up:
Salesforce Touch Platform
The Salesforce Touch Platform “leverages the power of the Force.com platform and its proven security, reliability, and scale for enterprise applications”, and offers standards-based options for Native and Hybrid development on both iOS and Android devices. The Salesforce Touch Platform contains three core components: Force.com for Touch, Mobile Container SDKs, and Identity. The SDK is Open Source Software on Github, and contains an encrypted container for storing and transferring data. Since it’s built on industry standard technologies, the developer ecosystem comes built in, and Github allows for anyone to be able to contribute patches to be reviewed by the Salesforce team.
Good Dynamics
Good Dynamics allows application developers to build apps that use the same encrypted wrapper technology employed by the Good Email/Calendar application. This has been employed by well known brands like Box.com and iAnnotate PDF to create apps that integrate with the Good container. Good Dynamics is based on native libraries that are included in the source of natively built apps for iOS and Android. Like Salesforce.com, the reliance on standard development technologies means that the developer ecosystem comes built in. Some weaknesses are the current lack of a hybrid development model, a proprietary closed-source system, and if you’re building apps for Salesforce.com, a lack of OAuth and REST API wrappers out of the box (though, the native Salesforce SDK could be combined with Good Dynamics to add this).
SAP Sybase Unwired Platform (SUP)
The SUP platform compliments SAP’s MDM offering, Afaria. It’s strengths are in delivering a hybrid app with a single codebase to many different device types. However, this model doesn’t come without tradeoffs. If you need integration with SAP from a mobile device, SUP may be the best option, but you’ll be giving up the slick, highly performant apps possible with native development, and you’ll be committing yourself to a complicated proprietary middleware architecture.
Appcelerator Titanium
Appcelerator Titanium allows you to build cross-platform apps using the Javascript language, but with a custom native compiler. With a free connector for Salesforce.com, it provides a good, if slightly non-standard way of building cloud-connected mobile apps. Appcelerator’s strength is in building cross-platform apps that are more performant than is possible with Phonegap/HTML5 hybrid solutions, but you are locking yourself into a proprietary client architecture to some degree. The developer ecosystem with Appcelerator is strong, and they even publish quarterly developer surveys that are always worth reading to see where the industry is headed.
Adobe Flex/AIR
Adobe has a long-standing partnership with Salesforce.com, and we’ve developed many great apps on Adobe technologies with our 2GO platform. Similar to Appcelerator, the main strength with Flex/AIR is that one codebase can be used to export apps for multiple different mobile devices, and even desktop PCs (Windows, OSX, and Linux). AIR comes with an encrypted SQLite database built in, and performance is typically better than would be expected of a standard Phonegap/HTML5 type app. Some businesses have shied away from Flex/AIR since Adobe open sourced Flex under the Apache foundation because it was widely reported as an abandonment of the technology, but Adobe has affirmed their commitment to Flex and the Flash Builder toolset longterm.
