The Oregonian and Oregon citizens are up in arms over the Cover Oregon website, the Oregon health exchange site that’s supposed to be the local solution to the also non-working federal site. The problem here aren’t the terms of the agreement or even Oracle, who normally I have no problem bashing because they compete directly with my own Paradigma Software.The sort of material the Oregonian has exposed as a part of the Oracle contract are standards in the industry – they ensure that not hitting goals dead on don’t get you sued. The reason for this, unlike what you find in most public works projects, is that the contractor has no control over the complexity of the unknowns of the system.
For example, integrating the system with existing systems, or problems created by hardware incompatibilities from third parties. A contractor can be expected to know their own systems well, but they cannot anticipate what happens when you bring together multiple third party systems. Just think about your experiences upgrading Windows or Mac OS X on a really complex system but on a hugely complex scale. Why not go with someone else who has better terms? For the most part, all software contractors use these terms, because they all understand the issues.
What they can do is try to systematize changes. In almost any software contract, your client will change their mind, or discover later they need something added. Changes are usually figured by using a specific hourly rate and ensure the staff are available to do the work.
So where did Cover Oregon go wrong? Lets start at the heart of the problem. Implementing what it is trying to accomplish.
A data system can be all kinds of complex, but if it has well defined rules and lots of load testing (will it endure if its hit with a lot of requests), you can expect it to work and keep working, provided you don’t make any other types of changes. A system like that can integrate ways of managing rule changes, but only insofar as the kinds of changes are known. Is a rule change a simple calculation? No problem. But what if a rule change has to pull in new types of data for a calculation? Well, a little more difficult. You have to test that intensively, especially if the sources are not entirely reliable. But what if the type of rule is changed? For example, a rule changes from being a multi-source automated calculation (pulling data from multiple sources and doing something new with it) to something that requires examining digitally scanned forms for pieces of information? That isn’t something that is implemented by flipping a switch – not unless all possible changes are known in advance, when the system specifications were first written.
Implementation is a problem because its not possible to know in advance what kind of changes are coming. Calculations themselves may be easy to change, but complete rule changes means re-engineering. And that means every time there is a major rule change to how the Affordable Car Act is implemented, the technology costs are going to be high – for every time they happen. For the kind of user experience the Obama administration and the public want, Obamacare is simply too complicated, with too many third parties involved. That’s a political problem, not a technology problem. Don’t be distracted by the technology issues; the source is not technological.
There could be some other issues at work here with Oracle, or government management.
Oracle’s database technology is well known in the industry for being among the most expensive of its kind, both for the software and for the maintenance. That’s one of the reasons why smaller companies like my company Paradigma Software, with its Valentina technology can continue to thrive. Oracle is the Microsoft of database technology companies. Were they the best choice for this project? I can’t be sure, but I know why I wouldn’t hire them for this project.
I can also see fault at both the Federal and State level. I already talked about the source problem of Obamacare being too complicated, but what about implementation insofar as governmental management? This project is so complex that technology experts who are among the best in their field cannot really anticipate all the variables of the project. Federal and state level don’t have that kind of experience. They are sort of making it up based on their best understanding of a complex document and technology that’s outside of their understanding or experience. This is exactly why complex software development work is not done in-house, but contracted out at very high rates to government contractors. Your direct managers in government are at best, technology project managers that report to administrative executives. Could this combination contribute to the debacle of Cover Oregon? Of course. But they aren’t the source of the problem – it is the complexity.