Agile architecture & programming 20 May 2010

1. Agile architecture & programming Agile Mëtteg – 20 May 2010

2. OBJECTIVES Understand the implications of agile development on architecture, design and coding practices Explain some misbelieves about software architecture and agility 20 May 2010 2 Agile Mëtteg – Agile architecture

3. AGILE PARTNER SERVICES Custom Software Development & Maintenance Our core business to answer customer needs IS services Thanks to our expertise we can support IT team to reach their productivity & quality objectives (Assessment, Coaching, Support, Training, Resource delegation…) IS Solutions Take benefit from commercial or Open Source platform to answer as quick as possible to specific needs IS users services We can support Product & Services owners to work closely with the IT team (Assessment, Coaching, Support, Training, Resource delegation…) 20 May 2010 Agile Mëtteg - Agile architecture 3 IS users Services 1 4 Software Development & SoftwareMaintenance 2 ISSolutions IS Services Agility Agility 3 1 2 3 4 Agility

4. WHO’S WHO Who are we ? Whatisourrole in ourorganization ? What are our expectations fromthisseminar ? 20 May 2010 Agile Mëtteg - Agile architecture 4

5. AGENDA Agenda Can Enterprise Architecture be Agile ? Misbelieves about architecture and agility Why Up Front Design doesn’t always work ? Emerging architectures and evolutionary design Coding practices So is Design dead ? 20 May 2010 Agile Mëtteg - Agile architecture 5

6. ARCHITECTURE ? WHICH ONE ? Architecture: very contextual activity Enterprisearchitecture Software architecture Technical architecture Etc. 20 May 2010 Agile Mëtteg - Agile architecture 6

7. Can Enterprise Architecture be Agile ? 20 May 2010 Agile Mëtteg - Agile architecture 7

8. CAN EA BE AGILE ? Enterprise architecture: Vision, principles, standards, roadmap Enterprise architecture frameworks: TOGAF 9, Zachman framework, … Define extensively structure and models Use them as guides, not as rules Beware of over-documentation 20 May 2010 Agile Mëtteg - Agile architecture 8

9. CAN EA BE AGILE ? 20 May 2010 Agile Mëtteg - Agile architecture 9 Example: Zachman framework

10. CAN EA BE AGILE ? Example: Zachman framework 20 May 2010 Agile Mëtteg - Agile architecture 10 EA Armory ;) Choose one or two weapon(s) Use Agile modeling (JIT Modeling) Helps to structure Leave no stone unturned DO NOT TRY AND IMPLEMENT EVERYTHING!!!!

11. Misbelieves about SOFTWARE architecture and agility 20 May 2010 Agile Mëtteg - Agile architecture 11

12. MISBELIEVES ON ARCHITECTURE You have to know precisely what to build before you can start building it. Building software is like construction building 20 May 2010 Agile Mëtteg - Agile architecture 12

13. MISBELIEVES ON AGILITY No architecture Code and fix nightmare Cowboy coding Onlyworks forsmallprojects 20 May 2010 Agile Mëtteg - Agile architecture 13

14. Why up front design doesn’talwayswork ? 20 May 2010 Agile Mëtteg - Agile architecture 14

15. Traditional / Waterfallapproach Design isdoneup front BigDesign Up Front = BDUF WHEN DO YOU DESIGN ? 20 May 2010 Agile Mëtteg - Agile architecture 15

16. IS THAT THE RIGHT APPROACH ? “In preparing for battle I have always found that plans are useless, but planningis indispensable.” [D.Eisenhower] 20 May 2010 Agile Mëtteg - Agile architecture 16

17. WHAT DO AGILISTS SAY ? “Design is there to enable you to keep changing the software easily in the long term.” [Kent Beck] Source : http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx 20 May 2010 Agile Mëtteg - Agile architecture 17

18. WHAT DO AGILISTS SAY ? “eXtreme Programming recognizes the importance of design decisions, but it strongly resists upfront design. Instead, it puts and admirable effort into communication and improving the projects ability to changecourse rapidly” [Eric Evans, DDD] 20 May 2010 Agile Mëtteg - Agile architecture 18

19. BDUF NOT ALWAYS WORKING ? You cannot foresee the future Requirements change Architecture documents are not carved in stone 20 May 2010 Agile Mëtteg - Agile architecture 19

20. BDUF NOT ALWAYS WORKING ? The « Architect » in hisIvoryTower Architects far from teams Developers kept out of architecture definition Frustrated teams ignore / bypass the model 20 May 2010 Agile Mëtteg - Agile architecture 20

21. BDUF NOT ALWAYS WORKING ? 20 May 2010 Agile Mëtteg - Agile architecture 21 Everheard about over design ?

22. OVER DESIGN CONSEQUENCES Lack of Flexibility Adaptability Extensibility 20 May 2010 Agile Mëtteg - Agile architecture 22 Effect on Cost ROI Time to market

23. Emerging architectures and evolutionary design 20 May 2010 Agile Mëtteg - Agile architecture 23

24. Waterfallapproach Design isdoneup front WHEN DO YOU DESIGN ? 20 May 2010 Agile Mëtteg - Agile architecture 24

