Network and Telecom Strategies Blog

Maximizing ROI for mobile applications - part 1

Posted by: Paul DeBeasi

Introduction

Thousands of ingenious, and sometimes frivolous, Apple iPhone applications have inspired developers to imagine new enterprise mobile applications. Inspiration is nice. But in this challenging economic environment, enterprises need to ask themselves how deployment of mobile applications will solve practical business problems and how they can maximize the return on investment (ROI) when developing mobile applications.

This post begins a three part series on maximizing ROI for mobile applications. Part 1 explains why mobile application development is so difficult and introduces three common deployment approaches. Part 2 will discuss the challenges and benefits of each approach. Finally, Part 3 will provide specific tips to help enterprises maximize mobile application ROI.

Mobile application deployment challenges

The worn out cliché that we live in a mobile world is nonetheless true. The executive road warrior, multitasking medical doctor, and airport hopping sales executive need continuous access to information. Whereas mobile workers once hoped for ubiquitous information access, they now demand it.

Unfortunately, satisfying these user demands is quite challenging. Mobile workers often need access to applications that require access to diverse back-end database systems and servers. Mobile cellular services have different throughput and latency performance characteristics that vary as the worker roams from place to place. Mobile device security and management capabilities are oftentimes insufficient to satisfy enterprise security policies. And finally, mobile device processors, form factors, graphical interfaces, operating systems, and development environments vary widely.

Thin client

There are three broadly defined approaches that enterprises commonly use to develop mobile applications. The most straightforward is the thin client approach. The thin client uses a mobile browser to access a server-resident enterprise application. The application relies upon the server’s hardware and software resources (CPU, memory, and operating system etc.). The mobile phone browser simply provides an interface to the application. The thin client requires a continuously active network connection in order to operate.

A related approach is to use a rich Internet application (RIA) framework on the mobile phone such as Java FX, Flash, mobile AJAX or Silverlight. Such frameworks provide an environment on the mobile phone within which developers can deploy more sophisticated applications. This approach blurs the distinction between a simple thin client application and a full-featured thick client application.

Thick client

The thick client approach is built upon full-featured, smartphone-resident software. The application relies upon the hardware and software resources of the mobile phone. The look and feel of the application is highly dependent upon the mobile device software development kit (SDK). The client uses the network to communicate with remotes servers and databases but it can function without a continuously active network connection using locally stored information. The enterpris must develop server side software that interacts with the smartphone resident thick client.

Enterprises develop thick client applications by using the development environment provided by mobile device manufacturers such as the RIM BlackBerry MDS, the Nokia Symbian OS, and the Apple SDK or by using mobile operating system vendors such as the Microsoft .NET CF for Windows Mobile.

Mobile middleware

The mobile middleware approach uses an abstraction layer that sits between the native mobile phone hardware/software and the enterprise application. Developers write their application using middleware application programming interfaces (APIs) instead of the native smartphone APIs. This approach improves application portability because the middleware APIs support a broad set of mobile hardware and software environments. The middleware also provides support for diverse back-end servers, databases, and communication systems.

Many of these mobile middleware solutions from companies such as Sybase iAnywhere, Dexterra, and Antenna software provide more than just an abstraction layer. They can also provide cross-platform security and device management features and may also package their own mobile applications (e.g., mobile email and instant messaging).

Next time

This post introduced three common approaches to mobile phone development. Each of the three approaches has their challenges and benefits. Part 2 of this series will analyze the challenges and benefits of each approach.

Remote Access During A Pandemic?

Posted by: Eric Siegel

(Edited Oct 18, 2009, with probably more edits in the future!)

It's late at night; it's a good time for worrying.

Current worry: pandemics. Swine (H1N1) Flu.

What happens if there's a pandemic, and your staff has to work from home?

First, see the U.S. Government website: http://www.pandemicflu.gov

But second, how are we going to handle the communications problem? If your staff is going to work from home, using their consumer-grade Internet connections (DSL, cable), they may be in for a bad surprise. I worry that everybody is going to have that same idea, and your staff will have to compete for the access paths with millions of people downloading movies and music and YouTube and Facebook. Remember, the first groups of people who will be sent home will almost certainly be schoolchildren, and I'd guess that they'll be heavy users of high-bandwidth applications.

