Mobile Insights

Mobilizing your enterprise applications

This series by Craig Mathias explores the usefulness of mobile CRM, ERP and SAP applications in the enterprise and looks at some potential roadblocks to mobilizing enterprise applications.

In this series:

    Requires Free Membership to View

  Form factor and middleware
  Potential roadblocks to mobilizing your applications



It has for some time been my opinion that the future of essentially all of IT is in mobility. Look at it this way: We've made great progress in improving the performance and availability of wireless networks, both wireless LANs and wide-area services, and we've seen great advances in mobile devices as well, especially in terms of their ability to support both local application execution and Web access. It's pretty clear that the trend toward anytime/anywhere computing is growing, as we topple technical and, perhaps more importantly, cultural and social barriers. No matter what the job, many professionals are now free to work wherever it's most convenient, comfortable and appropriate -- from the office to the home, from the back of a taxi to a park bench. And the key to all of this is bringing the services of the network -- whatever IT has to offer -- to where they need to be. Mobility equals productivity and can have a very positive impact on the bottom line into the bargain.

But let's face it, wide-area wireless networks aren't to the point where the service they offer is as good as that provisioned on the corporate LAN, and mobile devices will always represent a compromise in functionality that is simply inherent in making any enterprise-class device small enough to be really mobile. Nonetheless, if we can address these challenges -- mobilizing network services including access to applications -- we solve the problem of provisioning these in essentially any environment, including at the desktop. And many IT departments have realized this already.

So the question before us is how to mobilize network resources and especially enterprise applications, given these constraints. As it turns out, there are three key strategic possibilities here, as follows:

  • Remote access/remote desktop -- The key idea here is to use whatever access is available to tunnel (via a VPN, of course) back into the enterprise, using a remote-control metaphor. Virtual Network Computing (VNC), available from a number of suppliers, is going to become very important here, because it is fundamentally device-independent and thus allows access to any computer, regardless of operating system. The core challenge in this case is simply to map a big screen onto a small one, but there are many successful metaphors and techniques available to do this.
  • Local applications -- In this case, at least a partial port of the application to the mobile device is required. This can be very challenging -- mobile operating systems are not as robust as their desktop and notebook counterparts, nor are the processor, memory and storage available locally. And software developers are not cheap. But there is potentially less of a network dependency here (assuming enough data can be locally cached), allowing disconnected operations. A hybrid local/remote model is more likely when large amounts of data are involved, since a fairly robust server is almost always essential to enterprise apps today.
  • Web services via a browser -- I think this approach holds the most promise, as we can take advantage of an instance of the write once/run anywhere concept and provide essentially the same user experience (subject, again, to the constraints of the local user interface and the quality of the local browser) whether we're in the office or using a handset at a bus stop. But, again, this alternative depends upon the provision of essentially continuous connectivity, and wireless networks are not yet at the point where that can be taken for granted.

The big question, then, is where the applications run -- or, perhaps better put, should run. Advances in mobile devices, in terms of processing power and battery life, make the handset today an attractive host for enterprise apps. But, as I mentioned above, the constraint is more likely to be access to the data required, not the capabilities of the mobile device.

In the next section, we'll look at what some key enterprise-software vendors are doing in mobility today, and we'll close the series with a deeper look at why a hybrid local-execution/Web-services model is likely to dominate for the foreseeable future.


Form factor and middleware  

