Skip navigation

Looking at Email as a Service

Evolving messaging options could change your email strategy

Executive Summary: Enterprise messaging options for companies include inhouse email, such as Microsoft Exchange; hosted email; or a combination of the two. Learn about the pros and cons of each email option and important considerations you and your company must ponder before making any moves.

Enterprise messaging has evolved from the green-screen experience of applications in the 1980s to the newest generation of email: Messaging delivered as a service. But because technology generations overlap each other, deciding which messaging option or combination of options to use can be more complicated than meets the eye. Let’s look at the newest generation, known as hosted email or email as a service, and the ways your existing email deployment could evolve, plus what you need to consider as you chart your company’s messaging plan for the future.

Three Messaging Options
Options for enterprise messaging are evolving as new computing paradigms appear. If we take a five-year view from today, three major options appear that are viable alternatives:

  1. Use inhouse email based on a platform such as Microsoft Exchange or IBM Lotus Notes.
  2. Use email as a service, where the email service provider delivers all the necessary compute power, storage, and application logic via the web (sometimes called delivery via the cloud).
  3. Use a hybrid approach by offering inhouse email for users who require a great deal of functionality and hosted email service for users who need only the ability to send and receive messages.

Which option your organization should choose depends on its current infrastructure, its appetite for risk, the number of users and their security requirements and other needs, how much the company is willing to invest in the provision of an email service to users, and whether the company has made other investments in the email infrastructure that will be affected by a move to a new platform. For example, many large companies have deployed Research in Motion’s (RIM’s) BlackBerry Enterprise Server alongside Exchange or Lotus Notes or have built applications based on Exchange public folders or Lotus Notes mail routing. It’s hard to migrate to a new platform unless the new platform offers equivalent functionality. I’ll talk about more adoption considerations in a moment. First, let’s look at the newest option for email evolution—hosted email or email as a service.

Email as a Service
Email as a service is related to software as a service (SaaS), the software distribution model where customers access applications hosted by a service provider via the Internet. Cost is usually the major driver for using email as a service. A low-cost fixed-price offering is an attractive proposition when you consider the costs of servers, storage, networks, software licenses, and technical support necessary to run inhouse email.

Microsoft’s email-as-a-service solution is Microsoft Exchange Online, which is based on Exchange 2007. Part of Microsoft Online Services, a set of enterprise-class software offerings delivered as subscription services and hosted by Microsoft, Exchange Online should arrive toward the end of 2008, and is available in standard and dedicated versions. (For more information about Microsoft Online Services and Exchange Online see www.microsoft.com/online.) The standard version provides an infrastructure that hosts mailboxes from many different companies. The dedicated version is for companies with more than 5,000 users: Microsoft builds out a server environment to host the anticipated load. Both versions are based in Microsoft data centers and offer 1GB mailboxes, support for Windows Mobile devices, Outlook Web Access (OWA), antivirus and antispam, and 99.9 percent availability (the claim of 99.9 percent availability needs to be tested over time).

The dedicated version offers some optional services such as archiving, RIM Blackberry support, and data migration from an existing mail system. Customers using Active Directory (AD) can set up single sign-on (SSO) through a directory trust.

Google’s offering is Google Apps, which includes Gmail with a 25GB mailbox, Google Calendar, and Google Docs (e.g., word processing, presentations, and spreadsheets). Gmail is a perfectly acceptable email system if you’re willing to accept a web-based or IMAP client (including Microsoft Office Outlook) and less integration between components than is delivered by the Outlook- Exchange combination. Google offers antispam and antivirus services via its Postini subsidiary and can provide enhanced services for archiving, security, and compliance.

Moving to Gmail is straightforward if you use only basic email features such as Send and Receive messages. In particular, companies whose email strategy depends on POP3/IMAP4 based on a server such as Sun Microsystems iPlanet will find it easy to move to Gmail. However, companies that currently use an inhouse email system will run into problems associated with migration, the client experience, and interoperability. They might also find that their needs for e-discovery, compliance, and customization cause further complications. For example, some industry regulations require that every outgoing message (including those sent by mobile device) is stamped with a disclaimer text—with Gmail, it’s a challenge; with Exchange 2007, it entails a relatively simple transport rule. In the future, Google will likely develop Gmail as a more fully featured email server and improve its support for clients such as Outlook as well as invest in utilities that improve Gmail’s interoperability.

Speaking of support, that’s another issue that Google has yet to address. Large companies demand 24x7 support for applications and they want the same quality of support to be available in every country where they do business. Google has no background in delivering this type of support and although it will probably develop support capabilities over the next few years, anyone considering Gmail for the enterprise needs to consider this.

