Downloaded 14 times
Uploaded byAidan Casey
Evolutionary architecture guiding principles
The document discusses principles for evolutionary architecture: 1. Delay decisions as long as possible but no longer, and integrate changes continuously. 2. Write tests first and integrate code frequently to allow the architecture to evolve freely. 3. Use lightweight documentation like wikis for discussions and decisions, not emails. 4. Embrace continuous delivery and feature switches to reduce fear of releasing software. 5. Adapt the architecture to the organization's structure and use small, self-organizing teams. 6. Design systems to be robust and components to be replaceable.
More Related Content
![[Christopher Ngo] Intro DevOPS XP Day 2015](https://cdn.slidesharecdn.com/ss_thumbnails/christopherngo-cesintrodevopsxpday2015-150520014316-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Evolutionary architecture guiding principles
Evolutionary architecture guiding principles
- 1.
- 2. Aidan Casey chief architectMYOB Australia | @AIDANJCASEY | Microsoft Azure MVP
- 3.
- 5. Unusable rolling pin© Giuseppe Colarusso
- 6. “The best architectures, requirements,and designs emerge from self-organizing teams.” -Agile Manefesto
- 7. In 2016 themost popular design in software engineering is …
- 9. Big ball ofmud symptoms • Throwaway code • Merciless deadlines • Cut and paste • Sheer neglect • Afraid to change parts of the system • Brittle / fragile tests • Data shared promiscuously among distant parts of the system
- 10. Guiding Principles • LastResponsible Moment • Continuous Integration • Lightweight, Living Documentation • Continuous Delivery • Adapt for Organisational Structure • Design for Replacability
- 11.
- 12. • Decisions madetoo early in a project are hugely risky • Delay decisions as long as you can but no longer ! • Every additional tool / technology you add will slow you down….
- 13.
- 14.
- 15. • Without adequatetests your architecture won’t evolve freely • Code coverage stats are absolutely useless ! • TDD – writing tests first changes the shape of your code… • Be prepared to throw away old tests over time who cares ! • Code that is easier to test its easier to change, easier to understand
- 16. The simplest branchingstrategy ever! • Use (VERY) short lived feature branches • When you merge with master its ready for production • Continuously deploy from master
- 17. Unit API & integration UI faster, moreisolated increased scope, slower Manual tests
- 19. Pact – ConsumerDriven Contract Test
- 20.
- 21. • agile doesnot mean doing no documentation ! • No technical discussions / decisions in emails ! • Prefer , wiki’s & collaborative tools – e.g. yammer / slack / confluence • What to document - System diagrams (napkin sketches) - Design decisions - Operational instructions
- 22.
- 23. • Embrace continuousdelivery as an organisation • Deployments should be boring ! • Feature Switches • Takes the fear out of releasing software • Forces you to deal with versioning API’s from the start
- 24.
- 26. Conway’s Law “Organizations whichdesign systems ... are constrained to produce designs which are copies of the communication structures of these organizations” — M. Conway 1967
- 27. Two Pizza rule= better productivity
- 28.
- 30. Robustness "Be liberal inwhat you accept, and conservative in what you send“ - Jon Postel (God of the Internet)
- 31. Summary • Last ResponsibleMoment • Continuous Integration • Lightweight, Living Documentation • Continuous Delivery • Adapt for Organisational Structure • Design for Replacability
Editor's Notes
- #2 Always looking at new frameworks and most of us don’t spend enough time thinking about better ways to make software and teams work better
- #3 Always looking at new frameworks and most of us don’t spend enough time thinking about better ways to make software and teams work better
- #10 Despite the emergence of development methods that encourage and facilitate well-factored code, and the growth of the Software Craftsmanship movement, the Big Ball of Mud remains the most popular design for software, including greenfield development that has the full benefit of hindsight regarding the bad design approaches of the past.
- #11 Here are a number of useful techniques and principles that will help you to maintain a clean architecture through the lifetime of your product.
- #13 When we make decisions, delay then as long as possible but no longer ! The longer you wait the more you know, it minimises the Not about procrastination… Encorporating tools or technologies you don’t need slows you down Not all parts of your system need to be fully redundant , there is a cost you encur doing this etc.. Example – report designer – defer till a few forms built
- #14 To absorb change and allow late decisions you need to build the smallest thing possible to gain more knowledge ( MCVP) Example stat reporter – report evaluation process is time comsuming so it needs to be queue based and asynchronous… no it doesn’t !
- #16 Nothing builds or destroys agility more than a team’s commitment to continuous integration
- #21 The Agile Manifesto prefers “working software over comprehensive documentation”. This doesn’t mean that you can ditch documentation entirely. Wiki’s living breathing
- #22 The Agile Manifesto prefers “working software over comprehensive documentation”. This doesn’t mean that you can ditch documentation entirely. Wiki’s living breathing - Helps you get your thoughts straight by putting it down on paper Needs to be light enough if its any chance of surviving a project NEVER make important decisions in emails !
- #27 you should be looking for opportunities to split monolithic systems up around organizational boundaries ….. Who has lunch together, if as people they don’t talk to eachether their code wont either Broken communication results in silo’s… Don’t build silos based on technology into your organisation Having one group responsible for a piece of functionality E2E is the best
- #28 Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system. Two-Pizza Team Rule Works These independent teams can own the whole lifecycle of the services they create, affording them a greater degree of autonomy than is possible for larger teams with more monolithic codebases
- #31 As soon as there is data in the message people rely on it and its harder to change… If all you need is a post code in an address then ignore the rest of the payload… Not all API’s need to be versioned the same way, who relies on it and who are the consumers, When it comes to exposing data you should expose the bare minimum and no more and you should version all message contracts. Conversely when consuming an API its best to ignore parts of the message you aren’t interested in, you don’t care if these change over time.