Bring your own device … as long as it’s HTML5

As we talk with clients and prospects in the market we’re seeing a steady growth in interest around BYOD (Bring Your Own Device). This trend to allow employees to bring their own hardware (predominantly mobile phones) is putting new stresses and strains on existing IT infrastructure, operations and development practices. There are many pitfalls to watch out for, but if executed successfully, embracing the consumerization of enterprise IT can pay dividends by re-engaging a jaded work-force, simplifying cumbersome workflows and offering a launchpad to a next generation of more supple, usable and maintainable software.


The wave is inevitable

The days when organizations could mandate a limited set of issued (or supported) devices and provide access to services that were designed more around the constraints of existing IT than the users’ needs are ending abruptly. Organizations that are hesitating to overhaul their approaches are finding that employees are quickly finding ways to circumvent existing procedures and systems. It used to be the case that the software and hardware that enterprises offer their employees tended to be superior to what they encountered at home. With the advent of services like GMail, Dropbox and Skype and of hardware like the iPhone and iPad those days are well and truly behind us. Organizations that don’t respond swiftly to embrace this trend are finding themselves saddled with a disgruntled and unproductive workforce and a growing security attack surface as their employees find work-arounds to shoe-horn their favorite tools into their work lives.

BYOD introduces many challenges – security of services and data is high on the list as is distribution and provisioning along with exposing key systems, like email and calendar, to a range of native applications. However this article is focused on the challenges involved in building or migrating applications to work on a variety of devices and a range of contexts.

The multi-platform challenge

One of the major challenges facing IT organizations is how to support a broad range of devices from laptops to tablets, smartphones and beyond. In earlier times you could constrain costs by developing for and testing on a highly restricted set of platforms, but now costs are spiraling as services are expected to work on something other than just Internet Explorer and BlackBerries.

One response to this has been the attitude of: “You can bring your own device … as long as it’s an iPhone … We are planning an Android roll-out in Q2 of next year … budget depending”. This is a similar anti-pattern we’ve seen in consumer-facing mobile development too: the initial cost of hitting a single high-end, shiny, device is reasonably manageable (putting aside the cost of up-skilling your teams on building and deploying iOS applications), but the incremental costs of rolling out to other platforms (Android, WinPhone7, BlackBerry, Mobile Web, etc) can really kill IT budgets and support capabilities.

Luckily there are other options available to those who are willing to think strategically about their application portfolios and execute on a thoughtful and adaptive roadmap.


What to do with your existing systems

As you look across your application portfolio to review what changes are needed to support a mobile workforce bringing their own devices, likely options to consider are:

  • This application is no longer needed (kill it!) or doesn’t need mobile access (great!).
  • This one just needs the UI tweaking to work in mobile browsers.
  • This one needs a completely new mobile application, but we can probably re-use the back-end services.
  • This one needs to be completely replaced.
  • These two applications need to be merged into one.
  • This application needs to be split apart.

I’ve written before about how to be successful when replacing or revamping existing applications. That general advice still applies in a BYOD arena.

Where you decide some work is necessary you will have to address the challenge of building systems for multiple platforms.


Cross-platform solutions

When targeting multiple, disparate, devices the main options to consider are:

  • Limit which devices to support. This is far from ideal, but can constrain cost and complexity.
  • Build native applications for each platform. This is the most expensive option, but can make sense if you need very high-touch interactivity that makes extensive use of native device capabilities and the application is a key differentiator for your organization.
  • Use a cross-platform toolkit or service. This can be the correct choice if you are happy to trade off richness of experience for rapid platform coverage, but beware the “glass ceiling” inherent in most of these tools that means that to incrementally improve the experience may involve discarding the majority of your development effort.
  • Develop just for web. This is a great way to cover many platforms quickly, but doesn’t allow you to leverage key device capabilities or experience.
  • Use a hybrid web/native approach. In many scenarios this is a good option to explore. My ThoughtWorks colleague, Giles Alexander, has written a detailed article on how to execute a hybrid approach successfully.


Multi-platform strategies


