Coupling and Cohesion in IT Architecture

19.7.2024 In this article, we will examine the concepts that underlie a flexible and scalable IT architecture: coupling, cohesion, and error encapsulation. We will explain how failing to follow cohesion and coupling rules leads to monoliths and hard-to-maintain architectures. At the end of the article, there is a link to a quick test that will help you determine whether your IT architecture is monolithic.

The way elements interact within IT infrastructure gives it certain properties. For example, scalability and flexibility, or conversely, sluggishness and vulnerability to errors.

Understanding these properties and correlations is the key to choosing the right approaches and tools for integrations. Otherwise, a company risks becoming hostage to the tool - for example, by introducing an ESB layer to simplify integrations while still failing to overcome the limitations of the old good monolith.

That is why this article covers the theoretical basis: the concepts of cohesion, module coupling, and encapsulation. We will also propose specific criteria for evaluating the flexibility of IT infrastructure and a stress test to check whether your environment is monolithic.

Coupling, Cohesion, and Encapsulation in Microservice Architecture

Microservices make it possible to update and run individual functions. For example, a user management system or a payment processing module without affecting other parts of the application.
To build a working microservice architecture, you need to clearly define module boundaries. In the context of microservice boundary quality, there are three main concepts: 1.
Coupling is a measure of how interdependent different subroutines or modules are.
In other words, the way and degree of interdependence between software modules within a given IT architecture.
Coupling can be strong (high coupling) or weak (low/loose coupling).
High coupling means a high degree of dependence between modules, which makes them harder to understand, change, and test.
It is perceived as a serious system drawback and is also one of the characteristic properties of monolithic systems.
Low coupling is a system state in which changes in one module do not require changes in another.
A loosely coupled service has only the minimum necessary knowledge about the services it works with and is responsible only for its own data in the shared context.
A loosely coupled service has three main properties:
A small number of dependencies between subsystems (modules)
A low dependency of one module on changes in another module.
Ease of reusing subsystems. 2.
Cohesion is the degree of relatedness among elements within a module, that is, how closely the tasks performed by a software module are connected.
As with coupling, there are two levels of cohesion:
High cohesion is a state in which the responsibilities of components within one module are well aligned and the module does not perform an excessive amount of work. Unlike strong coupling, which concerns relationships between different modules, high cohesion within a single module is a positive sign.
Low cohesion is a state in which one module performs many disparate functions or unrelated responsibilities.
This module property leads to the following problems:
Difficult to reuse
Maintenance complexity, unreliability, constant susceptibility to change
The concepts of coupling and cohesion are closely intertwined.
Coupling describes relationships between objects across module boundaries.
Cohesion applies to the relationships between functional elements within a module's boundaries.
It is important not to confuse these two concepts. In this article, we focus on coupling as an indicator of a flexible IT architecture.
The ideal setup is a combination of loose coupling between service modules and strong cohesion between the components inside a module.
That is, when a module has a small number of external links and is responsible for solving related tasks. 3.
Encapsulation is hiding implementation details inside a microservice.
These details are, in a sense, placed in a capsule so they cannot be damaged from the outside.
The idea is to use only the data that is available and not dig into the internals.
In other words, a service should know the minimum possible context and data about the other service it communicates with, and it should use only what is available by default. For example,
David Parnas, a Canadian computer scientist and one of the creators of the software modularity concept, viewed the links between services as the assumptions they make about one another.
The fewer such assumptions there are, the easier it is to change one part of the service without affecting another.
Reducing the number of links and the amount of information services share with one another makes development faster and the service more transparent and flexible.

We'll curate materials for your task

clients@kt.team Telegram @kt_team_blog

We'll reply within 30 minutes and send relevant cases, diagrams, or analyses tailored to your context.

What does all this mean in practice, and what does shared context have to do with it?

Before moving from complex theory to practice, let us introduce the category of context. In software development, there are two contexts - the application context and the enterprise context. Service-oriented architecture, microservice architecture, and monolithic architecture are built around context. For example, orders in the contexts of a CRM system and an online store (e-shop) are different things.
Order attributes in a CRM system and an online store are different:
For the enterprise context, it is important to know only a limited set of order parameters - for example, the ID, customer, and amount.
All other CRM system attributes are not needed in the enterprise context.
To explain how strong and weak coupling differ in practice, let us look at two ways CRM and an online store can exchange information.
For data exchange, the CRM and the online store must understand each other.
The process starts with sending an order from the online store to a broker, and then another system takes the data and translates it into its own internal language.
But for that, the other system needs to know the context of the first one - that is strong coupling, or a monolith.
Contexts get mixed together, integration becomes more difficult, and a point-to-point approach emerges.
What principles would govern communication between services in the case of loose coupling?
Each system would think it is the only one in the enterprise and would be responsible only for what it contributes to the enterprise context.
Service buses (ESB) are a tool for implementing integrations in a loosely coupled architecture.

Key Signs of a Loosely Coupled Architecture

A loosely coupled system is easy to scale and extend with new services - other systems do not know that you added something to the shared context and continue managing their own backlog independently. In a tightly coupled or monolithic architecture, a point quickly comes when developers are overwhelmed by endless integration fixes, cross-team testing, order exports, and so on.

But something still keeps working incorrectly, and at some point changes also become economically unfeasible. For example, in 2001 Amazon faced a similar situation→, when its monolithic architecture caused major delays in releasing new features and difficulties in change management. In the end, the move to microservices improved scalability and development speed, although it required significant investment from Amazon in infrastructure and management. 2. Fault tolerance.

In loosely coupled integration, errors are encapsulated thanks to the small number of connections between services.

If one stream fails, all the others continue to work as usual.

At the same time, the system handles even peak loads without issues. 3.

Simple monitoring and fast incident resolution. In tightly coupled systems, monitoring and incident resolution fall to a super-senior engineer, often an overloaded one, because only they can untangle the spaghetti connections→ between services and find the source of the error. In loosely coupled systems, monitoring is straightforward and can be delegated to support. You can also set up automatic alerts for threshold breaches. 4.

Improving any one service does not affect the operation of all the others, and new data streams can be launched quickly.

Companies with loosely coupled architecture implement new services faster.

The faster innovations are introduced, the lower the lost opportunity.

According to experts, more than 80% of companies worldwide already use microservices→ to improve their chances of winning the competitive race. 5.

Here we return to the concept of a shared context and the example of a CRM system and an online store within the same company. In monolithic systems, each request from one system to another must be translated into its own context.

This leads to data errors, losses, and inaccuracies. In loosely coupled domains, this problem does not occur because each system is responsible only for passing its own data into the shared context. 6.

Protection against vendor lock-in.

The fact that a specific service has integrations with others does not prevent that service from being replaced or modified. And integration can be delegated not only to the team that develops the external service or to the vendor, but also to any developer or contractor.

Take the IT Architecture Quick Test

Find out whether you have a monolith or a loosely coupled architecture Take the test

Contacts

Let's Discuss Your Project

Leave your current contact details and describe your task. We will come back with clarifying questions and a proposal for the next step.

Characteristics of flexible, scalable IT infrastructure: a primer on the basic concepts and key evaluation criteria