Lean Architecture - Sergey Shishkin - Agile SG 2013

Presented in Agile Singapore 2013 Conference

Agile manifesto values working software more than comprehensive (architecture) documentation. Though working software is only a means to an end, to the ultimate agile aim – learning through feedback. The term "software architecture" has a bad reputation of big design upfront and analysis paralysis in the agile community, though if practiced deliberately it can become an efficient and effective learning tool in an agile toolbox.

In this workshop you will learn step by step how to:
- design lean architectures fast;
- incorporate requirements incrementally;
- communicate architecture effectively in teams;
- consider "non-functional" requirements;
- asses technical and business risks.

Transcript

1. LEAN ARCHITECTURE LEARN FAST, LEARN OFTEN
2. WHAT IS ARCHITECTURE? high-level structure of a system decisions which are hard to change
3. WE DON’T NEED ARCHITECTURE only working software counts all decisions should be revertable (easily) vague decisions at large (blueprints) lost in details
4. WE DO NEED ARCHITECTURE shorten the feedback loop shared understanding make decisions explicit
5. ARCHITECTURE IS “WHATEVER THE IMPORTANT STUFF IS”
6. OK, BUT HOW?
7. IT HURTS, SO WE DO IT OFTEN
8. ARCHITECTURE IS EVERYONE’S JOB
9. LEVERAGE THE DOMAIN POSTPONE TECHNOLOGY
10. FOCUS ON LEARNING (known unknowns)
11. PRACTICE PRACTICE PRACTICE PRACTICE
12. ONE OF MANY WAYS
13. 1. IDENTIFY ACTORS human users, components and external systems derive actors from the functional domain
14. 2. DRAW DATA FLOWS derive interfaces from data, not the other way around split heterogeneous data be specific
15. 3. GET FEEDBACK biz and tech risks data volumes security and privacy validate assumptions infrastructure operations costs estimation technology choice and … and … and …
16. 4. ZOOM IN AND REPEAT
17. LET’S TRY IT!
18. BUT IN THE REAL WORLD… aim for smaller increments work from priorities know when to stop! YMMV our job is to create the “real world” — Ron Jeffries
19. SUMMARY 1. functional components are more stable 2. maximize learning over effort 3. practice often
20. THANK YOU! shishkin.org @sshishkin
21. ARCHITECTURAL KATA WHERE’S FLUFFY? by Ted Neward original kata see for more katas archkatas.herokuapp.com
22. RULES 1. work in teams 2. eliminate assumptions 3. document decisions 4. iterate and increment!
23. INCREMENT #1 Pet owners can post details and photos of their missing pets. Anyone can see a list of pets missing near to their location.
24. IDENTIFY ACTORS 1. pet owner 2. visitor 3. postings service
25. DRAW DATA FLOWS
26. LEARN analyze data volumes
27. DOCUMENT DECISIONS 1. separate images component 2. fixed list of locations 3. no user registration needed
28. INCREMENT #2 Users can comment on pet missing entries, providing photo proofs of found pets, locations of sighted pets or area checked.
29. UPDATE ACTORS 1. pet owner 2. visitor 3. postings service 4. image service 5. pet scout
30. UPDATE DATA FLOWS
31. GET FEEDBACK define infrastructure
32. DOCUMENT DECISIONS 1. use geo-location to improve usability on mobile devices
33. INCREMENT #3 Pet owners provide rewards for found pets. The service brokers the rewards. Pet finders collect rewards on confirmation from pet owners.
34. UPDATE ACTORS 1. pet owner 2. visitor 3. pet scout 4. postings service 5. image service 6. pet finder 7. reward broker
35. UPDATE DATA FLOWS
36. LEARN 1. consider data security and privacy 2. (bonus) brainstorm risks
37. DOCUMENT DECISIONS 1. decision: support only monetary payments 2. assumption: can process payments via a third party provider 3. risk: no automatic payment cancellation