In the previous post, we started to discuss a specific type of coupling, the coupling between processes in a distributed system. We discussed the fallacy that loose technical coupling, i.e., using a message-based communication style is sufficient to ensure loose coupling between processes. We learnt that instead we need to implement loose coupling at a technical and a functional level to actually become loosely coupled.

Coupling is a big issue in software design. With software landscapes becoming more and more complex, coupling painfully steps on our toes whenever we attempt to change things. Hence, we want to reduce coupling. On the other hand, without any coupling systems and their parts would not be able to interact. Hence, we need coupling – feels a bit like being stuck between a rock and a hard place.

In the previous post, we discussed what we find at the peak of Mt. Resilience, the peak of advanced resilience (anti-fragility).

In the previous post, we broadened our view and learned about the sameness of business and IT. We also used the four response types of resilience to change our static approach regarding threats towards a more dynamic one, including continuous evaluation of threats, learning and repositioning in an ever-changing threat landscape. This adds the last missing shard to resilience: Anti-fragility.

In the previous post, we discussed what we find at the high-plateau of basic resilience.