Team, system og produkt er tre forskjellige enheter

Et team er en gruppe mennesker som jobber sammen for å nå et felles mål.

Et system er en digital enhet som utfører én eller flere oppgaver.

Et produkt er det brukerne møter, og gjerne i en større helhet.

Dette høres kanskje åpenbart ut, og grunnen til at jeg likevel velger å fremheve dette er fordi jeg opplever at de ofte sauses sammen: Vi setter rett og slett ofte likhetstegn mellom disse, og spesielt når opphavet er et prosjekt. Hvor mange har ikke opplevd at man navngir et prosjekt, for å gi teamet det samme navnet, og systemet det samme navnet?

Når man begynner å blande disse sammen, får man uønskede konsekvenser.

Arkitektur følger kommunikasjon

Et naturfenomen i arkitektur (eller systemdesign, om du vil), er at den vil følge kommunikasjonsstrukturen til de som lager den. Dette er kjent som Conways lov. Hva betyr dette i praksis? At teamene vi har, og hvordan de er innrettet, vil forme arkitekturen vår. Martin Fowler har en fin-fin artikkel om Conways lov som du kan lese her. Jeg bruker et eksempel fra hans artikkel her som en rask oppsummering:

Fowlers eksempel har tre team i USA, hvor to av teamene sitter i nord-øst, mens ett team sitter i sør-vest. Vi ser at:

• De sterkeste avhengighetene finner vi internt i hvert teams systemer
• Det er sterkere avhengigheter mellom systemene som er i samme tidssone (og hvor teamene formodentlig kan kjøre bil for å møte hverandre), enn det er mellom team på tvers av kontinentet

Med Conways lov i bakhodet, må vi holde tunga rett i munnen når vi definerer teamenes ansvarsområder. Målet vårt er:

1. ...å få en arkitektur som er bærekraftig over tid
2. ...å få en arkitektur som understøtter produktene vi leverer til brukerne

Dersom vi setter likhetstegn mellom team, system og produkt, bommer vi på begge disse.

Når vi sauser sammen team, system og produkt får vi dårlig arkitektur

...fordi, som vi har sett, arkitektur følger kommunikasjon. Ved å blande disse begrepene sammen, får vi en monolitt-arkitektur. Over tid blir den vanskeligere og vanskeligere å jobbe med, og min påstand er at mange moderniseringsprosjekter i stor grad skyldes nettopp dette.

Det vi bør gjøre i stedet, er å tegne opp verdistrømmene, og designe systemene og teamene våre etter disse. Vi ønsker å holde komponentene små og dedikerte, og avhengighetene til et minimum:

1. Vi starter i den brukernære enden, med produktet, ettersom det er dette som gir verdi for virksomheten vår.
2. Med Conways lov i bakhodet kan vi se på hvilke systemer vi trenger for å understøtte verdistrømmene (også kjent som produktvertikaler) i produktet.
3. Til sist kan vi se på hvordan vi hensiktsmessig kan organisere teamene for å best mulig levere og utvikle disse systemene. Dette er utenfor scope for denne artikkelen, men jeg har skrevet noen ord om det tidligere (se her, nærmere bestemt under "Effektiv organisering").

Tenk på hva brukeren skal gjøre når du designer team og systemer

De er tre forskjellige enheter, som egentlig er vidt forskjellige. Tenk eksempelvis på et digitalt produkt med en stor brukermasse, som Facebook. Jeg kan garantere at Facebook ikke har ett team som heter "Web", og ett annet team som heter "Mobil": Dette er flater som brukerne interagerer med produktet gjennom. De forskjellige systemene sys sammen i disse flatene, for å gi en helhetlig opplevelse.

Jeg tror at monolitter gjerne oppstår fordi man tenker innenfra og ut, heller enn å tenke utenfra og inn, når man skal innrette team:

• Med innenfra og ut mener jeg at man typisk ser et problem som må løses, også oppretter man et prosjekt, setter på ett eller flere team, leverer en antatt løsning på problemet, og sier seg ferdig.
• Med utenfra og inn mener jeg at man må se på problemet i kontekst av produktet, og "jobbe seg tilbake" til hvordan dette bør løses. Her tenker vi fra brukerens perspektiv, ved hjelp av verdistrømkartlegging. Videre organiserer vi team for å understøtte systemene som følger verdistrømmene.

Å lykkes med dette i praksis er selvfølgelig svært krevende, men det starter med å skille på team, system og produkt.

Jeg håper at denne artikkelen gjør at du stopper opp neste gang du ser at navnet på et team og et system (og kanskje også et produkt!) sammenfaller.