Sunday, July 26, 2009

Open Source as an Architectural Driver

Phillip Longman's post about open source products in healthcare (specifically, the VA's "health IT system") talks about how the Midland Memorial Hospital's installation of the VA system went well because it was easy to use, and it was easy to use because it was open source.

Well, the first one wasn't a surprise. Well-designed easy to use software is well, easy to use. The fact that this leads to successful system uptake/user adoption should be no more surprising than the fact that people like their iPhones. The second factor being easy to use because you are open source is a bit of mental speed bump: Easy to use open source? Well, maybe if you are a developer. The article states that the ease of use stemmed from its ease of modification. Now I can't comment on that since I am unfamiliar with the product and have never been involved in a hospital centric system.

However, open source and ease of modification? Yes, that fits. A successful open source project, by definition, must be relatively easy to modify: An interested developer should be able to jump in, modify the code and stand up a running test build in short order. Otherwise the project won't attract enough attention to survive. More importantly, I think a system that is easier to modify will leap ahead in functionality even if it starts out behind.

This is one of the reasons we've seen such useful build/test tools come out of the open source community e.g., ant/junit/maven etc.. All open source projects needs tools like these to succeed since they are critical situations where you cannot afford a dedicated buildmeister or QA organization e.g., you're a developer modifying the code to satisfy your needs.

Similarly a clean, modular, layered structure is going to be favored, codependencies (A depends upon B, B depends upon A) are going to be rejected, since they require understanding two pieces of code and their interrelationship to perform a successful modification.

Both of these issues can be more easily compensated for within a "closed source" shop, since revenue-generating projects employing full time personnel can invest the time and discipline to keep things working, even if the software has a few points of poor structure. In addition, if the points of 'bad architecture" are manageable there is little incentive to fix the problem, since it might easily cost more to fix than it's worth, given the costs of running a full-time development team.

One of the strongest examples I think we've seen of this is the EJB vs. Hibernate controversy with the resultant "conciliation" of EJB3. Hibernate, being open source, could give developers what they needed rather than what they "should want" & it won due to its simplicity and speed.

This argues for a bias towards an open source style, even in a closed source system. For example, can your consultants (internal or external) add/modify deep system functionality? Designing your system in a way that supports such modifications will make the architecture better and help keep the product fresh.

Again, why this works for hospital systems is beyond me, unless there has been an undocumented rash of coding by doctors and nurses.