Building Better Clouds: Four Lessons from the Healthcare.gov Fiasco

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

When your website has become a running joke on late-night talk shows, you know you have a problem. Yet, as CIOs move to cloud architectures, many are worrying that they’ll have a healthcare.gov experience themselves.

Of course, website launches fail spectacularly all the time. It’s not uncommon for new apps and sites to crash, hang and frustrate users in a million and one ways. Eventually, the kinks get ironed out, but those ROI projections you presented to the CEO are now a complete fiction.

Cloud Storage and Backup Benefits
1. Legacy doesn’t equal stability.
2. Evaluate providers for agile delivery capabilities.
3. Test and then test some more.
4. Give priority to open systems.
RELATED NEWS AND ANALYSIS

Cloud Storage and Backup Benefits

Protecting your company’s data is critical. Cloud storage with automated backup is scalable, flexible and provides peace of mind. Cobalt Iron’s enterprise-grade backup and recovery solution is known for its hands-free automation and reliability, at a lower cost. Cloud backup that just works.

SCHEDULE FREE CONSULT/DEMO

This is one of the reasons risk-averse CIOs are hesitant about moving from tried-and-true on-premise systems to cloud ones: fear of the unknown. If an on-premise system goes down, it’s not hard to figure out whose neck to choke. When a cloud application breaks, do you even have the visibility into the infrastructure to know what went wrong?

Here are four lessons you can learn from the healthcare.gov fiasco to help guide you as you adopt, migrate to, and build cloud applications.

1. Legacy doesn’t equal stability.

One thing overlooked as we discuss how profoundly Healthcare.gov failed as a site is that contractors were not able to tap in to the efficiencies of cloud providers like AWS, which until very recently was considered too insecure for federal purposes. Thus, legacy providers such as Oracle, Quality Software Solutions, Booz Allen and CGI Federal were tasked with building a patchwork healthcare.gov system that hearkens back to the late 90s.

You know that old IT saying: “No one gets fired for choosing [Big Name IT Company].” True enough, but, unfortunately, healthcare.gov missed its chance to create a streamlined, agile, cloud-based infrastructure, believing instead that this approach would be too risky.

Most organizations fear moving too quickly with new technologies. Sometimes the truly risky option is moving too slowly and sticking with the status quo, especially when the status quo is quickly disappearing in the rearview mirror (unless you’re stuck in the slow lane, of course).

2. Evaluate providers for agile delivery capabilities.

It’s been more than a dozen years since a few top-tier software developers met at a Utah ski resort and came up with the Manifesto for Agile Software Development. Yet, the very term “agile development” seems to be one that doesn’t translate into healthcare.gov development-speak.

“It’s important to engage service providers with experience in agile delivery methods that can effectively act as a catalyst for transforming delivery capabilities,” said Craig Wright, a principal at consulting firm Pace Harmon. “Ensure that outsourcing agreements include meaningful expectations around agile service delivery performance structures and relevant provisions to hold service providers responsible for quickly responding to changing needs, aggregating their services into an ecosystem-wide, seamless end-to-end service experience for users.”

The second (of twelve) Agile Software Development principle is one that the healthcare.gov team should take to heart: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

3. Test and then test some more.

A lingering question in my mind is: didn’t anyone see this coming? Good developers know about the bugs they ship. They may not have caught them all, but they know they’re in there and that they’ll have to fix them sooner or later. Typically, the product has reached “good enough” status, so shipping even with some bugs isn’t that big of a risk. Let’s just call this the Microsoft model, and that’s not a slam on Microsoft.

However, the Microsoft model dictates that the product is “good enough,” or that it actually works. It may not work perfectly, but if they’re shipping a browser, you can actually browse the web with it.

Judging from all of these healthcare.gov “glitches,” you have to conclude that QA engineers must have all been furloughed during the government shutdown.

“It is clear to us, by the types of issues consumers are experiencing with healthcare.gov, this past month that the site was not fully tested,” said Tom Lounibos, CEO of SOASTA, a provider of test automation and monitoring tools. “One of the most common problems in website development is the focus on the speed of delivery versus the quality of the end-user experience.”

Even if healthcare.gov is a website (and backend) that embraces outdated technologies and architectures, that doesn’t mean newer technologies can’t be pulled in to help with the design and testing. “With the major advances in cloud computing, organizations have the ability to test for millions of users throughout the website development process, quickly and affordably,” Lounibos added. “Not load testing across the entire website to better understand what a traffic spike may do to the user experience is a very painful lesson to learn for owners of consumer-facing websites.”

4. Give priority to open systems.

One of the rumors circulating this week is that Verizon will be tapped to fix healthcare.gov. But there’s a problem buried in that solution. It’s not always easy to jump ship this far into a project. The existing contractors, including GCI Federal and Booz Allen, will have to release their proprietary code to Verizon (or to whomever the fixer ends up being). That fact alone makes the repair more complicated and difficult.

As you evaluate various cloud providers, platforms and tools, it’s worth putting “open source” on your list of selection criteria. Then, if something goes wrong, it’ll be much easier to throw the fools causing the problem overboard and bring someone else in who can take the helm without a lengthy transition period.

Jeff Vance is a technology journalist based in Santa Monica, California. Connect with him on LinkedIn, follow him on Twitter @JWVance, add him to your cloud computing circle on Google Plus, or just shoot him an old-fashioned email at jeff@sandstormmedia.net.