Unless the government or the service providers insist on traffic restrictions; for example, bandwidth-limiting YouTube at the YouTube servers (which might interfere with videos that are important for flu sufferers) or bandwidth-limiting peer-to-peer file sharing, I'm guessing that a lot of oversubscribed consumer-grade Internet access will be a congested mess. A lot of kids (and adults) doing a lot of video-watching and file sharing during the day, combined with a lot of working-from-home parents, may overload the access networks. And it will be a really tempting time for criminals to launch DDoS attacks; service provider staffs will be thin and will be overstretched.

Indeed, a U.S. Department of Homeland Security study published in December 2007 ("Pandemic Influenza Impact on Communications Networks Study") using a pandemic model based on Chicago and a telecommuting exercise by the Federal Reserve Board showed that "In the 40 percent absenteeism pandemic scenario, the telecommuting strategy is expected to be significantly impacted for most telecommuters during the peak of the pandemic," and "In the high absenteeism [90 percent; e.g., local quarantine] scenario, the telecommuting strategy is expected to be unusable for the majority of telecommuters during the peak of the pandemic."

So what should we do?

One option is clearly to have business-class dedicated lines or business-class VSAT to some selected members of the staff.

Another option would be plain old dial-up modem service. It won't work for the beginning of a crisis; there will be too much use of cellular and land telephone lines. But after that, I'd guess that the public switched telephone network will be more stable and less congested and more available than any consumer-grade Internet access. Just dust off those old modem racks in your basement, and be sure you have connectivity. And be sure your users have a modem at home or built in to their laptops. "Application remoting" (e.g., Citrix XenApp or Microsoft Terminal Services) can help provide good performance over dial-up modem links; the new software WAN optimization products (e.g., from Blue Coat, Cisco, Citrix, Expand, Riverbed, Stampede) can also help.

And I have more worries: will your server room's Internet access, firewalls, and VPN equipment have enough capacity to handle all of those incoming Internet and POTS remote users?

That's assuming that you have your server rooms functioning, with some staff available to handle all of the dial-in users and their service desk problems! But that's a different question, for another night's worry. I'll do some more digging on this topic and post more blog entries. And, of course, I'd love your comments!

Final Catalyst WAN Performance Optimization Notes

Posted by: Eric Siegel

OK, two final notes on WAN Performance Optimization from the Catalyst Conference.

(By the way, I'll be rewriting my 90-page, hyper-boring paper "Optimizing WAN Performance" starting in a week or so; it should be published in a couple of months. Ask me if you need a draft copy sooner than that. And post a reply to this blog entry if you have any suggestions for me or for anyone about WAN performance optimization!)

FIRST, be sure to test using realistic user scenarios. Don't just rely on vendor promises or magazine articles or your buddy's experiences or some simple "drag and drop across the Windows desktop" copies! I've been saying this for years, but it really bears repetition.

The classical example is assuming that all vendors handle Microsoft's remote file access protocol, CIFS (or its latest Vista version, SMB 2.0) in the same way. They don't. And there's a difference between string-based compression (e.g., Riverbed) and Wide Area File Services (WAFS)-based compression (e.g., Cisco WAAS and Expand Networks). If you just do a sequential copy (e.g., drag-and-drop across the Windows desktop from a remote file share to your local disk), all of the CIFS systems look good. BUT if you open a file from INSIDE Microsoft Word, Excel, or some other application (is that what your users do?), then you'll see major differences. An application doesn't usually do only sequential reads and writes; it'll do "random" reads and writes within the file, and it'll create temporary files. So the intelligence of the WAN performance optimization solution becomes relevant: it can greatly improve performance when using remote file shares, possibly using the inherent caching ability of CIFS (i.e., the "oplock" capabilities), but it'll also be more complex and vulnerable to possible failure if the programming is sloppy.

SECOND, don't underestimate the impact of Web caching. Even major vendors, such as Microsoft, don't set their cache tags for performance. You can make simply astounding improvements in performance by setting Web cache tags appropriately, and your application front end (AFE) or load balancer can even do that for you. Be sure to include an "Expires" header, or most caches will not cache your pages, or they'll have to check back with the server to check the expiration status of every single object (unless you're using a specialized Web accelerator). See my Burton Group paper "Optimizing WAN Performance" and http://www.mnot.net/cacheability/, http://www.squid-cache.org/, http://www.web-caching.com/, and http://webmaster.info.aol.com/caching.html for more information. (Also look at http://developer.yahoo.com/performance/rules.html, which Nick Fiekowsky recommends, for more caching hints and general performance suggestions for the Web.)