Adaptability = Extensibility + Intermediaries (Federation) + Interoperability? I've been thinking a lot about SOA (Service-Oriented Architecture) these days, and to me, the essence of SOA is interoperability (aka integration). One might say that interoperability is simplly a network-centric way of thinking about modularity—decomposing complex systems into a network of simpler subsystems (modules).
When thinking about modular systems, one can focus on the modules and how the designer has factored the overall system to optimize adaptability (minimize coupling and maximize coherence) within the modules (modular adaptability). Or one can focus on perhaps the most important subsystem ("module"?) in the decomposition: the subsystem that enables the interaction among the modules. A great book with keen insights in general systems thinking, Fault Tolerance: Principles and Practices, refers to this interaction-enabling module as the design of the system.
So for example, if integrated circuits (ICs) are the "modules," then the circuit board that connects them is the "design." Continuing the analogy, there are many ways to design a circuit board—from soldering onto copper traces to a pluggable breadboard. But note that one can view the design as embedded not only in the circuit board, but also in the connectors embedded in the chips themselves. (Another way of putting this is that the design is embedded in both the connectors among the modules and the interfaces exposed by the modules.) A core issue of adaptability in designing a circuit board is designing one that can not only enable hot swapping of ICs (modular adaptability), but one that can also enable ICs with very different connectors to still interact, e.g., 5-volt ICs interoperating with 12-volt ICs, or electrical ICs interoperating with optical ICs.
This is what SOA is all about. As the electrical to optical example shows, however, to achieve interoperability between such different connection types requires a design that abstracts away all physical details and enables interoperability purely in terms of abstract (i.e. informational) identifiers, formats, and protocols (IFaPs). When a physical component has been abstracted to such a degree, it is appropriate to think of it as a service (aka process, abstract state machine) instead of an object (thing, physical machine). Of course, to achieve this level of abstraction (e.g., spanning optical and electrical designs) requires that the abstract design be based on intermediaries between the concrete designs. Such an abstract circuit board design would be a federated design.
Now a data communications network, like a circuit board, is a design that connects a set of modules to form a system. (Actually, both the data network and the circuit boards are both "networks" in the general sense of the term. Perhaps design == ([is equivalent to] network [connectors, intermediaries, and interfaces].) As with optical and electrical circuit boards, different networks have different physical characteristics. (There are in fact optical and electrical networks.) Thus, the core issue of adaptability in the network context is interoperating across two different types of networks so that modules on each network can be composed or combined to form a single system. This of course entails abstracting away from network specific IFaPs to abstract IFaPs that can be bound to any concrete IFaPs. (SCSI in fact does this across the optical [fibre channel] and electric [buses] networks that make up a SAN.)
The Internet did this, didn't it? So aren't we done? Well, yes, but there is no easy way to evolve the Internet IFaPs themselves. We've been waiting for a decade to evolve from IPv4 to IPv6. So in designing a network abstraction to overlay the Internet, we should not repeat the same mistake. We must design it to enable the generation of a wide variety of abstract IFaPs; hence the need for extensible formats (SOAP envelope) and extensible Message Exchange Patterns (protocols). (I'm not sure whether URIs are extensible enough identifiers. I have to look into XRN further.)
So… The adaptability of a design can be broken down into two distinct types of adaptability. First, the degree to which the design enables the modules to evolve/adapt internally, e.g., to enable one module to be replaced by a functional equivalent with superior performance/quality/price. Second, the degree to which the design itself can evolve/adapt.
I think HTTP and REST make the same mistake as IPv4. Although REST enables the evolution of the resources (modules) it interconnects, the REST IFaPs are not themselves designed to evolve to the same degree as the SOAP IFaPs.
7:48:25 AM 
