Google Apps

The University of California at Berkeley is slowly rolling out Google Apps as a replacement for the medley of campus-wide services originally available (internally managed email, Oracle calendaring, Microsoft SharePoint, etc.).  We migrated Cal Performances over to the Calendars maybe six months ago, and email (as well as everything else) more recently.

The University has chosen a limited subset of tools to deploy, consistent with what they think is appropriate for mission and what they have the resources to support internally: this has been a bit of a conversation with our shared services group, so while Google+ (and most immediately interesting to us, Hangouts) are not part of the project we have secured the ability to use Google Analytics and the Webmaster tools.

It's been and continues to be a big transition for the University.  One of the primary concerns of the model was outsourcing data security to a third party, rather than keeping it all in house, where we can claim full accountability for it, should there be any breaches, but also so that law enforcement requests for our data would have to go through our lawyers first.  The compromise was that Google has been able to assure us that for all their virtualization, UCB data will never be stored in datacenters outside of the US.

A couple of cautions:  Google's ability to spin off separate "business units" for their apps is remarkably poor.  They have virtually no complex administration tool, no way to farm out administration permissions in any kind of hierarchical way, and no solid concepts of access grouping outside of their traditional flat consumer model.

Whereas traditionally at Cal Performances we managed an email subdomain split off for us by shared services with convenient web tools that they provided, and maintained our own _domain_ base of email addresses, (@cpsma.berkeley.edu, vs. @berkeley.edu) with Google we've had to fold all email accounts for individual users on the campus into a single account (@berkeley.edu) and then create aliased addresses for our subdomains.  Moreover, our original domain aliasing system (which was simple, we had a rather large number of subdomain aliases which all resolved to our base @cpsma.berkeley.edu domain, including of course @calperformances.org) we have to allocate these aliases basically on a user by user and alias by alias basis, which is quite a nuisance.  The mapping between these accounts and what appears in the auto-fill-in when choosing users to email or invite or share with is confusing for our end users, and an occasional annoyance for even our technical users.  This is exacerbated in our case because the default contact list now spans the entire university, and @berkeley.edu addresses tend to show up before @calperformances.org address listings.

On top of the lack of control that our organization has now over our subdomain, a system that used to work brilliantly, "departmental accounts", is now rather clumsy.  Departmental Accounts allowed you to have an account that was not connected to a specific user, but was a shared purpose account, typically for communicating with outside entities on an "official channel", for instance our Box Office through ticketoffice@calperformances.org.  All managers and relevant staff could be given authorization to log in to that account using their own single sign-on, which then gave them access to the email and the ability to respond through the account, and that access could be quickly given or revoked through administration tools.  Now we're more or less back to a system of password sharing for those accounts.

And lists and user account provisioning continue to be handled through the old email system.

On the positive side, Drive and Calendars are rather more easy to use than the prior shared applications, and by virtue of having a separate organization outside of regular "consumer" Google you can run certain apps like Drive in separate browser tabs without having to choose one specific address to tie them to, which you do if you just have multiple "consumer" accounts.  Mobile device integration is also a lot easier, although I think Blackberries are now completely out of the question.

--Gawain

Hi Gawain,

Thanks so much for sharing your experiences of the migration to Google Apps - I'm particularly interested in what you say about the shared mailboxes - we currently have a shared mailbox for our Box Office and Customer Service team, boxoffice@glyndebourne.com. We understand that the solution to this will be to use Google Groups where we can channel all emails from this address & grant our Box Office team access to all mail received by this email address, assigning individuals to certain emails if necessary. Are the difficulties you outlined using Google Groups?

Thanks
Caspian 

Hi Caspian,

I'm not sure about how well Google Groups might work for that, as that was not part of our application pool at UCB.  The primary benefits of the old "departmental accounts" system was that you had one face for the department or customer service purpose (i.e. the customer emails and receives email from "Ticket Office"/ticketoffice@calperformances.org, regardless of who they actually talk to), the email records all stay in one place and are reviewable by all users and the account is permanent, living outside of any particular employee's account structures.  Beyond that the administration was perfect: users didn't need new login information (with our Gmail implementation a key must be shared out), we could simply authorize and deauthorize any user on our system whenever appropriate.  I haven't had enough time to really sit down and go through the ramifications and the impact on our users, but it's certainly made things a little less efficient.

--Gawain

Hi Caspian,

I'm not sure about how well Google Groups might work for that, as that was not part of our application pool at UCB.  The primary benefits of the old "departmental accounts" system was that you had one face for the department or customer service purpose (i.e. the customer emails and receives email from "Ticket Office"/ticketoffice@calperformances.org, regardless of who they actually talk to), the email records all stay in one place and are reviewable by all users and the account is permanent, living outside of any particular employee's account structures.  Beyond that the administration was perfect: users didn't need new login information (with our Gmail implementation a key must be shared out), we could simply authorize and deauthorize any user on our system whenever appropriate.  I haven't had enough time to really sit down and go through the ramifications and the impact on our users, but it's certainly made things a little less efficient.

--Gawain

P.S. If you decide Google Groups works out brilliantly for you, be sure to let me know.  There may be some ability in the future to appeal for an expansion of services.  One immediate concern that comes to mind, however, is that I believe that Google Groups does not allow any kind of file attachment.