follow up on SOA/ESB discussion

I got cut off from the call yesterday before being able to ask my question, so I'll post it now.

The speaker spoke about loose coupling as a feature of SOA and listed several types.  However, from my perspective, these all seemed to be "tight coupling."  I didn't see any recognition of linguistic coupling - using language to bind they space together in a semantic sense, rather than pre-defined, APIs that only deal with the syntax of the interaction.

This may seem like a strange question to those who have only worked with early-binding languages and systems, such as Cobol, Java, or C#.  But those who have used late-binding symbolic languages such as LISP, Prolog, or MUMPS see things from a different perspective.

The World Wide Web is "coupled" through language (linguistic expressions in HTTP, HTML, and URI linguistic domains) , not APIs.  Wikis are "coupled" through wikiword syntax, not APIs.  Spreadsheets are coupled through the visual display of rows and columns and their underlying formulas, not a collection of APIs.

VistA is based on the late-binding, symbolic language perspective - closer to artificial intelligence than a banking system.  And like the web, wiki, and spreadsheet, VistA can be seen as a technological "engine" driving a community of users.  Trying to understand Vista by reducing it to the "lines of code" perspective is a little like trying to understand the World Wide Web by studying the HTTP protocol.  You can't understand how Google, Amazon, and eBay succeeded by staring at the code in the Apache HTTP server.

My other question revolves around the definition of "Enterprise" in the architecture.  Are we defining enterprise to be a single VA/DoD/IHS health care enterprise?  Departmental systems? Regional?  Hospital? Clinic? Patient treatment Team?  Patient?

VistA grew up as a patient-centric model - the Patient file, interacting with the User file, was foundational to evolution of the system, and was a way of "creating a path of least resistance" to a comprehensive system.  VistA was "integrated" by virtue of not ever "disintegrating."

So, when I see folks talk about creating an "integrated" system, I ask myself, "what caused this system to disintegrate in the first place?"  Until these forces of disintegration are dealt with (for example bureacratic turf wars between the integrating parties), I suspect we are just going to continue trying to get out of a hole by digging it deeper.

My concern is that it we are moving to a "Humpty-Dumpty Integration Model" - breaking things into pieces in order to integrate them back together again.  This, of course is enormously attractive to the Systems Integration industry, who stands to profit from all of the complexity of the integration process - and the more complicated they can make the integration, the more money they can make.  Change orders made once the system is in place will be enormously more profitable than the original system cost.

In any case, I think we need to VERY carefully examine the coupling mechanisms in the future system, and recognize that APIs are only one way of linking systems.

like0

Comments

I found it interesting. . .

Carol Monahan's picture

Tom: you were probably off of the call by the time it came up, but it started to become clear that - although he was an expert on SOA called in to explain ESBs to us - Mr. Bell was not addressing the specific situation of VA and VISTA.

When pressed about the need for an ESB in various scenarios, he did state that an ESB is simply a particular tool, and not something that is universally a good idea. He stated fairly clearly that, depending on the goals one was pursuing, an ESB might be unnecessary or indeed a hindrance to a good solution.

like0

follow up on SOA/ESB discussion

