Posts tagged ‘loose coupling’

How Loosely Coupled Integration Strategies Can Make Complex Things Simple

We humans (not you and me but all the others ofcourse) have a tendency to handle complex situations by the intuitive strategy of “Separation of Concerns”. At first hindsight, there’s seems nothing wrong with that. Look at the picture of the pedestrian and the bicyclist. It makes perfect sense to separate them by giving them there own “path” so their concerns are satisfied by separation.

But how is this often done in ICT heavy environments? Often we want to separate concerns by adding layers or domains or policies or rules or (loosely coupled) integration strategies. Again, at first hindsight this seems like a good strategy but in practice we see this fail quite often. Why is that? Maybe it’s in the explanation of object oriented theory.

Take a look at the Law of Demeter or Principle of Least Knowledge. Wikipedia states the following about it: “The Law of Demeter or Principle of Least Knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. The guideline was invented at Northeastern University towards the end of 1987, and can be succinctly summarized in one of the following ways:

  • Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
  • Each unit should only talk to its friends; don’t talk to strangers.
  • Only talk to your immediate friends.

It’s the last principle that makes clear how the loosely coupled integration strategy should be policed: ‘Only talk to your immediate friends’. Or to put it more strict: ‘You are not allowed to talk to strangers’.  It’s exactly this “abstraction” rule that is often ignored. The ignorance comes from people who want to let object A (see the picture below) talk directly to object C and not via object B. They are motivated by the deduction that it’s simpler to let A talk directly to C than let A talk to C via B. By ignoring the policy, we in fact introduce an integration mess. Instead of satisfying concerns by separation, we in fact only add more dependencies than we really want. We make things more COMPLEX instead of simple. So if we want to really make complex things simple, our loosely coupled integration strategy should not be for the faint of heart. It should follow the Principle of Least Knowledge and also the Single Responsibility Principle. And it should be policed so that it helps reducing complexity instead of increasing it. Happy loose coupling!

About Centralisation And What You Can Do To Prevent The Binary Kite Syndrome

Do you know what the picture represents? It’s called a Binary Kite. You can find some more examples here. I stumbled upon this picture and got inspired to post an article about centralisation. For me, this Binary Kite represents what you see can happening all the time in our society: the drive for centralization. But most original ideas or innovations start decentralized. And then when they mature and are ready for growth, we allmost automagically see synergy potential by centralizing it. And before you know it, you have centralized so much that the Kite is becoming more of a disabler than of the original enabler it was meant to be. So what should you do when you see concepts growing and growing and becoming massive, dominant, slow, costly, inflexible? Decompose the centralized concept into more or less autonomous but smaller subsystems and introduce modularity and loose coupling between the subsystems where appropriate. Or develop a Creative Destruction strategy and let the environment build up a new, more decentralized ecosystem in parallel that is less massive, less dominant, faster, less costly and more flexible than the centralized original. It’s that easy.

Tag Cloud

%d bloggers like this: