Mobile Virtual Platforms – Possible sea change

(PingBack to original post on buzzfreezone.wordpress.com: http://wp.me/p1bJuJ-3b)

There have been a few recent developments that have individually generated an aggregate reaction somewhat equivalent to “Meh” (although the specialty markets and analysts have been abuzz). However, taken together, I think they can form the platform basis for a Sea Change in mobile platforms. Of course, a lot of this is based on hypothesis and doesn’t take into account industry trends related to brands, and market focus. But I think there is great opportunity here for players in the mobile space to leverage these technologies and offer a killer product. I’ll explain.

First, what “recent developments”?

1) VMWare to bring Virtualization to Mobile Phones (http://www.vmware.com/company/news/releases/mvp.html)

2) Multi-Core mobile processors (Toshiba Tegra 2, Dual Core SnapDragon, etc.)

While VWMARE lists several value scenarios for implementing and using mobile hypervisors, which are all valuable, I am interested primarily in the “Multiple Profile” scenario, except, I think it needs to go a step further. Here is what I mean:

I have mentioned before that end point convergence is real (most recently in my iPad blog post here) and organizations and government agency CIOs need to figure out how to accommodate end point convergence in their enterprise, balancing security and control over corporate use and data, against the ease, flexibility and personal use of end point devices. The mobile devices of the future are actually mini computers, and every major manufacturer is seeking to maximize returns by designing and selling the “killer device”, one that can excel at both enterprise affinity (security, encryption, policy compliance, Exchange/Domino Support, Enterprise Apps, VPN, Remote wipe, strong passwords, etc.) and personal mobility (movies, music, photos, maps, browsing, social media, location services, personal apps, games etc.).

Handset manufacturers, especially Blackberry and Apple have actually come a long way towards this goal, with the latest iPhone hardware and OS at “implementation under testing” stage for FIPS 140-2 certification with several enterprise management improvements in iOS4.2, and Blackberry getting better in the consumer space with OS 6, Blackberry App world, and new handsets like the Torch with a focus on Social Media.

However, organizations are still concerned about the implications of end point convergence. I have seen CIO shops to have several lingering questions, and compromises are typically made around them:

1) Should we let employees hook their personal unmanaged smart phones into the enterprise network? What is the risk? How can it be managed?

2) Should employees be allowed to download games and music onto company provided smart phones/tablets? What are the risks? How can they be managed? (see recent NPR story here)

3) Should we be able to monitor employee activities on company supplied smart phones? (IM, SMS, Email, browsing history, GPS locations?)

4) Should we be able to monitor employee activities on personal smart phones that are hooked into the corporate network? (IM, SMS, Email, browsing history, GPS locations?)

5) What about data retention/archival?

6) What if someone downloads illegal music/porn/does other bad stuff?

etc.

This is where my hypervisor/virtualization approach comes in. Except it is different from the virtualization architecture on desktop/server platforms.

A traditional desktop/server platform virtualization architecture looks like this:

This is a well established architecture for the server/desktop platforms.

So how can mobile virtualization lend towards solving the end point convergence issue? Simple. I think there is an opportunity to leverage mobile virtualization to sandbox the corporate virtual stack (VS) from the “personal stack”. In theory, it should be possible for an enterprise/agency to:

1) Develop a virtual software stack (VS) that includes apps, configuration, access layer, corporate data (offline cache of corporate data in the cloud/repository).

2) Deploy this corporate VS on top of a standardized mobile hypervisor using common APIs/Services.

3) Corporate VS to co-exist with the out of the box/personal stack that includes the individual’s personal data/music/pics/feeds/apps, etc.

4) Set a virtual firewall between VS’s so apps cannot directly access data/resources across the stacks

5) Allow policy based ability to set app and VS permissions (can GPS data be returned to a corporate VS app? Can a corporate certificate be accessed by a person app? etc.).

6) Encrypt the entire corporate VS on the phone with FIPS 140-2 compliance,

