Three years ago, mobile apps were a pooh-poohed as a fad by IT -- "you can't do anything real on a phone or tablet" was a common statement. Today, every tech vendor and consultancy is telling IT to go mobile only or at least mobile first.
For example, SAP is on a mission to make ERP sexy again (and justify its high cost) by using mobile apps and mobile access to unlock value from those core systems, letting users make a system of record like ERP or MRP into part of a larger system of engagement with direct value to users: Its Fiori effort finally brings ERP clients into the 2010s, a long-overdue acknowledgment that actual people use business software, something that frankly should have been done two decades ago in the Windows 95 era. Likewise, a legion of IBM consultants is offering its expertise to internal enterprise app dev to "mobilize" all those Windows apps users apparently want to jettison in favor of simpler, more process-specific iOS, Android, and Web apps.
[ How the mobile industry should tackle information security. | Buckle up -- here comes the hard part of mobile management. | Keep up on key mobile developments and insights via Twitter and with the Mobile Edge blog and Mobilize newsletter. ]
Every major consultancy -- Accenture, CSC, Deloitte, PwC, Unisys, and so on -- is knocking on CIO doors offering mobility services, from architecture to deployment. Dell and Hewlett-Packard are trying to shake their now-legacy PC reputation and instead be seen as mobile and cloud management and deployment experts. Salesforce.com, which disrupted traditional enterprise apps through cloud offerings, now feels compelled to advocate for a mobile cloud disruption. And on and on.
In IT's eyes, Intel seems suddenly vulnerable because it missed the mobile processor boat. It sees the shameless security industry go into super-fearmongering mode to sell technical straitjackets promised to imprison users beyond whatever they dreamed of selling in a PC world (never mind that most are unnecessary and some, like mobile antivirus, don't really work). It sees networking mainstays like Cisco and Juniper sanction those pesky Apple networking protocols because the mobile devices of choice in business use them. It sees the traditional IT ally, Microsoft, embrace the Apple mobile vision in Windows 8, the Surface tablet, and other new products (though not very successfully).
Everywhere IT turns, it finds a vendor or consultant is selling mobile -- and sees that employees and customers are all using it, IT resistance notwithstanding. There are even vendors selling mobile tools to IT, for everything from incident tracking to network sniffing.
IT would be foolish to adopt all those mobile technologies or believe all those mobile processes. But it does need to embrace mobile as part of its mission, and not just from a security or management standpoint. Unfortunately, most IT organizations have thus far treated mobile as a threat to be contained, not an opportunity to be exploited. That's only pushed business staffers to bypass IT, which is beginning to see its importance threatened by the perfect storm of mobile adoption, cloud adoption, and ownership of new technologies by departments such as marketing.
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.