Advertisements

Why is Healthcare.gov not working? (from a technical perspective)


Most web applications have a architecture like the below.  There are of course nuances and exceptions, but for the layperson, this will suffice.

The “Presentation Layer” handles all the graphical packaging of content in web pages presented back to the user.  This article in the Atlantic has a good description of the Presentation Layer for Healthcare.gov.  This is definitely NOT the problem as pages of just content come back very fast without problems.  Clicking 90% of the links in the Healthcare.gov sitemap come back in under a second.  BUT, a web application with just a good Presentation Layer is like a book with a nice cover design and nice pictures inside; no one will care if the text is not good.  The rest of the Healthcare.gov web application is the text and is seems to be horribly bad at the moment.

The next part of the system is the “Business Logic” layer.  In Healthcare.gov this is called the “Data Hub” and is described here.  There is a tremendous amount of coordination between different web services (Social Security Administration, IRS, Insurers, etc.) to make sure you get the insurance you’re supposed to.  Unfortunately, this is where the software engineers for Healthcare.gov have the least control over what happens, because they are dependent on these other services to relay data back to them quickly.

Finally, we have the “Data Access Layer” and “Data Source”.  This is where all the data is stored (e.g. your name, address, age, etc.).  The data that Healthcare.gov has to collect and then connect to other relevant pieces is tremendously complex and it is very possible that many of the problems lie here as well.  Fortunately, this is one place where you can “throw more servers at the problem” to alleviate performance problems somewhat.

While the answer to the question why healthcare.gov is failing is not entirely clear, I hope you have gained an appreciation for the complexity of this very important web application and how one problem in any of it parts can make the whole application slow down.  Unfortunately, I predict that many of these problems will not be fixed quickly because of their logical complexity.  Throwing servers at the system will only alleviate a small percentage of the problems and ultimately does not substitute for quality software.  Throwing more people at this problem violates one of the few laws we have in Software Engineering — “adding manpower to a late software project makes it later”.

Advertisements