7) Provide a remote “kill switch” within the hypervisor layer to remote wipe or lock the corporate VS, without affecting the individual’s personal stack,

8 ) Connect the encryption key to a corporate common ID/CAC/RSA token type of solutions that can be revoked remotely as needed.

There are also some key differences that will require some invention in this space. Some of which include:

1) The “Hypervisor Administrative Interface” is typically an on-board software toolset (Such VSphere Server Administrator console, or VMWARE Fusion on the Mac, etc. However, mobile end points are successful in a “Just Works” type of an environment. End users should not have to worry about which VM to kick off or restart, which one should be accessed when, and how to change resource access settings, etc. In theory, the “Hypervisor Administrative interface” should be a remote service for mobile platforms, similar in design to how the BES and Exchange Active Sync Administrator work. A centralized administrator in the Corporate mobile/NOC should be able to remotely push the corporate stack, manage it, trouble shoot it, etc. without on-device intervention by the user. Of course, this requires ubiquitous connectivity or device tethering to an iTunes or BlackBerry desktop client type of interface.

2) Mobile platforms are all about UI. Again, this goes back to the “Just Works” model. If this virtualization approach leads to different, fragmented UIs, and inevitably, with ugly, outdated corporate UIs, it will erode the usability and adoption of mobile platforms. If the user has to shut off their music playback to kick off a series of steps, enter a password, shutdown/start services to access the corporate stack, which looks/feels/acts ugly and frustrating, to access an app to perform a transaction and then all the way back again, it would be extremely frustrating. Moreover, cross device services like badges, notifications, alerts would not work unless you are “logged into” the corporate stack, again, taking away from usability. The solution then is to invent the ability for the corporate stack to “hook into” a Common UI layer for the mobile platform. The end user experience should be seamless (they hooked me up and all these new apps magically appeared that give me access to my corporate stuff). I think this is important for true and convergence.

The mobile virtual architecture will then look something like one of the following two approaches:

Option 1: Deep Hypervisor

Strengths:

1) No need to define an industry wide Hypervisor API standard

2) Can leverage existing UI and OS hooks in most OSes allowing inter-stack messaging

3) OS “awareness” of hypervisor minimal resulting in little development effort from existing platforms

Weaknesses:

1) System stability and security weaknesses due to distributed control over underlying resources

2) Potential performance challenges since there is no centralized dispatching and throttling

3) Requires multiple versions of the hypervisor, one for each platform, resulting in potential fragmentation and dilution of effort towards the platform

4) Requires very deep hooks into the hardware/software platform to install/manage.

Option 2: Higher level Hypervisor

Strengths:

1) Platform stability – Resources managed and dispatched by OS kernel

2) High level hypervisor resulting in easier development/extensions

3) Standards based hypervisor usable across platforms

4) As long as platform OS supports common API, hypervisor can be installed as a high level service, without requiring deep hooks.

Weaknesses:

1) Requires an industry accepted open standard for hypervisor API – Never easy

2) Requires platform OS to be hypervisor “aware” and implement the hypervisor API

3) Potential performance impact due to higher level software hypervisor

Ultimately, in either design, this concept would require device and platform manufacturers to open up their kimonos far wider than thay are currently used to. Standard Android based platforms may be easier to implement than the blackberry and iOS platforms.

Of course, there is always the third option of have a very high level hypervisor which effectively runs as an app on top of the OS API, and enables the corporate stack on top of itself, but I don’t think that would ever be a solid, high performance, acceptable platform due to its inability to deliver core enterprise functionality, encryption, policy and user experience. Besides, it would never have great performance.

I think we are at the very early stages of this strategy, but I think there will be great momentum over the next year to explore these options. I think we will use the first commercially available solution in the next 6-12 months, and a multi-platform standard set of multi-vendor offerings in 2012.

And yes… I know there are a LOT of rough edges here and smarter people than myself can tear this whole theory apart in about 10 seconds. However, I also think that these issues can be resolved with some thoughts and clever design.

Ideas? Thoughts? Better way of doing this? Please share