The document discusses software architecture's importance, drawing parallels to linguistic nuances, and introduces Kruchten's 4+1 view model to describe future systems effectively for various stakeholders. It covers architectural patterns, the differences between human and computer processing, and proposes approaches for designing user flows. Additionally, it emphasizes the continual review and iteration of system design to maintain a robust software architecture.

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