The document discusses the importance of pragmatic architecture in agile teams, emphasizing shared responsibility and collaboration among team members rather than relying solely on architects. Key concepts include balancing design methodologies, utilizing domain modeling for clearer communication, and maintaining effective documentation to enhance understanding and decision-making. It serves as a guide to improving architectural practices within agile frameworks, advocating for early prototyping and feedback loops.

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

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. Domain Modeling
5. 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. How can we be better?
3. Team vs.
Organizatio
n

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

18. Conway's Law

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

20. How can we be better?
4. Domain
Modeling

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

22. What the system..
IS vs DOES
Data vs Algorithm
Plan for change
Traits?

23. Languages, paradigms
and patterns
Modeling variance
Language features > libraries > design patterns

24. Role of DSL's
Modern languages support DSL creation
DSL often end up restrictive or fragile
"Nothing says screw you like a DSL"
- Stuart Halloway

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

26. How can we be better?
5. Documentation

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

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

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

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

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

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

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