Software architecture often comes in complicated charts and indecipherable UML drawings, involves cryptically named patterns, and requires both developers and users jump through multiple hoops to achieve desired results. Agile tries to get rid of software architecture thoughtfulness altogether, by advocating “emerging architecture” on the fly, in the course of writing code. This talk considers the goals of software architecture, the thought patterns used to arrive to architectural decisions, and ways to test architectural decisions. We will also look at the architectural pattern library that can make the work of an architect easier, more testable, and less mess-prone.

1. Thoughts on building
Software Architecture
Jane Prusakova
@jprusakova

2. Why architecture?
• Eskimo have 50 words for snow
• Italians – only one
• No easy way to describe something that
doesn’t exist

3. Kruchten’s 4+1 View Model
• Architecture is mostly a way to describe a future system
• Context & vocabulary to make decisions
• Communicate a vision of the system design at various levels for
• business stakeholders
• development team
• IT and devops
• end users

4. Building architecture
• Model the process
• Data flow
• Make decisions about blocks and interactions
• current knowledge
• expectations

5. From requirements to solution
• The data arrives from …
• Every … message triggers … action
• User can see data arranged in … way
• User can affect data in … way
• Processing results are forwarded to …

6. Architectural patterns
• Structural
• Layered
• Client-server
• Pipe & Filter
• Functional
• Broker
• Peer-to-peer
• Event bus
• MVC
• Platform

7. For all of the architectural patterns:
Pros
• Well-understood
• [Some] Can be delivered piece-
meal
• Offer good support for original
purpose
Cons
• Complex
• [Some] Big bang delivery style
• Suitable in distinct situations
• Hard to expand beyond original
goals

8. Thought patterns
Common & intuitive
• Data flow
• Step-by-step
Less intuitive
• Recursive approach
• State machine

9. Humans vs Computer programs
• Linear time
• Stakeholders handle the most
common case
• Often one or only a few options
• Step by step approach
• Humans handle special
circumstances well
• Computes are state machines
• Time is non-linear
• Every path must be pre-defined

10. Wizard vs Hub & spoke
Home
Pick a
product
Select
features
Retrieve
price
Select
quantity
Checkout
Home
Pick a
product
Select
features
Retrieve
price
Select
quantity
Checkout
Only one action is possible from every point. Any action is possible at any point.

11. W
I
Z
A
R
D

12. S
p
o
k
e
Hub
&

13. What’s the “right” wizard?
• Developers are notoriously bad at
inventing user flow
• Less defined flow makes for better
usability
• Leave every path open

14. Linear vs Hub & spoke
State
• Transition
• Context
Transition
• Action
• FromState
• ToState
State • Context
Transition • Action

15. Structured flow Open flow
• Season subscription
1. Pick a package
2. Select day
3. Select titles
4. Review dates
5. Review seating prices
6. Select seating
7. Add to cart

16. Ah… so what do I code first?
• Implement a valid state
• Implement another valid state
• Implement transition
Valid options
 Nothing selected
Product selected
Product & term selected
Product Subscription
Term

17. Future brings change
• Rewrite: every 3 years
• Survivors: Twitter
• Did not survive: Netscape
• Hurt: hundreds of businesses
• Conway’s law: software system takes a form congruous to the
organization that produced it

18. Next steps: Design
•Iterate on design
• Merge and split states
• Merge and split transitions
• Add states and transitions
•Refactor code
• To fit the design
State
State
State
State
State
State
State

19. Maintaining architecture
• Review system design every
development cycle
• Keep the diagrams out and in the focus of
the team
• Communicate architectural decisions
continuously
• made previously
• current
• being re-thought
• Continue asking stakeholders
• What else is there?

20. Inspired reading
• “The Mythical Man-Month”
by Fred Brooks (Addison-Wesley,
1975)
• “The Pragmatic Programmer”
series by Andrew Hunt and Dave
Thomas

21. Thoughts on building
Software Architecture
Jane Prusakova
@jprusakova