Evolution and Systems Architecture
The “Evolutionary Architecture” phrase has already been coined by Neal Ford, Rebecca Parsons, and Patrick Kua in their excellent book “Building Evolutionary Architectures,” but I would like to add a new perspective to the whole concept of evolution in regard to engineered systems.
The topic of this article develops the idea mentioned in “Chapter 8: Putting Evolutionary Architecture into Practice,” ”Product over Project” section of the abovementioned book.
At first, the evolution of engineered systems is very different from the biological evolution theory in many aspects:
- There is always “someone” who evolves the engineered system. This is important because we can talk about different practices, styles, and models that this “someone” (engineer, architect) can use to evolve the system.
- We don’t need to wait for multiple generations of the system to define and accept the best evolutionary mutation of the artificial system. More evolution cycles in less time is possible.
However, there is also at least one similarity between bio- and techno-evolutions I want to focus on:
Parallel evolution is possible: like mammals have a musculoskeletal system, digestive system, nervous system, and the cardiovascular system evolved in parallel (did you notice functional subsystems listed here? :) ).
The same approach works for engineered systems:
Engineered systems can be evolved by concurrent evolutionary streams on their functional subsystems.
And we know that “functional subsystems” as a systems engineering term means “Domains” (or more precisely, “Bounded Contexts”) in Domain-Driven Design. Please note that I don’t mention any architecture styles here: This rule works for modular monolith, microservices, microkernel, and any other style except “big ball of mud” for obvious reasons.
How can we leverage this in our mission to build “an ideal” architecture development flow?
Systems Evolution in Architecture Flow
The first and most important thing we must do is reset our “origin of coordinates” in architecture work from Feature to the Domain.
It is similar to the “Product vs. Project” mental model but is one step closer to architecturing maturity.
All engineering organizations are eager to build an ideal “features delivery factory,” which is fine. To achieve that, their leaders and architects focus on crafting the most efficient processes, artifacts, and templates, aiming to define a target feature. This is also fine. Unfortunately, in most cases, this focus on features comes with the high cost of losing the focus on the whole system. Fortunately, with some effort, we can have both an efficient feature-focused pipeline and a system-level evolution representation.
We not only need to remember that each feature is just an incremental mutation of the whole system. We must build our architecturing flow around this idea to benefit from this idea at its full potential.
…
Domain-centric Architecture Flow
Traditional architecture deliverables for any given Feature (aka product increment) may look like this:
or this:
There are many other combinations of architecture descriptions and views like that, but most of them lack an evolution perspective (sorry, but fitness functions give you zero information about how your business domains evolve — they only let you know if the quality of this increment is below expectations).
What we can do here is to model a Feature as an increment of one or multiple Domains in a form like this:
This metamodel gives your team additional perspective on architecture decision quality evaluation:
1 See all changes together (Feature-centric view) in the same way as it was in a classic design.
2 See each horizontal aspect in 3 states: current — change — target
Or logical
Or technical
In the following article in the series, I will add samples and provide more details on the process of designing systems in an evolutionary way.
