Take a Page From the PM Playbook When Crafting Your BYOD Strategy
It is no longer a question of whether or not the enterprise will support mobile devices, but a given. The general parameters of what shape a company’s program will take (COPE or BYOD) have as much to do with security as anything else. Thankfully, the ability to define and configure the appropriate policies to support a chosen approach is readily available in most EMM/MDM platforms.
Regardless of the program selected, your next question is which mobile platforms (and specifically, which devices) and which OS versions should you support? iOS and Android are the default choices, but when also looking at Blackberry and Windows Phone things tend to get murkier.
Oftentimes such decisions can be overly influenced by fanboy passion, internal politics, or loud-voiced people who have recently perfected their Khrushchev impersonations.
In the end, however, the one answer that’s sure to make everyone (i.e. executives who don’t have to deal with the implications) happy is “let’s support all major platforms.” Sounds great, but the rest of us know there are significant costs associated with each additional platform/OS a company supports.
In some cases, the decision may come down to which OS versions support specific APIs. Certain APIs may be critical to delivering the use cases you want to support, whereas other APIs may become deprecated or replaced by new ones, which might lead to a loss of support for older OS versions.
But where APIs aren’t a deal-breaker, a great way to cut through the clutter and politics is to simply follow the data. Like most enterprise IT organizations, developers know they have limited resources and can’t always afford to support all platforms and OS versions. Consequently, smart developers turn to their user data to determine the best path forward.
What Data Should I Consider?
To start off, you can look at general industry data like Comscore for directional information.
Unsurprisingly, Android and iOS represent almost 94% of current US smartphone subscribers. That’s a good starting point to help narrow down which platforms to support or to simply determine if the device population merits the development and support costs.
If we assume for a moment that this fairly reflects your employee demographic, it may not make sense to support anything other than Android and iOS. This doesn’t mean there isn’t a case to be made for Blackberry or Windows Phone, but objectively, it’s an uphill road.
To further refine your mobile device strategy, you should then turn to more detailed OS version usage statistics. Just because many OS versions exist in the wild, this by no means suggests you should support every single one. Remember, we’re trying to maximize the efficiency of our resources, not cover every corner case. Google explicitly recommends you use their stats to prioritize device profiles and optimize your development efforts (further, they provide even richer statistics within the Google Play Developer Console). Additional sources such as Chitika or Mixpanel also provide valuable information about iOS and other platforms.
A close look at this data will help you decide which OS versions to support. I like to think about this not as individual OS statistics, but in terms of the cumulative penetration. So now let’s look at the data a little differently:
Based on the chart above, one might comfortably decide to set iOS6 as the minimum supported version.
Your Mileage May Vary
Of course the above data is relevant to all smartphone subscribers, and does not apply solely to the general business user population. In a recent report, ABI Research noted that Apple’s iPhone, while trailing Android in raw market share, was the “most activated device within EMM/MDM platforms.” While ABI and other research companies can provide another layer of detail, even those estimates won’t provide the necessary information about your company’s specific mobile device population.
You have a few ways to get at the data you need:
- If you have an existing MDM platform, you should be able to easily pull down data on device manufacturer, model, and OS version.
- Depending on how you have the profiles set up, and what you’re doing for Telecom Expense Management, you might also possess information about employee contracts (when they are eligible for new devices, etc.). If a significant percentage are due for new devices, this may significantly impact your decision-making (especially with Android users whose only path to upgrading is purchasing a new device).
- If you don’t have any of this data already and/or you have new classes of employees who will be eligible for your COPE/CYOD/BYOD program, put together a simple survey to collect the data.
Now…About Those Windows Tablets
I’m calling this out because it’s an issue that has come up a lot recently. With many of our enterprise clients, there are at least some folks (if not many) who want to incorporate Windows Surface tablets into their overall strategy. In each case, the reason almost invariably stems from a desire to use a device lighter than a notebook, but which can still access all the Windows apps.
It appears Microsoft has been hearing a similar story, as evidenced by the recent Surface Pro 3, which WSJ’s Joanna Stern summed up as “A Tablet That Desperately Wants To Be a Laptop.” While the SP3 sports a larger screen, it’s also twice the weight, 2.5 times the price and delivers only 40% the battery life of an iPad Air.
But the biggest distinction of the Surface Pro 3 (and all previous Surface Pros) is that it runs the Windows desktop OS rather than Microsoft’s mobile OS. That’s why it has all that great compatibility with desktop apps. But it offers very little compatibility when considering a Windows smartphone app strategy. So while it may prove a good option to incorporate into an enterprise strategy as a laptop replacement, it shouldn’t lead one to add Windows Phone devices to their BYOD/smartphone roster.
I hope you find this an interesting approach to building a mobile device strategy. Please let me know what you think in the comments.