Last week, I wrote about Microsoft's announcement of Exchange 14. As with most product introductions, the E14 introductory video was a necessarily cursory look at something that has a lot more detail when examined up close. Unfortunately, the video's all we have to go on at this point—at least until a public beta is released! I was particularly struck by one thing in the video, though: note how E14 is introduced. KC Lemson's opening calls E14 "the first version of Exchange built from day 1, from the ground up, to be both software and a service." Of all the potential ways to introduce E14, why choose this one?

KC goes on to say that E14 will allow you to split your users between your own self-hosted Exchange Server systems and Microsoft's Exchange Online service, part of its Business Productivity Online offering. That's an extremely interesting statement because of what it implies. For example, there obviously has to be a way to route messages seamlessly between your servers and Microsoft's—but there must also be a way to federate directory information so that servers on each side of the link know which users are authorized internal users and which aren't. The mechanics of creating, provisioning, and maintaining mailboxes and user objects will probably prove to be pretty interesting, too.

More broadly, though, this announcement is a big step forward for Microsoft's Software Plus Services (S+S) strategy. It's one thing to offer a single product in both hosted and on-premises versions; Microsoft, IBM, Zimbra, and other messaging and collaboration vendors have done this for a good while. You might call that approach "software or services" because there's generally no migration path and fairly limited interoperability between software and service-based offerings. Having E14 (and, presumably, other future offerings from Microsoft—hosted SQL Server, anyone?) available in an S+S model offers the potential of a great deal more flexibility. For example, you could keep users who routinely work with confidential or sensitive information on your own servers, then put the bulk of your workforce on the hosted service. This possibility is especially appealing to companies that have lots of employees who work out of the office or where there's a high degree of turnover. It also enables some useful scenarios; for example, schools and universities can cheaply provide web-based services for students with Exchange Online, then host their own mailboxes for faculty and staff.

Cost will have a huge effect on whether this S+S play will be successful for Microsoft, of course. A lot of the discussion around first-generation cloud-based services, such as Google's Google Apps bundle, has focused on the cost of providing the service alone. This discussion ignores the fact that in a split environment, you still have to pay to maintain your internal directory, Help desk, and so on. Reducing the cost of email itself is useful but not sufficient if you still have to maintain multiple directories and provisioning systems. However, if you can tightly couple your internal services with your collaboration service provider, the overall cost of the service can be much more reasonable. Of course, we won't see real cost figures on the E14 S+S combination for quite some time, so for now all I can do is speculate!