SOA Day 6 - From Tightly Coupled to Loosely Coupled

Day 1 - Connections = Cost to Connections = Value
Day 2 - Function Oriented to Process Oriented
Day 3 - Build to last to Build for change
Day 4 - Prolonged Development to Incremental Deployment
Day 5 - Application Silos to Orchestrated Solutions

Today's mental shift is one that I have blogged about before in other forms; shifting our mindset from Tightly Coupled to Loosely Coupled. Coupling is another word for dependency, specifically the degree to which a program module depends upon other program modules. A certain degree of dependency is obviously going to occur within programs that actually provide value. The key is to make it no more than absolutely necessary.

This is another point that builds off of Day 3. By loosely coupling code we will be better able to "roll with the punches" or shift along with the requirements as they change. Good architectural design abstracts out the bits that don't need to be specific and keeps the coupling from being overly tight.

With SOA this is even more important because one of the classic issues that is seen with services is versioning. One version changes just a little bit and causes a ripple effect. There are patterns and best practices that mitigate this and... what do you know, they are focused on reducing the coupling and providing loose version ties.

Libraries and functions become services in themselves. Using orchestration to pull the pieces together we are then able to adjust simple properties rather than needing to rewrite and recompile code. By keeping the coupling loose systems can use underlying technologies that work the best for the application instance at rather than forcing separate components to be tied to the exact same approach. Of course, for all of this to work a shared semantic framework is required to ensure that messages have consistent meanings across them.