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.