Google will start letting Apps administrators delay the delivery of upgrades to their domains to give them a chance to prepare themselves and their users for interface or functionality changes.
Until now, Google has transparently pushed out enhancements to its Apps suite on a rolling basis as soon as they’re tested and deemed ready for prime time, just like it does for its consumer applications and sites.
However, some Apps administrators, especially those in large enterprises, said they would like to get both a heads-up on upcoming changes and also a time buffer before the upgrades go live on their domains.
Thus, Apps administrators will now have the option of the “Scheduled Release” track for upgrades, which consolidates enhancements into a weekly or bi-weekly pack and slates them to go live on those domains with a delay of one of two weeks.
“This is a new release process for Google Apps that caters to the needs of our enterprise customers,” said Rajen Sheth, Group Product Manager, Google Enterprise.
Along with the launch of the “Scheduled Release” track, Google is debuting a portal devoted to Apps upgrades and enhancements and designed to keep administrators better informed about this topic through resources like end user training material.
Apps is a fully Web-hosted collaboration and communication suite that includes e-mail, calendar, office productivity, instant messaging, intranet-building and other applications for workplace use. As such, Apps administrators have little to no control over the software, especially as it relates to how the applications are maintained and enhanced, a process handled by Google. For example, in 2010 Google pushed out 130 upgrade releases for Google Apps.
While having vendors host, maintain, patch and upgrade applications is a big draw of cloud-based software like Apps, it also has the downside of removing control from IT departments over these software release cycles.
Thus, some Apps administrators, especially in large to mid-size enterprises that have an IT department supporting end users, have told Google that they want more predictability around Apps releases, because even small changes can have a dramatic effect on their domains, Sheth said.
For example, an interface change could trigger a wave of help desk calls from confused end users that support staffers may not immediately know how to address because they may not have seen the upgraded features themselves.
“They want to know when upgrades are happening, what’s going into them, more advanced notice and better information for themselves and for their users about the new features,” Sheth said. “So we want to give people more visibility into this.”
Industry analyst Rebecca Wettemann calls this new “Scheduled Release” track a good idea. “It shows Google is working to make their apps more digestible for enterprise organizations,” she said via e-mail.
Enterprises often want to plan upgrades around training and other projects and initiatives or pilot the application for a small group before releasing an application to the broader population, she said.
“This should help IT managers take advantage of Google innovations on their own schedule to deliver the least disruption and most benefit to end users,” Wettemann said. “On the implementation side, we’ll be looking for feedback from administrators — and also looking for Google to further its efforts to show they’re investing in enterprise-class applications as well as the services and vendor support enterprise customers expect.”
Apps customers will be placed by default on this new “Scheduled Release” track, except for those which had previously opted to receive “Pre-Release features” in their domains. Those customers will remain on the existing “Rapid Release” track, in which changes are pushed out to their domains the moment they’re ready and without advance notice.
Even if they hadn’t signed up for “Pre-Release features,” Apps administrators will be able to switch from “Scheduled Release” to “Rapid Release” if they choose to.
The enhancements covered by the “Scheduled Release” track are those that are visible to end users, such as interface or functionality tweaks, but not back-end upgrades or security or bug patches and fixes, which will always be turned on as soon as they’re ready for everyone.