The Top 10 Reasons To Outsource Your Enterprise Email To Gmail Now

Last week, I wrote about how the recent Gmail outage actually draws attention to why Gmail is more worthy of enterprises than it has ever been. That opinion stands in contrast to a story my colleague Antone Gonsalves recently published (see "Google Takes Credibility Hit With Gmail Outage"). My response: If you are currently insourcing your e-mail and, at the very least, not considering that system's replacement with Gmail, I want some of what you're smoking.I said "considering."

For some organizations, Gmail simply will not do. But so long as those organizations are reaching that conclusion based on fact and not FUD (fear, uncertainty, and doubt), that's fine. For example, some organizations might be prevented by law from keeping their e-mail on systems that are publicly accessible through the Internet.

Unfortunately, it's incidents like this week's Gmail outage and the subsequent storm of rage in the press, blogs, and twittersphere that cause many decision makers to irresponsibly turn a blind eye to a solution that, in reality, is almost too good to be true. So, if you're one of those people who is willing to give Google a chance here, but you need to convince others, here is a top 10 list of reasons that should give any organization (and its CFO) pause for thought.

1. Your e-mail domain: Contrary to what many believe, when an organization embraces Gmail as its corporate e-mail solution, everyone in that organization gets to to keep their existing e-mail address. In other words, they don't have to accept a new address that's something like [email protected].

In order to keep your existing e-mail addresses, your organization must become a subscriber to Google Apps.

2. Who said "Ain't nuthin' for free"? There are two primary Google Apps offerings: Standard and Premier (Google also has special offerings for educational institutions, nonprofits, and ISPs). The Standard Edition (what I call GASE) is free. The Premier Edition (GAPE) costs $50 per user per year. Here is a chart that compares the two offerings.

Millions of businesses can make do with the free version. Yes, the free version comes with advertising, but the ads are relatively unobtrusive and living with them in exchange for getting a free service is worth the trade-off. Users of GASE get more than 7 GB of storage (25 GB for GAPE users). Providing that sort of e-mail storage to users (many of whom would kill to have it) is inconceivable to most organizations because of the time, effort, and gear required to keep such a storage infrastructure up, running, fault-tolerant, and backed up.

Even at $50 per user per year, most organizations will find that subscribing to Google Apps just for its e-mail and group calendaring compares favorably with the total cost of running any in-sourced solution (people, gear, software, add-ons for backup, mobility, etc.). Ask your CFO. What would s/he prefer (particularly in tough economic times where staffing levels are constantly in flux?)? An annual cost, some component of which must be written down and some of which may go to waste during downsizing cycles? Or subscription costs that hit the books differently (and more predictably) and that bypass the care and feeding associated with the people, gear, and software that are necessary to keep those in-sourced systems running?

3. "No way. You get that, too?" I'm hearing more and more about knowledge workers who, in lieu of the officially sanctioned Office Suite, use Google Docs (mainly word processing and spreadsheets, but sometimes presentations, too) to effectively collaborate on some document first. Once that document is complete, they must begrudgingly move it into the officially sanctioned legacy solution that requires local software to open the document and, in many cases, requires that the document be inefficiently passed around as an e-mail attachment (that constantly has to be stored locally, attached, and detached).

That was a round-about way of saying that for the same free price or $50 per user per year, you get an Office Suite, too -- one that will likely satisfy 99% of users 99% of the time. Never mind that those documents are accessible from almost anywhere and to almost any device because they're Web-based (see point #8).

To sweeten the deal, that Office Suite has collaboration so baked-in that there's no checking-out and checking-in of documents or additional infrastructure (servers, software, experts, etc.) that must be added to the equation to fudge collaboration. With Google Apps, when two or more people are looking at the same document at the same time, they can see the changes that everyone is making, in real time (you can also see who else is viewing and editing the document). Whenever people actually experience this for the first time, they usually have that "ah hah moment." It's sort of like "Where has this been my whole life?"

Traditional solution providers argue that they can match that functionality. But for the same $50 per user per year (or free) and for the same reduced headaches? I don't think so. But don't ask me. Ask your CFO.

4. Hands-free upgrades and patches: OK, I'm lying. I was going to write that neither you nor your users will have to lift a finger to take advantage of the lastest bug fix or new "release" of the service.

But the truth is that, effectively, you may end up lifting a finger. For example, if at 11:59, you're using the "old" version of Google Apps, and at 12:00, Google updates the Google Apps codebase, your browser will inherit that new codebase the next time you refresh the page (finger required) or Gmail's Ajax-based code does it for you (no finger required).

