Loose coupling and services oriented architecture

About 8 years ago I tried to sell the development organization I worked for on the term "loose coupling" as a way to build systems. I wasn't the only one back then, the term was floating around. The concept is as old as time, certainly older than software. I wasn't aware it was being used as long ago as 2003 to describe services oriented software design, until an Aufflick pos sent me to an older O'Reily article:

webservices.xml.com: What Is Service-Oriented Architecture

... Now we are able to define a Service Oriented Architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners...

... How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:

1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.

2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services...

Those of us from the medical ontology (SNOMED) and messaging (HL-7 RIM) know deeply what this means. Saying "schema limits the vocabulary and structure of messages" is a bit akin to the famous processing step of "... and then a miracle occurs". Said schema, if implemented, will end up setting in stone the fundamental data model buried within the service. That lesson still lies ahead ...