As I've said for some time, the goal of modern wireless technologies, services and products is to minimize the behavioral and performance differences that have historically separated wireline and wireless. While this loosely means that the capabilities we have and the throughput and responsiveness we experience need to be identical in both domains, it also means that applications will look pretty much the same. This is a very difficult challenge because, apart from notebooks and similar mobile computers, the user interface on really mobile devices, most notably handsets, is very different from what we usually have in the office. Display screens are smaller, and other user-interface artifacts usually aren't designed for heavy use. And there's a bigger problem: We've historically not had (and still really don't have) continuous, reliable, broadband wireless access in most locations, so mobile applications have followed the traditional model for the most part: a port of the application to the mobile devices. But there is a huge number of mobile platforms (including, but not limited to, the various flavors of Windows Mobile, BlackBerry, Mac OS, Symbian, BREW, Java, and many variants of LINUX beyond Google's Android and an even larger number of mobile devices upon which these platforms run, meaning that software application vendors must carefully choose which devices to support. The result is less choice for the enterprise in terms of devices and carriers, and a need for greater upfront planning and ongoing cost control.

A traditional port of code therefore involves careful business and technical decision-making and is often motivated by strategic alliances and/or clear and strong customer demand. A good example is the custom port of SAP's CRM app to the BlackBerry platform. But I think such moves will be the exception rather than the rule. Most enterprise and other software vendors, as well as enterprises that develop their own apps, seek as much device independence as possible in order to remove potential limitations and maximize ROI. And there's an easy way for them to get this: mobile middleware.

Mobile middleware has been around for many years, and in many forms, but its basic job is to allow remote access to server-based applications from mobile devices. Middleware can hide the details of interacting with a particular network, but -- much more important -- it allows a mobile user to run an application remotely, mapping portions of a desktop display onto the small screen. A good example can be seen in the Mobile Application Platform package from Vaultus, which allows an application designer to use a simple "Studio" application to select those elements of the application that will be remoted to the mobile user. A small piece of code on the mobile device handles interactions and eliminates the requirement for a big, custom port of an application. Middleware can also provide optimizations like data compression and can handle out-of-range and other temporary conditions. In short, essentially any application can be made to run in a mobile environment without too much work. Of course, that little piece of client code needs to run on your particular platform and device, so truly universal mobile access to applications isn't yet available. But, as I'll discuss in the next section, it's certainly on the horizon. Finally, middleware is now making its way to network servers -- check out Cisco's new Mobility Services Engine for an example of this important approach.

All of the major software vendors -- Sybase, Oracle, Microsoft, and many others -- have products specifically aimed at wireless and mobile users. The big issue, though, isn't so much the applications and where they run but rather the data and where it resides and how it's managed. We'll also look into that in more detail in the next section.


Potential roadblocks to mobilizing your applications  

So here's the problem -- the fundamental conundrum facing mobile computing and mobile networking. As I noted last time, we now have the technology necessary to run enterprise-class applications on mobile computers, including in many cases handhelds and the emerging class of mobile Internet devices (MIDs). But though we can execute code, we can't -- nor in most cases should we even attempt to -- carry with us all of the data that those applications need. Apart from the obvious storage requirements, it just doesn't make sense even to think about replicating and managing the synchronization of data on that kind of scale. Sure, personal information management (PIM) and personal productivity (word processing, spreadsheet, presentations, etc.) fit nicely into a mobile computing environment, but enterprise apps are another story.

As I suggested at the start of this series, I believe that, going forward, the Web services model is the best hope for IT, both fixed and mobile. The idea of building apps inside the browser (an increasingly inaccurate term, to be sure) metaphor makes the most sense, in that we should be able to write code that will run essentially everywhere, given that we now have mobile browsers like Opera Mobile, Safari, Skyfire, and Thunderhawk running on handhelds and essentially duplicating desktop browser functionality. We don't have to port code to the multitude of mobile devices that we're likely to use (networks may be converging, but mobile computers and communicators are doing quite the opposite), and overall IT costs should be reduced even if (perish the thought!) mobility isn't a core requirement.

But this vision breaks down today owing to the nature of wide-area wireless data services currently available. Coverage can be spotty, throughput variable (or even nonexistent), and costs high. The lack of a national telecommunications policy is partially to blame, along with the high costs imposed by the auction process used to allocate spectrum. The billions of dollars required for carrier network planning, build-out, and operations also don't help in addressing this challenge. But the good news is that more spectrum is becoming available, and new wide-area wireless technologies like Wave-2 WiMAX (based on MIMO) and LTE promise significantly higher throughput, improved reliability, and better coverage. So the idea of Web services as a foundation for mobile computing going forward isn't a crazy idea at all -- and I think it will become the norm over the next five years.

So, even with the restricted processing power, screen size, battery life and related limitations of mobile computers, such products can indeed support access to applications of all forms. The limitation isn't the device itself; rather, it's that it is simply infeasible -- indeed, impossible -- to carry all of the data one might need to run an enterprise app. There's no alternative: We must proceed with massive, global deployment of wireless broadband networks. And, don't forget, converged WWAN/Wi-Fi networks will make available a huge amount of additional spectrum and bandwidth, augmenting what the wide-area networks can do by themselves. The future thus couldn't be brighter for anyone needing anytime/anywhere access to enterprise apps and other IT resources.

So what should the key elements of your mobile computing plan be over the next five years? First, assume that Web services are the right model for the future and that a hybrid local/remote app strategy will serve you best in the interim. Assume greater availability, reliability and price/performance of wireless data networks, especially as competition in the 4G space builds next year and beyond. Assume greater diversity in mobile devices, but assume that all of these will sport both robust local execution environments and desktop-class browsers. Assume that vendors and developers of apps will seek to run on as many platforms as possible but that you'll need to choose wisely as to which devices to approve for use within your enterprise. And, yes, assume that the handheld will indeed replace the notebook computer in many cases. Looking just a few years into the future, it's easy to see how handhelds and MIDs will be doing it all.

About the author: Craig Mathias is a principal with Farpoint Group, an advisory firm, based in Ashland, Mass., specializing in wireless networking and mobile computing. The firm works with manufacturers, enterprises, carriers, government, and the financial community on all aspects of wireless and mobile. Mathias can be reached at

This was first published in July 2008

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: