Agil arkitektur - agile manifesto princip #11 vs termodynamikkens 2. hovedsætning

Hvis der er en ting, som karakteriserer de agile udviklingsmetoder er det, at de intet har at sige om arkitektur. Det tætteste er The agile manifesto’s princip #11("The best architectures, requirements, and designs emerge from self-organizing teams”). Det postulerer at optimal struktur opstår af sig selv. Nu har jeg arbejdet med det der arkitektur i nogle år, og jeg må indrømme, at jeg ikke kan genkende dette postulat fra en eneste systemimplementering, agil eller andet.

Tværtimod er det nærmere termodynamikkens 2. hovedsætning, som synes at regere, nemlig at entropi vil tiltage i systemet. Eller for at sige det på en anden måde, uorden, og altså ikke orden, opstår af sig selv. Det agile team må aktivt gøre noget for at holde denne uorden nede hele tiden. Det sker primært ved at re-faktorere når det hele bliver lidt for uoverskueligt.

En anden vej?

Derfor er det spændende når nogen prøver at tage dette seriøst. Dean Leffingwell, som selv er en agil guru, har indset at god arkitektur ikke i alle tilfælde opstår af sig selv. I sin bog “Agile Software Requirements” tackler han udfordringen med at skalere agil udvikling til store virksomheder baseret på personlige erfaringer. Om strukturen på større virksomhedssystemer siger han “It can’t simply emerge. Something has to tie it all together” (386). Han har derfor udviklet otte principper for agil arkitektur. Det var med stor glæde jeg opdagede dette og det kriblede i fingrene for at finde ud af hvordan man gør, for jeg synes også, at det er en af de største uklarheder ved eksisterende agile metoder. Efter at have gennemlæst de otte principper kom jeg lidt ned på jorden igen. For det er da nogle meget fornuftige almindeligheder, men det har stort set intet med arkitektur at gøre.

Lad mig først gøre klart, hvad jeg mener med arkitektur for at undgå misforståelser: Arkitektur forstår jeg i forlængelse af ISO/IEC 42010:2011 :"fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. Jeg forventer altså en eller anden beskrivelse af nogle komponenter, deres relation og principper for design og udvikling. Her er Leffingwells principper og mine kommentarer.

• 1) The team that code the system also design the system - dette er bare en paraphrase af agile manifestos princip om empowered teams og siger vel egentlig, at en arkitekt ikke sådan rigtigt er nødvendig.
• 2) Build the simplest architecture that can possibly work - en floskel, som meget få kan være uenige i. En god test er at prøv at sige det modsatte. Hvis det er selvindlysende forkert, er udsagnet tomt. Man skal risikere noget, når man laver principper.
• 3) When in doubt, code it or model it out - så man skal lave et forsøg, hvis man er i tvivl. Hmm, nogle gange fornuftigt, nogle gange spild af tid, nogle gange umuligt, men i alle tilfælde har det intet med arkitektur at gøre. Arkitekter bygger jo ikke et hus for at se om det vil virke. Men de bygger selvfølgelig modeller, men hvordan det skal overføres til arkitektur kan jeg ikke gennemskue.
• 4) They build it, they test it - så udviklerne skal også være testere, det vil de sikkert blive glade for. Det er jo velkendt, at det er en af de opgaver de normalt kaster sig over med størst entusiasme og udfører med stor kvalitet (ironi, sorry). Jeg er fundamentalt uenig i, at det er en fordel, at man tester det, man selv har lavet på grund af confirmation bias. Det er jo også derfor man har peer review og code review og alt muligt andet review. Man bliver jo blind overfor sine egne frembringelser. Men uanset om det er en god eller dårlig ting, kan jeg ikke se relationen til arkitektur.
• 5) The bigger the system, the longer the runway - Runway refererer til hans begreb “Architectural Runway", og her ser det ud som om han siger, at jo større systemet er jo længere tid tager det at udvikle og implementere arkitekturen. Well, ok….Det kan vel næppe komme som det helt store chock, at det tager lidt længere at lave og implementere arkitekturen til storebæltsbroen end til end FDF spejdernes træbro over Tuse Å eller?
• 6) System architecture is a role collaboration - Så man skal samarbejde? ja, det er altid godt at samarbejde. Endnu en tom anbefaling, der ikke rigtig hjælper så meget.
• 7) There is no monopoly on innovation - så alle må komme med ideer. Det lyder også som et pludselig indspark fra tiden rundt om lejrbålet med protestsange. Igen, helt enig, men hvad siger det os egentlig om arkitekturen?
• 8) Implement architectural flow - det lyder spændende, og det er så centralt, at der er et helt kapitel til det. Dette kapitel anbefaler, at man begynder at arbejde med Kanban og prioriterer sine arkitektur epics. Det er måske mig, men kunne man ikke godt have fundet på det selv eller bare læst Don Reintertsens bøger istedet?

Så hvad gør vi?

Der er desværre essentielt set intet at hente i disse 8 tilfældige lyse ideer, som Leffingwell er kommet på. Jeg undskylder, at det lyder så negativt, men det er ren skuffelse, for resten af Leffingwell's bog faktisk er aldeles glimrende med rigtigt mange gode tanker om, hvordan man implementerer agile arbejdsmetoder i større mere komplekse virksomheder. Jeg ville ellers enormt gerne have lært noget mere om hvordan, man sørger for at agile teams løsninger konvergerer mod en arkitektur, og hvordan denne designes. Hvordan det sikres at arkitektur patterns bliver fulgt. Hvordan arkitektonisk udvikling i produkter med legacy komponenter eller interfaces, som er reglen ikke undtagelsen, ville tage sig ud. Kort sagt så ville jeg rigtigt gerne vide, hvordan vi sørger for at arbejdet i agile teams ikke bare blindt følger termodynamikkens anden hovedsætning.