Evolutionary architecture guiding principles
•Download as PPTX, PDF•
2 likes•777 views
corkdev.io Feb 2016
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Evolutionary architecture guiding principles
Similar to Evolutionary architecture guiding principles (20)
More from Aidan Casey
More from Aidan Casey (12)
Recently uploaded
Recently uploaded (20)
Evolutionary architecture guiding principles
- 2. Aidan Casey chief architect MYOB Australia | @AIDANJCASEY | Microsoft Azure MVP
- 3. NO CODE
- 5. Unusable rolling pin © Giuseppe Colarusso
- 6. “The best architectures, requirements, and designs emerge from self-organizing teams.” -Agile Manefesto
- 7. In 2016 the most popular design in software engineering is …
- 9. Big ball of mud 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 • Last Responsible Moment • Continuous Integration • Lightweight, Living Documentation • Continuous Delivery • Adapt for Organisational Structure • Design for Replacability
- 12. • Decisions made too 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….
- 15. • Without adequate tests 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 branching strategy 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, more isolated increased scope, slower Manual tests
- 19. Pact – Consumer Driven Contract Test
- 21. • agile does not 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
- 23. • Embrace continuous delivery 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
- 26. Conway’s Law “Organizations which design 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
- 30. Robustness "Be liberal in what you accept, and conservative in what you send“ - Jon Postel (God of the Internet)
- 31. Summary • Last Responsible Moment • Continuous Integration • Lightweight, Living Documentation • Continuous Delivery • Adapt for Organisational Structure • Design for Replacability
Editor's Notes
- 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
- 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
- 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.
- Here are a number of useful techniques and principles that will help you to maintain a clean architecture through the lifetime of your product.
- 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
- 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 !
- Nothing builds or destroys agility more than a team’s commitment to continuous integration
- The Agile Manifesto prefers “working software over comprehensive documentation”. This doesn’t mean that you can ditch documentation entirely. Wiki’s living breathing
- 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 !
- 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
- 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
- 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.