Principles and Techniques of Evolutionary Architecture Rebecca - - PowerPoint PPT Presentation

principles and techniques of evolutionary architecture
SMART_READER_LITE
LIVE PREVIEW

Principles and Techniques of Evolutionary Architecture Rebecca - - PowerPoint PPT Presentation

Principles and Techniques of Evolutionary Architecture Rebecca Parsons Chief Technology O ffi cer ThoughtWorks Agenda Why should I care? De fi nition of Evolutionary Architecture Principles of evolutionary architecture Techniques of evolutionary


slide-1
SLIDE 1

Principles and Techniques of Evolutionary Architecture

Rebecca Parsons Chief Technology Officer ThoughtWorks

slide-2
SLIDE 2

Principles of evolutionary architecture Why should I care? Definition of Evolutionary Architecture How to achieve an evolutionary architecture in practice Techniques of evolutionary architecture

Agenda

slide-3
SLIDE 3

It’s harder to predict the future Expectations for pace of change are increasing rapidly Business model lifetimes are shortening If you miss your minute of fame...

Why Should I Care?

slide-4
SLIDE 4

Evolutionary Architecture supports guided, incremental change across multiple dimensions.

slide-5
SLIDE 5

Evolutionary Architecture supports guided, incremental change across multiple dimensions.

slide-6
SLIDE 6

Evolutionary Architecture supports guided, incremental change across multiple dimensions.

slide-7
SLIDE 7

Evolutionary Architecture supports guided, incremental change across multiple dimensions.

slide-8
SLIDE 8

Evolutionary Architecture supports guided, incremental change across multiple dimensions.

slide-9
SLIDE 9

Postel’s Law Last responsible moment Architect and develop for evolvability Conway’s Law Architect for testability

Principles of Evolutionary Architecture

slide-10
SLIDE 10

Minimizes technical debt from complexity Delay decisions as long as you can, but no longer Maximizes the information you have Evolutionary, neither emergent nor based

  • n guesswork

Decide early what your drivers are, and prioritize decisions accordingly

Last Responsible Moment

slide-11
SLIDE 11

Consider data lifecycle and ownership Sensible breakdown of functionality Lightweight tooling and documentation Appropriate coupling

Architect for Evolvability

slide-12
SLIDE 12

Software internal quality metrics focusing

  • n ease of change

Find hotspots and focus efforts there Measure continually, focusing on trends

Develop for Evolvability

slide-13
SLIDE 13

Reversability

slide-14
SLIDE 14

Only validate what you need Be conservative in what you send Be liberal in what you receive Use version changes when a contract must be broken Holds for any information exchange

Postel’s Law

slide-15
SLIDE 15

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

Architect for Testability

slide-16
SLIDE 16

Broken communications imply complex integration Organizations design systems reflecting their communication structures If you don’t want your product to look like your organization, change your

  • rganization (or your product)

Silos often result in broken communication

Conway’s Law

slide-17
SLIDE 17

Database Refactoring Continuous Delivery Choreography Contract Testing

Techniques

slide-18
SLIDE 18

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

Database Refactoring

slide-19
SLIDE 19

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

Continuous Delivery

slide-20
SLIDE 20

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

Choreography

slide-21
SLIDE 21

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

Contract Testing

slide-22
SLIDE 22

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

Evolutionary Architecture

slide-23
SLIDE 23

Thank you!

http://rebeccaparsons.com http://www.thoughtworks.com @rebeccaparsons