Why ShrinkRay?

In the last post, How to Mobilise? (Aka: Why ShrinkRay?), I suggested enterprise mobilisation questions that decision makers should consider:

1. How to reap the benefits and avoid the pitfalls that come back to haunt when salary review season kicks off?
2. In which cases should I be developing applications to run on mobile platforms versus creating web applications that can be accessed from the mobile browser? (For clarity:  A mobile application is one which is compiled and deployed to run on a mobile handset.  A mobile web application is NOT deployed to the mobile handset.  Mobile web applications are served from a web server and displayed on the mobile device browser, just like a web application on a PC is presented on Internet Explorer, Firefox, Safari, etc.)
3. What tools and approaches should I be using?

In earlier posts, starting with The Mobile Channel, I addressed some key strategic considerations.  The concluding Mobile Channel (Part 4) post provided this summary:

Companies should urgently establish a mobile channel.  This should be part of a broader, urgent strategic action plan to radically escalate customer experience management capabilities across all contact channels and mechanisms. 

Among the recommendations, deliverables and actions:

1.  Optimise agility across all current and new channels to maximise likelihood of engaging the customer in the channels and places they choose.

2. Avoid the creation of new organizational and technology stovepipes to implement channels and to manage and measure across all channels.  This will lead to unsustainable costs, unresponsive services and excessive delivery intervals for crucial capabilities.  Companies should streamline and align technology and organizations to maximise the customer's ability to control their contact channel choices in real-time.

3.  "The customer, not the channel, must become the point of integration for marketing programs and spend decisions."  Align the marketing organization around the customer as much as possible, rather than following past practices of aligning marketing organizations against channels and thereby indirectly to specific customer groups.

4. Implement real-time measurement and analytics processes to adjust and manipulate the channel mix and capabilities in response to detailed knowledge of customer behaviour on each and every interaction.

Ok, great!  Pretty lofty goals!  How to get this rolling without breaking the bank?  How to do something affordable but with real, long-term strategic value?  

Remember, there are really only two main options: 

1. Build a mobile application and deploy it to each mobile phone you want it to run on.

2. Build a web application and access it from the mobile browser.

If you look across the marketplace, there's a fair tilt towards constructing mobile applications compared to delivering mobile web applications.  A great many people don't look too much further, particularly since most executives have attempted to browse the web on their Blackberry and experienced, first-hand, the challenges in web application delivery to mobile browsers. 

Web pages were not designed to run on mobile networks or for small mobile phone screens.  Even the best modern 3G mobile connection is slower, more error-prone and has higher latency than fixed broadband networks. The pages take too long to load on a mobile phone browser, if they load at all. They don't fit on the screen.  Users can't find the functions they want.   And mobile devices are not as fast or as capable as a PC.  Mobile browsers vary wildly in their support for all the stuff that makes PC browsers run so smoothly.  The state-of-the-art iPhone doesn't support Flash, and frequently doesn't process javascript on advanced web2.0 sites.  Windows Mobile, RIM and other leading platforms all have their own set of issues.  All quite different.

In the picture below, I've added the rocket-propelled car to symbolise the rocket-speed broadband corporate network and a nimble ATV to symbolise the equally sophisticated but wildly different attributes of wireless networks web.  Web application traffic must traverse both types of networks to get to the mobile browser, and this will clearly be a problem if the web application was never designed with this requirement in mind!   It's quite understandable why web applications must be specifically tailored to mobile networks, just as much as the mobile device they are intended to run on.

It's pretty easy to see why mobile applications look like a good bet.  Developers are able to take full advantage of device capabilities to tailor the look and feel of the application.  Integration with on-device functions like the contact PIM, the camera or the GPS is easily done with the provided API's.  The amount of data exchanged with enterprise servers can be minimised.  The application can be designed to minimise reliance on anything that has to be sent from a server.   This approach is successful at providing a highly responsive solution that optimally presents the required functions.  The approach has been attractive to some:

• Advertisers doing big budget campaigns for major consumer brands.  
• Games and applications that require little external integration or communication.

The drawbacks of the approach are significant:

• A completely purpose-built user interface must be built and deployed for every variation of phone that needs to run the application.  Changes to the application must similarly be deployed every time there is a change to the application.  If the application must work for a large cross-section of consumers or business users on a large or uncontrolled range of mobile phones, the approach can be prohibitively costly.
• Integration work is required to connect the device to the enterprise.  If existing web services can be used, this is relatively simple.  If not, an enterprise integration project will be required to enable the mobile application.
• As new phones are introduced, the application must be ported at additional cost, and with a delay after the phone becomes available for development.
• The development and deployment infrastructure is a new technology stack.  All functionality developed and delivered using it will require a full suite of productization steps:  Full functional testing, failure-mode and performance testing.  All new functionality will require full regression testing, with full test coverage right back to the databases and business rules driving the application, wherever they reside.

At this point, it's a good idea to read backwards, and look at some of the key recommendations for enterprises implementing a mobile channel.  Building mobile applications from the ground up does not address many of these requirements.  The approach makes sense for applications which will have a large enough user-base to amortize the development and deployment cost on each selected mobile platform and also the extra costs of managing interactions that cross to other customer communication channels.  Otherwise, it's a fundamentally a bad choice, and it's no coincidence, you don't see a lot of enterprises building out enterprise mobile applications. 

Mobile application creation is costly and violates key channel management considerations for enterprises.  Existing web applications don't run well on mobile phone browsers.  The only other approach is creating new mobile-specific web applications.  And if you do the research, there are a number of technologies for building these.  However, they share the same problem that mobile applications have:  Building a new mobile-specific web application will require a new presentation technology stack, and this triggers the need for complete, parallel mobile-specific development cycles that must be coordinated with changes to the corresponding web applications.

This brings us to the reason ShrinkRay was conceived!  It solves the problem of creating mobile-specific web application presentations that perform extremely well on mobile networks.  It does so in a novel way that avoids the "new technology stack" problem and positions the enterprise to take full advantage of emerging mobile technologies.  In the next post, I'll explain how we overcome these issues and provide some great examples of ShrinkRay in action.

 I'll leave you with an update to the last picture.  This one shows ShrinkRay inserted to solve the problems involved in making web applications work on mobile phone browsers.  Note, with ShrinkRay, the rocket-propelled car is running all the way across the mobile network to the mobile browser! 

Dave

Dave Dingle

Co-Founder, BoomBoat Inc.