In keeping with last week’s vein of hosted or outsourced messaging services, let’s talk about the differences between using a third party for an Exchange Server deployment and using an internal corporate deployment, the solution most of us are accustomed to. I received a lot of feedback on this topic. Because ISPs or application service providers (ASPs) have different goals and requirements when deploying hosted or outsourced Exchange services, discussing these differences is a worthwhile topic.
The first big difference is the customer or client. In a corporate environment, most administrators don’t get paid on a per-user basis; the cost of corporate messaging systems is usually covered under the overall IT infrastructure. Also, corporate Exchange Server users often want a different feature set. Generally (I know there are exceptions), outsourced users are more focused on messaging rather than features such as collaboration and calendaring. Certainly, as outsourced Exchange services become more common, we'll see all Exchange features leveraged, but for now, basic messaging seems to be the focus.
Hosted messaging typically uses different protocols. Although most corporate Exchange Server deployments are messaging API (MAPI)-based, hosted services will rely more on Internet protocols, such as POP3, IMAP, and SMTP. Internet protocols don't offer the same rich features as MAPI protocols. The real boon for outsourced messaging will be Exchange 2000 Server's Outlook Web Access (OWA). OWA will let ISPs and ASPs deliver the calendaring and collaboration features via an Internet protocol (HTTP-DAV) instead of MAPI. I foresee a lot of ISPs and ASPs offering hosted services that include the rich features of an Outlook client delivered to a browser at a customer’s site via HTTP.
Another significant difference in outsourced messaging deployments is the overall design and support model. Most corporate Exchange Server deployments vary from somewhat centralized to somewhat decentralized. For ISPs that provide hosted services, the nature and cost constraints of their business require a highly centralized design. This centralized design, along with the support and service-level requirements, will result in a new approach to how data centers for hosted services are structured. These service providers will need huge farms of servers and highly available utility-based storage to meet the service level agreements (SLAs) that their customers require. Technologies such as Storage Area Networks (SANs) and clustering will be high on the list of priorities. If the hosted services are based on Exchange 2000 and OWA, the front-end and back-end architectures that Exchange 2000 provides for Internet protocols will be extremely relevant. For corporate messaging deployments stuck with MAPI, this architecture will be meaningless. The bottom line is that data centers and deployment designs will be much different for the hosted environment.
Regardless of the approach that an ISP or ASP takes for hosting Exchange services, the provider will require Microsoft and other sources of Exchange Server expertise to provide new ideas, designs, and solutions for these deployments. In the short term, the needs for hosted messaging services are simply different and there is not yet a significant body of knowledge available for Exchange in these environments.
