Agile Architecture

How does the architect's role change in an agile project with empowered, cross-functional teams? How to balance too much design up front with no design at all?

Transcript

1. Agile Architecture
2. The Architect   Tension   Diagrams & Documents   Encapsulation & Modularity   Real Options   Architecture Options
3. The Architect
4. Doesn’t code Covers every detail Their word is law Most effort up front
5. Doesn’t code Covers every detail Their word is law Most effort up front
6. Vision & Expertise Guides evolution   and technical direction Creates and investigates   options for implementation ✓
7. Tension
8. Predictability vs   reacting to change   Independence vs duplication of effort
9. BDUF Pains:   Over-Engineering Unnecessary Features   Premature Commitment
10. ‘Integrated Problem Solving’ 1. Understanding and solving the   problem happen at the same time   2. Information released early   3. Information released frequently   4. Information flows in 2 directions   5. Prefer face-to-face over documents
11. Refactoring is continuous   local design improvement   Enable easy sharing   (knowledge & code)
12. Build for today   Architect for next week   (not next year)
13. Diagrams   & Documents
14. Typical BDUF documentation:   Functional Requirements   Functional Design   Solution Architecture   Technical Design   Etc.
15. Do you have all of these on your project?   Are they all up to date?   Do people actually use them?
16. Unused documentation is   at best a waste   Consider the need behind   the documentation
17. Tests are definitely needed   Documentation may be needed   Tests = Documentation?
18. Appropriate documentation Documentation should be   valuable to someone Documents don’t come first
19. Diagram as formal as needed   Diagram as detailed as needed Diagrams are a snapshot
20. Encapsulation   & Modularity
21. Minimise responsibilities   Hide the internal   implementation details   Expose the behaviours
22. From OOP to SOA   Applications   Services   Components   Classes
23. ‚ EXAMPLE
24. Typical MVC App
25. Getting   harder   to grow
26. Decompose   into services
27. Extend easily   Reuse features
28. Real Options
29. An Option is the right,   but not obligation   to do something
30. Options are used to defer   commitment until more   is known about the situation
31. Real  Options   Options  have  value   Options  expire   Never  commit  early   unless  you  know  why
32. ‚ EXAMPLE
33. Working  in  London  on-­‐site  full  time   Need  accommodation  this  week   Apartment  lease  might  be     signed  on  Monday   Apartment  lease  might  fall  through
34. Could  pay  for  the  hotel   for  the  whole  week   We  won’t  know  until  Monday   if  lease  is  signed   Need  to  create  an  option
35. We  want  to  delay  the  decision     until  we  have  more  knowledge   So  we  pay  a  deposit  for  a  hotel   reservation  for  the  week   If  lease  signed,  we  cancel   If  not,  we  stay  in  hotel
36. For  the  price  of  the  option,   we  can  delay  the  decision  and   make  a  more  informed  choice
37. The  option  has  a  value   The  option  will  expire   Don’t  commit  until  we  know   for  sure  about  the  lease
39. Architecture Options
40. Use Real Options to reduce risk   in technical decision making
41. Identify areas of risk   Look for big assumptions   Make options to defer decisions
42. ‚ EXAMPLE
43. MongoDB or MySQL?   Assume or delay work?
44. Defer the decision & keep   working on concrete needs
45. Commit later when more   knowledge has been gained
46. Value: later decision based on   more knowledge   Expiry: may eventually need   to have persistent storage   Avoid early commitment:   unless there is a real need
47. Get   Involved
48. “Code wins arguments” Spike solutions for feasibility Hands-on experience equals credibility
49. ? QUESTIONS