As I mentioning in a previous post, I've been doing a lot of deep thinking about Service-Oriented Architecture recently. Over the past couple of years, I've been relentlessly positioning SOA as essentially a set of architectural principles for interoperability. One of the most important interoperability principles is the internetwork principle, which SOA inherited from the Internet: an interoperable network must be designed as a network of (heterogeneous) networks.
But in working with organizations implementing SOA (and its preferred SO- technology, Web services), I've noticed that while they achieved dramatic improvements in basic interoperability, as advertised, they failed to achieve dramatic improvements in extensibility. This is ironic, given the central importance of XML, the eXtensible Markup Language, in SO- technologies. So I've spent the last six months really thinking hard about extensibility specifically and evolvability generally (or course I'm always thinking about evolvability).
I've come up with what I think is a pretty profound insight: interoperability enables evolvability. In fact, to push the point, I'd argue that they are two sides of the same coin. Both are very slippery terms, so let's get specific. Interoperability deals with how different systems interact to form a unified system. Often, the concept is centered on the interaction between offerings from two or more different vendors. For example, if modems from several vendors can interact to communicate, we say they are interoperable. Interoperability is enabled by a common protocol implemented by multiple vendors.
But now think about a product from a single vendor as it evolves from version to version. If the versions need to interact (e.g., communicate directly by some protocol or indirectly by sharing files), then we have what is commonly know as a compatibility issue (specifically forward and backward compatibility). The crux of my insight is that compatibility and interoperability are merely different aspects of fundamentally the same concept: interaction. Interoperability is focused on the interaction among vendors' products implementing a specific protocol version, while compatibility is focused on the interaction among one vendor's products implementing different protocol versions (which includes file or document versions).
But in both cases we are really dealing with variations (versions) of a common protocol. In both cases, a vendor is modifying its implementation of a protocol to add new behavior, remove old behavior, or change current behavior. If products implementing different versions of a protocol can successfully interact then they are said to be interoperable, when the products are from different vendors, or compatible if the products are from one vendor. But despite the different labels, it's the same concept underlying them.
To put it succinctly: Compatibility is simply interoperability between old, current, and new versions.
Accordingly, the better an SOA enables interoperability, the better it should enable compatibility. Of course, the concept of a spanning layer (the narrow waist of the hourglass) is key to compatibility as well. If a spanning layer can be used to unify heterogeneous resources in the bottom of the hourglass, such resources can be different because they are from different vendors or because they are different versions from one vendor. Viewed this way, a rolling upgrade (whose formal definition I cannot seem to find on the web) is simply a federation across old, current, and new versions--in principle no different from a federation across systems from different vendors.
I'll have a lot more to say about interoperability and compatibility; but for now, just think about it.
11:34:11 PM 
