Services Oriented Architectures

While I’m thrilled to see SOA momentum, my cynicism tells me that many of the headline grabbing initiatives in health care are poorly conceived, based upon what I’ve read and heard from those involved. I see a gold rush to SOA in health care, but many people still don’t “get it” when it comes to fully grasping SOA concepts. Ironically, we are over complicating the basic software engineering issues and overlooking the simple lessons-learned from previous similar frameworks and building blocks like JCL, DCE, RPC, OOP, CORBA, and COM. More than any other point, I emphasize that SOA concepts are not new, nor revolutionary. They are very much evolutionary, and the more we in the health care industry understand about the history of events, methodologies, and technologies which preceded the current attention on SOA, the more likely we are to be successful and avoid the mistakes of the past. Kevin Chamberlain in Harvard Business Review On-Line wrote: “Leaders often fail to consider history because they have an unhealthy sense of their own uniqueness, and they have a sense that the events around them are 'peculiar' to their time and therefore history is of little value.” I see young and inexperienced software engineers and marketing representatives from vendors who tout the heroics of their capabilities in SOA, yet can't answer basic questions like:

• What led to CORBA's poor adoption rate?
• Which companies have grasped the essence of SOA and are leveraging it best and how?
• How do you balance fine and coarse granularity of services in an overall design strategy?
• What principles of granularity have you developed for your software engineers?
• What's the value of UDDI in a smaller organization with no intent to publish?
• How does an entire industry manage UDDI without the content imploding over time?

One of the most important and first SOA steps in health care is simply the development of a semantic list of services and the basic API's for services associated with our industry. This exercise is equivalent to defining the message types in HL7, but at the software services layer, not the messaging layer. To use another metaphor, think of data modeling at the software services layer. I believe HL7 is the best governance organization for this new "SOA Standard" to reside, but I'm not encouraged by HL7's embrace of or progress on the topic so far. I'll keep my fingers crossed.

I was a chronic agonist to my friends and colleagues at Intermountain Health in the late 1990s about this topic. Arguably, the failure of our relationship with 3M and the Care Innovation Suite can be traced to a poorly designed services layer. In 1998 or 1999, we finally held a retreat at the local Marriott and documented the list of core software services, and their behaviors, which would define a future path for our development efforts. I'm not sure what happened to that list-- I would love to have a copy-- but the 3M relationship was eventually replaced by GE, and the development of the 3M services fizzled. I hope the current development agreement between GE and Intermountain has somehow resurrected those core services, at least conceptually. Developing the list of services does not represent a "rocket science" endeavor. It's a day-long affair with a handful of bright people who understand software engineering and healthcare processes. Iterative improvements on the list will go on forever, but getting started is not that complicated.

Anyway, the bottom line is: We are transitioning from a "buy and maintain" to a "buy and develop" culture at Northwestern and we plan on making tangible progress with our SOA in 2008, but we likely won’t be looking to any of the early headline leaders in health care for positive role models unless I see a greater appreciation for the history that got us here.