Conways lag och teamstruktur

Conways lag påverkar SaaS-arkitekturer i hög grad:

• Monoliter: Byggs ofta av stora, tätt sammankopplade team, vilket leder till en enda sammanhängande kodbas.
• Mikrotjänster: Växer ofta fram ur mindre, självständiga team där varje team ansvarar för en specifik tjänst.
• Modulär design: Om teamen är organiserade kring verksamhetsdomäner kommer deras tjänster naturligt att återspegla dessa domäner.

Genom att förstå detta kan vi utforma bättre organisationer för att skapa bättre programvara.

Kommunikation handlar inte bara om formella möten. Den omfattar:

• Teamstruktur: Vem som rapporterar till vem och var teamgränserna går.
• Verktyg: Chatt, projekthantering och kodarkiv.
• Processer: Kodgranskningar och pipelines för driftsättning.
• Informella kanaler: Småprat vid kaffemaskinen och sociala interaktioner.

Alla dessa faktorer påverkar hur information flödar och därmed hur ert SaaS-system är strukturerat.

I stället för att låta organisationsstrukturen styra arkitekturen kan vi göra tvärtom! Detta kallas Reverse Conway Maneuver.

Om ni vill ha en mikrotjänstarkitektur kan ni proaktivt organisera teamen i små, autonoma enheter där varje enhet äger en specifik tjänst eller domän.

Detta strategiska arbetssätt hjälper er att uppnå önskade arkitekturresultat genom att påverka hur teamen samverkar.

Med utgångspunkt i Conways lag erbjuder boken "Team Topologies" av Matthew Skelton och Manuel Pais ett praktiskt sätt att strukturera team.

Den identifierar fyra grundläggande teamtyper och samspelsformer som optimerar för snabb och säker leverans av programvara.

Målet är att minska den kognitiva belastningen och förbättra flödet för flödesanpassade team.

Flödesanpassade team utgör kärnan i modellen Team Topologies. De är:

• Fokuserade på ett enda kontinuerligt arbetsflöde.
• Direkt anpassade till en verksamhetsdomän eller användarresa.
• Bemyndigade att leverera värde från början till slut med minimala beroenden.

De bör ha låg kognitiv belastning och fokusera på att göra en sak riktigt bra.

För att stödja flödesanpassade team har vi:

• Enablement-team: Kortlivade team som hjälper flödesanpassade team att ta till sig ny teknik eller övervinna hinder, och sedan upplöses.
• Plattformsteam: Tillhandahåller interna tjänster, API:er och verktyg som andra team kan använda. Tänk på det som "Software as a Service" för interna utvecklare.

Dessa team minskar belastningen på de flödesanpassade teamen och låter dem fokusera på verksamhetsvärde.

Den sista teamtypen är team för komplexa delsystem. Dessa team specialiserar sig på områden som kräver djup och nischad expertis.

• De hanterar komplexa algoritmer, AI/ML-modeller eller svåra integrationer.
• Målet är att minska den kognitiva belastningen för flödesanpassade team genom att tillhandahålla denna komplexitet som en tjänst.
• Interaktionen med dem sker vanligtvis via väldefinierade API:er.

De är mindre vanliga men avgörande för specialiserade komponenter.

Idag utforskade vi Conways lag och dess djupgående påverkan på programvaruarkitektur, särskilt inom SaaS.

• Vi såg hur organisatoriska kommunikationsstrukturer återspeglas i systemdesignen.
• Vi lärde oss om Reverse Conway Maneuver, som används för att medvetet forma arkitekturen.
• Slutligen introducerade vi de fyra grundläggande Team Topologies: Stream-Aligned-, Enabling-, Platform- och Complicated Subsystem-team, samt hur de optimerar flödet och minskar den kognitiva belastningen.

Att förstå teamdynamik är avgörande för att bygga skalbara och lättunderhållna SaaS-produkter.