pragmatic architecture for agile teams - geecon 2014

"All Hands on Deck"

PragmaticArchitecture

for Agile Teams / Janne Sinivirta @v3rtti

geecon prague 2014

OutlineWhere are we now and why?How can we be better?

1. Balance2. "All Hands on Deck"3. Team vs. Organization4. Domain Modeling5. Documentation

Forgotten Architecture

Where are we now?

Conspiracy?

Bad Rapfor Architecture

How can we be better?

1. Balance

BDUF vs. YAGNIBig Design Up Front vs. You Aren't Gonna Need It

* see "Balancing Agility and Discipline" by Barry Boehm and Richard Turner

MVP and ArchitectureAgile is all about emergent designArchitecture gives the code a place to growDesigning architecture only for MVP is short-sighted

- Uncle Bob Martin

Architecture from tests only .. is horse shit!

The Dilemma ofLast Responsible

MomentRecognize hard problemsStart early and prototype

How can we be better?

2. All Handson Deck

In Hurry toWait

Team Decisions

Architecture is too important to be left for the architect.

Modern Architect

Kaizen

Optimizing the organization and the value stream.

How can we be better?

3. Team vs.Organizatio

n

Local and FastAllow local decisionsEnsure feedback both ways

Conway's Law

No organization

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

How can we be better?

4. DomainModeling

Domain DictionaryAim for common language in teamReduce misunderstandingsDon't conquer all with single dictionaryCreate with stakeholdersAliases that combine multiple terms/concepts

What the system..IS vs DOES

Data vs AlgorithmPlan for changeTraits?

Languages, paradigmsand patterns

Modeling varianceLanguage features > libraries > design patterns

Role of DSL'sModern languages support DSL creationDSL often end up restrictive or fragile

- Stuart Halloway

"Nothing says screw you like a DSL"

Users and DomainExperts

Genchi Genbutsu (現地現物) Go and see for yourselves!Matching users mental model"Future proofing" with crazy ideas

How can we be better?5. Documentation

BasicsWho's the reader?Code as forward thinking documentationDocument relationships that are not visible from code

Must-have documentsExternal integrations diagram

Created with PlantUML

Must-have documentsInternal component diagram

Created with PlantUML

Must-have documentsDomain Model as Code

https://github.com/NitorCreations/DomainReverseMapper

Must-have documentsInternal component diagramExternal integration diagramDomain model as codeDomain dictionaryDecision log

SummaryDesign enough, early enoughArchitecture is a team responsibility"See for yourself!" is essential in good designDocument things that are not visible from code

Thank you!Questions?

Janne Sinivirta / @v3rtti