I recently tweeted that 47% of the Global 500 companies are testing or rolling out iPads, according to Apple CFO Peter Oppenheimer. Whether or not all these tests turn into rollouts, there is going to be a whole load of iPads (and Android and WebOS tablets too) arriving in the enterprise. This is going to lead to a knock-on pressure to connect into back-end enterprise systems so that these tablet devices can do “real work” for the business. By “real work” I mean going beyond email and calendaring to apps that streamline the vital business processes in the enterprise that support the bottom line.
One key obstacle that have dogged the mobile enterprise applications space for years is the need for customization of these apps to support differentiated processes. Your company is more profitable than others in your industry because you do something different to the herd, something different that customers value, that increases revenue or reduces cost. So off-the-shelf business apps downloaded from the App Store aren’t going to help much here. In the past this has needed specialist custom mobile applications to be written, leading us down the road of hand-crafted software with all the high development costs, high support costs and non-scaleability that this implies.
The holy grail of mobile integration in the enterprise is a technology that can link any enterprise back-end platform that has been customized in some way (think SAP, Siebel or IBM Websphere here) to any of the popular new (and old) mobile platforms (think iOS and Android, but also Blackberry because it’s not going away just yet). This technology needs to support mobile sync, not just mobile browser access to data, because the app has to work as well as my email app, and that means in the jargon on the mobile technologists that it must be able to work in “occasionally-connected mode” i.e. with a local data store that can sync with a back-end server whenever the mobile network allows.
The mobile integration matrix
At Teamstudio, we’ve been pondering the right technology to support this. In the mobile integration matrix pictured above, we want to be able to sync any back-end enterprise system with any front-end mobile platform. With (for example) 12 important back-end systems in a large enterprise and important 3 mobile OS platforms to support, that means building up to 36 point technology solutions (or at least, 36 different software “connectors”) if we do it the old-fashioned, hand-crafted way. With our Unplugged software, we’ve been using the Lotus Domino server as a kind of universal integration hub, but not every company is capable of or wants to run a Domino infrastructure.
Recently, we’ve been looking for a more universal synchronisation approach that could sync any mobile front-end to any enterprise back-end. The first step was to look for any well-documented open sync protocols that exist in the public domain. Yahoo’s Alex Kessinger gives a succinct summary of these in his blog article The Future of Mobile Sync, identifying 3 possible candidates:
- Odata (created by Microsoft but an open, license-free protocol)
- FeedSync or Simple Sharing Extensions built on top of RSS
Of these three, OData is particularly interesting because the protocol can encapsulate a standardized rendition of the Entity Data Model of the back-end system, so no deep knowledge of the internals of the back end system is needed to create a new custom mobile front end. The Odata + Sync protocol that is defined in Microsoft Sync Framework 4.0), meets most of the sync requirements that we see with Unplugged projects. Microsoft are providing OData interfaces in all of their main back end systems, including SQL Server, Sharepoint and Dynamics. Other vendors are picking up on the potential of OData, e.g. SAP with their NetWeaver Gateway.
A second, related Holy Grail question in my mind is how to package a mobile sync technology in a way that would allow a typical developer in the enterprise to create an up-and-running mobile sync service in minutes, rather than hours or days. However, that’s a topic for another day.