Sagt: Smidig modellering? Prøv C4
(Jeg har lest bok. Dette er en slags bokrapport, men også en liten oppfordring til modellering.)
Gjennom mine ca. 20 år med smidige metoder har jeg sett og hørt mange tanker og meninger om hva som er smidig og ikke minst hva som ikke er smidig. En gjenganger er at dokumentasjon er overflødig, alt man trenger å vite ligger i koden. Dette følges gjerne av en henvisning til det smidige manifests punkt om «Working software over comprehensive documentation». Joda, hundrevis av sider med informasjon som ikke er oppdatert er avleggs. Men ingen systemdokumentasjon? Næh. Da svinger pendelen litt for langt.
Det kan være mange grunner til å ønske å dokumentere et system med noen gode modeller. Mange tenker bedre visuelt enn med tekst, så en god modell vil gi en bedre forståelse.
Det er lettere å kommunisere om en visuell modell enn en stor mengde tekst, særlig hvis man vil ha med noen ikke-programmerere i diskusjonen. Og bedre kommunikasjon og forståelse gir bedre beslutninger.
Men da må vi ha en felles forståelse av modellen og notasjonen den bruker.
For hva betyr det egentlig at den ene linjen er stiplet linje og den andre heltrukket? Skal vi ha pil eller kråketær på de gule linjene? Og hvilket nivå ser vi på når Customer-klassen er tegnet inn i samme diagram som ERP-systemet?
Om du bruker UML, BMPN eller OPM, sannsynligheten er stor for at det er forskjellige meninger om hva de forskjellige elementene i notasjonen betyr, og man må ofte ha opplæring i alle modelleringstypene for å henge med, noe som lett ekskluderer mange nøkkelinteressenter som vi gjerne vil ha med på laget.
C4 to the rescue!
Som ChatGPT så treffende sier: «C4-modellen gir et enkelt og strukturert rammeverk for å beskrive og kommunisere software-arkitektur. Med bare fire abstraksjonsnivåer, kan utviklingsteamet fokusere på å bygge en klar og sammenhengende beskrivelse av systemet, uten å bli overveldet av detaljer eller kompleksitet.»
Jeg skal ikke gå veldig detaljert til verks her, det gjør Simon Brown så veldig mye bedre, både i bok og på Youtube. Men kort fortalt:
Context – Container – Component – Code
Fire forskjellige diagrammer på fire forskjellige nivåer. Så slipper du at en klasse står ved siden av ERP-systemet og later som den er på samme nivå. (Og jada, koden er den evige sannhet. På sitt nivå.)
Context-diagrammet er veldig overordnet og setter systemet ditt (en enkelt boks) inn i en sammenheng. Hvilke systemer kommuniserer det med? Hvem bruker det?
Container er det neste nivået (ikke tenk Docker), og deler systemet inn i hoveddeler. Disse vil typisk ha forskjellige ansvarsområder: presentasjon, kommunikasjon, lagring etc.
Component beskriver de forskjellige elementene i Containeren og kan være individuelle tjenester, moduler, biblioteker eller annen funksjonalitet som er nødvendig for å støtte systemets oppgaver.
Code er nettopp det: kode. Om du trenger å visualisere på dette nivået finnes det gode verktøy for det, for eksempel sekvens- og klassediagrammer. Det kan være nyttig hvis noen skal sette seg inn i koden, men kan i så fall genereres automatisk og ved behov.
Sett det før lissom? Jeg vet, det er bokser og piler. Og aktører tegnet som en form for person-ikon. Men det er noe mer der, det er tekst som faktisk gir mening. Og her kommer vi inn på magien i C4-modellen: I stedet for å bruke et utall bokser med små forskjeller i fasongen for å skille dem fra hverandre så står det i klartekst hva boksen er. Og det samme med pilene: Det er ikke stiplet, hel, med og uten kråketær. Det er en pil som indikerer hovedretningen og en tekst som er beskrivende nok til å fortelle deg hva som skjer.
Du kan godt tilføre elementer. Fargekoder for eksempel. Eller tagger. Varianter av bokser også, om du vil. Men da må du også legge til en Legend som forteller, i klartekst, hva fargen eller fasongen betyr. I tillegg er det en del av notasjonen å kunne bruke en stiplet boks for å gruppere elementer, for eksempel interne og eksterne systemer eller hvilke systemer som er en del av modellen på nivåene under.
C4-modellen er et billig verktøy for kommunikasjon og forståelse. Det er lett å lære og å ta i bruk, og min erfaring er at det også går raskere å lage og forstå modeller når jeg kan fokusere på innhold og ikke notasjon. Når det er billig å jobbe med modellen er det lettere å holde den oppdatert, og oppdaterte modeller er nødvendigvis en bedre støtte for dialog med interessenter enn en modell som ikke er oppdatert.
Alt i alt kan C4-modellen bidra til å skape en felles forståelse av software-arkitektur i utviklingsteamet, og til å forbedre kommunikasjonen med andre interessenter. Modellen (modellering generelt, egentlig) kan også bidra til å redusere kompleksiteten i systemer og gjøre det enklere å vedlikeholde dem over tid. Og det er jo en god ting.
Sagt av:
Sagt: Smidig modellering? Prøv C4
(Jeg har lest bok. Dette er en slags bokrapport, men også en liten oppfordring til modellering.)
Gjennom mine ca. 20 år med smidige metoder har jeg sett og hørt mange tanker og meninger om hva som er smidig og ikke minst hva som ikke er smidig. En gjenganger er at dokumentasjon er overflødig, alt man trenger å vite ligger i koden. Dette følges gjerne av en henvisning til det smidige manifests punkt om «Working software over comprehensive documentation». Joda, hundrevis av sider med informasjon som ikke er oppdatert er avleggs. Men ingen systemdokumentasjon? Næh. Da svinger pendelen litt for langt.
Det kan være mange grunner til å ønske å dokumentere et system med noen gode modeller. Mange tenker bedre visuelt enn med tekst, så en god modell vil gi en bedre forståelse.
Det er lettere å kommunisere om en visuell modell enn en stor mengde tekst, særlig hvis man vil ha med noen ikke-programmerere i diskusjonen. Og bedre kommunikasjon og forståelse gir bedre beslutninger.
Men da må vi ha en felles forståelse av modellen og notasjonen den bruker.
For hva betyr det egentlig at den ene linjen er stiplet linje og den andre heltrukket? Skal vi ha pil eller kråketær på de gule linjene? Og hvilket nivå ser vi på når Customer-klassen er tegnet inn i samme diagram som ERP-systemet?
Om du bruker UML, BMPN eller OPM, sannsynligheten er stor for at det er forskjellige meninger om hva de forskjellige elementene i notasjonen betyr, og man må ofte ha opplæring i alle modelleringstypene for å henge med, noe som lett ekskluderer mange nøkkelinteressenter som vi gjerne vil ha med på laget.
C4 to the rescue!
Som ChatGPT så treffende sier: «C4-modellen gir et enkelt og strukturert rammeverk for å beskrive og kommunisere software-arkitektur. Med bare fire abstraksjonsnivåer, kan utviklingsteamet fokusere på å bygge en klar og sammenhengende beskrivelse av systemet, uten å bli overveldet av detaljer eller kompleksitet.»
Jeg skal ikke gå veldig detaljert til verks her, det gjør Simon Brown så veldig mye bedre, både i bok og på Youtube. Men kort fortalt:
Context – Container – Component – Code
Fire forskjellige diagrammer på fire forskjellige nivåer. Så slipper du at en klasse står ved siden av ERP-systemet og later som den er på samme nivå. (Og jada, koden er den evige sannhet. På sitt nivå.)
Context-diagrammet er veldig overordnet og setter systemet ditt (en enkelt boks) inn i en sammenheng. Hvilke systemer kommuniserer det med? Hvem bruker det?
Container er det neste nivået (ikke tenk Docker), og deler systemet inn i hoveddeler. Disse vil typisk ha forskjellige ansvarsområder: presentasjon, kommunikasjon, lagring etc.
Component beskriver de forskjellige elementene i Containeren og kan være individuelle tjenester, moduler, biblioteker eller annen funksjonalitet som er nødvendig for å støtte systemets oppgaver.
Code er nettopp det: kode. Om du trenger å visualisere på dette nivået finnes det gode verktøy for det, for eksempel sekvens- og klassediagrammer. Det kan være nyttig hvis noen skal sette seg inn i koden, men kan i så fall genereres automatisk og ved behov.
Sett det før lissom? Jeg vet, det er bokser og piler. Og aktører tegnet som en form for person-ikon. Men det er noe mer der, det er tekst som faktisk gir mening. Og her kommer vi inn på magien i C4-modellen: I stedet for å bruke et utall bokser med små forskjeller i fasongen for å skille dem fra hverandre så står det i klartekst hva boksen er. Og det samme med pilene: Det er ikke stiplet, hel, med og uten kråketær. Det er en pil som indikerer hovedretningen og en tekst som er beskrivende nok til å fortelle deg hva som skjer.
Du kan godt tilføre elementer. Fargekoder for eksempel. Eller tagger. Varianter av bokser også, om du vil. Men da må du også legge til en Legend som forteller, i klartekst, hva fargen eller fasongen betyr. I tillegg er det en del av notasjonen å kunne bruke en stiplet boks for å gruppere elementer, for eksempel interne og eksterne systemer eller hvilke systemer som er en del av modellen på nivåene under.
C4-modellen er et billig verktøy for kommunikasjon og forståelse. Det er lett å lære og å ta i bruk, og min erfaring er at det også går raskere å lage og forstå modeller når jeg kan fokusere på innhold og ikke notasjon. Når det er billig å jobbe med modellen er det lettere å holde den oppdatert, og oppdaterte modeller er nødvendigvis en bedre støtte for dialog med interessenter enn en modell som ikke er oppdatert.
Alt i alt kan C4-modellen bidra til å skape en felles forståelse av software-arkitektur i utviklingsteamet, og til å forbedre kommunikasjonen med andre interessenter. Modellen (modellering generelt, egentlig) kan også bidra til å redusere kompleksiteten i systemer og gjøre det enklere å vedlikeholde dem over tid. Og det er jo en god ting.
Sagt av:
