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.