The following post was originally authored by Sean O’Shaughnessey.
With the launch of the iPhone 5S, consumers have been treated to yet another leap forward in technology and ease of use, but that creates a problem as well. Enterprise consumers of mobile applications are basing their expectations of performance on popular consumer applications on devices like the iPhone.
Applications such as Facebook, Angry Birds, Evernote and Dropbox are built for high performance. Not only are the applications designed to work well on a mobile device, but the infrastructure behind them is also designed to respond to the inputs (events) initiated by the mobile user and their environment (like location).
Avoid the Frustration
The problem for the enterprise starts very early on. When companies first make a foray into mobile devices, they often just expose their standard application to the mobile device with, perhaps, a slightly different stylesheet (presentation layer). This results in a slow and confusing experience that frustrates the user.
It’s usually not cost effective to hire developers to write native applications for simple workflow-dedicated applications. The cost of development, required constant updates, and the small user base simply make it impractical to develop dedicated applications. This is complicated by the popular use of Android and iPhone platforms, which likely splits the enterprise user base.
There Is a Solution
To solve this problem, companies need to consider a mobile device management (MDM) solution. While these implementations are still quite new, not all of the experiences to date have been successful. This is because there is too much application logic--the heavy lifting of mobile technology--required on the device. Sometimes, and just as difficult, the heavy lifting is being pushed to the database-driven applications far in the backend. The only way around these two challenges is, not surprisingly, the middle path: create a services-based layer to handle this effort.
In many cases, the end-user mobile application interfaces to multiple backend systems. This is a problem that is begging for a Service Oriented Architecture (AKA … SOA). Unfortunately, most MDM solutions create direct connections from the data source to the application, which exacerbates the problem of scalability. This architecture lends itself to a structure that simply does not scale as the number of users and applications expand rapidly, as everyone hopes they will. Therefore, if the first applications are only deemed to be a partial success, the success rate is likely to decline as the number of users, mobile apps and connected enterprise applications increases. Just like that, we’ve created a highly repeatable mobility failure scenario.
When you investigate the infrastructure behind many consumer applications, like Facebook or Google Maps, you find that most of them use a highly scalable infrastructure that maximizes the use of RAM. These implementations resemble a SOA environment in that they easily scale to allow for millions of potential users. It defies logic that a company providing applications to its users would have a less flexible architecture than the infrastructure for internal applications, yet that’s what happens.
Despite this common scenario, I’ve witnessed success in my accounts. Here at TIBCO, we use mobility and integration software to manage the orchestration of multiple-source enterprise applications. This is further augmented with the highly scalable in-memory data grid (like RAM on a computer) to reduce the reliance on inherently slow database applications. This modern architecture provides a platform that has the flexibility of an enterprise mobile device platform, but the scalability of a consumer-based mobile platform. To learn more about mobile integration, read this whitepaper: Seven Principles for a Mobile Integration Strategy.
This post first appeared on The TIBCO Blog and has been lightly edited.