When trying to select the best option there are various questions to consider:

  • Questions that drive how heavily you should favor a native application:
    • How rich and interactive an experience is required?
    • How important is it to use some or all features while offline?
    • How much do you need to leverage device-specific capabilities (NFC, GPS, Camera, accelerometer, contacts, etc)?
    • Is the application the product in itself or more of a channel to the real product?
  • Dimensions that push a hybrid or web-centric approach:
    • How many platforms do you need or want to support?
    • What is the range in capabilities of the targeted devices?
    • How much budget do you have?
  • Considerations that help decide how client or server-heavy the architecture should be:
    • How complex is the logic?
    • Are there special security or privacy constraints?
    • How much does the application need to interact with existing services?
    • How rich do you want the disconnected / offline experience to be?
  • Questions that help decide how much to invest:
    • What is the expected lifespan of the application?
    • Is the application a strategic differentiator for your organization, or just a utility?
    • How painful is the current alternative?
  • Helpful questions that may focus (and limit) the scope:
    • Does the whole of your business workflow need to be accessible while on the go, or can you focus on some key interactions?
    • What are your users’ expectations, hopes and pain-points?

These questions should be helpful thinking-tools to inform your strategy selection.


Macro-trends support “web-first” strategy

When evaluating the correct strategy it is worth considering a few macro-trends:

  • The capabilities of web applications / HTML5 are improving rapidly. The distinction between native and web apps will gradually erode. Google are clearly betting on this with their “all web” Chrome OS where the browser is the operating system.
  • There are 4 screens to consider (and counting). TV, desktop, mobile and tablet are all distinct categories with very different usage patterns, constraints and possibilities.
  • The consumerization of IT is raising users’ expectations of their software. Just because it’s an enterprise application there’s no reason for the user experience to suck!

Looking at these trends together – high expectations for software usability, many device-types to stitch together and touch-points to understand, along with the maturing of web as a platform – there is a very strong case for leaning heavily on web technologies and minimizing the amount of native, device-specific, coding you employ.


Strategic versus utility

It is likely that looking across your portfolio of applications you will want to employ a combination of approaches. When choosing where to focus budget for custom application development it’s worth considering where each application falls on the Strategic/Utility divide as outlined by Martin Fowler. Though be aware that your employees’ expectations about the usability of enterprise software is increasing and this may alter where the dividing line should lie between mere utility projects and the strategic ones that are worth investing in.


Strategic versus utility projects

For applications that fall on the utility side of this divide it is sensible to consider lower cost or off-the-shelf options, such as toolkits or SaaS services that expose or port your applications to a range of mobile devices. Most of these approaches trade off flexibility and a rich user experience for a cost effective way to target multiple mobile platforms and devices. They also tend to suffer from the “glass ceiling” problem mentioned earlier – if you want to change the trade-off and improve the flexibility or user experience you often have to discard much of the framework or service and start again from scratch.

For those applications that count as strategic (or that may become strategic over time) we strongly recommend considering custom application development. When considering custom development there are two important pieces of advice to remember.


Understand your users – deliver early and often

Reviewing your application or application portfolio creates a great opportunity to look at how they are actually being used and how well they meet the needs of your users and your business. Mobility gives a great extra focus and new perspective. When evaluating what to expose to mobile usage don’t just fall for the easy approach of expecting “feature parity” across mobile and desktop versions. Instead go and take a look at how your users are using your application and what context they’re in when they want mobile (or tablet, or TV) access and what scenarios are really pertinent in that context. You may well find that there is a much more limited set of use cases that you need to support and you may also discover that being mobile offers interesting new opportunities. Can you leverage their location (GPS) or their camera? Can you make use of the time that they’re disconnected from the network to progress “micro workflows” like approving a next step? Can you simplify the workflow and interactions (or at least a subset of them) to such an extent that they can be implemented over SMS? Does mobile introduce new social options for you?

This user-centric and context-aware approach to designing the mobile experience has the double benefit of both creating a more usable and intuitive application and at the same time reducing the amount of work you have to undertake since you will no longer be blindly chasing feature parity across all platforms and channels.

To really make the most of this approach you will likely want to be getting rapid feedback from your end users so you can validate that your design and implementation is actually solving real needs. This requires a two-pronged approach:

  1. Setting your teams up with the discipline and practices necessary to deliver a rapid and reliable flow of new features. This approach is better known as Continuous Delivery
  2. Tying design and real user feedback into your rapid iteration cycle so you can validate that you’re actually continuously delivering something worthwhile. This yoking together of Continuous Design and Continuous Delivery is where the real 1+1>2 magic happens.

