The pressure is only increasing to either go mobile or go home.
There is no one-size-fits-all strategy for going mobile, but there are some principles to adopt:
- Anything that faces customers or clients should work in a mobile context, meaning at least iOS and Android. Whether those functions are native apps or adaptive Web services is an implementation question based on the needs and nature of the function.
- Note the use of the word "function" — monolithic systems can make great sense on the back end, but mobile users need to focus on specific tasks, especially in the smartphone context. They need mini-apps or widgets — functions — not suites of the scale of Microsoft Office, SAP R3, Oracle Business Suite, and so on. Decompose those monoliths on the client side, at least. And think about minimal essential requirements (an agile concept) rather than boil-the-ocean completeness —more apps, if properly segmented, is better than big apps. The real trick is how to connect those client apps with the back end so that clients can be flexible and can be changed without messing up the back end; you need some equivalent to a transmission's differential.
- User experience matters as much as process, perhaps more. Typical enterprise systems derive from an era when IT specialists ran apps and sent the results to the business staff. Today, businesspeople drive the apps directly. They've complained for years that what they get from IT is clunky and hard to use, and in locked-down offices full of IT-managed desktop PCs, their complaints were ignored. Now they bring in their own mobile devices (even computers), choose their services, and run commercial apps designed for them, such as Keynote or Quickoffice. IT and its traditional vendors are competing for user mind share with those well-designed mobile apps. IT has to learn how to do UX and how to do it well from the ground up, not as a decoration slapped on at the end of the effort. Don't build crapplications.
- Don't get caught up in technology wars. HTML5 and native apps both have their place; IT's job is to figure which is best for the problem set at hand. Likewise, just because your PC apps use ActiveX or version-specific Java or Internet Explorer functions, don't insist on finding a way to retain those dependencies on modern platforms like iOS and Android that don't use them. The middleware and remote-call technologies are changing, and you may have to use more than one. It's caled heterogeneity, and it's now a fact of life.
- Don't try to enforce standardization outside of outcomes. A core attraction to mobile is that it is "yours": You choose the device and apps based on how they fit your preferences and working style. Honor that impulse by imposing outcomes only where possible. For example, who cares if a user prefers iWork or Quickoffice if he or she can deliver documents that meet your document formatting, tracking, and file-format requirements? Only if you have legitimately required processes embedded in specfic apps should you insist on those apps being used, either directly on the device or via a browser or VDI session.
- Don't focus on buzzphrases like "mobile first" or "mobile only." They're fine to jar your expectations and get you out of your comfort zone, but different users and processes need different solutions. Mobile-first makes sense for services delivered to people often on the go — sales and online retail are good examples — but also to people who come back to a PC. Mobile-only makes sense for services used only on the go, such as for delivery truck drivers and field repair technicians. But some people need PCs, even if they use them at home, and people who primarily work at a desk should be treated with a desktop-first mentality, followed by a tablet optimization (as tablets are as useful at a desk as on the road), and then maybe by a smartphone optimization (maybe). In other words, the solution set and priority should fit the problem domain's needs.
- Do think about what mobile adds to the mix. Mobile devices are chock-full of sensors, such as light sensors, GPS radios, accelerometers, cameras, and gyroscopes. What can you do with them to add new value wherever a person happens to be working? If you start with a PC frame of reference for mobile services, you'll forget these new capabilities. Likewise, keep in mind mobile's great affinity for the cloud — it's a great adjunct for both processing and storage. Although apps should need run their core functions when disconnected, they can be designed to do more when connected. Think different.
Sign up for CIO Asia eNewsletters.