conor dowling's picture
Tom, I like this split: "coupled through language" vs "API, syntax coupling". I'd add that coupling in language isn't rigid: you can partially understand and still operate. This is a key difference between language and rigid pipes: you don't need to understand everything on a web page (human) or web document/rdf (machine) in order to operate. With APIs, complete mutual understanding is expected. Now there's an argument for tighter (not complete) coupling when you're changing things - you have to know valid combinations - but reading/querying can be very loose. As you well know, when you query VistA data, all you need to know is a resource's address and can then interpret as much of the results as you're capable of handling, but to insert, move data-into VistA you need a fuller definition, one that covers permitted ranges, field combinations, on and on. To Carol's point, ESB good, ESB applicable, ESB, what is it in this context? When stripped of all acronyms and meta-speak, I think ESB means "next-gen, joint DoD/VA messaging" and if it touches VistA (though Mike O'Neill said not necessarily), then for our context it means "replace HL7 v2 as primary messaging medium into and out of VistA" and nothing more than that. If it doesn't touch VistA then it's just a point of inter-organization interoperability and isn't relevant for here. But I don't know. I'd like to know something concrete - scope, VistA-impact - is it a driver to fully analyze VistA, a pull to change it ...? Conor
like0

UNCLEAR QUESTION

Bugzi Scotpress's picture

TOM, WOULD YOU MIND TO EXPLAIN YOUR QUESTION?

like0

RE: follow up on SOA/ESB discussion

James Keith's picture

The Service Bus architecture is meant to enable configuration and coordination of disparate systems - VistA and ELSE.  As I understand Tom, I don't think the goal should be to replace the parts of VistA that are working - and clearly HL7 is working.  We all use it today. The approach here should be parallel to the convergence discussion and they will cross and meander together along the way.  We need to select from the multiple contributing codes-base the elements that work best together today and "RE"-integrate those elements, building a strong core again from the divergent pieces.

To address the industry of integration and the process of implementing an ESB for connection to external devices and systems - I would recommend some form of standard interface capable of easily accomodating the multiple standards and interface requirements of both clinical and biling systems.  One of which would include the Open Source Mule ESB - upon which has already been built Mirth, which is a successful ESB/Translation/Interface Engine already in use with VistA in several locations.

like0

follow up on SOA/ESB discussion

conor dowling's picture
J.D., concretely "configuration and coordination of disparate systems" involves particular mechanisms and, as you say, right now when you integrate a stand-alone ADT or Radiology system or ... to VistA, you use HL7. MSC added a bunch of protocols to tie outside systems into VistA. I'm wondering If this is still to be the case. If it is then the ESB is a "beyond VistA" thing. If it's not, if integration is over the bus, then VistA must talk some flavor XML messaging. Which is it to be, moving forward? It's a simple, binary question, the best kind! One example of why it would be good to know - you're told to describe VistA's current HL7 (and vendor add-ons). Why are doing this? Just because more documentation of anything is always better? Or because you want to scope the effort to do equivalent things over a bus? If the latter, you compare-and-contrast, while "for its own sake" documentation lacks context. Conor
like0

follow up on SOA/ESB discussion

Jignesh Patel's picture

Conor,

Not sure I understood 100% what you mean by here. But if we are talking of
using ESB and then standardizing on XML message then why ESB?

-Jignesh

On Thu, Apr 19, 2012 at 6:10 PM, Conor Dowling
<conor-dowling@caregraf.com>wrote:

> J.D.,
>
> concretely "configuration and coordination of disparate systems" involves
> particular mechanisms and, as you say, right now when you integrate a
> stand-alone ADT or Radiology system or ... to VistA, you use HL7. MSC added
> a bunch of protocols to tie outside systems into VistA.
>
> I'm wondering If this is still to be the case. If it is then the ESB is a
> "beyond VistA" thing. If it's not, if integration is over the bus, then
> VistA must talk some flavor XML messaging. Which is it to be, moving
> forward? It's a simple, binary question, the best kind!
>
> One example of why it would be good to know - you're told to describe
> VistA's current HL7 (and vendor add-ons). Why are doing this? Just because
> more documentation of anything is always better? Or because you want scope
> the effort to do equivalent things over a bus? If the latter, you
> compare-and-contrast, while "for its own sake" documentation lacks context.
>
> Conor
>
> On Thu, Apr 19, 2012 at 1:40 PM, jdkeith <jkeith@dssinc.com> wrote:
>
>> The Service Bus architecture is meant to allow configuration and
>> coordination of disparate systems - VistA and ELSE. As I understand Tom, I
>> don't think the goal should be to replace the parts of VistA that are
>> working - and clearly HL7 is working. We all use it today. The approach
>> here should be parallel to the convergence discussion and they will cross
>> and meander together along the way. We need to select from the multiple
>> contributing codes-base the elements that work best together today and
>> "RE"-integrate those elements, building a strong core again from the
>> divergent pieces.
>>
>> To address the industry of integration and the process of implementing an
>> ESB for connection to external devices and systems - I would recommend some
>> form of standard interface capable of easily accomodating the multiple
>> standards and interface requirements of both clinical and biling systems.
>> One of which would include the Open Source Mule ESB - upon which has
>> already been built Mirth with is a successful ESB/Translation/Interface
>> Engine already in use with VistA in several locations.
>> --
>> Full post: http://www.osehra.org/discussion/follow-soaesb-discussion
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/699
>>
>
>
> --
> Full post: http://www.osehra.org/discussion/follow-soaesb-discussion
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/699
>

like0