1. Agile Architecture Itera Group Kiev Johannes Brodwall, Chief scientist Exilesoft Global

2. What is an architect? From greek Arkhi-Tecton Tecton: Builder Arkhi: Chief. Like “Arch angel” Or “Arch villain”

3. What is an architect? “Chief builder”

4. What is an architect? (Exilesoft definition)

5. A solution architect is someone who understands the problem of the customer and uncovers and communicates a feasible solution

6. A solution architect is someone who understands the customer’s problem (including contraints, context, domain knowledge) and uncovers (though a team effort) and communicates (with credibility) a feasible solution (primarily, but not exclusively technical)

7. Uncover problem vision, stakeholders, usage flow Describe problem context and domain model Describe solution deployment, implementation model Simplify architecture feature oriented structure Deliver software rainbow plans

8. Describing architecture Simplifying architecture Delivering architecture Delivering software Delivering architecture

9. Part I:

10. Describing architecture

11. Understanding problem Uncovering solution Communicating architecture

12. Understanding the problem

13. (Tool time)

14. For some stakeholder Who has a responsibility The Itera architecture community Is a type of activity Which gives a capability. Unlike most relevant alternative This has a distinguishing attribute.

15. For __________________ Who ________________ The _________________ Is a _________________ Which ________________. Unlike ______________________ This _______________________.

16. Participant? Who are they? What do they do? Why do they care? ??? Description Duties Values ??? Description Duties Values

17. Example «Smidig» conference application

19. Example vision statement

20. For Agile practitioners Who need to expand on their experience and network The Smidig conference Is a networking event Which connects you with other Agile practitioners. Unlike traditional conferences This presents the experience of many people through lightning talks.

21. For Conference organizers Who want to organize a good conference The Smidig conference app Is a web application Which eliminates unnecessary work. Unlike commercial conference apps This is optimized for the large number of talks we have and allows us to make changes fast.

23. Example stakeholders

24. Speaker Description Experienced New speaker Passionate Duties Register talk Upload slide Give talk Values Constructive feedback on talk Easy CfP Fast answer Attendee Description Knows about agile Works in project Norwegian Duties Pay for conference Get approval to go Values Easy registration Organizer Description Volunteer Works in evenings Has network Duties Select talks Follow up payments Values Easy selection process Good information overview Never lose a participant Financial transparency

25. Sponsor Description Busy Manager Not very interested Duties Provide logo Pay sponsorship Values Informal communication Easy evaluation

26. Example usage flow

27. Attendance 1.Agile project practitioner wants to learn 2.Attendee goes to Smidig website 3.Attendee registers 4.Attendee pays 5.Attendee receives confirmation mail 6.Organizer can see the registration 7.Organizer sends reminder email to attendee to come 8.Organizer prints badges for attendees 9.Attendee shows up at Smidig and has an excellent time

29. Speaker 1.Agile experts wants to share knowledge 2.Potential speaker goes to Smidig website 3.Potential speaker registers personal info 4.Potential speaker registers talk 5.Potential speaker receives registration confirmation email 6.Organizer sees registered talk and can market speaking opportunities 7.Organizer accepts talk for confence 8.Speaker receives acceptance email –Alternative: Speaker withdraws talk – organizer updates the talk and selects another 9.Organizer prints badges for speakers 10.Speaker shows up at Smidig and gives talk

30. /Understanding the problem

31. Uncovering a solution

32. Example context model

33. Smidig2011.no Participant Speaker Organizer Printing company Paypal

34. Example domain model

35. User Name Email Company Phone Password Accepts email? Registration Ticket type Price Paid amount Paypal ref Payment date Invoice address [optional] Talk Title Description Tags[] Slide file Status : {pending, accept, reject} Email_sent Position Speaker * * Comment Title Text Created date * * Period Stage Title Time of day Day

36. Example deployment model

37. Heroku Smtp.dreamhost.com Paypal PostgreSQL Smidig- conference (Rails) Web userDeveloper smidigdb git.herokugithub git push git pull html/http http smtp

38. Example implementation diagram

39. Router Controller 1. Find controller 2. Dispatch action Model class 3. Find model Model 4. Manipulate model 5.? Save model Database View template 6. Render model with view template

40. Router /app/controllers UsersController 1. Find UserController 2. update(id) / app/models User class 3. find(id) app/models User 5. update_attr(params) 6. save Database 8. Redirect /users/ POST /users/ 4. SELECT … FROM users 7. UPDATE users SET …