25. Agile approach Design ispart of the developmentprocess WHEN DO YOU DESIGN ? 20 May 2010 Agile Mëtteg - Agile architecture 25 Iteration 1 Iteration 2 Iteration n No specificorder

26. 20 May 2010 Agile Mëtteg - Agile architecture 26 How would you eat this cake ? LAYERED CAKE

27. ARCHITECTURE LAYERED CAKE Iteration n 20 May 2010 Agile Mëtteg - Agile architecture 27 Iteration 3 Iteration 2 Iteration 1

28. ABOUT EMERGENCE Tobias Mayer Emergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work. They will not become clear if we simply talk about them. Big Up Front Design might result in Big Wrong Design or at best Big Working But Totally Inflexible Design. When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface. Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution. 20 May 2010 Agile Mëtteg - Agile architecture 28

29. ABOUT EMERGENCE Tobias Mayer Emergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work. They will not become clear if we simply talk about them. Big Up Front Design might result in Big Wrong Design or at best Big Working But Totally Inflexible Design. When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface. Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution. 20 May 2010 Agile Mëtteg - Agile architecture 29

30. HOW DOES IT START ? It all startedwith a vision Initial architecture envisionning 20 May 2010 Agile Mëtteg - Agile architecture 30

31. AGILE MODELING 20 May 2010 Agile Mëtteg - Agile architecture 31 JIT modeling / design Coding practices Envisioning Source : http://www.agilemodeling.com/essays/initialArchitectureModeling.htm

32. DESIGN DURING DEVELOPMENT eXtremeProgramming Iteration 0 "The first iteration must be a functioning skeleton of the system as a whole.“ [Kent Beck] System metaphor Followingiterations Spike solution Proof of concept 20 May 2010 Agile Mëtteg - Agile architecture 32

33. DESIGN DURING DEVELOPMENT Domain Driven Design (Eric Evans) Just in time modeling Ubiquitouslanguage (cf System Metaphor) 20 May 2010 Agile Mëtteg - Agile architecture 33

34. VALUES OF AGILE ARCHITECTURE 20 May 2010 Agile Mëtteg - Agile architecture 34

35. Coding practices 20 May 2010 Agile Mëtteg - Agile architecture 35

36. PRACTICES Test DrivenDevelopment BehaviorDrivenDevelopment Refactoring Continuousintegration 20 May 2010 Agile Mëtteg - Agile architecture 36

37. TEST DRIVEN DEVELOPMENT (TDD) Makeit breakwrite the test first Makeitpasswrite the simplestimplementation Makeit right refactorwithoutchanging the behavior 20 May 2010 Agile Mëtteg - Agile architecture 37

38. TDD EXAMPLE FizzBuzz Kata Multiple of 3  Fizz Multiple of 7  Buzz Multiple of 3 and 7  FizzBuzz 20 May 2010 Agile Mëtteg - Agile architecture 38 Source : http://www.viddler.com/explore/Lostechies/videos/1/

39. BEHAVIOR DRIVEN DEVELOPMENT 20 May 2010 Agile Mëtteg - Agile architecture 39 User stories

40. BDD : EXECUTABLE SPECIFICATIONS Scenario : Accountis in credit 20 May 2010 Agile Mëtteg - Agile architecture 40

41. REFACTORING Refactoring Change “How” not “What” Pay your technical debt Use of patterns Refactor towards patterns only when needed Leverage ubiquitous language 20 May 2010 Agile Mëtteg - Agile architecture 41

42. CONTINUOUS INTEGRATION Your product builds at any time Run the tests often Ease deployment 20 May 2010 Agile Mëtteg - Agile architecture 42

43. So is design dead ? 20 May 2010 Agile Mëtteg - Agile architecture 43

44. SO IS DESIGN DEAD ? “Not by any means, but the nature of design has changed.” [Martin Fowler] Keep code as clean and simple as possible. Refactorto confidently make improvements. Use design patterns when needed. Communicate the design using code, diagrams and above all conversation. 20 May 2010 Agile Mëtteg - Agile architecture 44

45. EMPHASIZED COMMUNICATION 20 May 2010 Agile Mëtteg - Agile architecture 45

46. AGILE ARCHITECTURE MANIFESTO ? Business focus Emergence Simplicity Extensibility 20 May 2010 Agile Mëtteg - Agile architecture 46 Technical perfection Up front design Excessive design Omnipotence

47. QUESTIONS 47 Agile Mëtteg - Agile architecture 20 May 2010

48. NEXT TRAININGS & CERTIFICATIONS 20 May 2010 Agile Mëtteg - Agile architecture 48 Complete calendar on: http://www.agilepartner.net/training/training_calendar.html

49. RESOURCES Agile Partner: www.agilepartner.net Agile Interest Group Luxembourg:www.aiglu.org Agile Alliance: www.agilealliance.org Scrum alliance: www.scrumalliance.org Scrum.org 20 May 2010 Agile Mëtteg - Agile architecture 49

50. CONTACTS Thank You 20 May 2010 Agile Mëtteg - Agile architecture 50