Don't burst in Tiers: setting the boundaries in a right way

The idea of decomposing application into layers (logical vertical split) or tiers (physical vertical split) isn't new - it's bread'n'butter of systems architecture. Reasons for such a split are still...

4 years ago

Latest Post How does Dunning–Kruger effect impact collaboration in tech teams by Sebastian Gebski

The idea of decomposing application into layers (logical vertical split) or tiers (physical vertical split) isn't new - it's bread'n'butter of systems architecture. Reasons for such a split are still the same (as they were in 90s, 80s & beyond):

No-brainer, right? Good.

Problem appears when you consider the boundary between layers / tiers as a boundary between separate systems / applications. Developed & maintained:

What happens is - upper tier is very heavily dependant on lower tier, because pretty much every scenario is a spike (goes through all the layers):

X-layer / x-tier comm is not an interface (or API)

"Wait, in multi-tier scenario the upper tier just calls lower tier using some sort of communication standard: REST, WebService, MOM, etc. The contract is agreed, data structures are confirmed - doesn't it sound like a typical on-line interface?"

In general, there's some truth in this statement:

  1. such an x-tier contract is a form of abstraction that hides the implementation behind itself
  2. it's also dedicated for the sole purpose of fullfiling upper tier's needs - if there's another 'client', it can easily get another contract
  3. actual usage pattern is very simple & interface-like: you know who's the caller, who's provide the 'service', so it's also quite easy to set up the (theoretical) responsibility

However, there are some differences as well:

  1. there's completely different velocity of change - when there's a functionality to get developed, in most cases all parts (upper tier, lower tier & the contract) get modified
  2. granularity of operations is different - they are very atomic & vivid: this kind of contract gets changed pretty much on daily basis - I don't mean just data structure changes, but also behavior coupling changes - the expectations on the functionality behind the contract that impact the functionality in the upper tier(s)
  3. in the usual cases, when two modules (microservices, separate applications) depend on each other heavily (each action / service calls actions / services of other application / module) it means that we have a problem with coupling. In this particular case it's not high coupling, but rather a high cohesion -> these tiers BELONG together (domain-wise): so you have to leverage that (developer together, test together, deploy together) instead of forcing the decoupling

The lesser evil(s)

Sometimes your reality is just broken & the split is already there: tiers belong to different teams, org units or even companies (sic!). To make it inconvenient:

But these are just workarounds & anesthetics. In the end there's just one solution to the problem:

MERGE. TEAMS; MIX. SKILLS.

... to make sure that the full spike will be fully covered within one, interdisciplinary, cross-functional team.

Regardless of:

This will help you to:

  1. enable separate (& independent) workstreams
  2. limit the number of unnecessary dependencies between teams
  3. set proper boundaries between actual subdomains (easy to abstract as products), not within them

Pic: Betty Crocker. http://www.bettycrocker.com/recipes/rainbow-layer-cake/4969fed8-141e-45f5-9a04-e03addd20fbb

Sebastian Gebski

Published 4 years ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.