Email As a Service Not As Easy As It Sounds

It seems that executives in every organization these days feel the pressure to move to the cloud. The United States government is no exception, as the administration’s Cloud First policy is driving federal agencies to move essential systems to the cloud—and fast.

News: Cloud Computing Gains in Federal Government

In response, agency CIOs have scrambled to identify the low-hanging fruit: applications or systems that would be relatively straightforward to migrate. Topping the list are public-facing Web sites, customer relationship management, content and document management and email.

As it turns out, running corporate email in the cloud—email-as-a-service, or EaaS—is on everybody’s low-hanging fruit list. After all, there are many public EaaS offerings that already host thousands of organizations and millions of users. Email standards and technology are quite mature, and it’s unlikely that your existing on-premises email system responsible for moving emails around today is so decrepit that migrating off of it is a Herculean task. Plus, of course, email is so easy to use that moving to a new system shouldn’t involve onerous change management and training.

Or so the reasoning goes. Look closely at your existing on-premises corporate email system, though, and you’ll identify a number of gotchas that complicate the move to EaaS.

• Your email system is probably tightly integrated with your identity and access management system, especially if your employees enjoy single sign-on capabilities that include their email accounts.
• Your email is likely connected to your corporate calendar, address book and other collaboration technologies.
• Don’t forget that your employees like to check their email on their work computer, their home computer and their smartphone.

Any EaaS migration strategy must take into account all of these issues.

Trade Agreements, Politics Complicate Government EaaS Efforts

The federal government has all these problems and more—not only because if its sheer scale but also because of the diversity of its needs and the regulated nature of its operations. For example, security is obviously a paramount concern, and security requirements vary depending on whether it’s a civilian, law enforcement, military or intelligence agency. At the same time, the government’s free-trade policies prevent it from restricting contracts to U.S.-based providers unless there is an overarching reason to do so.

Analysis: Email in Security Hot Seat With Rise of Cloud, BYOD

The General Services Administration (GSA) found these competing priorities in a request for quotation it issued in May 2011. This RFQ anticipated the awarding of a blanket purchase agreement for EaaS that would enable many agencies and departments across the government to purchase email from a preapproved list of EaaS vendors—in the process saving the government millions of dollars and satisfying an essential Cloud First mandate.

However, after conversations with the Office of Management and Budget and the office of the United States Trade Representative (USTR), the GSA realized it needed to balance agency security concerns with free trade policy and let agencies select EaaS providers with data centers outside the United States. The GSA’s challenge was determining which countries were too risky for hosting government email data centers in a way that complied with law and policy. (Some countries, Iran, Cuba, China and North Korea, were clearly too risky and therefore easy to exclude.)

To this end, the request for proposal called for the restriction of EaaS data centers to countries designated under the Trade Agreements Act (TAA), a list of countries to which all GSA schedule contracts are subject. After all, there was plenty of precedent for this choice, and the list excluded all of the problem countries. The GSA had good reason to believe that using the TAA designated countries list would balance agencies’ security requirements with the principle of free trade.

Nothing, however, is ever that simple. A small handful of contractors cried foul, pointing out that the TAA list was excessively arbitrary and would only constrain where data center providers located their headquarters, rather than the locations of the data centers themselves. These contractors filed a protest, and the Government Accountability Office (GAO) agreed. After all, the TAA designated countries list would theoretically allow data center providers in countries such as Yemen, Somalia and Afghanistan while arbitrarily excluding providers in India, South Africa and Brazil. The GAO also agreed that the RFQ as written would allow for the possibility that a company might be headquartered in a TAA-allowed country even though its data centers might be in, say, China.

News: Government Seeks Guidance on Cloud-Brokerage Services

As a result of the GAO’s findings, the GSA headed back to the drawing board to revise its RFQ. With no way to formally designate which countries it might consider to be safe enough for EaaS data centers, it simply required EaaS providers to tell the government where its data centers were located. Each agency could decide for itself whether that Indian or Brazilian data center is sufficiently secure to meet its needs.

Email As a Service Brings Cloud Deployment Questions

There’s more to this story. In the same RFQ, the GSA called for respondents to offer several different cloud deployment models, including public cloud, government community cloud, secret enclave private cloud and a few others. The same protesters also took issue with the GSA’s addition of government community clouds. Their theory: there is no technical difference between such clouds and public clouds, and the only salient difference is that non-government traffic is prohibited on the government community cloud. As a result, the protesters argued, a government community cloud would unfairly restrict competition.

News: Salesforce to Launch Government Cloud

In this instance, the GAO decided against the protestors, concluding that the security risks inherent in a multitenant cloud environment are substantial enough to warrant excluding non-Government traffic from government community clouds. In fact, the GAO points out, the hypervisors that underlie multitenant virtual architectures in today’s market have inherent security flaws that excluding non-government tenants would mitigate.

After adjusting its RFQ, the GSA reissued it, and selected 17 EaaS providers for its BPA in August. As a result, any agency or department can purchase services in five “lots,” including office automation, electronic records management and email migration and integration services in addition to EaaS. The BPA also covers the diverse cloud deployment models the government requires for its EaaS capabilities. Finally, to lead the way, the GSA is rolling out its own internal EaaS to 17,000 employees.

The moral of this story, of course, is that there’s a lot more to moving your corporate email to the cloud than signing up with your EaaS provider of choice or provisioning an email server at your favorite public cloud. While most private sector companies don’t have regulations requiring them to purchase services from overseas trading partners, virtually every enterprise has bumps along the road to EaaS similar to the ones that the government faced. Email may be low-hanging fruit for the cloud, but don’t let the mundane nature of email fool you into thinking that transitioning this most basic of IT services to the cloud is a simple task.

The other important lesson here is that moving to EaaS presents challenges that are more organizational than technical. True, security is a perennial concern, but regulatory and change management challenges create pitfalls into which even the most technically astute IT organization may fall. Moving to the cloud may lead to dramatic cost savings and increased business agility for your organization, but only if you get it right. Don’t take anything for granted.

Jason Bloomberg is the president of ZapThink. Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.