"Coupling", in code, is usually described as loose or tight, and is a way of measuring how dependent one piece of code is on another piece. In integration, we talk about coupling between systems. But it's not as simple as loose and tight; there are many different kinds of coupling between systems, and that's the topic of this post.
When choosing an integration approach, coupling can be measured along many dimensions:
Application 1 understands a "Customer" as someone with an active, billable subscription. Application 2 understands them as anyone who has filled in the online Register form. Will one application be forced to conform with the other? Or can the two understandings co-exist?
Is Application 1 taking a dependency on the implementation details of Application 2? Or do they rely on well-defined contracts?
Does Application 1 require Application 2 to be online in order to function? Will performance problems in Application 2 affect Application 1's SLA?
If Application 1 grows old and is replaced with another system, will Application 2 need to change (either in code, or in configuration)?
- Source Cardinality
Application 1 uses information from Application 2. Will Application 1 need to be changed if Application 3 is introduced as a supplementary source of information?
By splitting coupling into some different categories, we can apply them to some of the integration solutions we've explored.
Coupling in integration solutions
For each solution, I gave the dimensions of coupling a rating from 1 to 5 (1 being loosely coupled, 5 being very tightly coupled). I came up with the scores based on the highly scientific approach of using my gut:
A few thoughts came to mind while creating this visualization:
- Web services technologies like WCF talk a lot about decoupling, but they are still lead to tight coupling in many ways
- I'm probably leaning towards choosing ETL solutions over web services unless my integration requires a lot of application logic
- Shared databases are the best way to ensure your applications become hard to maintain
Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool.
Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.