Agile Architecture & Programming 16 September 2010

1. Agile architecture & programming Agile Mëtteg – 16 September 2010

2. OBJECTIVES Understand the implications of agile development on architecture, design and coding practices Explain some myths about software architecture and agility Show some best practices 16 Sept 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…) 16 Sept 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. ABOUT ME About Me 16 Sept 2010 Agile Mëtteg - Agile architecture 4

5. AGENDA Agenda Myths about agility and architecture What do we mean by Architecture? What do we mean by Agile? How does agility affect architecture? Introduction to Domain-Driven Design Introduction to Component-Based Design Coding practices 16 Sept 2010 Agile Mëtteg - Agile architecture 5

6. Myths about Agility and Architecture 16 Sept 2010 Agile Mëtteg - Agile architecture 6

7. MYTHS ABOUT AGILITY & ARCHITECTURE Agile = Fragile No Architecture No Design Only works for small projects 16 Sept 2010 Agile Mëtteg - Agile architecture 7

8. What do we mean by Architecture? 16 Sept 2010 Agile Mëtteg - Agile architecture 8

9. WHAT DO WE MEAN BY ARCHITECTURE? Architecture embodies the critical design decisions that classify a system Enterprise Architecture (relates to organizational structure, cost of change, ...) Technical Architecture (infrastructure) Software Architecture (capabilities of the system, structure of code ...) etc. 16 Sept 2010 Agile Mëtteg - Agile architecture 9

10. WHAT DO WE MEAN BY ARCHITECTURE? A good architecture is one in which the significance of decisions is reduced This means key decisions are the ones that reduce the significance of other decisions Makes changes easy Reduces cost of change A stable and robust architecture does not mean it is “frozen” 16 Sept 2010 Agile Mëtteg - Agile architecture 10

11. WHAT DO WE MEAN BY ARCHITECTURE? The importance of decisions needs to be well understood and assessed Heavy-weight approaches are likely to reduce the understanding and the ability to evaluate Keep it simple! 16 Sept 2010 Agile Mëtteg - Agile architecture 11

12. WHY ARCHITECTURE IS SO IMPORTANT Base for further decisions Influence on team structure Foundation for GUI “The interface is the program” (Raskin) Reflects system design Web, Smart Client, Client/Server, Embedded ... 16 Sept 2010 Agile Mëtteg - Agile architecture 12

13. What do we mean by AGILE? 16 Sept 2010 Agile Mëtteg - Agile architecture 13

14. AGILE MANIFESTO Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 16 Sept 2010 Agile Mëtteg - Agile architecture 14

15. AGILE DEVELOPMENT What makes development agile is ... Sustainability of process and code Feedback at different levels of scale Awareness of what is being built and how The right detail at the right time and in the right place The engagement of people in the process Economy 16 Sept 2010 Agile Mëtteg - Agile architecture 15

16. How does agility affect Architecture? 16 Sept 2010 Agile Mëtteg - Agile architecture 16

17. HOW DOES AGILITY AFFECT ARCHITECTURE? Requirements for an “agile” design The design should improve inter team communication It must be comprehensible to everyone without a lot of documentation It must support testing The design must support customer communication and collaboration It must respond to change 16 Sept 2010 Agile Mëtteg - Agile architecture 17

18. BUFD, NUFD or RUFD? 16 Sept 2010 Agile Mëtteg - Agile architecture 18

19. WATERFALL / CLASSICAL APPROACH 16 Sept 2010 Agile Mëtteg - Agile architecture 19 Project Plan Build Test Review Deploy

20. WATERFALL / CLASSICAL APPROACH Big upfront design Impossible to know everything in advance Lack of flexibility Lack of extensibility Lack of adaptability “Ivory Tower” metaphor Architecture might be ignored because team members were not involved in its creation 16 Sept 2010 Agile Mëtteg - Agile architecture 20

21. SCRUM 16 Sept 2010 Agile Mëtteg - Agile architecture 21 Sprint Plan Deploy Plan Plan Plan Review Build Build Build Build Test Test Test Test Review Review Review Review Feature 1 Feature 2 Feature 3 Feature 4

22. AGILE MODELLING No Up-Front Design Team members have a very high technical expertise Team members have in-depth knowledge of the domain 16 Sept 2010 Agile Mëtteg - Agile architecture 22

23. AGILE MODELLING Keep up-front design short But not tooshort You do not have to know precisely what to build before you can start building it. A sprint/iteration 0 can help defining key architecture concepts, a vision and initial architecture Use existing expertise Delaying critical design decisions does not mean we ignore existing knowledge Use proof of concepts to backup the architecture and document it 16 Sept 2010 Agile Mëtteg - Agile architecture 23

24. D RUFD vs NUFD 16 Sept 2010 Agile Mëtteg - Agile architecture 24 Release G A H A - J E B I F C J 1st Sprint 2nd Sprint 3rd Sprint Inception D A G J A - I E B H K F C I L 1st Sprint 2nd Sprint 3rd Sprint 4th Sprint