No downloads are necessary. No regression testing of patches to make sure they're not going to destabilize your desktops. No checking up on all your desktops to make sure they received and installed the latest patch. No reboots. No deskside visits. And this doesn't even take into account the patch/upgrade cycle for your e-mail servers.

In the bigger scheme of total cost of ownership, you probably don't have a dollar-value assigned to this "line-item" since, technically, it's a soft-dollar cost. It's hard to pinpoint the real cost. But given the comparative complexity and number of potential points where things can go wrong when upgrading desktops and servers, companies need to ask themselves whether the additional value they're sure they're getting by insourcing their e-mail systems is worth the headaches associated with maintaining them.

There's also a less-talked about but supremely groundbreaking side to this upgrade or patch-the-cloud point (and it's not just true of Gmail). We've all encountered buggy software. The dirty little secret, if you ask me, is that all software is really "beta" software. After all, what's the difference between some software's codebase on the day before it's "released to manufacturing" ("RTM'd") and the day after it's RTMed? Maybe fewer bugs. But no bugs? Now you know why, in reality, all software is beta and cloud-based services like Gmail are no different.

What is different from insourced, shrink-wrapped solutions like Exchange and Lotus Notes to outsourced cloud-based solutions like Gmail is the turnaround time when it comes to taking care of those bugs. In the insourced world, if you run into a critical bug with your software, you might pick up the Batphone and call your solution provider and ask them to fix it. That is, of course, if you have a technical support contract that gets you the red carpet treatment. Otherwise, you could be waiting for the next service pack before that bug gets eliminated.

