Content

Mobile device management

The products that we looked at this month were no walk in the park to deploy. Right out of the chute we would strongly advise that you get all of the support you can from your chosen vendor. Fortunately, that is, for the most part, easy to do, and the support teams generally are quite good. They recognize that this is a new world and they are ready to help.

That said, do a lot of fact-checking regarding statements made by the vendors. For example, one vendor reacted to our admonition that these apps don't belong in the commercial "play" stores. We strongly believe, for several reasons, that professional applications belong in the organization's proprietary app store, not in the same place with games and toys. There is no reason why organizations cannot deploy their own app stores.

However, we were surprised when one vendor adamantly told us that there was no choice. Google and Apple require developers to sell (or give away) their wares on either Google Play Store or the Apple Store. Because we know that there are literally thousands of corporate app stores - including one of the vendors we reviewed this month - we questioned that. We went so far as to ask the vendor if that meant that those organizations that chose to create their own app stores for their specific corporate products were violating developer agreements. We got some rather convoluted explanation of certificates that meant nothing so, yes, they are violating their terms of service for developers.

Since that meant that the offenders were violating licensing agreements, I next asked if that meant that any developer who does not distribute through the play stores is breaking the law? "Yes" was the answer. So we went to the vendor with its own app store and asked why the other vendor had said what he did. I was directed to Google and Apple developer guidelines. 

So I took a look and that vendor was right. Neither Google nor Apple requires a developer to distribute through the app store. They issue licenses to the organization - not the application - that describe the standards required for development and the resources available for support. Nowhere that we could find was there a restriction requiring the use of their stores. In fact, quite the opposite. Moral of the tale? Fact-check vendor claims as you make your selection.

Another thing that we saw was that some vendors are taking a very targeted approach to MDM. One we liked limited its functionality to controlling the apps that users can deploy. If you want to interact with organizational data, you use one set of apps. Otherwise - for your personal use - you use a different set. This, in part, goes back to the issue of the app stores. There is no reason for your organizational app to coexist with Angry Birds. This approach is very unobtrusive and when it comes to "move on down the road" to another organization or the device is lost or stolen, the owner is comfortable that the organization won't wipe his or her family album and the organization is comfortable that its data are preserved from prying eyes or worse.

Finally, we find that there is a vendor perception that people with mobile devices already have accounts with Google or Apple. We know that there are lots of users who simply have the mobile device for phone, email, text messages and so on. They never have set their virtual foot in an app store and don't want to. When Google asks for a credit card number, these folks just say no and move on. That was our experience in the university deployment.

So, our usual how-to-buy for this class of product is pretty easy. First, really spend time working over your policies to address BYOD and organizational mobile device security. It is those policies that will dictate directly and explicitly how you configure your MDM tool.

Next, fact check vendor claims. There is a lot of snake oil out there - not that the term characterized any of the vendors in this group...it doesn't - and you really need to keep your eyes open. Match the tool to your needs, as always, and in this particular case spend the time to do pilots with more than one product. It's the only way you can tell what the product is capable of. 

Finally - and we cannot stress this enough - make sure that the vendor stays close to you from pilot through implementation and early deployment/provisioning. During the pilot you'll learn a lot about the vendor and its support policies. Of course, select based on more criteria than you might be used to: user comfort, ease of deployment/provisioning and admin resources required. MDM lacking of any of these can be real project killers.


Specifications for MDM tools

 

Citrix Systems 

IBM

Sophos

VMware
AirWatch

Maintain device security policy through app or active sync

Allows application white and black listing

Allows selective remote wiping

Provides browser content filtering

Supports devices 
other than Android and iOS

 

 

Apple, Windows, 
BlackBerry, LG, 
Motorola, Samsung
Windows, Samsung, 
LG, Sony

 

Apple, Windows, 

BlackBerry, Symbian, Tizen

Requires commercial app store download

Available,
 but not required

Cloud-based (SaaS)

On-premises

MDM

MAM

Allows separate containers for personal and organizational data

Allows separation of personal and organization-permitted apps


Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.