The document discusses agile architecture and solution design, outlining how an architect should understand the customer problem, uncover and communicate a feasible solution through describing the architecture, simplifying it based on constraints, and delivering the software solution through iterative development and demos using a technique called "rainbow planning".

1. Agile Architecture
Odessa
Johannes Brodwall, Chief scientist
Exilesoft Global

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

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

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 goal
The Odessa agile user group (?)
Is a type of activity
Which gives a capability.
Unlike most relevant alternative
This has a distinguishing attribute.

15. For __________________
Who ________________
The Odessa agile user group (?)
Is a _________________
Which ________________.
Unlike ______________________
This _______________________.

16. Example
«Smidig» conference application

17. Example vision
statement

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

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

21. Example
stakeholders

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

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

24. Example usage flow

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

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

28. /Understanding the
problem

29. Uncovering a
solution

30. Example context
model

31. Participant Speaker
Organizer
Paypal Smidig2011.no
Printing
company

32. Example domain
model

33. 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 : {pending, • Day
accept, reject}
• Email_sent
• Position

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. Example
implementation
diagram

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

38. /Uncovering a
solution

39. Communicating a
solution

41. Vision
Stakeholders
Usage flow
Context
Domain model
Implementation
Deployment

42. Does the architect
have to do this
herself?

43. Team effort

45. /Communicating a
solution

46. /Describing
architecture

47. Part II:

48. Simplifying
architecture

49. • Lasagna architecture
• Feature oriented architecture
• Deployment constraints

50. Lasagna
architecture

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

52. Controllers
Services
Managers
Workers
Repositories

53. Controllers
DTO
Services Mapping
Domain
Managers
Workers
Repositories

55. Customer
Invoice
Order
Product

56. Tidying up art (Ursus Wehrli)

59. Feature oriented
architecture

60. Coherence
• What changes together
lives together

62. Tolerance
• What should be different
can be different

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

66. Your thinking is
contrained by
technology fashion:

67. Controllers
DTO
Services Mapping
Domain
Managers
Workers
Repositories

68. Your solution is
constrained by
deployment

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

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

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

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

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

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

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

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

77. /Simplifying
architecture

78. Part III:

79. Delivering software

80. • Common sprint problems
• Demo driven development
• Rainbow plans

81. Common Sprint
problems

82. User stories without
context

83. Every feature must be
perfect at first try

84. Users don’t understand the
demo

85. One-sentence
Scrum

86. We demonstrate progress
at regular intervals

87. It’s all about the demo

88. We demonstrate progress at
regular intervals

89. Progress towards
what?

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

93. Rainbow plan

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

95. What would you do
in Sprint 1?

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

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

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

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

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

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

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

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

104. /Delivering software

105. Conclusion:

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

107. What’s the common
theme?

108. Usage flow

109. Good architecture
comes from
understanding usage

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