Evolutionary architecture in practice
What it is made of and when to start
Slide contents
1. Evolutionary architecture in practice
What it is made of and when to start
2. The company grows faster than the architecture settles
Why we need evolutionary architecture
16M+ customers, growing about 35% a year
A multi-product company with its own IT verticals
The products are merging into an ecosystem
Monolithic teams split into stream-aligned ones
3. Tech debt can be repaid evolutionarily instead of via a 2.0
Why you need evolutionary architecture
Tech debt accumulates as the system grows
Left unpaid, it can lead to bankruptcy
That turns into revolutionary 2.0 and 3.0 systems
But the process can be approached evolutionarily
4. 01. What is architecture?
The two definitions the talk builds on
5. A decision's importance is the cost of changing it
What architecture is
The set of important design decisions shaping a system
Importance is defined by the cost of change
And a shared understanding of trajectory and boundaries
Where the project is going and its mental model
6. 02. What is evolutionary architecture?
Incremental and guided change
7. Small changes must stay on course
8. 03. Incremental change
A closed loop from idea to deploy
9. An increment is a closed loop, not a single step
Idea → requirements → development → deploy
Idea
Requirements
Development
Deploy — and the loop repeats
10. 04. Fitness functions
How architectural conformance gets measured
11. A fitness function is both a guide and a constraint
The definition from the «Evolutionary Architecture» book
A measure of how the solution fits its context
And that context keeps changing
It acts as a guide for how architecture evolves
And as the constraint that evolution runs inside
12. Tests and metrics validate architecture
13. Dimensions differ in their architectural importance
14. There are tools to check fitness functions with
Tooling for automating fitness function checks
Static code analysis and testing frameworks
Penetration testing and load testing
Monitoring and logging
Architecture checks: ArchUnit, Danger, fitv
15. 05. Appropriate coupling
Modularity and organizing components
16. Cohesion looks inside a module, coupling looks out
Modularity, cohesion, coupling
Modularity — a logical grouping of related code
Cohesion — how much the parts belong in one module
Coupling — the interdependence between modules
One is about links inside, the other about links between
17. Stable components need abstractions
18. 06. How do you know it is time to evolve?
Team evolution triggers and their link to architecture
19. Change the teams and you must change the system
Conway's law, and brownfield rather than greenfield
Organizations design systems that copy their communication
The desired team structure changes
So the system has to be redesigned
The business cannot pause — so we redesign evolutionarily
20. Three signals that teams need to evolve
21. The questions we covered
What evolutionary architecture is and when you need it
What evolutionary architecture is
Why it is needed
What it consists of: incremental change
…fitness functions and appropriate coupling
When it is time to evolve the teams and the systems
22. Links for further study
The sources from the talk's closing slide
«Evolutionary Architecture» and «Fundamentals of Software Architecture»
«Clean Architecture» with two reviews
«Team Topologies» and its three-part summary
Articles on the double loop and Essential Architecture
23. Thank you!
polomodov.tech
All slides and links are in the Telegram channel
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@book_cube