Building iOS and Android apps only outside your core systems means you're not getting the value you could from mobile

InfoWorld|Mar 14, 2014

For several years, most IT organizations have been focused on treating mobile devices as risks to contain or manage. But some have focused on mobile as an opportunity to provide or extend business value. Because the IT focus has been on security, hundreds of mobile security vendors are out there. But there's much less available in terms of capabilities to enable the use of mobile for constructive purposes.

As a result, mobile apps ironically remain underdeveloped in the enterprise. There are plenty of tools to create mobile apps, of course, but these tools are designed for self-contained apps or apps that tap into cloud-delivered services -- resulting in apps that barely tap into enterprises' core data and systems. That perpetuates the notion that IT manages only inwardly focused "back office" core systems, while business units and outside developers are where you get the new "front office" capabilities. That's not good for IT -- or for your business.

But some technologies are available for creating useful, valuable mobile apps that are actually part of your business. One venue for them is Force.com, which leverages Salesforce.com's customer relationship management (CRM) software to let businesses create real business apps. For example, Coca-Cola Enterprises, the European Coke distributor, uses Force.com modules in mobile apps that help its roving sales and distribution employees better serve customers by using sales data.

Another venue should be your core in-house systems, such as your enterprise resource planning (ERP) systems or other transactional systems, including e-commerce, distribution, or supply-chain management. The problem is, such systems live in technological silos designed to keep them safe, consistent, and self-contained. The notion of federating data or services is alien to their architecture. Yes, there are integration methods, but they're typically pipelined extract/import methods, passing data from one system to another.

A decade ago, the services-oriented architecture (SOA) approach had a brief moment in the sun, marketed as a way to create apps from services assembled on the fly using standard APIs. "Legacy" back-end services woud be wrapped in ways that let them interact to some degree with these flexible, composed apps.

But SOA quickly became another monolith: As organizations struggled with managing all those services, they began to combine them into more complex but fewer modules, managed through enterprise service buses. It was good old middleware with a fancy new name. As a result, the promised explosion in Web apps didn't happen. A few industries used them to expose reports and basic customer data in dashboard-like apps, but Web apps à la SOA didn't really happen.

Today, mobile apps are the new Web apps, but with a twist: They run on truly different devices -- mobile devices. That's important because it was easy for most IT organizations to create a simple .Net or Java application for computer users rather than create browser-based Web services. Windows was Windows, while browsers varied widely. And browsers didn't have the richness of a Windows for client apps.

Mobile devices are so different that this "one native client" approach just doesn't work, despite the efforts of companies like Citrix Systems to try to run Windows apps on iPads, iPhones, and Androids via virtual desktop infrastructure (VDI) technology.