| Loose coupling exists if A affects B ... | Weick's example | |
| 1 | suddenly (rather than continuously) | threshold function |
| 2 | occasionally (rather than constantly) | partial reinforcement |
| 3 | negligibly (rather than significantly) | damping of response (constant variable) |
| 4 | indirectly (rather than directly) | a superintendant can affect a teacher only by first affecting a principal |
| 5 | eventually (rather than immediately) | lag between a legislator's voting behaviour and the response by the electorate |
These characteristics describe aspects of the causal relationship between A and B. Whereas Weick was thinking primarily about people and organizations, we can extend this to situations where A and B are sociotechnical entities of any kind.
Flexibility, Tolerance and Reuse. One way of thinking about loose/tight coupling is the extent to which A (or the behaviour of A) determines the behaviour of B. How much scope / leeway does B have in responding to A? Is B's response to A overdetermined (constrained) or underdetermined (flexible)?
Let's say I'm expecting a delivery from the online grocery store. If the delivery time is specified as 4pm, then the grocery store is constrained to deliver at this time. If the delivery time is specified as between 4pm and 5pm, then the grocery store has greater leeway in making the delivery: optimizing its own schedule while satisfying the defined service level. If I am not too bothered about the exact time of a given service, I can pass this flexibility on to the service provider. This is called tolerance. The delivery time is not so tightly coupled.
But by giving flexibility to the service provider, I am giving up some flexibility I don't expect to need myself. I may regret this later, if something else comes up unexpectedly and I need to leave home at 4:30. The situation is now reversed - I can't leave home until the delivery van has come - my movements are tightly coupled to the grocery store.
More generally, we can underdetermine a service by strengthening the preconditions (I shall be ready to receive the delivery any time between 4pm and 5pm) and weakening the postconditions (the delivery will be between 4pm and 5pm).
Conversely, a tolerant service provider can offer greater flexibility to the consumer by weakening the preconditions and strengthening the postconditions.
Industrial use of interchangeable components has always relied on some degree of engineering tolerance. In software and services, tolerance promotes interoperability and reuse. Accurate orchestration calls for careful matching between these tolerances, at design-time and/or at run-time.
Uptight. The opposite of tolerant is uptight. (This word was used by Bateson to describe systems that are operating close to the limit, and are therefore not able to flex any further. The word is also useful to describe people whose emotions are in this state.)
A contractual relationship can shift from tolerant (loosely coupled) to uptight (tightly coupled) as a result of other changes. As volumes and business pressures increase, resources that were once lightly used may become heavily used. This forces tighter synchronization of the use of these resources.
For example, in a railway system, it is possible to decouple the management of the trains from the management of the track only at relatively modest traffic volumes. As traffic volumes increase, this decoupling becomes increasingly dysfunctional. Similarly, there are huge differences between a major airport in which all the staff and facilities are constantly utilized (and where planes often need to circle in the air until there is space to land) and a minor airport where staff and facilities are unoccupied for large chunks of time. Although the business services may be the same in large and small airports alike, the degree of coupling between the services is not the same. (This will of course be reflected in the orchestration of these services.) And if a minor airport tries to turn itself into a major airport, it will soon discover that the IT architecture inhibits change rather than supporting it.
Paradigm Shift. When systems are decoupled into loosely coupled subsystems, the subsystems are now tightly coupled to the interface between them. Each subsystem can be freely changed, as long as the interface remains the same.
For example, it is common in manufacturing to define a Bill of Materials, which specifies the assembly of parts into products. This is created by a Design or Engineering function, and referenced by various functions including Logistics and Production. There may be a Publish/Subscribe relationship to release new versions of the Bill of Materials.
That's all very well, but it involves some structural coupling at the next level of abstraction. The bill of materials determines the manufacturing process which determines the bill of materials - we are locked into a particular mode of manufacturing. This is okay until there is a paradigm shift in production methods. But as soon as you want to do something radical (such as moving from a Ford-style production line to Volvo-style teamworking production), the architecture starts to inhibit change instead of supporting it.
Changing Requirements / Spiragile / Evolutionary Acquisition. The software architect can easily dismiss these examples as unfair. What can you expect if the business changes the requirements? (Casual shrug of shoulders, palm-upward gesture.)
But SOA sells itself on adaptability. This means that we can't just back away from these challenges ...
Related posts: Loose Coupling 2 (April 2006), Boundaryless Information Flow (June 2011)
See also: Richard Veryard, Business Adaptability and Adaptation in SOA (CBDI Journal, February 2004)
No comments:
Post a Comment