Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lean Architecture - Sergey Shishkin - Agile SG 2013

66a1bb94b08fe5dcd07635a59681626c?s=47 Agile Singapore
November 08, 2013
120

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.

66a1bb94b08fe5dcd07635a59681626c?s=128

Agile Singapore

November 08, 2013
Tweet

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