arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down RSS star Twitter twitter GitHub white-balance-sunny window-close
Integration: Coupling
2 min read

Integration: Coupling

This is an old post and doesn't necessarily reflect my current thinking on a topic, and some links or images may not work. The text is preserved here for posterity.

"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:

  • Semantic
    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?
  • Implementation
    Is Application 1 taking a dependency on the implementation details of Application 2? Or do they rely on well-defined contracts?
  • Reliability
    Does Application 1 require Application 2 to be online in order to function? Will performance problems in Application 2 affect Application 1's SLA?
  • Lifecycle
    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 radial plot of different solutions and the coupling they create

A few thoughts came to mind while creating this visualization:

  1. Web services technologies like WCF talk a lot about decoupling, but they are still lead to tight coupling in many ways
  2. I'm probably leaning towards choosing ETL solutions over web services unless my integration requires a lot of application logic
  3. Shared databases are the best way to ensure your applications become hard to maintain

Enjoying these posts? Subscribe for more

Subscribe now
Already have an account? Sign in
Paul Stovell's Blog

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

Comments

You've successfully subscribed to Paul Stovell's Blog.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.