In the case of Gmail (and I'm sure other cloud-based services, but I know this to be true of Gmail), Google has engineers that are monitoring the health of the application 24/7. Behind the scenes, Gmail traps the problems that are encountered by users and, depending on the criticality of the bug, a fix can be made (and pushed to the user base) within hours if need be. So, not only can bugs be dealt with by the solution provider in a matter of hours, applying the fix generally requires a click of the refresh button (and sometimes, not even that).

5. Great anti-spam at no additional cost: So bad is the spam problem that it has spawned an entire industry of solutions that companies must go out and buy (read: pay extra for) in order to have the industrial strength anti-spam police on your side.

Or, with Google Apps (and even standalone Gmail), you can get the industrial strength stuff for free (it's also included in the $50 per user per month package). Part of an anti-spam system's effectiveness lies in its all-seeing, all-knowing capability. The more e-mail an e-mail server sees, the better the odds are that it will spot the spam. For example, if you were the Gmail server (yes, I know people cannot be servers, but play along with me on this one), you would see a lot of e-mail passing through you; far more than if you were the e-mail server for one company. The more e-mail you see, the more you get to see how many copies of the same e-mail are going out to the world and who is sending those e-mails.

I'm greatly oversimplifying what happens behind Google anti-spam curtains. But to help you understand the importance of this one technique alone, consider this: The providers of other expensive commercial anti-spam systems use the number of customer installations and the fact that they get to analyze a lot of e-mail across all those installations as a selling point.

6. Break the chains that have bound you: Forgetting for a moment that we're talking about Gmail and Google Apps here. If there's one thing that we've learned from any of the major Web-based e-mail operators, it's that the Web is truly the great desktop platform playing field leveler.

Every company has them; the outliers. The people who for one reason or another can't go along with the rest of the employees and run whatever standard desktop stack that everyone else is running. In some companies, you have to justify the need for something off the beaten path before the purchasing department will even consider buying it for you. Then, if you survive the inquisition, there's a good chance you'll be on your own. Maybe the vendor of your e-mail system makes a client for that other platform. But chances are, it works very differently (ahem, Entourage vs. Outlook). So much so that it's practically a deterrent to buying or using the software.

But once you move to a Web-based e-mail system like Gmail, everyone, regardless of platform, gets the same user interface in such a way that it's one major step toward not just the sort of platform independence that your users should be entitled to, but also the sort of platform independence that your entire company should be entitled to because of the way it lowers the barrier to switching.

Think back to the days when hardly a month seemed like it passed without yet another major transgression being committed against the many highly vulnerable Windows-based systems of the day. Windows has come a long, long way since those days so I'm not here to dig Windows. But, back then, when asked why they were sticking with Windows in the face of so many security problems, most IT departments weren't saying "Because we just love Windows so much we can't fathom anything else." For most, it was an addiction to certain Windows applications that couldn't be broken.

Again, this isn't about being anti-Windows. Addictions to anything are unhealthy and, at times, can be expensive. Moving to Web-based applications helps to break chains that deserve to be broken.

Finally (on this point, #6), keep in mind that most major e-mail systems that you'd insource have Web interfaces as well. So, there's that option as well. But Gmail's ability to go offline (point #9) without requiring anything more than the Gears plug-in (available for Firefox, IE, and Safari) should give you pause for thought.

7. Go mobile without the BS: I took some liberties there. I'm referring to the Blackberry Server (normally known as BES or BlackBerry Enterprise Server). The market for smartphone platforms that, one way or another, end up getting connected to corporate e-mail systems is crowded and is only going to get worse.

But even with some brilliant competition in the market, the BlackBerry platform is still king of the corporate hill. The only problem is that integrating it with the prevailing enterprise e-mail systems costs extra. For example, according to Research in Motion's Web site, if you were to go out today and add a BlackBerry Enterprise Server to your system for 101 users, the cost would be $2,999 (for the BES with one client license) plus $5,999 (for an additional 100 client licenses). That's approximately $89 per user, which is $39 more than the total cost per user per year for the Premier Edition of Google Apps itself.

Right now, you're saying "But David, you're comparing apples and oranges! The licensing terms are different for shrink-wrapped software than they are for subscription services!" Fair point. But consider this; like a lot of shrink-wrapped software, there's an additional fee for support. How much? It's not entirely clear because RIM doesn't publish the pricing for its five different levels of support the way it publishes the retail pricing for its servers and client license fees. But I did find a reseller's price sheet for the third level of support.

Meanwhile, to get Google Apps Gmail (and Calendar) on a BlackBerry, Google offers a free download. Updates to Google's BlackBerry software are free as well. Google charges no additional support fees. For $50 per user per year, Google includes 24/7 support (listed on the bottom of this page).

Just as important, though, going back to my last point (#6) about breaking the chains that deserve to be broken, you don't necessarily need a download to read your Gmail on a mobile device. Provided the mobile device has a robust-enough Web platform, Gmail's mobile Web interface gets the job done.

8. Any time. Anywhere. Pretty much any device: Given the other points that were listed already, maybe this point goes without saying. But then again, it's such a powerful point that it deserves to be listed separately in the top 10. Since becoming a Google Apps convert, I can't tell you how many times I have checked my mail from a device other than my own.

In fairness, before I moved to Google Apps, I was able to do this with my corporate e-mail account because it was available through Outlook Web Access (a.k.a. OWA).

But the question IT departments need to ask themselves is whether they want to be responsible for providing and supporting a Web interface to the enterprise e-mail system at whatever expense it ends up costing (in hard and soft dollars). Or, would they rather that a reputable provider be on the hook for providing the service. Keep in mind that Google isn't the only company that offers hosted Web-based e-mail using your domain. Microsoft offers a service called Exchange Online starting at $10 per user per month and even though it's more expensive than Google Apps, it will still be worth it in the long run to let Microsoft instead of you worry about running your e-mail systems.

9. They (the Google Engineers) pulled a rabbit out of their hat: Dating back to May 2006 when Sun's Francois Orsini was showing off JavaDB, I have very publicly been an optimist about the idea that, one day, someone would figure out how to make browser-based applications work offline. Plenty of people told me I was dreaming. They said it couldn't be done and that the offline problem (aka "the airplane problem") will always hold browser-based applications at bay.

If that's the case, then will someone please wake me up? Because, if I'm not mistaken, Gmail can now be accessed offline from the comfort of my browser (Firefox, Safari, and Internet Explorer all supported). If you haven't tried this, here's a ScreenCast that shows how easy it is to set up (text continued below the screencast):

I'll concede that right now, the offline functionality is currently in an experimental mode (Google calls these experimental features "Labs") and that it lacks one very important capability to some -- the ability to attach a file to an e-mail while working offine. The problem is easily worked around.

But, for an experimental feature, it works pretty darn good. Good enough that I've finally been able to give up my installation of Outlook (that ran on a Windows Vista-based virtual machine using VMware's Fusion). The only reason I had that copy of Outlook set up was so that I do integrated e-mail and calendaring while working offline (and in a way that both my e-mails and my appointments synced back to my Google Apps-based Gmail and Calendar).

10. Gmail account aggregation. We all have them -- those personal e-mail accounts that we use for personal business. The ones that we send our friends to because we know that those accounts may actually survive the e-mail address that's associated with our current job. Many people use regular Gmail for those accounts. But what many people don't know is that Gmail can be configured so that not only can all mail flowing through all of your Gmail accounts be funneled to one in-box, but from that one in-box, you also can send outbound mail from any one of those accounts.

The net net is that you can have a whole bunch of Gmail and Google Apps accounts. But to check them, or send mail from them, you only need to login to one of them. This is a killer feature that's hard to appreciate until you've actually experienced it.

Bonus Point #11. Google's Labs: Useful. Fun. As mentioned earlier, a "Lab" is Google's parlance for experimental feature. Some Labs are graduated into full-blown features. Others are decommissioned and never make it to the big leagues. Gmail's Offline Lab will very likely graduate to a production feature of Gmail.

One point the Labs really drive home is point #4 (the one about the hands-free upgrades). Technically, these aren't upgrades. They're sort of like plug-ins or add-ons. The only difference is that they're basically a radio-button away from being added to your Gmail account. When you think about what it would take to have similar functionality for locally installed shrink-wrapped software, having Labs takes all the complexity out of trying out new features and then either keeping them or leaving them behind.

Perhaps just as important is how the entire idea behind Labs draws the users of Gmail into the conversation about the technology. With previous generations of software, the idea that vendors would promote an open and public dialog with engineers was ridiculous. A suggestion box was practically unheard of. But, for every Lab that Google makes available to Gmail users, there's also an associated Google Group threaded discussion area where users of the Labs can comment on them, interact with the engineers, and suggest other useful Labs.

At last count, there were more than 35 Labs that, with the click of a radio button, could be added into any Gmail user's user experience. In addition to the offline functionality, there are Labs for rearranging Gmail's layout, creating canned responses, adding a task list to Gmail, adding keyboard shortcuts, the now infamous Mail Goggles, and, going back to Top Ten Point #10, there's a Lab for looking at multiple in-boxes simultaneously (if you'd rather not funnel them all into one).

Some Labs are incredibly useful. The Canned Response Lab is one of my favorites. I've created about 6 canned responses and they've increased my productivity because of how much faster re-usage of text allows me to respond to certain e-mails. There's another Lab that embeds access to Google Documents directly into the Gmail interface (very cool) and another one of my all-time favorites is the addition of a Send & Archive button that sends an e-mail and archives it (takes it out of your in-box) in one fell swoop (OK, guys, now give me a Send & Delete button and you're really talkin!).

But in addition to some of the more productive Labs, there are some that are just fun. For example, a random signature Lab that randomly picks famous quotes to append to the end of your e-mails. Or, the Old Snakey Lab that diverts you to a game of "Snake" when you could use a diversion. There's also a texting Lab that lets you text any phone in the United States without having to leave the Gmail interface.

No doubt, more labs will be on the way. For example, Gmail has an autocomplete feature for adding e-mail addresses to the TO:, CC:, and BCC: fields. Unfortunately, it doesn't work if all you can remember about someone's e-mail address is their domain (eg: techweb.com). So, I'd love to see a Lab that enhances the autocomplete feature in such a way that I only need to enter the domain name.

And, for that additional functionality that might never show up as a Lab, some of it may actually already be available from third parties who've created a library of paid add-ons that you can enhance Google Apps with.

Conclusion If you've made it this far, then clearly, you're interested enough to give the idea some consideration. If that's all you do, it's a step in the right direction. Google Apps isn't for everybody. But, if you ask me, it's very worthy of a great many businesses who so far haven't given it much thought, if any at all.

David Berlind is an editor-at-large with InformationWeek. David likes to write about emerging tech, new and social media, mobile tech, and things that go wrong. He can be reached at [email protected] 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 and his hope that the stock market can't get much worse. Also, if you're an out-of-work IT professional or someone involved in the business of compliance, he wants to hear from you.

Twitter: (@dberlind)
My Facebook Page  (Facebook should have a namespace like Twitter, FriendFeed, and the others)
Flickr (davidberlind)
YouTube (TechWebTV)
FriendFeed (davidberlind)
Del.icio.us (dberlind )
Me on LinkedIn (LinkedIn should have a namespace as well)
Plaxo (davidberlind)
Disqus (DavidBerlind)