November 3, 2012: I wrote an update for this post.
I helped with a massive Google Apps deployment to over 30,000 users at my last job with Fortune 250 RR Donnelley. We were moving away from Lotus Notes, which I was happy to be rid of. However, in retrospect, Notes is a relative joy to manage compared to Google Apps. Although being “in the cloud” is trendy and provides your management with a cool golf course buzzword, supporting Google Apps in the enterprise is nightmarish and should not be taken lightly.
- Email and calendar syncs with multiple devices – Native apps for Android and Blackberry, and IMAP support for the iFolks. No need for Blackberry Enterprise Server. Coming from an environment where only upper level management got Blackberries, having my calendar and e-mail on my phone was a huge plus.
- Multiple editors – Google Docs lets you have multiple users in the same document editing simultaneously. This proved highly useful for many collaborative efforts.
- Education – Provides a low cost, easy way to provide email accounts and collaboration tools for a constantly changing set of users.
- User Deletion – When you delete a user, it’s 5 days before you can put that user back in. It was an accident? Too bad. That user is without their e-mail account for 5 days.
- Document Deletion – When a user is deleted, so are all their documents. Seriously. Every document they own is *poof* – gone.
- Management Delegation – There are no degrees of admin rights – you’re either an admin or you’re not. Although you can do some interesting thing with delegation using Google Organizations, many corporations have a centralized helpdesk. If you want any helpdesk worker to be able to help any employee, the helpdesk worker has to be a full blown administrator over the entire Google Apps domain. This is not a particularly palatable choice when you’re talking about hundreds of outsourced workers.
- Bandwidth – Your bandwidth costs are going up. WAY up. Using Lotus Notes, a file attachment sent within the company never left the WAN. With GMail, the sender has to upload the attachment to the Internet, and then each user who receives it has to download it over the Internet. Every time people check their email, it’s Internet bandwidth and not WAN bandwidth. That’s thousands of users generating Internet traffic that didn’t exist with Notes
- Constant Development – Google Apps is continuously changing, and changes are pushed to Production with no warning. Things break overnight and it irritates the hell out of your users, and drives up support costs for IT.
- No Logs – Logging is nonexistent. There’s no event viewer, no activity log, nothing. You have no idea who is doing what and no way to look it up
- Emergency support – You can’t get support without your support PIN, and you can’t get that without administrative access to your Google domain. The PIN changes periodically, so you can’t rely on having written it down. If you’re locked out of the domain, you’re stuck with filling out a form and waiting for e-mail support to get back to you.
- The apps – Using the apps feels a lot like using Office 1.0. They’re rough, good enough for the very basics but not really ready for primetime. Your accounting department would stage a revolt if you forced them to use Google Spreadsheets instead of Excel
- Enterprise Integration
- Passwords – You can use the Google Apps Directory Sync (GADS) tool to automate user provisioning up to Google Apps by syncing your existing LDAP infrastructure with Google. However, passwords are quite a challenge. If you have a way to extract the user’s password out of your LDAP directory, you can push that up to Google – but who wants Google to have a copy of the user’s corporate password? So you’re left with maintaining a separate Google password. Even if you implement Single Sign-On and authenticate users against your own LDAP server, that only applies to access via web browser. The separate Google password is still used for mobile device access.
- Single Sign-On – If you decide to go the SSO route, you have to have a secure way to store a user’s e-mail address within your directory structure. With SSO, no user credentials are sent to Google – instead, Google uses a certificate to ask your company’s SSO server to authenticate you. Your SSO server must send the user’s e-mail address back to Google. This directory attribute must be created and secured, otherwise anybody with access to that attribute can impersonate any user. Let me repeat that – *ANY* user in the organization with access to the “email” property in your directory system can use SSO to read *ANY* user’s e-mail. For many enterprises, this means an unacceptable number of non-privileged IT workers have the ability to read anybody’s e-mails. Google does not offer any kind of AD schema update like an Exchange installation would to create a properly secured set of properties for e-mail address, so you are forced to create the properties manually and come up with a set of ACLs to achieve the proper security. This can be extraordinarily tricky in a large enterprise.
While Google will try to sell you Google Apps as a simple solution, neither the implementation nor the ongoing maintenance are simple. The Google resources assigned to the implementation project were simply not up to the task of navigating the complex political and technical landmines of a Fortune 250 corporation. The resources weren’t necessarily at fault – it was Google’s fault for several reasons. The resources assigned were simply too junior with insufficient experience at the enterprise level. They also had no idea how to address many of the enterprise level problems we encountered because they had never had to deal with a corporation the size of RRD. We felt like we were flying by the seat of our pants with little to no direction from Google.
Google Apps a great choice for a small company and possibly for education, but it’s just not ready for the enterprise.