Federal agencies have a “Cloud First” mandate from the Office of Management and Budget (OMB) which specifies that, if a “secure, reliable, cost-effective cloud option exists”, it should be used by default in federal agencies. Since the definition of “secure” can be a moving target, the Federal Risk and Authorization Management Program (FEDRAMP) was established to provide an approval stamp and ongoing certification for Cloud Service Providers. If all the cogs in the machine work as designed, an agency using a FEDRAMP approved vendor should not have to worry about Cloud related security concerns, or excessive red tape when contracting with a FEDRAMP approved Cloud vendor.
That being said, there are still the “reliable” and “cost-effective” parts of the mandate that need to be established. Even if a solution is rock solid secure, it’s absolutely no good if it’s not effective, or if it ends up costing more than using a previously existing solution. Just as with any IT project, reliable and cost-effective are equally as much about how well your project is managed as it is about how good your programmers are.
Part of the problem is the mindset that implementation failure is due to bad coding and a lack of resources. If you just had better code, or a few more GB RAM, then your site would be a marvel of efficiency and cost savings. Back in the real world, the problem is more that the individual components of your solution work up to specifications on their own, but when you try to put them together you end up hitting walls where a database connection from Healthcare.gov to Homeland Security or the IRS doesn’t connect efficiently, and slows down the application.
Healthcare.gov is different from “Cloud First” mandated applications. It was, and is, a sprawling application that covers multiple agencies and was intended to be accessed by millions of external users simultaneously. Federal agencies moving their internal applications to the Cloud should have far less complexity to deal with than Healthcare.gov had, and the transition should be smooth and flawless. Right?
Not necessarily. Federal Computer Week (FCW) reported on an executive briefing by Wolf Tombe, CTO of Customs and Border Protection (CBP), outlining mistakes that were made in their Email-as-a-Service Cloud implementation. FCW quotes Tombe’s summary of the experience as:
Tombe… said the agency did not specify with the vendor how the migration to cloud email would occur, nor did it contractually demand visibility into the vendor’s cloud infrastructure.
Upon signing the contract, Tombe said, the agency learned the vendor would initially be able to migrate only about 100 users per week to the cloud. A server blade failure soon after led to a total system outage, getting CBP’S email-as-a-service offering off to a terrible start.
“We should have known we were in for trouble,” Tombe said. “It wasn’t what we signed up for, and we’re still not seeing the cost realization you’d expect for cloud. It was a custom infrastructure built for us — not a managed service.”
CBP’s experience with their attempted Cloud migration led to changes in their Cloud acquisition strategy. While some guidelines were requirements for Cloud vendors, there were other internal requirements to ensure a successful Cloud implementation:
- Start with small, low visibility applications rather than trying to migrate large scale, agency wide applications.
- Make sure mission owners are committed to the implementation
- Set a reasonable level of expected cost savings, and prove that those savings are being achieved.
Focusing on the mission owners and their experience with migrated applications is important in establishing the “reliable” and “cost-effective” portion of the Cloud mandate. Are Cloud based applications working just as well as the locally hosted ones? Are there any problems integrating the as yet unmigrated applications with the newly migrated applications? If the Cloud based applications are not as reliable as locally hosted applications, do the savings justify the move? If not, can you back out and return to your previous application? These questions are all much more manageable with small, low visibility applications.
However, organizations seldom have applications that are completely standalone. A web processing application and email system may have links to each other, and moving one to the Cloud without the other can cause that integration to breakdown. As Healthcare.gov demonstrated, trying to integrate disparate components requires careful management to make sure that the individual components work together as a whole. Planning for how to re-integrate applications after migration should take place well before the first application is migrated to the cloud.