At a recent conference, I participated in a panel discussion about the pros and cons of Bring Your Own Device programs. One question that was asked was, "Once you have implemented BYOD, is it possible to reverse the policy?" Unlike other IT infrastructure services, when it comes to mobility, the investment in end user devices represents the majority of the expense, at least for now, and the lifecycle of that investment is only two to three years. Does this mean that a company could offer BYOD for one or two device lifecycles, possibly save some money on phones, and then take back the policy if it does not work anymore?
Reasons You Would Outgrow Your Program
Why would the employee-liable device program (i.e. BYOD) that you worked so hard to plan and implement not fit anymore? There are many reasons, ranging from the policy simply being a poor fit to begin with, to changes in technology and requirements that cause the company to outgrow even a carefully planned strategy.
For example, what if it turns out that it is more expensive to support employee-owned devices than company-provided devices? This is an unpopular proposition, given that so many BYOD programs were initially justified by claims for lower support costs, but it could happen. It's cheaper to provide a $500 device than it is for an employee to be unable to work, so support still is critical if the device provides connectivity into IT services; and it is cheaper to support a standardized device with standard applications than it is to support a variety of consumer devices with potentially conflicting apps. It may be possible that some IT groups decide to rein in control on their devices in the future, ironically to save money.
As much as security concerns have been in the forefront of employee-liable device "gotchas", this may turn out to be one of the easiest problems to resolve. Many tools are already available for mobile device management that do a good job of segregating data, enforcing policies and selectively wiping information. It's a competitive market for the tools, and as a result they are improving all the time.
If a BYOD program is limited to delivering email and calendar services to a personal device, there will be effective security solutions. However, as with almost all IT systems, application requirements may outgrow current security solutions. Consequently, this is where your company may outgrow its own BYOD program.
Enterprise Mobile Apps
Company sponsored enterprise mobile applications for the most part are not being developed with personal (i.e., employee-owned) devices in mind. Communications Advantage's (my company's) consulting practice focuses on communication and infrastructure strategies more than application development, but because of the dependency on applications in developing an enterprise mobile technology strategy, I have had a decent amount of exposure to a mixture of enterprise mobile application initiatives.
In one case, an electronic "brochure" was developed which could be sent to sales prospects. It added the contact name to a database in order to send product updates to the recipient, in compliance with that industry's safety regulations. This was built for company-provided tablets even though the company had a BYOD program.
In the next case, at the CTIA Wireless conference in San Diego, Jon Merritt, Sr. Manager of Flight Operations Technology for United Airlines, showcased the company's tablet-based flight manual. This easily-updated flight manual saves money, and even saved weight on each flight compared to the 45 pounds of documentation that a pilot used to have to carry on board prior to having the tablets.
All the contents are documented for submission to the FAA for approval. Due to FAA requirements, pilots are not permitted to download non-approved applications, including games (it is comforting to know that there are not four hour long Tetris tournaments happening in-flight, with the plane on auto-pilot).
Again, with this application, employee owned devices were considered, and then decided against. Mr. Merritt mentioned that in some cases the pilots wanted to use their own tablets. Beyond the regulatory hurdles that drove United Airlines to deploy the program on company-liable tablets, I would bet it was also just a lot easier to support on a controlled device, and that the majority of the project costs were not the iPads.
Next page: Different Mobile Applications Platforms
Someone might argue that their company strategy is to develop applications for any device, but usually "device agnostic" apps are simply a mobilized web portal or web page. This may be an adequate method of delivering content in the short term, but there is a lot of potential for more collaborative mobile applications with real time access in the future.
At the CTIA conference, I spoke to Varun Kashiv, the Business Development Manager of Web Spiders, a mobile application developer. Varun gave a great explanation of the differences in mobile application platforms: First you have the lowest common denominator, HTML 5. HTML 5 is supported on most mobile devices and provides a common platform for web-based applications.
This is sufficient if the data never has to be accessed offline. As soon as there is a requirement to store or cache any data and use the device without connectivity, additional functionality is required beyond the standard development platform (caching is supported in HTML 5, but the coding is often specific to the mobile browser or OS); there are multiple hybrid application platforms that can reuse code across varying mobile OSs. Finally, application development native to the mobile OS is required if there is device-specific functionality that will be used (e.g. scanner, camera).
Many mobile device management providers offer a "portal" approach to mobile security for unmanaged devices, rather than provide native interfaces into company domains and directories. This is a virtualized version of the apps. It's usually easy to configure and control, but any time the security solution requires a "window" into an application, there will be a challenge to duplicate the experience of the native app.
Next page: Hardware-specific Functionality
Hardware-specific Functionality
A typical BYOD plan is to first support iOS (iPhone, iPad) devices, then some specific Android devices, moving into broader support of Android, Windows, RIM, then "any device". Once again, the underlying assumption is that access will be limited to mail, calendar services and mobilized web portals. What is not usually considered is the potential specialization of mobile devices, and the more specific hardware requirements that may accompany it.
For example, if you have seen the ad for the Samsung Galaxy where the two acquaintances can share a photo just by touching phones together, that is a simple example of NFC (Near field communications). NFC can be built into a wireless device, or increasingly the capability can be added via an enhanced SIM or MicroSD card.
On the consumer side, NFC could be used for electronic "wallet" applications. It is also gaining interest in travel and hospitality to provide remote hotel check-in (NFC becomes the room key), identifying loyalty and reward program members and even car rentals. NFC is also working its way into business applications, from supply chain and inventory to security, access and time clock solutions.
As devices and applications become more specialized, supporting the mobile OS will become the easy part. If you consider how specialized mobile devices may become, there may come a time when the SIM cards, special radios and connectivity requirements for both work and personal use are just too much for a single device. It could be simply that employees no longer want to use the same device for both work and home, because there are too many apps to access for both environments.
Here's an analogy: For as long as I can remember, the State of California has issued a driver's license with a magnetic strip on the back, but employees of companies with large campus environments still carry a separate "badge" for work (which they often forget) and have no other use for after they clock out. It would not be hard to use that driver's license for building access, but people would not agree to it because it is too personal, and it's too important for so many other things.
As the mobile device becomes an individual's wallet, VIP pass, boarding pass and remote home control, those individuals will not want to have it co-managed by their company. They will not agree to have it selectively "wiped". Folks may want to get email on their Android device, but they still don't like to share the remote control.
Planning Your Mobile Strategy and Your BYOD Program
Someone shared a mobile strategy with me recently in which BYOD was the final goal. I prefer to think of enterprise mobility as a larger strategy and BYOD as just a program. BYOD programs should not be the driving force in how a large IT organization decides to leverage mobile technology.
A better way to plan is to look at long term business functionality that will benefit employees, then determine the level of access that will be needed to support those processes. Perhaps you will discover that the level of access that is currently required can indeed be supported on employee liable devices, and specific business groups will require more specialized access in the future.
BYOD programs may continue to provide email and calendar access to personally owned devices, because it's relatively easy. Some type of BYOD program will probably fit into your plan.
Consider this: If you currently provide guest WiFi access, you are already supporting non-company devices. If you have a portal that provides access to company services from a non-corporate computer, you already are supporting BYOD. So next time someone asks you when you are going to do "BYOD", you can tell them "We already are, my friend!". You are simply limiting the level of access that is allowed on non-corporate devices.
Conversely, I have heard the term "Pure BYOD" used recently, and no one in the discussion was really sure what it meant. Does it mean no governance or security on personal devices, with no reimbursement? That will probably be very rare.
Next Page: Have an Exit Strategy
Plan BYOD with an Exit Strategy
Plan your BYOD program so that it can be reversed. Mobile technology will become a critical asset and the IT department should retain visibility into how mobile technology is being used in the enterprise. It is clear that at a minimum there are requirements for policy enforcement and security tools, which is already one area of visibility. Enterprises are also wise to understand their overall wireless costs, both direct and indirect, for strategic purposes.
IT organizations should not give up the leverage that they have with wireless carriers, and employees should not have to pay consumer rates when the aggregate revenue stream is still going to the carrier. Offering participating employees an individual liable discount plan for wireless services helps to control costs. Wireless carriers are very cooperative with offering almost the same incentives on individual liable plans as on a corporate liable plan if the alternative is losing control over the revenue stream, with thousands of devices being split among individually selected carriers. This keeps your visibility into costs and participation. This approach benefits you, your employees, and the carrier.
Finally, BYOD will be tough to control if it is the only alternative. There are many untested policy issues around requiring a device for work but providing no alternative to a BYOD program. More importantly, you want to have a say in what devices will be supported and what other applications can be used. Having a company provided alternative makes the demands you may impose on a personal device a much easier sell. Simply put, "If you don't like your BYOD choices, use the device we provide to you."
Currently, Bring Your Own Device programs are considered forward thinking. I agree, but it is only a few steps forward. Consider the reality that even the organizations allowing BYOD are at the same time providing devices to support expensive, specialized applications.
It is great that you are thinking about BYOD, but don't think you have made the final change to your IT Strategy. With richer applications and specialized device capabilities, BYOD could turn out to be "so 2012".
