Musings on the role of Coupling in Complex System Designs
Is loose coupling better than tight coupling?
It's a question that has come up a few times recently with my current client and it's a topic I think is well worth exploring a little deeper. It's a really powerful concept and is, in my opinion, one of the core building block concepts of digital age solution design - and I'm not just talking about software here though that is obviously a fundamental component of any digital age solution.
So, to kick things off let's have a look at the key concepts.
What is Coupling?
For those of you that haven't come across the term before (in a systems sense!), it is one that is often used in the software development domain in the following context:
In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are;[1] the strength of the relationships between modules.
Roughly speaking a system can range from very loosely to very tightly coupled. I'm sure there is some rigorous software engineering method for measuring a systems coupling level but we're not going to get into that here. Let's just stick with the core concepts.
Is there a link with the concepts of Integrated vs. Modular Design?
Before I get into the pros and cons of each coupling design pattern let me also throw in what I believe is a related design pattern that is often used in other domains such as business model analysis - this the concept of Integrated vs. Modular design. This is a concept that I have read about most recently at the site of one of my favourite tech writers, Ben Thompson over at Stratechery.com. Ben often uses this concept when comparing the business models and products of some of the biggest companies in the world. His go-to example of the ultimate "Integrated" platform product company is Apple and the iPhone which is the ultimate black box with interfaces. On the other extreme he sometimes places Microsoft, which has a much more "modular" platform. For example, in the PC design many of the core building block components - hardware and peripherals in particular, were their own black box components using standard interfaces, all of which could be glued together and leveraged by the Microsoft owned Windows platform. Very much a modular design.
So how is this linked with the concepts of tight and loose coupling?
I believe you can equate tight coupling to integrated design and loose coupling to modular design.
I think there is value in seeing whether there are lessons you can take from each domain and see if they apply in the other domain and as a result make each concept more valuable.
Let's see how this might play out ...
Loose Coupling/Modular Design vs. Tight Coupling/Integrated Design
Interestingly Wikipedia has an entry for Loose Coupling but none for Tight Coupling possibly reflecting that fact that, at the beginning, there was only Tight Coupling and that Loose Coupling has evolved from that. Here's what they say about loose coupling:
In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services.[1]
For me it's what I like to also describe as the "black box with interfaces" architectural design pattern. Tight Coupling on the other hand is defined as everything that loose coupling isn't - more inter-dependency, more co-ordination, more information flow. I really like this graphical representation of the 2 structures and their key characteristics:
When it comes to Integrated and Modular design we see the same story in Wikipedia. Integrated Design gets relatively light coverage compared to Modular Design.
Integrated design is an approach to design which brings together specialisms usually considered separately.
Modular design, or "modularity in design", is a design approach that subdivides a system into smaller parts called modules or skids, that can be independently created and then used in different systems. A modular system can be characterized by functional partitioning into discrete scalable, reusable modules; rigorous use of well-defined modular interfaces; and making use of industry standards for interfaces.
https://en.wikipedia.org/wiki/Modular_design
Tightly Coupled / Integrated Designs - Pros & Cons
Here's my own take on the pros and cons on designs that are aligned to the integrated/tightly coupled design pattern.
Pros (yes there are some!):
The best tightly coupled systems tend to be fast and very efficient as there is very little management overhead
When relatively low in complexity these systems are relatively easy and quick to change (within the basic constraints of the system itself). Data integrity is also relatively easy to maintain (mainly because of the low system complexity)
Performance characteristics can hold even when the size of the system grows but the bigger it gets the more rigid/less tolerant to change it will get.
Cons:
This design pattern becomes very rigid when scaled up . Once you get to a certain level of complexity, performance can still be good but general flexibility reduces as making changes, even small ones, becomes really difficult due to the challenges of managing complex system inter-dependencies.
Loosely Coupled / Modular Designs - Pros and Cons
Unlike tightly coupled systems the benefits of the loosely coupled / modular design pattern have been widely documented. Below is my take on some of the key pros and cons I see in relation to this design pattern.
Pros
Ability to build much more complex systems due to clear isolation of functionality into discrete units (services, microservices etc.), thereby increasing the ability of the system to manage all of the complex inter-dependencies inherent in the system
Ease with which component plug and play is facilitated allowing the system to more quickly evolve and improve via component upgrades. Improvements can take the form of increased performance, increased functionality or reduced cost. These are realised by the ability to easily introduce new and improved components with minimum change management overhead.
Cons
Loosely coupled/modular systems incur higher communication overhead as inter-dependencies must be managed through standard interfaces as much as possible, which by their nature, are more complex to manage than simple, custom direct connections.
Data and transaction integrity can also get pretty tricky. Making sure that data integrity does not become a major performance bottleneck is a real challenge as these systems grow in size (often well beyond what would be achievable with an Integrated/Tightly Coupled design).
Suggested guidelines on when to use these different design patterns
This is where looking at the lessons learned from different domains may provide some useful guidelines that you can use on your next design assignment.
Use the Integrated / Tightly Coupled Design approach when tacking something new. It's quicker to implement and it stops you from building too much before you know whether it is really going to work or not.
Use the Loosely Coupled / Modular Design when you've got something you know that works and you want to be able to scale it up massively and at the same time maintain agility and flexibility. Think Netflix and their microservices architecture.
Consider merging the two approaches at the same time. I would argue that the basic "cell" of any efficient complex system is effectively an integrated, tightly coupled system, but which is combined with hundreds, thousand, millions of other cells in a loosely coupled, more modular meta-system.
I'll leave you with one last idea - how about we apply these concepts to organisation design? Where we have a "team" i.e. a manager and a group of directs, we go for an integrated tightly coupled model but between teams in the organisation, we use a loosely coupled, modular approach.
Till next time.
