Google's Smartphone Management Drops Another Big Barrier To "Apps" Adoption
Google has removed what for many CIOs and IT professionals has been one of the last remaining hurdles to their adoption of Google Apps for business documents, spreadsheets, presentations and probably most importantly: email. Yesterday, the biggest of the cloud-based challengers to Microsoft and IBM-Lotus announced it now has a range of Blackberry-esque mobile device management features (including the ability to remotely wipe a smartphone) for iPhones as well as Windows Mobile and Nokia-based dev
Google has removed what for many CIOs and IT professionals has been one of the last remaining hurdles to their adoption of Google Apps for business documents, spreadsheets, presentations and probably most importantly: email. Yesterday, the biggest of the cloud-based challengers to Microsoft and IBM-Lotus announced it now has a range of Blackberry-esque mobile device management features (including the ability to remotely wipe a smartphone) for iPhones as well as Windows Mobile and Nokia-based devices.According to a post on one of Google's official blogs, the new mobile management features will be available to organizations using the Premier or Educational editions of Google Apps and are as follows:
Remotely wipe all data from lost or stolen mobile devices
Lock idle devices after a period of inactivity
Require a device password on each phone
Set minimum lengths for more secure passwords
Require passwords to include letters, numbers and punctuation
InformationWeek has prepared a short image gallery that demonstrates how these features bubble up into Google's Apps administrative interface.
During a telephone interview regarding the announcement, Google Apps Product Management Director Raju Gulabani stressed to InformationWeek the degree to which this promotes the sort of choice that frees organizations from having to standardize on one type of handset in order to also benefit from BlackBerry-like centralized management features like being able to "remotely wipe all data from lost or stolen mobile devices."
While the addition of the mobile management utilities to Google Apps means that end-users of Google Apps may now be able to use their favorite handset instead of a company issued standard one, Google Apps isn't unique in this aspect. Microsoft Exchange shops have the same flexibility at their disposal. In fact, it is through the same Microsoft-built software -- a technology Microsoft calls Exchange ActiveSync (EAS) -- that Google is able to remotely manage iPhones, Nokia's smartphones, and Windows Mobile smartphones. Those happen to be the same smartphones that Microsoft's Exchange ActiveSync already comes on.
Gulabani said that the reason that Google doesn't have to install any software locally on the handsets is that ActiveSync already has all the management hooks that are necessary to accomplish the five aforementioned features. According to Gulabani, Google gets to take advantage of the fact that Apple and Nokia are licensees of ActiveSync. While this explains how Google is able to open such management functionality to three additional smartphone platforms (enterprises that already connect BlackBerries to Google Apps through RIM's BlackBerry Enterprise Server have the same functionality), it also explains why the new management functionality is limited to those three platforms. For example, Android remains an "unmanaged" platform with respect to this announcement (more below).
How Google Whittles Away At Microsoft's Walled Garden
Over the years, Google has left few stones unturned in smoothing out the migration path from Microsoft's Exchange Server to its cloud-based Google Apps. Early on in Google Apps' history, the company rolled out a turnkey weapon that neither Microsoft nor Lotus made available when the two were in an email server death match with each other back in the 1990s.
But for many organizations, migrating to Google Apps let alone browser-based email wouldn't cut it. Say what you want about Microsoft's email client Outlook. The truth was that as radically different (and perhaps more efficient) as Google App's browser-based user experience was, there was a certain very large class of business users that wasn't about to sacrifice the creature comforts of Microsoft Outlook any time soon. Comforts like off-line access to drag and droppable folders. Outlook could be connected to Google Apps, but not in a way that users would detect a serious loss in functionality.
Eventually, through a plug-in technology called Gears, Google addressed the offline problem. But the technology only supported users accessing Google Apps through their browsers and for many, Google's still-revolutionary user interface (see Ode To Gmail's Conversations) for email was too much of a departure for Outlook users. Google would have to do more which is exactly what it did when it added the second of a one-two punch. Whereas migrating Exchange Server to Google Apps represented the first punch, Google followed up in June of 2009 with an Outlook plug-in (Google Apps Synch For Outlook) that, for email, contact management, and group calendaring (eg: looking up free and busy times), essentially made Google Apps appear to Outlook as though it were an Exchange Server.
Prior to the availability of Google Apps Synch For Outlook, the closest that brave-hearted IT pros could come to mimicking an Outlook-Exchange Server connection was through the combination of (1) a technology called Google Calendar Sync and (2) the standard but antiquated IMAP email replication protocol that for many reasons didn't work well for Outlook when connecting to Google Apps (see Why Outlook Isn't The Best IMAP Client For Gmail).
But to do it right, Google would somehow have to mimick the fashion in which Exchange Server exchanges email, calendar, and contact information with Outlook: a non-standard technology known as "MAPI/RPC" (a.k.a. "Outlook Exchange Transport Protocol") that under the hood has helped to keep Microsoft customers relatively locked-in. Microsoft eventually opened up the protocols for access by third parties but the idea was probably more to enable third party application and non-Windows-based access to Exchange Server rather than for someone like Google to build a substitute that looked, felt, and smelled like an Exchange Server to MAPI/RPC clients like Outlook.
Along the way, Google has removed other barriers as well. Another reason CIOs were reluctant to sign off on going with Google Apps for email was the lack of high-end integration with BlackBerries. BlackBerries are still the most prevalent smartphone for business users and through Research In Motion's BlackBerry Enterprise Server (BES), IT shops could easily (if not expensively) deliver mobile mail in a very centrally managed fashion. Unfortunately, BES didn't integrate with Google Apps as well as it did with with Microsoft Exchange or Lotus Notes. With IT management and corporate executives usually being among the first to grow addicted to their "crackberries," that lack of integration was also a major barrier to even considering Google Apps.
Then, in May 2009, Google obliterated that barrier as well by facilitating the connection of BES to Google Apps. Looking at how Google Apps can now remotely manage iPhones, Nokia, and Windows Mobile smartphones without the need for anything like a BES, I asked Gulabani if Google has any plans to eliminate the need for BESes altogether. In other words, will there come a day where Google reverse engineers what a BES does and build that into Google Apps, thereby avoiding the expense of having a BES in the first place (and they are expensive). Chuckling, Gulabani didn't hesitate to say "no" which means that for the foreseeable future, integrating BlackBerries with Google Apps will involve a BES "tax" that doesn't exist with the three other supported smartphone platforms. Gulabani mentioned that there are now third-party BES hosting services that might be more cost effective if owning your own BES isn't your cup of tea.
Currently, the ability to remotely manage iPhones doesn't appear to extend to either of Apple's other two devices that are primarily based on the same operating system: the newly released iPad and the iPod Touch.
No Android! What gives?
About the only question yesterday's announcement leaves one asking is "What about Android?" It would seem that with the tidal wave of last month's Android news that surely, Android would be one of the platforms included in yesterday's announcement. But bear in mind that yesterday's announcement was limited to platforms that already include Microsoft's ActiveSync technology. Android doesn't include ActiveSync which means that Google must either license ActiveSync for inclusion in Android or build its own ActiveSync-like technology that businesses can require Android-based end-users to install. When pressed for details, Gulabani would only say "As you know, Android started out in the consumer space and today is a consumer device. But we are working to enable the same kind of policies as well on Android. So stay tuned."
David Berlind is the chief content officer of TechWeb and editor-in-chief of TechWeb.com. David likes to write about emerging tech, new and social media, mobile tech, and things that go wrong and welcomes comments, both for and against anything he writes. He can be reached at email@example.com and you also can find him on Twitter and other social networks (see the list below). David doesn't own any tech stocks. But, if he did, he'd probably buy some Salesforce.com and Amazon, given his belief in the principles of cloud computing.
Google in the Enterprise SurveyThere's no doubt Google has made headway into businesses: Just 28 percent discourage or ban use of its productivity products, and 69 percent cite Google Apps' good or excellent mobility. But progress could still stall: 59 percent of nonusers distrust the security of Google's cloud. Its data privacy is an open question, and 37 percent worry about integration.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.