Bite-Size Chunks

Thursday, 4 November 2010 23:03 by ebenroux

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.

"Silo, where are you!"

Thursday, 27 May 2010 09:19 by ebenroux

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!