We have all heard by now the issues with the HealthCare.gov site. There have also been a number of other sites created by states and private and public health care companies that support the new ACA system that has had mixed results. Although the federal site has been getting the most attention, and seems to have the most trouble, what is missing is the understanding of just how complex enterprise sites like these are to create. There are a number of outside agencies that need to contribute information and requirements, stacks of regulation and reams of technical specifications and performance matrices that need to be followed. Having been working on such a project, I can speak of these challenges first hand.
But when I read stories about 3 programmers that ‘hacked’ together a site that provide AFC Silver plan price calculations, I was impressed. But after reviewing the actual calculations, UI and even the back-end data for creating a site like this, that is not the difficult part. The difficult part is accomplishing this in a VERY highly regulated and compliance-sensitive environment. Further, creating enterprise compliance level applications are not something you can just whip up on a LAMP stack, you need to be working with enterprise tools, which typically means Java or .Net. Once you are working at the level where you need to worry about Sarbanes–Oxley, SAML 2.0, HTTP Post binding, Web SSO Profiles, SOC2 data centers compliant system for data retention, ensuring privacy, hacker proof, scalable, and data system talking with legacy systems; you are now working at a totally different level.
Since it is very difficult to create systems like this from the ground up, it is sometimes better to grab a mature enterprise product and go from there. In fact, HP’s Autonomy suite is targeted to just such an environment; where one needs to spend far more time around compliance issues then creating the features and functions of the application. What is nice about Autonomy is that they have very specific tools that you can add to your suite that is specifically designed around compliance. So data retention or session login protocols, or data protection is going to be at the enterprise level. As someone who is dealing with this issues day to day, that is a big plus. Or you could go the Microsoft route using SharePoint as a starting point, although I think that may take more work since they do not have as many tools that are specifically targeted at the compliance market. However, with SharePoint, it is a bit easier to get inside-the-box to make modifications or create new features and functions to satisfy your business needs. However, I’m sure there are many 3rd party venders that have offerings around compliance similar to Autonomy, so it becomes a question of cost, what pre-exiting systems you already have in place, and the knowledge base of your current IT department.
Now, that being said, I’m not sure you could take SharePoint or Autonomy and get something like HealthCare.gov working out of the box, but given all the regulatory issues involved, it might be a good start. However, even with platforms like these, developing in a highly custom and closed environment has its challenges. Having also ‘slung code’ in a LAMP stack environment, the time and cost estimations for added features and function are 5 to 10 orders of magnitude. Complicate this even further with the common issue of trying to get these systems to work with other outside data sources, many of them still running legacy code, and you can increase your complexity and thus time and costs again. And the final road block: typically the larger the project, the greater the number of stakeholders that have conflicting and loosely defined demands, missed deadlines for requested information, and at times, inability to make quick decisions because of internal structures. Then you find your project is at even greater risk.
So, now that we have a little better idea what is means to create an ‘enterprise’ and highly regulatory compliant applications, that little hack some guys put together in 3 days does not sound so impressive anymore. This does not excuse the federal site for falling flat on their faces with the rollout, other systems have had challenges day one just as we experienced, but a smart team will understand the risks involved in building these types of applications, and plan for unknowns and last minute changes. As understood by those who have read Mythical Man-Month, by Fred Brooks, grabbing a few more hot shot coders out of the valley is not going to save you here.