Det finns ingen arkitektur – bara beslut som hänger ihop

”Vi använder REST.”

Det är ett besked om ett teknikval. Det säger inte mycket om varför det var rätt val för projektet, eller när ni borde ompröva det.

Den skillnaden är viktig när jag pratar om lösningsarkitektur. Diagrammen hjälper oss se hur delarna hänger ihop. Besluten bakom dem hjälper oss förstå varför.

Teknikval får konsekvenser för arbetet

Bygga själva eller köpa? Samla funktionerna i ett system eller dela upp dem? Koppla ihop direkt eller via en gemensam lösning?

Det är tekniska frågor med konsekvenser för tid, kostnad och ansvar. Teamet ska kunna bygga lösningen, någon ska kunna drifta den och verksamheten ska kunna leva med vad som händer när en del slutar fungera.

En snygg teknik kan fortfarande vara ett dåligt val för ett team som saknar förutsättningar att ta hand om den.

Skriv ner vad ni väljer mellan

Ett kort beslutsunderlag kan besvara:

• Vilket behov eller problem ska valet hantera?
• Vilka alternativ övervägde vi?
• Varför valde vi det här?
• Vilka nackdelar accepterar vi?
• Vad skulle få oss att tänka om?

”Teamet kan redan den här tekniken och leveransdatumet är nära” kan vara ett fullt rimligt skäl. Men skriv också vad ni avstår från och vad som blir svårt att ändra senare.

”Vi byter när det behövs” är inte en plan om ingen har funderat på vilka delar som då måste göras om.

Undersök begränsningen innan ni byter arkitektur

Om ett system inte klarar belastningen behöver ni veta var det tar stopp. Att kalla det en monolit förklarar inte i sig problemet, och att dela upp det garanterar inte en förbättring.

Samma sak med att kopiera någon annans upplägg. Ni behöver förstå vilket problem deras val löste och om ni faktiskt har det problemet.

Jag vill hellre se ett avgränsat försök som prövar ett viktigt antagande än en stor skiss där alla svåra frågor göms i pilarna.

Dokumentera sedan resultatet tillsammans med beslutet. Om ett halvår ska kollegan som tar över kunna förstå mer än vilka verktyg ni råkade välja.