Monday, March 4, 2013

What you need to know about using tablets as clients for enterprise applications


The flurry of new mobile devices continues.  Consumers (who look a lot like your employees) love them.  And they naturally want to use them in their (er, your) enterprise IT environment.  And that’s where the problems start.
It seems like it would be simple to introduce tablets and other mobile devices into the enterprise.  But here’s the worst-kept secret in IT today: it’s not.
And this is a huge problem.  Tablets, which should be a boon to productivity and flexibility for employees, are instead causing IT headaches.
The new mobile realities for application architecture, or: what’s changed thanks to tablets
As we here at Framehawk have been focusing our efforts to help enterprises make tablets productive with enterprise applications, the first thing we see companies struggling with are their long-standing application architecture assumptions.  The tablet is a different animal and many of IT’s assumptions about how clients work with their enterprise apps are no longer valid.
Here’s a quick list of what’s changed in moving from only traditional PCs to a list of application clients that includes tablets.  I’m calling this a list of the “new mobile realities”:
The networks are now varied and unreliable.  Existing applications expect a high-quality, consistent corporate LAN to communicate between clients and servers.  When you use an iPad, you replace that LAN with WiFi or an unreliable mobile network.  Add in the complexities of latency from large geographic distances and network security concerns, and the network becomes a major source of uncertainty.
Client devices now have very constrained – or completely unknown – computing capabilities. iPads, Android tablets, Microsoft Surface, and other mobile devices all have processing and memory constraints connected to size, weight, and battery life trade-offs.  This means that relying on the edge device to take on any of the processing load for applications will put a severe drag on the performance of those applications on that device.  In a BYOD environment, you also have no idea which device will actually be the client at any given time, since by definition you are leaving the choice up to the employee.
The new user interaction model – touch – is drastically different.  Enterprise applications in use today were built to receive input from a mouse and keyboard. The touch and gesture interface of tablets, however, is a very different interaction approach, and the difference is going to have to be accounted for when trying to work with existing applications via a tablet.  In addition, tablet users have an expectation that their interaction on the device will be very simple, specific, and easy – a situation that, putting it nicely, may be at odds with the way an existing enterprise application is designed.
The new client device usage model is quite varied.  With the introduction of tablets as a client in the enterprise application environment, applications need to support a variety of different usage models.  They must be able to handle the short-duration, quick-interaction style usage from tablets at multiple times throughout the day.  They must also still be able to handle the long-lasting, consistent-connection usage from the traditional desktop and laptop PC clients.  And, in some cases, they also need to be able to handle the very dynamic, get-in/get-out usage pattern of smartphone users.  Because employees aren’t (generally) giving up their PCs, enterprise applications must support all of these different patterns at different times from the same user.  IT has to be ready for all possibilities.  The business processes must support all these possibilities as well – no business process silos allowed.
Cloud computing means new deployment options.  At any given time, an application’s servers might be in an organization’s data center, in a hosted virtual private cloud, or in a public cloud – the answer depends upon cost, load, time of day, security, or other business requirements.  Or, the enterprise may be using Software as a Service (SaaS) applications provided by a third party. All of these scenarios add complexity in attempting to provide access to those applications via tablets – and even more so when accessing multiple applications in an enterprise’s portfolio.
Security for mobile devices has many more moving parts – and some different assumptions.  By allowing new devices not owned by IT access to applications from outside the corporate network, the bad guys could have more attack options.  IT’s traditional approach to dealing with unknown or untrusted devices is to say no or lock everything down.  This approach with tablets or other mobile devices results in either unacceptable user experience trade-offs (such as multiple, repeated log-ins and challenges) or draconian legal requirements to control devices that they do not own (such as requiring agreement to remote wipe and the like), putting personal information and assets at risk to somehow meet the enterprise requirements.  And, some of the approaches that IT has used in other situations (like VPN) open up more security holes themselves.
What can IT do about these new mobile realities to accommodate tablets?
So what do you do about this?  There are a number of existing approaches to application mobilization.  But these New Mobile Realities I’ve been talking about are the very things that give the existing approaches fits.  Whether you use VDI, HTML5, or develop some native apps, there are some unavoidable and painful trade-offs.
Of course, here at Framehawk, we look at this as a huge opportunity in need of a solution (we have a white paper you can download that tells a bit more about how we handle a lot of this).
But regardless of what you think of our solution, step 1 for an enterprise is to figure out where the moving parts are and begin to consider solutions that address (or at least understand) the issues.  Hopefully, this list starts you in the right direction.  Stay tuned for a follow-on blog about new ways to think about a solution.

This post also appears on the Framehawk blog.

No comments: