The faulty assumption that e-mail is a commodity can lead to a lack of due diligence when assessing cloud-based e-mail services. Understanding the complex nature of e-mail systems will lead to more informed decisions about e-mail provisioning models.

Overview

A deep understanding of the operational, architectural, policy and feature requirements of an e-mail system will help organizations ascertain the suitability of the cloud provisioning model for e-mail services.

Key Findings

E-mail is far from a commodity for most organizations — user demands are rapidly increasing, leading to custom deployments that cannot always be matched by cloud suppliers. A well-run, feature-rich e-mail system can add significant value to an organization via better uptime, resiliency, security and content control.

Recommendations

Organizations need to examine current and future needs for e-mail services and determine if cloud suppliers can meet their e-mail needs. Currently, there are numerous areas — such as security and resiliency — where cloud suppliers may not meet enterprise requirements. Investigations over e-mail provisioning models should cover diverse areas such as security, integration, routing, uptime, recovery time objective/recovery point objective (RTO/RPO), mobility, storage, compliance and topology.

Analysis

With the ascendency of cloud e-mail services we routinely hear e-mail described as a commodity — therefore worthy of immediate migration to the cloud provisioning model. The thinking seems to be that since e-mail adds no strategic benefit to an organization, and since there are many inexpensive e-mail options in the cloud, it is a no-brainer to move mail to the cloud. Reality, however, suggests something far different. In fact, a well-run, feature-rich e-mail system can add significant value to an organization. And e-mail is far from a commodity for most organizations —internal demands are rapidly increasing, leading to custom deployments that cannot always be matched by cloud suppliers.
A commodity generally implies an undifferentiated supply of an unchanging product from largely undifferentiated suppliers. E-mail itself and cloud e-mail suppliers don't generally share these characteristics. Consequently, the decision about which provisioning model to use for e-mail services — cloud or on premises — must accommodate two countervailing trends:
As e-mail deployments get more sophisticated they get more complex — which leads organizations to examine cloud models to avoid increasing complexity.
As e-mail deployments become more sophisticated (and more likely to deliver competitive differentiation) they become more customized — making them less likely to be a good fit for cloud deployments, which generally offer generic, rather than custom, services.
Therefore, as organizations debate e-mail provisioning models, they need to examine current and future needs for e-mail services and determine if cloud suppliers can meet these needs. Below we discuss 10 broad categories of e-mail services which generally demonstrate that e-mail is not a commodity and which — in a customized form — may not be available from cloud suppliers.

Security. It is counterproductive to discuss e-mail security without a more granular definition. Administration control, for example, is a security subtype referring to who has what rights to manage what parts of the e-mail system. Granular administration rights can protect system security by allowing only a few trusted individuals to manage particularly critical attributes (such as the MX record). Cloud suppliers generally don't enable granular administrations rights, creating a security risk for many organizations.

Another example is support for Transport Layer Security (TLS), a hop-to-hop encryption method often used by companies to securely communicate with business partners. Cloud suppliers will support "opportunistic" TLS (when the sending and receiving router both support TLS, TLS will be used) but are unable to enforce mandatory TLS (when a TLS session is a requirement for message transmission).

Generally speaking, the more security layers in an e-mail system, the more complex the system is. Other security areas to assess when evaluating cloud services include:

• - Physical and logical data center safeguards.
• - Anti spam/virus/phishing services.
• - Data leak protection.
• - Location of mailbox replica copies.
• - Multi-factor authentication.
• - Access to logs and forensic capability.
• - Password rule compliance and/or synchronization.

Integration. Perhaps the mother of all complex e-mail services, application integration is only sporadically supported by cloud suppliers, depending on the nature of the integration. Simple SMTP integration can be transferred to the cloud, but tighter integration via proprietary APIs to the mail system are generally not transferable. Voice mail, faxing, message-based workflow, alerting and notification services are all routinely integrated into e-mail infrastructures, creating a complex overlay over the base messaging system that often cannot be replicated by cloud suppliers

Routing. Organizations often have complex internal routing requirements necessitating an internal e-mail backbone supplied by vendors such as Sendmail. Companies may have requirements for appending different disclaimers on messages as a result of country-specific requirements, or they may require address rewriting to preserve multiple domains. Other organizations might have to establish ethical walls to prevent certain parts of the organization from communicating with other parts of the company, or they may write policy rules enforced over the backbone for message size or message content. Putting policy controls in a mail backbone also enables newly acquired companies to be more rapidly integrated into the corporate system and enables policy to be applied across diverse e-mail systems. Routing and control requirements can be very complex, and often cannot be fulfilled by cloud suppliers.

