"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
Enjoying these posts? Subscribe for moreSubscribe now
Already have an account? Sign in
Hello, I'm Paul Stovell
I'm a Brisbane-based software developer, and founder of Octopus Deploy, a DevOps automation software company. This is my personal blog where I write about my journey with Octopus and software development.
I write new blog posts about once a month. Subscribe and I'll send you an email when I publish something new.Subscribe