Architecture in an Agile World

1. Don McGreal Architecture in an Agile World don.mcgreal@ImprovingEnterprises.com @donmcgreal linkedin.com/in/donmcgreal

3. Agenda • Agile and Architecture • Reducing Technical Risks • Team Makeup & Roles • Architecture Anti-Patterns

4. What is Software Architecture? 5

5. Business Goals • What business goals could affect our Architectural decisions? 6

6. Non-Functional Requirements • Usability • Scalability • Portability • Maintainability • Availability • Accessibility • Supportability • Security • Performance • Cost • Legal • Cultural • ... 7

7. Does it compare to building this? • House

8. … or this? • ???

9. Simple Everything is known Complicated More is known than unknown Complex More is unknown than known Chaotic Very little is know Level of Complexity Source: Ralph Stacey, University of Hertfordshire

10. Empirical vs Defined Processes Plan Do P D P D P D P D

11. Sprint Retrospective 1/2 day Sprint Review 1/2 day • Sprint Planning • 1 day • Acceptance • Defined • Team commits • Tasks created Scrum Burn down • Business Case • Financing • Scope & Approach • Contracts • Initial Release Plan • Assemble Team Daily Scrum < 15 minutes Sprint 1 to 4 weeks Product Owner establishes vision and prioritizes Product Backlog velocity Releasable Increment Team (BA, QA, Dev, etc.) createsand estimates Sprint Backlog (tasks) Burn up

12. BigDUF or LittleDUF? PB Creation PB Sizing Release Planning LDUF Sprint Planning Sprint Planning Sprint 1 Sprint Review PB Grooming Retrospective Sprint 2 Sprint Review PB Grooming Retrospective

13. Non-Functional Requirements • Usability • Scalability • Portability • Maintainability • Availability • Accessibility • Supportability • Security • Performance • Cost • Legal • Cultural • ... 14

14. Non-Functional Requirements • Captured as: • Acceptance Criteria • Definition of Done • Stories • Usability • Scalability • Portability • Maintainability • Availability • Accessibility • Supportability • Security • Performance • Cost • Legal • Cultural • ... 15

15. Sprint Capacity over Time

16. … but one is different Usability Scalability Portability Maintainability Availability Accessibility Supportability • Security • Performance • Cost • Legal • Cultural • ...

17. Most Important Architecture Goal? • Maintainability

18. Agenda • Agile and Architecture • Reducing Technical Risks • Team Makeup & Roles • Architecture Anti-Patterns

19. Technical Debt in an Unhealthy Team Time available for new feature development Time struggling with complexity and debt *From Scrum.org’s Professional Scrum Master certification course

20. Yuck. *From Scrum.org’s Professional Scrum Master certification course

21. How do you get out of debt? *From Scrum.org’s Professional Scrum Master certification course • Stop creating debt • Make a small payment each Sprint • Repeat from 2

22. Sprint Retrospective 1/2 day • Sprint Planning • 1 day • Acceptance • Defined • Team commits • Tasks created Definition of Done Daily Scrum < 15 minutes Done Sprint? Versioned In UAT Integrated others? Done Feature? Acceptance Tested On Test Server Performance Tested others? Sprint 1 to 4 weeks Product Owner establishes vision and prioritizes Product Backlog Sprint Review 1/2 day Sprint Review 1/2 day Done Task? Unit Tested Code Reviewed Checked-in others? Done Release? Compliance Labeled Training others? Releasable Increment Releasable Increment Team (BA, QA, Dev, etc.) createsand estimates Sprint Backlog (tasks)

23. Paying off Debt

24. Paying off Debt

25. Design Patterns != Good Design

26. Core Aspects of Good Design • Low Coupling • High Cohesion ✓ Good Design

27. Coupling vs. Cohesion

28. Core Aspects of Bad Design • Duplication • Ambiguity . • Complexity X . Bad Design

29. Bad Smells The Bloaters Long Method, Large Class, Data Clumps The OO Abusers Type Attribute, State Attribute, Indecent Exposure The Dispensables Lazy Class, Dead Code, Data Class The Couplers Feature Envy, Message Chains, Middleman The Change Preventers Divergent Change, Shotgun Surgery, Non-localized Logic

30. How do we get there? ✓ X ➔ Bad Design Good Design

31. Refactoring ✓ X ➔ Bad Design Good Design Refactoring to / towards / away from Bad Smells Design Patterns

32. Refactoring ✓ X ➔ Bad Design Good Design Refactoring to / towards / away from Bad Smells Design Patterns Encapsulate Field Extract Method Generalize Type Pull Up Push Down Rename Method ...

33. Agenda • Agile and Architecture • Reducing Technical Risks • Team Makeup & Roles • Architecture Anti-Patterns

34. Vertical Teams TEAM 1 TEAM 2 TEAM 3 TEAM 4 Presentation Business DB Persistence

35. Vertical Features TEAM 1 TEAM 2 TEAM 3 TEAM 4 Presentation Features Features Features Features Business DB Persistence

36. Ideal Team Composition Team A Team B

37. Realistic Team Composition Team A What now? What now? Team B

38. Specialists • IDEAL: Specialists are dedicated to a team and participate throughout the sprint. • REALISTIC: Specialists service multiple teams and participate as needed. • WORST CASE: Specialists do not participate in a sprint, but someone on the team takes responsibility for working with them.

39. Architect Roles • Enterprise Architect (policies & standards) • Infrastructure Architect (systems & network design) • Solution Architect (advisory & governance) • Application Architect (on teams)

40. Where to Plug In? PB Creation PB Sizing Release Planning LDUF Sprint Planning Sprint Planning Sprint 1 Sprint Review PB Grooming Retrospective Sprint 2 Sprint Review PB Grooming Retrospective

41. Agenda • Agile and Architecture • Reducing Technical Risks • Team Makeup & Roles • Architecture Anti-Patterns

42. Presentation S h a r e d Controller Façade Business Integration Persistence Logic in Wrong Layer • Think about what would need to change in other layers if one was swapped out or modified.

43. No Architectural Vision • A single architecture vision should be well defined and communicated across the team and organization. • The vision should map to business goals and objectives. • All decisions should be made with this vision in mind.

44. Swiss Army Knife • Do not try to anticipate every possible use of the system and over-design the interfaces - this will lead to needless complexity. • Do the simplest thing that works, within the Architectural Vision.

45. Threading • Do your homework! • Typically not necessary • Adds massive complexity • Hard to maintain, test, and debug • Rely on the application frameworks threads

46. Caching • Do your homework! • Do you even need a cache? • Can you keep everything in memory? • Rely on persistence framework’s caching

47. Ivory Tower Architect • It is very hard to truly know the best solutions for design problems if you are not working (coding) on the project. • It takes many iterations of a solution before it finally works - so you can’t suggest a solution then leave.

48. Custom Frameworks • May seem like a good idea at first. But... • Who will maintain it? • Who will upgrade it when it’s depended upon libraries are upgraded? Java version? • How long will your new hires need to learn it? Who will teach them? • Look for an off-the-shelf solution first. • You can hire/train people on it easier. • It will be upgraded for you.

49. So, to sum up…

50. Emergent Architecture • Agile architects build plans and foundations that embrace change • Today’s technologies and enterprise frameworks give usthis flexibility We just need to take advantage of them.