25. EVOLVING ARCHITECTURE 16 Sept 2010 Agile Mëtteg - Agile architecture 25 Feedback Models, Vision Envision Initial Architecture Communicate Architecture to Stakeholders Update Architecture Models, Vision Feedback Models, Vision Work with developers Models, Vision

26. LAYERED ARCHITECTURE Iteration n 16 Sept 2010 Agile Mëtteg - Agile architecture 26 Iteration 3 Iteration 2 Iteration 1

27. InTrODuction TODoMain-DRIVEN DESIGN 16 Sept 2010 Agile Mëtteg - Agile architecture 27

28. DOMAIN-DRIVEN DESIGN Domain-Driven Design (Eric Evans) Focus on the core domain and domain logic Model is the base of complex designs Initiating a creative collaboration between technical and domain experts to find the conceptual heart of the problem iteratively. 16 Sept 2010 Agile Mëtteg - Agile architecture 28

29. DOMAIN-DRIVEN DESIGN Domain-Driven Design Concepts Just in time modeling Ubiquitous language Bounded Contexts Decoupling business logic from other aspects of the system Separation Of Concerns Cohesiveness 16 Sept 2010 Agile Mëtteg - Agile architecture 29

30. InTrODuction TOCOMPONENT-BASED DESIGN 16 Sept 2010 Agile Mëtteg - Agile architecture 30

31. COMPONENT-BASED DESIGN Component-Based Design An individual component is a software package, a web service, or a module that encapsulates a set of related functions (or data). All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes) Software as a circuit board 16 Sept 2010 Agile Mëtteg - Agile architecture 31

32. COMPONENT-BASED DESIGN Component-Based Design Concepts Modularity Reusability Composition Encapsulation Separation Of Concerns Cohesiveness 16 Sept 2010 Agile Mëtteg - Agile architecture 32

33. COMBINING APPROACHES Using Domain-Driven Design within a component To create domain model and logic Bounded Contexts Anti-Corruption layers Improve communication with UL 16 Sept 2010 Agile Mëtteg - Agile architecture 33

34. COMBINING APPROACHES Using Component-Based design to achieve Modularity Composition Encapsulation and Decoupling The component defines a bounded context Enables us to focus on one problem at a time 16 Sept 2010 Agile Mëtteg - Agile architecture 34

35. SOFTWARE CELLS 16 Sept 2010 Agile Mëtteg - Agile architecture 35 Presentation Presentation Presentation Presentation Domain Model Domain Model Domain Model Domain Model Data Access Data Access Data Access Data Access is composed of Presentation Presentation Domain Model Domain Model Data Access Data Access

36. Coding practices 16 Sept 2010 Agile Mëtteg - Agile architecture 36

37. TEST-DRIVEN DEVELOPMENT Test-Driven Development Design tests BEFORE implementing a feature Tests are testing the expected behavior of a component or class Implementation is done step by step until all tests pass Supports thinking of a design that can be tested 16 Sept 2010 Agile Mëtteg - Agile architecture 37

38. BEHAVIOR-DRIVEN DEVELOPMENT Behavior-Driven Development Get business specialists involved in testing! Focuses on collaboration between developers, quality assurance and business users Might be used for User Acceptance testing 16 Sept 2010 Agile Mëtteg - Agile architecture 38

39. VERSION CONTROL & CONTINUOUS INTEGRATION Version Control A version control system allows the team members to simultaneously work on the code base. It automatically merges differences and reports conflicts. Continuous Integration Regular builds of the code base Early discovery of introduced bugs Automatic execution of test base Reduces Regression 16 Sept 2010 Agile Mëtteg - Agile architecture 39

40. REFACTORING Refactoring Improve code quality without changing its behavior Code towards design patterns Consider separation of concerns and cohesiveness TDD, BDD, Version Control and CI are the foundation for refactoring (a safety-net), they reduce the fear of change 16 Sept 2010 Agile Mëtteg - Agile architecture 40

41. DECOUPLING Decoupling How? Inversion of control Dependency Injection Encapsulation Helps with Modularity Extensibility Maintainability Testability 16 Sept 2010 Agile Mëtteg - Agile architecture 41

42. DESIGN PATTERNS Design Patterns Do not re-invent the wheel Design Patterns provide solutions for common problems Domain-Driven Design defines a set of architectural patterns 16 Sept 2010 Agile Mëtteg - Agile architecture 42

43. DEMo 16 Sept 2010 Agile Mëtteg - Agile architecture 43

44. QUESTIONS IntentionallyBlank(ish) 16 Sept 2010 Agile Mëtteg - Agile architecture 44

45. RESOURCES Agile Partner: www.agilepartner.net Agile Partner blog: blog.agilepartner.net Agile Interest Group Luxembourg:www.aiglu.org Agile Alliance: www.agilealliance.org Scrum alliance: www.scrumalliance.org Scrum.org 16 Sept 2010 Agile Mëtteg - Agile architecture 45

46. NEXT TRAININGS & CERTIFICATIONS June 17th, 2010 Agile Mëtteg - Continuous improvement in practice 46 Complete calendar on: http://www.agilepartner.net/training/

47. CONTACTS Thank You 16 Sept 2010 Agile Mëtteg - Agile architecture 47