Uptime. As e-mail gets its long overdue recognition as a mission-critical application, organizations are getting more aggressive about improving uptime. We see many organizations moving from a 99.5% uptime SLA to a 99.9% uptime SLA, which typically mandates an investment in physical redundancy and process improvement. This redundancy creates additional complexity. We also see planned maintenance windows being trimmed. Cloud suppliers generally offer a 99.9% uptime SLA — some offer financial compensation for missed targets, others offer more service time as compensation. Over the past year, cloud suppliers have had mixed results in meeting uptime SLAs — companywide sustained outages are relatively uncommon, but short-term, scattered outages are common.

RTO/RPO. Along the same line, with e-mail being recognized as a mission-critical application, aggressive disaster recovery services become mandatory, such as sub-four-hour recovery time objectives and sub-five-minute recovery point objectives. These RTO/RPO investments can be substantial and can greatly increase complexity. Better uptime and substantial RTO/RPO programs, however, can lead to real competitive differentiation — the ability to have e-mail working continuously in the case of a catastrophic failure while rivals experience downtime. Cloud suppliers may have RTOs and RPOs that do not meet the established internal company criteria for recovery goals — from major cloud suppliers, RPOs range from 10 minutes to 24 hours.

Mobility. Users are demanding — for legitimate business reasons — greater access to e-mail from a wide variety of devices and locations (e.g., kiosks, home). Several years ago, it was generally only the elite few that were provisioned with mobile service (mostly via BlackBerry Enterprise Server [BES]), but now most knowledge workers desire both browser access and mobile services from a wide variety of smartphones. Broader deployment of Web and mobile services increase system complexity (and cost), particularly in more security conscious organizations. Cloud suppliers can generally supply ActiveSync mobile services (for most smartphones), browser access and BES services. But BES services can be expensive and vendors generally struggle with BES uptime and may fail to provide all security and control requirements for mobile use.

Storage. E-mail storage is perhaps the number one source of frustration for end users. Average server-side mailbox stores remain stubbornly in the 300MB to 500MB range, forcing users to scramble to stay in compliance with storage parameters. Much larger server-side stores can be created cost-effectively with technology such as database availability groups in Exchange 2010 — but these approaches, which can require up to four disk-based copies of the mail store, can add system complexity. Cloud vendors generally offer 25GB per user, basically obliterating user storage concerns but introducing IT concerns. The organization, for example, may have a 60-day purge requirement, or an e-mail system link to a records management system — both of which may break as a result of a move to the cloud. Similarly, organizations may have sophisticated archive procedures, with specific age-out, discovery or hold request support. Companies may also have specific rules on backup retention. Cloud suppliers typically don't back up beyond 30 days and those backups are stored as disk-based replicas — there is no provision for offline copies and for longer-term backups.

Compliance. Some organizations have externally mandated requirements for longer-term storage of all or some messages or for encryption of certain information or for review of some messages. These are generally industry-specific and cloud suppliers are generally not equipped to handle these complex requirements. Compliance requirements are generally becoming more common given government interest in electronic communications and are becoming more complex as country- and/or region-specific regulations proliferate. Most cloud suppliers are unable to handle multiple region-specific regulations.

Topology. Global organizations typically have at least three data centers (North America, EMEA and Asia/Pacific, for example) with e-mail servers, thereby enabling companies to optimize e-mail performance (e.g., avoid latency issues) and meet local requirements for e-mail privacy, compliance and/or message appending. These topologies and local requirements add complexity to the system. Cloud suppliers, in some cases, cannot meet the need for geography-specific server locations or for adherence to local laws.

Management. IT personnel typically want rich management platforms for granular control of mail functions and for efficient operations. The richer the management console, the more control, but with it comes increased complexity. IT staff also require in-depth reports on mail activities for security, performance and capacity planning purposes. Change management for on-premises e-mail systems is typically done carefully with established and proven methodologies. Cloud e-mail systems typically don't offer rich management consoles, leading to lack of control, insight and efficiencies, and reporting and change management services are typically substandard compared to well-done, on-premises deployments.

In many ways a "commodity" e-mail service from a cloud supplier offers lowest common denominator e-mail services. Most organizations, however, don't run a commodity e-mail service — making cloud e-mail a misfit for many organizations. This situation is likely to change. Cloud e-mail services are immature today, but are likely to mature rapidly over the next three years. In the 2014/2015 time frame we believe vendors will have made major strides in improving services across all 10 categories listed above.