Microsoft announced list prices for its standard service in July 2008, with Exchange at $10 per mailbox or $15 for Microsoft Business Productivity Online Standard Suite (Exchange, SharePoint, Office Communications Server, and Live Meeting). The annual cost for Exchange Online is more expensive than Google’s Gmail—the premier edition of Google Apps costs $50 per user per year (www.google.com/a/help/intl/en/admins/editions.html)—but it’s possibly justified by the higher levels of functionality available using Exchange. Exchange Online doesn’t support Unified Messaging, probably because of the difficulty of integrating a standard service with multiple variants of PBXs and telephony backbones. The list prices from Microsoft and Google are guidelines and depend on the number of seats, their location worldwide, the services used, the length of the contract, how the service is supported, and the volume of business that a company does with the vendor over time.

Microsoft’s email service is likely to change over the coming years to incorporate new technology and keep pace with Google. The company is investing heavily in deploying the data centers to support Exchange as a service and in making changes in the Exchange code base; you can expect to see many of these changes in Exchange 14, due in 2009.

Unlike Google, Microsoft has to perform a balancing act as it develops its online presence. It doesn’t want to cannibalize its traditional market, and because not all of its software can yet run in the cloud, it doesn’t want to force customers to use cloud-based services because the change might cause customers to consider non- Microsoft options. If Microsoft gets it right, online services will add to its overall market. If not, it might be the start of an expensive dismantling of its Office franchise.

Inhouse Email
Because the features in Exchange and Lotus Notes have been assembled over the years, these servers can meet the needs of large enterprises in a way that a consumer-based product can’t. For example, many companies customize the display templates used by Exchange to show details of objects fetched from AD. New fields are added, fields are removed, and display text altered to meet the exact needs of the company. A well-populated Global Address List (GAL) complete with organizational information is a very useful tool for anyone who has to navigate through the organization. You can argue that this level of detail can be easily traded for a much lower cost of operation, until you compare access to an LDAP directory through whatever interface you select to go alongside Gmail. Although the LDAP lookup works, it’s not as easy for users and could actually increase costs through lower productivity and additional calls to the Help desk.

Another factor to consider is the health and richness of the ecosystem around successful products such as Exchange and Lotus Notes. Google is doing its best to encourage developers to leverage Google Apps and no doubt will succeed over time. Indeed, the fast iteration model used by Google for application development means that new solutions appear all the time. However, using Gmail today might mean having to search for new solutions to problems that have been solved many times over on the Exchange platform. Additionally, many companies have built a complete collaboration environment based on Microsoft technology (e.g., Exchange, SharePoint, and Office Collaboration Server). It might be easy to replace the messaging functionality delivered by an inhouse email server by purchasing email as a service, but you need to also consider the overall collaboration environment of your users. For example, customers using SharePoint Online can’t expect Microsoft to allow them to deploy custom web parts in Microsoft’s shared infrastructure.

Continue to page 2

Clients are an important factor to get right because user satisfaction (and the number of calls to the Help desk) is largely determined by user interaction with the server through the client. Gmail’s standard web-based UI is simple and robust, but it could only be loved by its developers and their mothers. The biggest shock for users new to Gmail is that Gmail’s UI is devoid of the traditional folders used to organize email. Google’s perspective is that you don’t need folders to organize email because you can search for and find any message very fast. Regardless, it does take time for users to figure out how best to use Gmail.

Gmail supports POP3 and IMAP4 access so you can connect other clients including Outlook 2007, Outlook 2003, and Outlook Express if you don’t like the web interface. I prefer to use the Windows Mail client provided with Windows Vista to connect to Gmail, and this solution works well, though an occasional glitch causes the server to lose client credentials. For a comprehensive discussion about using Microsoft clients with Gmail, see my recent article “Connect Microsoft Email Clients to Gmail,” InstantDoc ID 99782.

A Hybrid Approach
You might consider combining approaches to best meet user needs. A hybrid approach means deploying inhouse email for users who need a full feature set and deploying email as a service for users who need only the ability to send and receive messages and use a calendar. However, you still have as many factors to consider when moving to a hybrid approach as when you migrate from one email system to another:

Interoperability. A Google Docs user with a Gmail account must be able to open and view a Microsoft Word attachment sent by an Exchange user, make changes to embedded tables while preserving the format, and send it back to the Exchange user.

Migration. You should be able to move user data from one environment to another, including transferring data from a legacy email system.

Portabiility. You should be able to transfer user mailboxes between all of the email systems deployed in the enterprise (including legacy systems) without data loss. Ideally, there should be a highly automated process to move mailboxes.

Compliance. Users who must comply with legislative or regulatory requirements should be assigned to an email service that can support this need. Exchange of information between both of the email services must comply with these regulations.

