Eben Roux

I came across this article on ZDNet: "The bigger the system, the greater the chance of failure"

Now, I am all for "bite-size chunks" and Roger Sessions does make a lot of sense.  However, simply breaking a system into smaller parts is only part of the solution.  The greater problem is the degree of coupling within the system.  A monolithic system is inevitably highly coupled.  This makes the system fragile and complex.  The fragility becomes apparent when a "simple" change in one part of the system has high ramifications in another part.  The complexity stems from the number of states within the system that increases exponentially since they are all coupled.

If we simply break the system down into smaller components without removing the high coupling we end up with the exact same problems.  This is typically what happens when folks implement JBOWS.

What is required is to break down the system into components and remove the coupling.  One option is to make use of a service bus to facilitate sending messages between the components asynchronously.  In this way the different components rely only on the message structures in the same way that an interface (as in class interface) abstracts the contract between classes.  So in a way it is a form of dependency inversion since the components no longer depend on the concrete component implementation but rather on the message structures (the data contracts).

Coupling comes in two forms: temporal and behavioural.  Web services are a classic case of high temporal coupling.  Since a service bus is asynchronous it results in low temporal coupling.  Behavioural coupling is tricky either way.

When I left work yesterday I had to work through a turnstile.  One of those big ones that only one person can go throught at any one time, in either direction.  So it turns both ways.  It is secured so I have to swipe my access card to get in or out.

This got me thinking about how that system works.  Let's look at a highly coupled mechanism:

Since the turnstile allows either in or out the service the readers needs to know which reader does what.  When a request arrives to allow someone access into the building our card reader service checks with the autorization system whether the person has access and if so sends a message to the turnstile to allow it to turn in the relevant direction.  So here our card reader service needs to know how the turnstile works and which card reader is attached to which action.  This is rather high behavioural coupling.

Now for something a bit less coupled.  Let's say our turnstile simply 'unlocks' allowing the turnstile to turn once in any direction.  Now the card reader service simply has to ask whether the person has access to unlock the turnstile and send the unlock message.  So our card reader service now does not care how the turnstile works.  This is low behavioural coupling.

Either way can be implemented but I'd say the first is somewhat more complex to get done.

I just read an interesting article.

The reason I say it is interesting is that silos have been denounced for quite some time now, and they should be.  Yet, here is someone that appears to be a proponent thereof:

"Silos are the only way to manage increasingly complex concepts"

Almost well said.  I would paraphrase and say:

"Bounded Contexts are the only way to manage increasingly complex concepts"

But bounded contexts do not solve complexity on their own.  You definitely need a sprinkling of communication between them.  A lack of communication is what leads to silos.  Communication is a broad term but in this sense is simply means we need a publish / subscribe mechanism between the bounded contexts so that relevant parties are notified when a particularly interesting event takes place.

Without such communication systems duplicate data that does not directly relate to the core of that system.  In this way systems get bloated, difficult to maintain, and complex to integrate with other systems.  Eventually someone will come up with the grand idea of a single, unified system to represent everything in the organistion.  Enter the über silo.  At this point we can say hello to a 3 to 5 year project and after the first 90% the second 90% can begin.

Don't do it!