Wow reclist? Thanks guys!!! :-) Lots of good input from IT folks coming in...
As someone with nearly 30 years in IT and having worked on federal IT implementations for most of that time, I have a few observations on the "debacle" that occurred during the rollout of Healthcare.gov. Follow me below the orange Mobius for some discussion...
There are a number of alleged flaws to the design or architecture of the system. In addition, there are some assertions about how the companies involved came to be selected.
1. The vendor
Apparently it is being asserted in right-wing blogs that this was a sole-source procurement.
Anyone who knows federal IT can tell you that sole-sourcing new development is almost impossible. Even sole-sourcing operations and maintenance (O&M) of existing systems is rare. The Federal Acquisition Regulations (FAR) make that very difficult. It is far more likely that this contract went to the lowest bidder. Despite the evolution of "Best Value" procurements, far too often federal contracting offices interpret it as lowest cost, either because the RFP didn't correctly weight technical factors over cost or didn't probe deeply enough into delivery capability. And again, given the FAR, and the type of procurement, the contracting folks may have had limited flexibility in that regard.
I stand corrected. This WAS a sole-source. But in hindsight, given how long and expensive a procurement can be, this may have seemed like a smart decision at the time.
2. The architecture
Here I think there may be legitimate concerns. This appears to have been, more or less, an attempt at a service-oriented architecture (SOA). Given the way this thing is supposed to provide real-time validations of inputs via its "data hub" connecting to remote systems, there could be many points where the systems exposing the data validation (presumably via web services) could have been overwhelmed. What is apparent is that the crucial service choreographer component did not gracefully handle the failure of a service to respond.
This could have been a function of the process design, which in turn came from the requirements provided by the government. Ideally, you would want the system to TRY and validate the input, but if it fails, simply go ahead to the next step but flag the record for subsequent review (what we call a "human task"). This is especially important for synchronous calls where processing on a thread is halted until a response is received. But if that wasn't specified in the requirements, or especially if it was explicitly ruled out, then such graceful handling of an error condition would not have been implemented. If the people in the government insisted on a completely automated data validation process, they exposed themselves to this risk. Whether the vendor understood this and raised it as a risk, is something we are unlikely to discover.
3. Website or app?
As far as turning it into an app, it is not so easy. Apps suck for significant data entry because phones are not designed for typing. Furthermore, there are limits to what "responsive design" can accomplish when you have to enter a lot of data, plain and simple: screens that work great on PCs or Macs will be virtually unusable on small form factor devices.
Yes, the youth of today are more likely to use phones for internet access, and this is particularly true of less affluent youth. But the fact remains, some things are just not good on mobile devices, and it really is a limitation of the devices rather than the applications. There is such a thing as fit for purpose.
4. Government fails again
I have read a lot about how this just shows how incompetent the government is in general, and with specific reference to IT in particular. I think this is horseshit, frankly. The primary difference between government IT failures and corporate IT failures is that the former tend to be on the front page of the Washington Post whereas the latter do not.
For example, how many of you endured the debacle that was Virgin America's switchover to the Sabre reservation system? This is a system that most airlines use and it should have been smooth and easy, but instead features of their website didn't work for days or even weeks. Mostly this surfaced in the tech press because Virgin is practically the house airline for the tech community (full disclosure: I absolutely LOVE Virgin America but a fail is a fail).
Here is a list of 10 Famous ERP Fails that again most people don't know about. (The last one in the list is kind of a gag.) But again, this stuff happens all the time in complex implementations.
I've seen a lot of people write that "we should have had Google or Amazon engineers build this." Well, look at the outages of the Amazon and Microsoft clouds. These are companies that have spent billions of dollars on infrastructure, and it is a core competency for them. And yet, stupid things happen and boom, down it goes, for hours, sometimes many hours. And Facebook has had it share of coding fails, where they expose such and such or whatever. These companies tend to fix their problems quickly, but the problems still occur.
My personal favorite is the Romney campaign's abysmal tech failure. You could write a textbook on that one.
5. In Conclusion
I am sure there are many people involved in Healthcare.Gov whose individual decisions were quite rational at the time given what they knew or thought they knew, but who with the benefit of hindsight would make a different choice. That being said, the unexpected always happens, and the measure of individuals, companies and governments is how they handle it. If they get this fixed in a couple weeks, six months from now few will remember it. But it is NOT another example of a government failure. Failure is part of technology. That's why it is wise to always be at least a bit skeptical about betting the farm on it.