Are we not grasping the nature of the problem itself? TPM Reader ST says the issue isn’t so much the website as legacy computer systems throughout the federal bureaucracy and the need to stitch them all together until a single interface.
I’ve been following the flawed Healthcare.gov rollout with some interest. I’ve been working in the technology space for over 10 years, with experience both working on Federal systems and in the private sector.
What has surprised me most about the reaction to the rollout is how even seasoned IT pros seem to be misunderstanding large parts of the problem.
Your recent reader comments from RN and JC are focused on the HealthCare.gov website itself – how fast it loads, the code libraries used to build it, etc. While some of the initial hiccips on October 1 may have been due to issues with capacity on the website itself, I can say with a lot of confidence that the site itself is not the problem (or only a small piece of a much larger problem), especially now that the “minor” glitches like account creation seem to be mostly fixed.
The Healthcare.gov site itself is probably one of the best Federal websites ever built, both in design and in the appraoches used to code it. It’s pretty, usable, relatively fast, and overall really quite good. So then what’s the problem?
The Healthcare.gov site itself is just like a server in a restaurant. The server may be the main point of interaction you have — bringing you menus, taking your order, and bringing you food – but without the kitchen, there’s no meal. And yet when a kitchen messes up and can’t get food out, the server often unfairly gets blamed. And it doesn’t matter if you have the best waiter in town if the kitchen can’t get its act together.
Healthcare.gov is basically just showing you your menu of insurance options, taking your order for insurnce, and bringing everything back to you when the order is complete. In tech terms, it’s just the front end. All the heavy lifting takes place on the back end, when the website passes your data to an extremely complex array of systems that span multiple agencies (like so many cooks in a kitchen). A central processing hub needs to get data from each of these systems to successfully serve a user and sign up for insurance. And if one of these systems — several of which are very old in IT terms– has a glitch and can’t complete the task, the entire operation fails for that user. Only if everything works perfectly, and the data gets passed back to the website, does the user have a good experience with Healthcare.gov.
The problem is that throwing more capacity at the website itself, or praising or criticizing how it was built, is as useless as criticizing a server when it’s the kitchen that messed up. Maybe cathartic, but not much else.
The complexity involved in making all these systems work together is tremendous. Reader RN doubted that there are 500 million lines of code involved, but if you add up what originally went into building 10 or so huge systems, across multiple agencies, plus all the stuff to make them work together, 500 million lines of code might be realistic. (Especially as many of these systems are old and have been patched and built onto many times.)
My biggest worry is that the basic vision for signing up for coverage in real time is unrealistic with the old systems in place today. It probably would have been better to either use an invite-based system (like so many startups use) to meter usage initially, or to have the user submit a request and get an email when it’s done processing a couple of hours later. While it’s unlikely that capacity is the only issue, using measures like these to better manage capacity might have helped.
Hopefully all the back end problems with Healthcare.gov will be fixed in short order. But I do worry that in trying to promise a startup-style experience on the back of multiple old and lumbering IT systems, there’s a long way to go — even after all the initial issues with accessing the site itself are resolved.