e-discovery. You need to capture and archive messages that flow between the email services to meet e-discovery requirements.

Security. Both of your email systems should support common methods to sign and encrypt messages.

Directory. The email systems should share a common directory that people can use to validate email addresses, check organizational information, and so on. Common distribution lists (groups) should also be available.

Service management. It’s relatively easy to commit to a Service Level Agreement (SLA) for email that’s managed inhouse but harder when responsibility for the delivery and availability of the service is moved “into the cloud.” It’s even more complex when you have different service providers managing different email services. It’s possible that a company might have to upgrade its Internet access if it switches network traffic from predominantly internal access to email servers to exclusive access to cloud-based servers, or a mixture of both.

Outsourced Hosting
With outsourced hosting, a customer contracts with an outsourcing provider to run the email application in the provider’s data center. For example, if you elect to use Exchange, Outlook clients access email over the Internet using RPC over HTTPS (aka the Outlook AnyWhere feature in Exchange 2007) and network proxies direct client traffic from the customer network across the Internet to the provider’s data center. The advantage of outsourcing is that you purchase an email service at a known cost for as many mailboxes as required. You don’t have to worry about systems administration, software or hardware upgrades, capacity planning, management and monitoring, and all of the other work required keeping an email system running smoothly. An email hosting solution can also support hybrid systems and deliver both full-function and basic email to different user communities within the same company.

Buying email from a cloud-based service offers the promise of lower cost but the potential loss of some functionality. However, it’s possible to reduce cost while preserving functionality by outsourcing email to a provider who offers full-function products (i.e., Exchange) delivered from the Internet at a predictable cost. Many service providers offer hosted Exchange, chiefly for small-to-midsized businesses (SMBs), and they typically use the same kind of infrastructure that Microsoft has built for its email-as-a-service solution. What’s different is the combination of outsourcing the service with Internet access. Traditional outsourcing runs applications such as email as part of a customer’s IT infrastructure or in the service provider’s data center with dedicated network access for clients who wish to connect to the service. Because Exchange 2007 is more flexible than its predecessors, hosting based on this platform is now the standard for outsourcing companies who use the Microsoft platform.

What Should Your Company Do?
The advent of email as a service is just another change you need to take into account as you consider how to deliver email to users in the future. A simple fivestep approach can help to crystallize the discussion about email and prepare you to balance demands from different constituencies in your company. For example, users will be interested in large mailboxes that they see available from Google while the CIO will want to restrict costs of deployment, operations, and support.

1. Don’t panic. If your current system is based on outdated software that will no longer be supported, now is a good time to consider options and plan for early action. On the other hand, if you’ve recently upgraded to the latest software release on new hardware, you’ll want to realize value from this investment and not change anytime soon.

2. Know what you have today. Understand your current email infrastructure, from the basic hardware and software to clients and add-on products. Assess the benefits and drawbacks of the current email system and compare it against the potential benefits of a new email system. You also need to understand how the email system is used today including aspects such as traffic volume, patterns (internal versus external, daily peaks, weekend use), user types (roaming, office, executive, basic), and numbers, as well as the dependencies that exist with other parts of the infrastructure such as the enterprise directory.

3. Cost the change. Even an upgrade to a new version of your current email system incurs some cost. You need to understand how much short-term and long-term investment is required for the move. The cost categories that should be considered include

  • Transition—what work needs to be done to move from one email system to another?
  • Migration of user data, system data, and applications
  • Operations and monitoring
  • Possible need for new software and hardware
  • Support (clients and server)
  • Network—your current network is probably designed to handle the load generated by clients to internal servers, but can it handle connectivity if you switch to consuming services from the Internet?
  • Add-on products such as antispam, antivirus, mobile devices, and fax connectors

4. Involve users. If you decide that moving to a new service is a good idea, test the user experience with a variety of people so that they understand the advantages and disadvantages of moving. Get user input: Some esoteric scheduling feature that involves multiple calendars might be unimportant to you but critical to them.

5. Have a Plan B. Before making a major change in your email strategy, you should know what to do if the change doesn’t work. For example, let’s assume that you plan to move 10 percent of the user population to email as a service. Have a plan in place if and when users complain about missing features, network latency, client interfaces, or anything else. The plan may call for you to back out of the new system or specify how to make changes (including any additional costs) to improve the system so that it meets user expectations.

Making Your Decision
Although SaaS makes it easy to buy and use a service such as email, it doesn’t make the decision-making process any easier. In fact, it can complicate matters. But equipped with the information you’ve gained, you will now be able to make a data-driven rather than emotion-driven plan for future email services.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish