Forget Exchange, the hosted email debate has moved on

The trouble with the debate about whether to insource or outsource email is that it always seems to end up as a price comparison for hosted vs on-premises Exchange. As Dion Hinchcliffe wrote on Saturday, and Zimbra's Scott Dietzen yesterday, that completely misses the point.

I alluded to this in my posting on Friday,Why wait for Microsoft to develop, test and package the full feature set? What's the true cost of running email in-house, when I asked "how did we end up centering the discussion on Exchange hosting when it was originally sparked by Google's moves with Gmail?" As Scott points out in his response, the discussion conflates two quite distinct SaaS models. I disagree with how he's chosen to define each one so let me restate them in my own terms, referencing a couple of my previous postings as background:

Same old Software, as a Service (SoSaaS) — "Take any old software package, run it up on a server in a data center, do a bit of financial engineering so customers can pay on a monthly plan, and hey presto! you've got an on-demand application." To be fair to Microsoft, there is a version of Exchange Server that's specifically designed for high-volume hosting providers, which makes it a little bit more sophisticated than the efforts of most conventional software vendors. But the fact remains that this is a software package that is designed and built for on-premises installation, and therefore it always will be less than ideally suited for operation in an on-demand environment (as George Ou points out for example, it passes attachments around instead of sharing a single master copy, thus ensuring abysmal performance on anything except a high-speed local LAN connection. How dumb is that?)

Software that actually works — "The on-demand model isn't about delivering software per se. It's about delivering the results of successfully using the software." When email is delivered as an on-demand service, what you get isn't a hosted email server — the internal mechanics aren't of any interest at all — what you get is a commitment from your service provider to make email work for you. That's vitally important in this day and age because, as Dion notes in his posting, "The nature of e-mail itself is changing and evolving. And IT shops will have a hard time keeping up ... Folks want to add voice, video, chat, RSS feed subscriptions and more to their e-mail systems."

That's something else, then, to add to the list of things people forget to include when calculating the cost of keeping email in-house — the cost of researching and evaluating the evolution of email along with all the other forms of communication and collaboration that users will be demanding, to make sure that your systems stay up-to-date with what your competitors are using.

Of course, you can still choose to outsource that product development to Microsoft and wait for the next release of Exchange to gestate at the company's glacial development pace. But why wait for Microsoft to develop, test and package the full feature set when your on-demand provider just lets you mashup its services with all of the new capabilities being launched every day via Web 2.0? As long as Exchange is trapped in its legacy on-premises licensing model, it can't afford to offer that same mashup flexibility because it will give away its monopoly on the messaging feature set you license from it.

There's a simple rule of thumb here. If you can build exactly what your email provider has, then I'll concede that the like-for-like comparison, as Mi8'sPatrick Fetterman explained to me, is balanced on a knife-edge, and whether it's better to insource or outsource is down to factors such as your own resource pool, your specific requirements, and how trustworthy your provider is — but equally, you're not looking at a true on-demand service, you're looking at hosted legacy. If, on the other hand, your email provider's infrastructure is an impenetrable black box and you would have no idea (nor inclination) how to implement it internally (think Gmail, for instance), then that's a true on-demand service, and the further it evolves over the next few years, both organically and via mashups with other services, the more it will knock Exchange — hosted or insourced — into a cocked hat.