The document discusses agile architecture and the role of a solution architect. It defines a solution architect as someone who understands the customer's problem, including constraints and domain knowledge, and uncovers and communicates a feasible solution. It emphasizes that discovering the solution is a team effort. The architect's responsibilities include understanding the problem, describing the problem context and domain model, describing the proposed solution, and simplifying and delivering the architecture and software.

1. Agile Architecture
Colombo Agile Meetup
Johannes Brodwall, Chief scientist
Exilesoft Global

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

3. What is an architect?
(Exilesoft definition)

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

5. 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)

6. 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

7. • Describing architecture
• Simplifying architecture
• Delivering architecture
• Delivering software

8. Part I:

9. Describing
architecture

10. Understanding the
problem

11. (Tool time)

12. For some stakeholder
Who has a goal
The Colombo Agile Meetup
Is a type of activity
Which gives a capability.
Unlike most relevant alternative
This has a distinguishing attribute.

13. For anyone interested in agile methods
Who ________________
The Colombo Agile Meetup
Is a _________________
Which ________________.
Unlike ______________________
This _______________________.

14. Example
«Smidig» conference application

15. Example vision
statement

16. 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.

17. 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.

19. Example
stakeholders

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

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

22. Example usage flow

23. 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

25. 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

26. /Understanding the
problem

27. Uncovering a
solution

28. Example context
model

29. Participant Speaker
Organizer
Paypal Smidig2011.no
Printing
company

30. Example domain
model

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

32. Example
implementation
diagram

33. Browser Smidig2012.no Paypal.com
1. POST /users
Save user info
2. Redirect to paypal
with return_url and notify_url
3. Perform payment
4. POST /payment_notifications
Update user
info
5. Redirect to return_url
5. GET /user/<id>
Show user info

34. Example
deployment model

35. Web user
Developer html/http
git push git push
git pull
Smidig-
conference http
Paypal
github git.heroku (Rails)
smtp
Heroku
Smtp.dreamhost.com
smidigdb
PostgreSQL

36. /Uncovering a
solution

37. Communicating a
solution

39. Vision
Stakeholders
Usage flow
Context
Domain model
Implementation
Deployment

40. Does the architect
have to do this
herself?

41. Team effort

43. /Communicating a
solution

44. /Describing
architecture

45. Part II:

46. Simplifying
architecture

47. Lasagna
architecture

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

49. Controllers
Services
Managers
Workers
Repositories

50. Controllers
DTO
Services Mapping
Domain
Managers
Workers
Repositories

52. Customer
Invoice
Order
Product

53. Tidying up art (Ursus Wehrli)

56. Feature oriented
architecture

57. Coherence
• What changes together
lives together

59. Tolerance
• What should be different
can be different

61. Meaning
• What is central in domain
is central in code

63. Your thinking is
contrained by
technology fashion:

64. Controllers
DTO
Services Mapping
Domain
Managers
Workers
Repositories

65. Your solution is
constrained by
deployment

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

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

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

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

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

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

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

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

74. /Simplifying
architecture

75. Part III:

76. Delivering software

77. Common Sprint
problems

78. User stories without
context

79. Every feature must be
perfect at first try

80. Users don’t understand the
demo

81. One-sentence
Scrum

82. We demonstrate progress
at regular intervals

83. It’s all about the demo

84. We demonstrate progress at
regular intervals

85. Progress towards
what?

86. 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

89. Rainbow plan

90. 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!

91. What would you do
in Sprint 1?

92. 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!

93. 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!

94. 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!

95. 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!

96. 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!

97. 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!

98. 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!

99. 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!

100. /Delivering software

101. Conclusion:

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

103. What’s the common
theme?

104. Usage flow

105. Good architecture
comes from
understanding usage

106. 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