How to build an evolutionary architecture

Description

Around 2017, Antonio Jimenez and Pedro Martos embarked on an ambitious journey: to redefine one of the company’s most mission-critical, most complex products from scratch. After some thorough investigation, the company eventually determined that the architecture style that would prove most suitable to satisfy the requirements would be a microservices-based architecture, taking domain-driven design (DDD) to the extreme and using continuous delivery as the cornerstone.

Some time later, when the system had been running in production for a while, the company noticed the design that emerged didn’t quite fit the one inspired by the beautiful diagrams that had been devised right at the beginning of the project. As a result of various circumstances, the priority of certain functionalities and improvements had been lowered with the passing of time and ended up being discarded altogether. It was pretty evident that the company had to find a way to quantify how far its “actual” architecture was, compared with its “ideal” architecture in order to be able to make responsible, focused decisions in the future. The main objective was to come up with a tool that it could run against each new version of the system to guarantee that the product would improve in a continuous way, delivery after delivery, without compromising key aspects of the initial design, and allowing seamless introduction of new functionalities in the system. Little did the company know that the tool it was looking for already existed; it was none other than the so-called fitness functions from the evolutionary architecture theory.

Antonio and Pedro share the story of all those architectural decisions they had to make and that contributed to the definition of the company’s fitness functions. You’ll learn about each of them and see how to gather metrics and how these align with architectural requirements. You’ll gain an insight into the concept of evolutionary architecture by looking at a real example.