BYOD (bring your own device) in the enterprise is here, and it will get stronger, except for folks in a few specialty areas (e.g., the military). You may want to dig your heels in and hope it won’t happen, but that isn’t going to stop it. Let’s roll up our sleeves and delve into the kinds of challenges BYOD presents enterprise developers, and see what we need to do to overcome them.
Even if your enterprise is deploying devices that integrate with your existing authentication infrastructure, BYOD means that you need an alternate route of authentication. It will be tempting to just throw in a quick ‘n dirty application-specific authentication into your application — do not do this, because it just infuriates users as they encounter password and username sprawl. Instead, authenticate against the enterprise’s system. It will probably be less work, and it will make your users happy.
Native or Web?
Native or Web has been a big question for mobile app developers for some time. Before BYOD, enterprise developers had the freedom to go with native applications and know that, short of a massive rip and replace program, it was a safe choice, and that for every native application they wrote, that made rip and replace a little less likely. With BYOD, I recommend that you go with Web development, unless you have a ton of in-house native application expertise and resources waiting to re-develop the front end (or worse, the entire application, if you don’t use Web services for the heavy lifting) for each device type out there.
One of the joys of enterprise development has been that you knew the one to three screen sizes used by the company. With BYOD, you can forget that. Your application must adapt to different screen sizes adroitly, which is a bit of work for a native mobile application if you want it to look really nice instead of counting on the OS scaling it. With Web applications, that is a lot easier.
There was a very long period when enterprise applications could get away with looking like a Windows 3.1 application or just be a bunch of screens with grids of data. Users have higher expectations now, and a successful BYOD strategy needs to meet those expectations. Applications need to be much more usable. While appearance is not a functional requirement, ugly applications can be frustrating to use, and attractive applications make a good impression on the stakeholders.
No Active Directory or Group Policy
One of the really nice things about working in an enterprise environment is that you can almost always count on Active Directory and Group Policy being there. Group Policy in particular is fantastic because it lets the system administrators centralize settings and configuration. Your application needs to be added to the “Trusted Sites” in order to work fine? No problem, push it through Group Policy. Require an obscure registry setting to be changed? Group Policy to the rescue! Is there an OS feature that must be installed for the application to work? Yeah, Group Policy does that too.
With BYOD, your application must work without any kind of centralized configuration or control, which means that end users need to be able to configure it on their own. Maybe this means that you leverage DNS (like Exchange does) to help point users to a central configuration, or perhaps you use another configuration server scenario. You cannot count on Group Policy and Active Directory for management and configuration anymore.
With traditional enterprise applications, we got used to rolling out something and having the users get trained on it. The training worked because everyone had the same experience.
BYOD users expect to install an app or point to a URL and start working. And even when there are opportunities to train, users will have different experiences because they won’t all be using the same device. Your applications must be usable without formal training, and have self-contained help and documentation and tutorials.
Lots of companies set up barriers to VPN like physical tokens and third-party applications. These setups are sold with the promise of increased management and reduced headaches, but in a world of BYOD, they shut most devices out of the VPN entirely, meaning that everything needs to run over the public Internet. You should be prepared for your application to run over the public Internet too, unless it is something that is entirely useless off-premises. You should expect all traffic to be HTTP (good luck getting the IT staff to open a different port just for your application), and plan to leverage the device’s built-in email capabilities if you need to send email.
The networking concerns bring us to the topic of security. Your application absolutely must be secure. This means HTTPS for anything but the most innocent of traffic, for starters. Even then, you should consider encrypting sensitive data “on the wire” too to defend against man-in-the-middle attacks and snooping when the user is on public Wi-Fi. Any sensitive data stored on the device should be encrypted. You need to treat data from the device like you would treat data from a public-facing Web site, and protect against SQL injections, cross-site-scripting, and other similar attacks. This sounds like a pain in the neck, but any good, modern development environment goes a long way in helping here.
More to come
In future posts, I will take a more in-depth, hands-on look at many of these topics and show how to implement the needed changes.
Additional BYOD resources
For more on this topic, check out the ZDNet and TechRepublic special feature BYOD and the Consumerization of IT, the TechRepublic Pro BYOD policy download, and The Executive’s Guide to BYOD and the Consumerization of IT.
Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.