Lessons Learned from Healthcare.gov
There is a theory that was developed by a computer programmer, Melvin Conway, which goes like this, “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” Basically, if your organization has a dysfunctional or disparate communication structure at its core, the technology initiatives you are seeking to put into place will likely mimic it.
This often can be seen as organizations seek to adopt cloud and virtualization models. Recently, we saw this with the launch of Healthcare.gov. Many states, opting out of developing their own health insurance exchanges, have turned to Health and Human Services’ (HHS) federal exchange, Healthcare.gov, to enable users to sign up and research affordable health insurance policies. It was a daunting task to develop and integrate a mix of public and private databases combined with a nearly unprecedented demand for real-time secure information. Unfortunately for HHS, the site’s functionality and performance is receiving ongoing backlash from frustrated users.
HHS Secretary, Kathleen Sebelius recently offered a formal apology to the American people for HealthCare.gov after facing many technical glitches that caused serious frustrations. “You deserve better, I apologize,” Sebelius said to the public in her opening remarks to the House Energy and Commerce Committee. “I’m committed to earning your confidence back by fixing the site.”
Of course, we recognize that hindsight is 20/20, but the lessons learned from Healthcare.gov can be a tutorial for other agencies and organizations seeking to implement a large, complicated IT project involving big data and cloud architecture.
Communication Is Key:
We can’t speak directly to the HHS implementation, but we often find that when too many organizations are involved in an implementation, no one takes ownership. Streamlining the process with a clear understanding of the goals, objectives and strategy for the solution is critical to the success of any technology implementation.
Think about Scalability:
In the case of Healthcare.gov, the demands on data required that the system be scalable and could handle the volume of transactions. HHS used proprietary databases and software that did not integrate well between the system’s requesting and committing of data. The individual systems and integration points were not built with web-scale flexibility and scalability in mind. Leveraging best practices for web-scale deployments utilizing private and public cloud infrastructures would have allowed for greater flexibility and scalability.
Keep it Open:
It was pointed out in a recent NY Times article that “as many as five million lines of software code may need to be rewritten before the web site runs properly.” That is a lot of code, even for a project this big, and it suggests that original code was written instead of relying on open-source external libraries.
Don’t Recreate the Wheel. Follow Guidelines:
What is interesting in the case of Healthcare.gov is that in many cases the enterprise architecture framework that was developed for federal agencies was not always followed. It could have reduced the architectural complexity and lessened the headache that HHS is facing today.
The Common Approach to Federal Enterprise Architecture was created to “accelerate new technology enablement by providing standardization, design principles, scalability, an enterprise roadmap and a repeatable architecture project method that is more agile and useful.”
As HHS is in the midst of tapping into the private industry for expertise that can fix Healthcare.gov prior to the deadline, other agencies and organizations should take heed and consider the lessons learned from this situation. Implementing best practices, following standard frameworks and opening the doors to communications will be critical to the success of your next IT deployment.