For many years, software architecture was described as "the parts that are hard to change later". But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on the recently published book Building Evolutionary Architectures co-authored by Rebecca anf Neal Ford, investigates how to build evolvable systems. The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework or technique leads to disruption and the establishment of a new equilibrium.

1. PRINCIPLES AND TECHNIQUES OF
EVOLUTIONARY ARCHITECTURE
REBECCA PARSONS
Chief Technology Officer, ThoughtWorks

2. AGENDA
● Why should I care?
● Definition of Evolutionary Architecture
● Principles of Evolutionary Architecture
● Techniques of Evolutionary Architecture
● How to achieve an Evolutionary Architecture in practice

3. WHY SHOULD I CARE?
● Expectations for pace of change are increasing rapidly
● Business model lifetimes are shortening
● It’s harder to predict the future
● If you miss your minute of fame...

4. Evolutionary Architecture supports
guided, incremental change across
multiple dimensions.

5. Evolutionary Architecture supports
guided, incremental change across
multiple dimensions.

6. Evolutionary Architecture supports
guided, incremental change across
multiple dimensions.

7. Evolutionary Architecture supports
guided, incremental change across
multiple dimensions.

8. Evolutionary Architecture supports
guided, incremental change across
multiple dimensions.

9. Last responsible
moment
Architect and
develop for
evolvability
Postel’s Law
PRINCIPLES OF EVOLUTIONARY
ARCHITECTURE
Architect for
testability
Conway’s Law

10. LAST RESPONSIBLE MOMENT
● Delay decisions as long as you can, but no longer
● Maximizes the information you have
● Minimizes technical debt from complexity
● Decide early what your drivers are, and prioritize decisions accordingly
● Evolutionary, neither emergent nor based on guesswork

11. ARCHITECT FOR EVOLVABILITY
● Sensible breakdown of functionality
● Consider data lifecycle and ownership
● Appropriate coupling
● Lightweight tooling and documentation

12. DEVELOP FOR EVOLVABILITY
● Software internal quality metrics focusing on ease of change
● Find hotspots and focus efforts there
● Measure continually, focusing on trends

13. REVERSIBILITY

14. POSTEL’S LAW
● Be conservative in what you send
● Be liberal in what you receive
● Only validate what you need
● Holds for any information exchange
● Use version changes when a contract must be broken

15. ARCHITECT FOR TESTABILITY
● Aiming towards testability produces a well-architected system
● Messaging infrastructure used for messaging, not business logic
● Business sensible components
● Testing at many levels, including contract
● Build pipelines support the volume

16. CONWAY’S LAW
● Organizations design systems reflecting their communication structures
● Broken communications imply complex integration
● Silos often result in broken communication
● If you don’t want your product to look like your organization, change your
organization (or your product)

17. Database
Refactoring
Continuous
Delivery
TECHNIQUES
Choreography
Contract
Testing

18. DATABASE REFACTORING
● Decompose big change into series of small changes
● Each change is a refactoring/migration pair (or triple if you include access code)
● Changes compose in the same way functions compose
● And of course, version control the changes
● And apply in the various environments during promotion

19. CONTINUOUS DELIVERY
● Automate environments and configurations
● Automate builds and deployments and use continuous integration
● Automate testing at all levels
● Deployment should be boring!!
● Just because you CAN release at any time doesn’t mean you HAVE to

20. CHOREOGRAPHY
● As opposed to orchestration
● Scripted outcomes and vision
● Individuals perform to the vision without a conductor
● Distributes authority about interactions
● Introduces new kinds of failure scenarios

21. CONTRACT TESTING
● Acceptance tests at the systems’ interface
● Documents assumptions made
● Maximizes parallel independent work
● Used in conjunction with Postel’s Law
● One traditional role of Enterprise Architect

22. Define your
architectural
fitness function
Delay your
decisions as long
as you can
Understand
various forms of
technical debt
EVOLUTIONARY ARCHITECTURE
Implement
evidence based re-
use
Create and
maintain the
testing safety net

23. THANK YOU!
rebeccaparsons.com
thoughtworks.com
@rebeccaparsons