Where and why do we still need tight coupling?
In my previous post, I discussed the virtues of loosely coupling, rising it to the level of an IT commandment.
One reader, Richard Veryard, responded in his own Weblog, however, that maybe loose coupling isn't appropriate in all situations, and there still is a place for tight coupling.
As Veryard puts it:
"The trouble with proclaiming the wonders of loose coupling is that it sounds as if tight coupling was just a consequence of stupid design and/or stupid technology. It fails to acknowledge that there are sometimes legitimate reasons for tight coupling."
Why? Veryard points out that "loose coupling carries an overhead - not just an operational overhead, but a design and governance overhead. Small-grained services may give you greater decoupling, but only if you have the management capability to coordinate them effectively. In sociotechnical systems, fragmentation may impair the effectiveness of the whole, unless there is appropriate collaboration."
Veryard added that the good thing about SOA is that it gives enterprise planners the option of either electing to go with loose coupling, or keep things tightly coupled, where appropriate. A highly sophisticated system that requires tight coordination of resources and sub-second response times, such as an air traffic control system, may be an example where tight coupling is required.
I put the question of when it's best to loosely couple or not to my ZDNet colleague here Phil Wainewright, who also runs, appropriately enough, the LooselyCoupled.com site. Phil observes that, yes, "tight coupling is still very important when your process is very stable and you want maximum performance.... Loose coupling comes into play when you want flexibility rather than stability."
Phil goes on to quote another colleague, Eric Newcomer (CTO of IONA), who made this observation about binary XML: “Performance is often cited as a major concern with SOA but this misses the main point – an SOA should be used for loosely coupled integration … Performance is less critical than the ability to access the data.... don’t fret so much about saving the odd second in system response times. Worry about the minutes and hours your users are wasting because they can’t get at the data they need."