Hvorfor prosessen med å visualisere arkitekturen din er viktigere enn det ferdige produktet, og hvordan du kan bruke visualisering til raskere onboarding, bedre tekniske beslutninger og for å bidra til tverrfaglig brobygging.
Vi har alle vært der: Du starter i et nytt prosjekt, åpner kildekoden, og føler at du stirrer inn i en ugjennomtrengelig jungel av logikk. Eller kanskje teamet sitter i et teknisk møte og diskuterer forbi hverandre i en time, før dere innser at dere har hatt tre helt forskjellige oppfatninger av hvordan systemet faktisk henger sammen.
Visualisering er et av våre kraftigste verktøy for å skape felles forståelse, men det blir ofte neglisjert. Mange dropper å dokumentere fordi «systemet endrer seg så raskt uansett» og frykter at diagrammene vil ende sine dager som utdaterte skisser i et glemt område på Confluence.
I dagens luke skal vi se på hvorfor du bør børste støv av tegnebrettet, og hvordan du gjør visualisering til en aktiv del av utviklingshverdagen. Bokser og piler FTW!
Hvorfor skal man visualisere?
Det er flere grunner til at det å visualisere arkitekuren til systemet ditt, og hvordan systemet ditt fungerer kan være nyttig.
1. Fra individuelle til felles mentale modeller
Den viktigste grunnen er for å skape en felles forståelse av hvordan systemet ditt fungerer. Min erfaring er at man ofte kan sitte med forskjellige mentale modeller av hvordan et system ser ut og fungerer, og det å visualisere systemarkitekturen kan være et veldig kraftig verktøy for å bidra til skape en felles forståelse.
Ved å få disse modellene ned på en tavle (fysisk eller digital), ser vi raskt hvor vi er uenige eller hvor forståelsen brister.
Husk: Selve prosessen med å visualisere er ofte mer verdifull enn det ferdige bildet. Diskusjonene som oppstår mens man tegner, er der den virkelige verdiøkningen skjer.
2. Bli enig om teknisk retning og identifisere avhengigheter og flaskehalser
Det å skape en felles forståelse for hele systemet er én ting, men et annet tips er å bruke visualiseringer til å diskutere og bli enig om teknisk retning og målbilder for hvordan man ønsker at systemet skal utvikle seg videre. Et godt oversiktsbilde gjør det tydelig om systemet er fornuftig modellert og delt opp, eller om det ligner en «ball of mud» med avhengigheter på kryss og tvers.
Ved å enklere se hvilke avhengigheter, potensielle flaskehalser og robusthetsutfordringer systemet ditt har kan visualisering derfor være essensielt for å:
- Avdekke potensielle flaskehalser før de blir produksjonsproblemer.
- Synliggjøre hvilke deler av systemet som krever ekstra fokus på robusthet eller testing.
- Brukes som underlag til å identifisere justeringer man bør gjøre i arkitekturen sin og hvilke steg man kan gjøre for å komme seg dit.
3. Utvikling av nye features
Kanskje et åpenbart område hvor visualiseringer er nyttig er å bruke det som et verktøy til å diskutere hvordan nye features kan og bør løses. Det gjør ofte at alle i teamet raskere kommer inn i problemstillingen og at man danner en felles forståelse for hva man faktisk forsøker å løse.
I tillegg vil det å visualisere og tegne kunne gi et godt grunnlag for å diskutere ulike løsningsalternativer, fordeler og ulemper samt identifisere mulige risikoer.
4. Raskere onboarding
For en ny utvikler er et arkitekturdiagram på rett abstraksjonsnivå et uvurderlig kart. Det gjør det mulig å forstå domenet og systemets ansvar uten å måtte lese hver eneste linje med kode først. For å unngå å basere seg på utdatert dokumentasjon, kan en løsning være at man rett og slett tegner opp systemet sammen.
Det å starte på et høyere abstraksjonsnivå enn direkte i koden vil gjøre at man raskere kommer inn i et system og domene, enn hvis man ikke har et felles mentalt bilde av hvordan systemet henger sammen.
5. Tverrfaglig brobygging
Et viktig poeng er at visualisering av arkitektur og systemer ikke bare er for utviklere og teknologer. Det fungerer også veldig bra som et felles språk mellom teknologer, designere og ledelse. En god visualisering kan forklare komplekse tekniske valg for en produktleder, eller hjelpe en designer med å forstå hvordan data flyter gjennom systemet.
Et annet tips er også å inkludere andre fagdisipliner, som designere, i selve prosessen med å visualisere systemet. De har ofte en meget god evne til å skape gode visualiseringer, og ikke minst kommer de inn med andre perspektiver enn de rent tekniske og evner ofte i enda større grad å lukke gapet mellom det tekniske og andre fagdisipliner.
Hvordan skal man visualisere?
Det største hinderet for visualisering og dokumentasjon er kanskje frykten for at den skal bli utdatert. Mitt forslag til en løsning på det er å endre perspektiv: Se på diagrammet som et nåtidsbilde som skal løse et spesifikt problem eller støtte en beslutning her og nå.
Tilpass og vær bevisst detaljering og abstraksjonsnivå
Det er fort gjort å blande ulike nivåer i samme tegning, alt fra detaljerte databasefelt til overordnede skytjenester. Det skaper bare støy. Et diagram bør enten vise detaljene i én tjeneste eller det store bildet, ikke mange deler på en gang.
Er det en teknisk forsamling hvor man skal dykke ned i tekniske detaljer for å skape forståelse eller ta en teknisk avgjørelse, kan det kreve et annet type diagram og detaljnivå enn hvis man skal bruke det mot ledelse eller andre for å forklare hvordan man bør prioritere ulike oppgaver eller hvordan ting fungerer i dag.
Generelt vil et godt diagram uten forstyrrende detaljer, på rett abstraksjonsnivå kunne bidra til effektiv kommunikasjon av tanker og ideer til mange ulike målgrupper.
Bruk kjente teknikker og verktøy
I utgangspunktet kommer man langt med tavle og tusj for å visualisere ting uten et spesielt verktøy eller teknikk. Men det finnes også en del verktøy og metoder som kan være nyttig å ha med seg i verktøykassa.
C4-modellen
En for mange kjent og kjær måte å strukturere arkitektur-tegningen sine på er C4-modellen. Dette er en modell hvor man strukturerer systemer på fire nivåer: Context, Containers, Components og Code. Spesielt nivå 1 og 2 er gull verdt for de fleste team.
Flyt- og prosessdiagrammer
Det å beskrive ulike forretningsflyter og -logikk, eller hvordan systemer snakker sammen kan ofte blir rotete med mer statiske modeller som C4-modellen. Jeg vil derfor anbefale å teste ut ulike flyt- og prosessdiagrammer, gjerne hvor man får med seg ulike systemer eller roller i f.eks. et swimlane-oppsett.
Flytdiagrammer er også veldig nyttig for å få frem ulike brukerreiser i ett system, eller på tvers av flere system.
Sekvensdiagrammer
Et klassisk sekvensdiagram er også et nyttig verktøy å ha i verktøykassa når du skal visualisere hvordan data flyter mellom tjenester over tid. Detaljerte flyter som går på tvers av komponenter blir mye tydeligere her og vil kunne fungere som både dokumentasjon og ikke minst som underlag for diskusjon.
Verktøy
Som sagt er en tavle og tusj ofte tilstrekkelig, men det finnes også en rekke digitale verktøy man kan benytte:
- Miro, Draw.io, Lucidchart, Excalidraw el.l.: Lav terskel og enkelt å komme i gang med. Mange av disse verktøyene har også støtte for de ulike type diagrammene nevnt over.
- Mermaid.js eller PlantUML: "Diagrammer som kode". Kan versjonshåndteres i Git sammen med koden og kan legges sammen med kildekoden din. Mermaid støttes også ut av boksen av f.eks. GitHub.
- Structurizr: Spesialverktøy for C4-modellen som sikrer konsistens mellom nivåene og gir mulighet til å navigere og klikke seg rundt i en modell mellom ulike nivåer.
Oppsummering
Ikke la arkitekturvisualisering bli noe stort og tungt og noe å være redd for. Start enkelt, tegn ofte, og husk at målet er kommunikasjon, ikke kunst. Neste gang dere står fast i en komplisert diskusjon: Finn frem en (digital) tusj og be noen tegne det de snakker om. Du vil bli overrasket over hvor mye raskere dere kommer til enighet, og hvor nyttig et par bokser og piler kan være.