Given that the mobile usage of corporate apps is new terrain, coupled with the fact that mobile is still in a state of growth and experimentation, it’s highly unlikely that you will know up-front exactly what your users need. This pushes strongly for an ongoing iterative approach both for delivering applications and for directing their product roadmap.

As an aside it is worth noting that, other things being equal, it’s much easier to iterate quickly in via web-based / hybrid rather than native apps. You can just introduce changes server-side without annoying users with constant update notifications.


Think “roadmap”

In the face of many IT failures and with the advent of Agile development and, more recently, Lean Start-up approaches there is a strong case for structuring a roadmap that focuses on shipping a usable product quickly and then growing it based on real user feedback and usage metrics.

This evolutionary approach to design and development embraces the old adage of how to escape the iron triangle of tough scope, budget and time constraints: “do less, start sooner“!

Hybrid, web-first, strategies fit well with incremental roadmaps for product development. You can target many devices quickly with an initial web application and then gradually decide where and when it is worth applying some native gloss by wrapping your web application with a thin native shell. This approach maximizes the trade-off between platforms covered and cost to deliver. It also has the subsidiary benefit of favoring the skill-sets you are more likely to have already in-house – standard web development skills tend to be much easier to come by than native iOS or Android developers. Though beware that you do need to treat JavaScript as a first-class language.

A roadmap that favors web technologies also sets you up nicely for the ongoing convergence of different channels. Users are expecting to be able to interact with your services in whatever way suits them and this will more and more include many different types of screens, devices and locations. While there is currently a large focus on mobile as a separate channel to your users that needs to be treated separately, we are rapidly approaching the point at which mobile becomes “business as usual” and naturally integrated into all (or most) initiatives. This onset of an “omnichannel” landscape is well served by web technologies – access to a decent browser across all channels is becoming more and more reliable.

The roadmap view of the world treats software not as something to be conceived of, designed, built and deployed in one fell swoop, but rather as an ecosystem to be grown, observed, adjusted and nurtured. In my mind software development (at the macro scale) is more akin to urban planning and regeneration than it is to architecting a building or engineering a bridge.

Your roadmap should be driven by addressing real business needs and value as early as possible. It should be guided by a vision of where you are headed and what the architecture will likely look like, but that vision, or “true north”, should be open to adjustment and change based on contact with real world users and shifting business needs and opportunities. The continuous delivery practices mentioned above should give you the suppleness to respond to these changes and the user-centric continuous design approaches should give you visibility into the right direction to head.

Beware the long tail of devices

If your roadmap is focused on delivering real value regularly, then there will be natural trade-offs to be made. One particular trade-off worth monitoring in a BYOD environment is your strategy for supporting a large number of devices. Do you insist on the same level of experience and functionality across all devices, no matter their capabilities, or are you comfortable gradually degrading (or sharply cutting off) the experience as you enter the long tail of lower capability or older, less standards-compliant phones?

You just need to look at one of the lists of Android devices observed in the wild to understand the cost involved in just testing across a small subset of them, let alone making harder and harder tweaks to retain the same look and behavior. The parallels with the pains many organizations have felt supporting IE6 and other legacy browsers is valid.


Supporting the long-tail of devices

Having encountered this situation on many projects our strong advice is to feel comfortable degrading across lesser used and less featured devices. Responsive web design coupled with progressive enhancement approaches can make this strategy reasonably easy to execute. As with any roadmap the key is to monitor real usage and feedback and adjust to meet the highest impact needs.

Leapfrog your existing IT constraints

Although migrating systems to support a myriad of mobile devices can be a painful process it also holds great opportunity. Many organizations have become weighed down with the baggage accumulated from decades of changing technologies and methodologies and the technical and process debt created by the compounding of a thousand minor trade-offs and tactical decisions. Each one in it’s own right is not a real problem, but in aggregate they can choke an organization’s ability to move forward at any kind of reasonable pace.

Luckily, responding to the demand for BYOD with an evolutionary roadmap that embraces rapid user-centric design, supported by lightweight yet rigorous engineering practices can provide an escape route. This approach offers an opportunity to leapfrog your existing constraints and provide quality software and services at a rate that will both surprise and delight your customers and employees.