Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building Evolutionary Architectures - Rebecca Parsons

581 views

Published on

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.

Published in: Software

Building Evolutionary Architectures - Rebecca Parsons

  1. 1. PRINCIPLES AND TECHNIQUES OF EVOLUTIONARY ARCHITECTURE REBECCA PARSONS Chief Technology Officer, ThoughtWorks
  2. 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. 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. 4. Evolutionary Architecture supports guided, incremental change across multiple dimensions.
  5. 5. Evolutionary Architecture supports guided, incremental change across multiple dimensions.
  6. 6. Evolutionary Architecture supports guided, incremental change across multiple dimensions.
  7. 7. Evolutionary Architecture supports guided, incremental change across multiple dimensions.
  8. 8. Evolutionary Architecture supports guided, incremental change across multiple dimensions.
  9. 9. Last responsible moment Architect and develop for evolvability Postel’s Law PRINCIPLES OF EVOLUTIONARY ARCHITECTURE Architect for testability Conway’s Law
  10. 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. 11. ARCHITECT FOR EVOLVABILITY ● Sensible breakdown of functionality ● Consider data lifecycle and ownership ● Appropriate coupling ● Lightweight tooling and documentation
  12. 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. 13. REVERSIBILITY
  14. 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. 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. 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. 17. Database Refactoring Continuous Delivery TECHNIQUES Choreography Contract Testing
  18. 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. 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. 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. 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. 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. 23. THANK YOU! rebeccaparsons.com thoughtworks.com @rebeccaparsons

×