SVP Cloud Technology Partners

David S. Linthicum, CTO & Founder, Cloud Technology Partners

It’s been more than a month since Healthcare.gov went live. A couple of big questions remain about the U.S. Department of Health and Human Services’ botched launch of the website. This article could be about the lack of ability to scale, including outages, slow page loads and the inability of users to complete coverage applications. Or, we could talk about how some insurance providers say they have received inaccurate application information from the website.

The problems appear related to a number of factors, but HHS officials have talked little about the specific technology problems. However, the problems are pretty clear to me, at this point. There are lessons to be learned by HHS and other government IT leaders who are charged with rolling out new and critical systems.

How Not to Build a Website

The specific technology problems are not at all clear at this point, with HHS officials speaking in general terms during briefings and congressional testimony. However, we do know that the website was plagued with software and database integration issues. Of course, those of us in IT understand that could mean anything.

However, most of those who cover the ongoing issues and technological drama seem to agree that there was no contractor who oversaw the entire architecture of the system. Indeed, contractors were assigned that role in mid-October, after the website had already pretty much failed.

Moreover, the registration issues were hindered, since they made a decision to abandon some site functionality just two weeks before the launch. The problem that drove this decision, I’m sure, was an impending deadline. Most of us who have launched systems or products have pulled back on features within the time box.

Finally, there was a clear lack of website testing to insure production. Only two weeks of testing occurred, clearly not enough. I suspect the system was launched with the contractors knowing full well that it was not ready for the load that would be placed upon it, and they were right.

Of course this system ran within the Verizon cloud, and thus I spoke with reporter after reporter over the last 30 days looking for that “cloud bad” angle. Just to be clear, this thing could have run anywhere and the same issues would have occurred. It was not the platform, it was what ran on the platform. You can fail just as badly in the cloud, make no mistake about that.

The Larger Picture

What strikes me about the issues with Healthcare.gov is that they are pretty much issues that we’ve seen around many system launches within the government. This one just had too many eyes upon it, and thus it turned into a huge embarrassment for the administration. If you push a system development effort to meet a certain set of requirements, in a compressed period of time, these things are more than likely to happen.

The problems with Healthcare.gov are really a systemic problem in how government builds systems in general. Typically, there is no central control and responsibility, or, no single person or organization that is responsible. The workload is too distributed, and thus you have many organizations that are not working or playing together as effective as they should be. The long, and highly regulated procurement cycles, lead to a compressed time for design and development, and almost no testing.

What government CIOs can learn form this includes a few very simple and basic lessons:

There should be a single entity held accountable for the success of the system. This typically includes an architect, who oversees the design and development. If you’re attempting to build one of these systems by committee, you might as well add 50 percent more cost and time to the project or it will fail, just as the Healthcare.gov system failed.

When I consult with companies on the design and development of large cloud-based systems, the first question I ask is: Who’s the architect? If I get an “It’s complicated.” answer, chances are, they are already in trouble.

There should be enough funding and time to accomplish the task. In this world where Agile is leveraged everywhere, and people think they can scrum their way to success, it comes down to the amount of resources you can put on a design, development, and deployment effort, and the time allowed to build the thing. If you lack any of these things, the risk of the system falling on its face goes way, way up.

The problem is that,in many instances, government IT leaders are asked to accomplish the impossible. This is largely due to political promises made without a clear understanding of what they are promising, and thus setting up the government IT staff for failure. Some of that was true with Healthcare.gov.

If government is to move many of their core systems to cloud-based platforms, the ability to migrate existing applications or to create new cloud-based applications is an imperative. These are fundamentally complex tasks, and require a great deal of work and planning, which many government organizations are not prepared to undertake. Perhaps it’s time that we think through these issues before problems that occurred around Healthcare.gov become more common place.