Referensarkitekturer

Det här biblioteket växer fram ur verkliga projekt, inte från en whiteboard. Varje referensarkitektur representerar en lösning på ett problem jag faktiskt har byggt, driftsatt och underhållit – med kompromisser och avvägningar dokumenterade öppet. Det är inte 'best practices' i teorin, det är vad som fungerade när verkligheten satte press.

En referensarkitektur är en startpunkt, inte en färdig ritning. Om eran last är 10x högre, ert team har en annan kompetensprofil, eller era krav är unika – då ska ni inte följa den slaviskt. Ni ska förstå varför varje komponent finns, vilka alternativ som övervägdes, och sedan anpassa efter er verklighet.

Just därför är avvägningarna den viktigaste delen av varje arkitektur. Jag dokumenterar inte bara vad jag valde – jag dokumenterar varför jag valde som jag gjorde, och vad jag kompromissade bort. Det är den informationen som låter ert team fatta egna, informerade beslut när förutsättningarna ändras.

Varje arkitektur är strukturerad i fyra delar: komponenterna (vad som ingår och deras roll), avvägningarna (de viktigaste vägvalen med för- och nackdelar), kostnadsintervall (vad det kostar att driftsätta i olika skalor), och en länk till den tjänst som bäst motsvarar behovet av att bygga liknande lösningar.

Om du fastnar på en avvägning eller undrar varför ett alternativ valdes bort – kommentera eller hör av dig. Det bästa sättet att förbättra en referensarkitektur är att utsätta den för ett verkligt användningsfall som skiljer sig från det ursprungliga.