41. Router /app/controllers UsersController 1. Find UsersController 2. show(id) /app/models User class 3. find(id) User Database /app/views/users show.html.erb 5. Render GET /users/ 4. SELECT … FROM users 6. Get attributes

42. Alternative

43. BrowserSmidig2012.no Paypal.com 1. POST /users 2. Redirect to paypal with return_url and notify_url 3. Perform payment 4. POST /payment_notifications 5. Redirect to return_url 5. GET /user/ Update user info Show user info Save user info

44. /Uncovering a solution

45. Communicating a solution

47. Vision Stakeholders Usage flow Context Domain model Implementation Deployment

48. Does the architect have to do this herself?

49. Team effort

51. /Communicating a solution

52. /Describing architecture

53. Part II:

54. Simplifying architecture

55. Lasagna architecture Feature oriented architecture Deployment constraints

56. Lasagna architecture

57. Person- Controller Person- Controller- Impl Person- Service Person- ServiceImpl Person- Repository Impl Person- Repository Impl PersonDao Impl PersonDao Impl Session- Factory

58. Controllers Services Managers Workers Repositories

59. Controllers Services Managers Workers Repositories DTO Domain Mapping

61. Customer Invoice Order Product

62. Tidying up art (Ursus Wehrli)

64. Feature oriented architecture

66. Coherence What changes together lives together

68. Tolerance What should be different can be different

70. Meaning What is central in domain is central in code

72. Your thinking is contrained by technology fashion:

73. Controllers Services Managers Workers Repositories DTO Domain Mapping

74. Your solution is constrained by deployment

75. Web Application Web user Database Browser JSON/http Web Service SOAP Web Service Service Consumer DTO? DTO Controller

76. Web Application Web user html/http Database Controller DAO

77. Web Application Web user html/http Database Reverse proxy html/http Controller DAO

78. Web Application Web user Database Browser JSON/http DTO? Controller DAO

79. Web Application Web user Database Rich client Web service DTO Service Consumer Controller

80. Web Application Web user Database Rich client Objects over http DTO Controller

81. Web Application Web user Database Browser JSON/http Web Service SOAP Service Consumer DTO? DTO External client Controller DAO

82. Web Application Web user Database Browser JSON/http Service External client DTO Controller DAO

83. /Simplifying architecture

84. Part III:

85. Delivering software

86. Common sprint problems Demo driven development Rainbow plans

87. Common Sprint problems

88. User stories without context

89. Every feature must be perfect at first try

90. Users don’t understand the demo

91. One-sentence Scrum

92. We demonstrate progress at regular intervals

93. It’s all about the demo

94. We demonstrate progress at regular intervals

95. Progress towards what?

96. Usage flow 1.Something happens in the real world 2.The event is communicated to the system 3.The system does something 4.Someone does something with the system 5.… 6.… 7.… 8.… 9.… 10.Some goal is achieved

99. Rainbow plan

100. Usage flow: frugalflights.com 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

101. What would you do in Sprint 1?

102. Usage flow: frugalflights.com 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

103. Sprint 1: Walking skeleton 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

104. Sprint 2: SMS support 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

105. Sprint 3: Complete workflow 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

106. Sprint 4: Complete SMS 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

107. Sprint 5: Web pages 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

108. Sprint 7: Integration 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

109. Sprint 8: Spit-and-polish 1.A customer wants cheap vacations 2.The customer signs up for daily or weekly notifications of special flight offers 3.Periodically the System checks which customers should get notifications 4.The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system 5.The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email 6.The customer accepts the offer via SMS 1.Variation: The customer accepts the offer on the system website 7.The System books the tickets on behalf of the customer 8.The system confirms the booking by sending an SMS to the customer 9.The customer can at any point see their active offers and accepted offers on the system website 10.The customer enjoys a cheap vacation!

110. /Delivering software

111. Conclusion:

112. Travel light – 7 perspectives Domain oriented architecture Sprint with a (rainbow) plan

113. What’s the common theme?

114. Usage flow

115. Good architecture comes from understanding usage

116. Thank you jbr@exilesoft.com http://johannesbrodwall.com http://exilesoft.com http://twitter.com/jhannes Vision Stakeholders Usage flows – rainbow plans Context Domain (Simple) Deployment (Feature oriented) implementation