The document discusses pragmatic architecture for agile teams. It argues that architecture is too important to be left solely to architects and should be a team responsibility. It recommends balancing agility and discipline by designing enough architecture early while still prototyping. Key aspects of good architecture include getting all hands on deck in architectural decisions, prioritizing local team decisions while ensuring feedback, and documenting relationships not clear from code like domain dictionaries, component diagrams, and integration diagrams.

1. "All Hands on Deck"
Pragmatic
Architecture
for Agile Teams
Janne Sinivirta / @v3rtti

2. Outline
Where are we now and why?
How can we be better?
1. Balance
2. "All Hands on Deck"
3. Team vs Organization
4. Documentation

3. Forgotten Architecture

4. Where are we now?

5. Conspiracy?

6. Bad Rap
for Architecture

7. How can we be better?
1. Balance

8. BDUF vs. YAGNI
Big Design Up Front vs. You Aren't Gonna Need It
* see "Balancing Agility and Discipline" by Barry Boehm and Richard Turner

9. MVP and Architecture
Agile is all about emergent design
Architecture gives the code a place to grow
Designing architecture only for MVP is short-sighted
Architecture from tests only .. is horse shit!
- Uncle Bob Martin

10. The Dilemma of
Last Responsible
Moment
Recognize hard problems
Start early and prototype

11. How can we be better?
2. All Hands
on Deck

12. In Hurry to
Wait

13. Team Decisions
Architecture is too important to be left for the architect.

14. Modern Architect

15. Kaizen
Optimizing the organization and the value stream.

16. Users and Domain
Experts
Genchi Genbutsu (x˜x) Go and see for yourselves!
Matching users mental model
Future proofing with crazy ideas

17. How can we be better?
3. Team vs.
Organizatio
n

18. Local and Fast
Allow local decisions
Ensure feedback both ways

19. Conway's Law

20. No organization
There's no organization. Just people. Get to know them!

21. How can we be better?
4. Documentation

22. Basics
Who's the reader?
Code as forward thinking documentation
Document relationships that are not visible from code

23. Must-have documents
Domain Dictionary
Aim for common language in team
Reduce misunderstandings
Don't conquer all with single dictionary
Create with stakeholders
Aliases that combine multiple terms/concepts

24. Must-have documents
External integrations diagram
Created with PlantUML

25. Must-have documents
Internal component diagram
Created with PlantUML

26. Must-have documents
Domain Model as Code
https://github.com/NitorCreations/DomainReverseMapper

27. Must-have documents
Domain dictionary
Internal component diagram
External integration diagram
Domain model as code
Decision log

28. Summary
Design enough, early enough
Architecture is a team responsibility
See for yourself! is essential in good design
Document things that are not visible from code

29. Thank you!
Questions?
Janne Sinivirta / @v3rtti