Jeg gikk inn i IT bransjen i det bransjen gikk over fra fossefall til smidig utvikling. På den tiden hadde vi en stor mengde tooling og ritualer som da etterhvert gikk av med døden, ettersom smidig prosess ønsket “individer og samhandling heller enn prosesser og verktøy, samt fungerende programvare fremfor omfattende dokumentasjon”.
Et av de verktøyene vi ofte brukte før smidig var UML. UML stod sentralt i fossefall og var konstant brukt i den omfattende forhåndsdesignen (big up front design) som den tiden var kjent for. Men så var fossefall plutselig erklært for utdatert og med det sluttet mange universiteter å undervise i denne gammelmodige formen for systemdokumentasjon.
Misforstå meg rett: Smidige prinsipper, spesielt de som står på trykk i manifestoet er sunn fornuft og god logikk, men som alle oppgjør med fortiden så ble fortiden fullstendig demonisert. Fossefall og det tilhørende skulle knuses.
Smidig hadde nå tatt over og vi satt der, i designmøte etter designmøte, og vi hadde kasta ut UML. “Fysjom”, sa smidig-evangelistene, og erklærte at “vi kan like gjerne tegne på et whiteboard og unngå innfløkt UML” - og med det ble skriblerier på whiteboardet født, hvor arkitekter tegner kråketær og hieroglyfer mens utviklerne nikker som vise menn. Når møtet er slutt knipser noen et bilde med mobilkameraet og laster det opp til Jira eller Confluence.
Og her må jeg stoppe historien og innrømme at noe gikk tapt i overgangen fra fossefall til smidig.
Klarhet
Lang tid etter designmøtet, etter at oppgaver med høyere prioritet er blitt lukket, så begynner implementasjonsfasen. Og har har det vist seg, gang etter gang når vi gikk tilbake til tegningene så var det ikke lenger like klart hva “den underlige buen midt på diagrammet” betød, eller hva arkitekten egentlig hadde skrevet i “boksen øverst til høyre”. Hadde han signert kunstverket, som programvareindustriens svar på Banksy, eller hadde det en faktisk betydning?
Og forstod du alt så kunne det hende det likevel var store mangler og fravær av implementasjonsdetaljer. UML var nemlig så omstendelig at det meste ble fanget opp, men slik fungerer ikke whiteboard-design møtene. Her blir ønsket sentral funksjonalitet fanget opp, men kontekst og edge-cases blir ofte glemt. Eller kanskje de ikke blir glemt, men blir diskutert på ledergruppe-møter og ikke fanget opp i f.eks. brukstilfelle-diagrammer, og dermed blir ikke informasjonen overført til den faktisk utførende part. Vi snakker ikke om gigantisk forhåndsdesign, men at C4 er blitt laget for å komme med akkurat nok informasjon til at oppgaven kan løses.
Denne situasjonen søker C4, med sine ulike nivåer av problembelysning og zooming og filtrering på komponentnivå, å løse.
Problemer vi ofte møter
Nå er det ikke noe unikt vagt med whiteboard-skissene i bransjen vår. Faktisk så hadde UML også en rekke problemer som ble spesielt sterke nå i moderne tid hvor færre og færre får en formell utdannelse i dette modelleringsspråket. For det som er selvfølgelig for en utvikler går hus forbi en annen. UML er nemlig et ekspertverktøy. og krever mestring for å kunne forstås fullt ut. Faktisk så er det mange dyktige arkitekter og utviklere som sitter med oppslagsverk hver gang de skal tegne noe i UML. “Hvilken pil skulle jeg bruke igjen? Hvilken retning skal pilen ha?”, er spørsmål mange brukere av UML har stilt seg.
Dette er også spørsmål jeg til og med har fått under intervju for enkelte arkitektroller. “Hvilken vei skal pilen peke, og hvilken form skal den ha?”. Nå er det kanskje mange arkitekter som leser dette og slår seg litt på brystet og erklærer at de kan dette til perfeksjon, og ære være dem, men kan alle andre det? Vet scrum masteren hva den stiplete pilen din betyr? Forstår business owner hvorfor du valgte sekvensdiagram fremfor aktivitetsdiagram?
Vaghet i kommunikasjon er nemlig IT-bransjens svøpe, og ulikt elektrikerne så har vi ikke en standardisert måte å tegne diagrammer på som alle kjenner. Det er avvik og ulikheter i våre whiteboard-skriblerier og UML skisser. Vi har bokser som ikke burde vært der, linjer som ikke er forklart og symboler og farger som ingen vet hva betyr.
Enda verre så har vi ofte diagrammer som ikke gjenspeiler virkeligheten - et gap mellom diagrammer og kode som ofte ikke er rent lite.
Introduksjon av C4-modellen
Det var problemstillinger som dette som den velkjente arkitekten Simon Brown ville til livs når han designet C4.
C4 kan ses som et forsøk på å lage et enklere, mer intuitivt modelleringsspråk, et felles modelleringsspråk for bransjen. I tillegg er modellerings-språket C4 smidig-vennlig og består av et hierarkisk sett av diagrammer.
Det hierarkiske settet av programvarearkitekturdiagrammer er som følger:
- System Context (Programvaresystem).
- Container.
- Komponent.
- Kode.
Hierarkiet gir ulike nivåer av abstraksjon. C4 er notasjonsuavhengig (ikke bundet til en spesifikk visuell representasjon eller symbolsett) og det er verktøyuavhengig.
Fordeler med C4 over UML
C4 er et enklere og mer intuitivt modelleringsspråk enn UML. Det fokuserer på essensiell arkitektur, istedenfor den komplekse og ofte unødvendige arkitekturen UML endte opp i. Det er ingen tvil om hverken piler eller diagrammer. En legende nederst i hjørnet forklarer alt som må forklares, akkurat som når du leser et kart. Dette gjør at man unngår vaghet, tvetydighet og misforståelser. Det er ingen spørsmål om hva symboler og farger betyr selv når man går tilbake lang tid etter at designmøtet er ferdig avsluttet.
Simon Brown har en klar anbefalning til alle som modellerer med C4. For å unngå gap mellom design og kode så ber han designerne “å tenke som utviklere” når de tegner C4 diagrammene. Det er utviklerne som er primær målgruppe, og det er den faktiske implementasjonen C4 er ment å forklare.
Ønsker du å lese mer om gapet mellom kode og modell så har George Fairbanks en fin forklaring her: https://www.georgefairbanks.com/software-architecture/model-code-gap/
Det vi da sitter igjen med er et felles modelleringsspråk som bedre reflekterer det vi faktisk skal bygge, som atpåtil er bedre tilpasset smidig arbeidsmetodikk. C4 gir oss et høynivå-perspektiv, og skal du endre noe på dette nivået i en senere iterasjon så er det enkelt å endre designen - spesielt hvis designen er lagret med koden i git f.eks. med PlantUML eller Mermaid.
La oss liste opp noen av disse fordelene:
-
Enkelt og klart: C4-modellering tilbyr en enkel tilnærming med fokus på fire nøkkeldiagrammer, noe som gjør det enklere å forstå og kommunisere arkitektur.
-
Lettvektspråk med minimalt med overhead: I motsetning til UMLs omfattende notasjonssystem er C4 et lettvektsspråk. Her reduserer vi tiden og innsatsen som kreves for å opprette og vedlikeholde diagrammer. Dette er i tråd med smidigs fokus på effektivitet.
-
Letter effektiv kommunikasjon: C4-diagrammer er utformet for å være enkle å forstå for både tekniske og ikke-tekniske interessenter, noe som igjen fremmer samarbeidet i smidige team.
-
Støtte for iterativ og inkrementell utvikling: C4-modellering legger til rette for iterativ utvikling ved at diagrammene kan utvikles i takt med systemet. Dette gjenspeiler den smidige prosessens fokus på kontinuerlig forbedring.
-
Lett å oppdatere og vedlikeholde: C4s enkelhet gjør det enkelt å holde dokumentasjonen oppdatert, noe som er avgjørende i smidige miljøer der endringer skjer ofte.
-
Fokus på essensiell arkitektur: C4 legger vekt på arkitekturelementer på høyt nivå uten å gå for mye i detalj, slik at teamet kan fokusere på å levere verdi.
-
Tilgjengelighet og læringskurve: Med sin minimale notasjon er C4 lettere for teammedlemmene å lære og ta i bruk sammenlignet med det omfattende UML-språket.
-
Fleksibilitet og tilpasningsevne: C4 gjør det mulig for teamene å tilpasse diagrammene etter egne behov uten å måtte forholde seg strengt til formelle standarder, noe som støtter opp om smidigs fokus på tilpasningsdyktighet.
-
Forbedret samarbeid: Ved å levere klare og konsise diagrammer forbedrer C4 kommunikasjonen mellom teammedlemmene. Dette er avgjørende for samarbeidskulturen i smidige metoder.
-
Støtter smidige dokumentasjonsprinsipper: C4 er i tråd med det smidige prinsippet om «akkurat nok» dokumentasjon, noe som sikrer at diagrammene er nyttige uten å bli en byrdefull oppgave.
Hvordan C4 løser vanlige problemer
Som nevnt tidligere så gir C4 oss klare og konsistente diagrammer. Samtidig gir det oss bedre kommunikasjon mellom teammedlemmer ved at det reduserer misforståelser og miskommunikasjon ved å bruke en lett-tolket modell som selv ikke-tekniske teammedlemmer lett forstår, både under modellering og i ettertid. Ved å bruke C4 mens vi tenker som en utvikler når vi tegner så forener vi modell og kode - vi reduserer modell-kode gapet og skaper en faktisk representasjon av systemet.
Ulike nivåer i C4-modellen
Når han laget C4 så lot Simon Brown seg inspirere av Phillippe Kruchten og hans “4+1 nivåmodell for programvare arkitektur” (les mer her). Mer spesifikt lot han seg inspirere av hvordan Kruchten søkte å representere en arkitektur sett fra flere perspektiver. Derfor har vi i C4 disse fire nivåene:
1. System Context Diagram
- Viser systemet i sin sammenheng med brukere og eksterne systemer.
Over: System Context Diagram
2. Container Diagram
- Viser de viktigste containere i systemet og hvordan de samhandler.
- Containere er distribuerbare enheter som webapplikasjoner, databaser osv.
Over: Container diagram
3. Component Diagram
- Viser de viktigste komponentene innenfor en container.
- Komponenter er grupperinger av relaterte funksjoner.
- Her kan vi zoome inn på forskjellige nivåer og filtrere vekk det som ikke interesserer oss.
Over: Component diagram
4. Code Diagram
- Går ned til kodenivå, viser klasser, funksjoner osv.
- Her bruker vi ofte standard UML, og da spesielt UML sine klassediagrammer, sekvensdiagrammer, objektdiagrammer, aktivitetsdiagrammer og tilstandsdiagrammer. De øvrige diagramtypene er i stor grad gjort utdaterte av C4.
- Simon Brown anbefaler at vi ikke fokuserer stort på kode/UML nivået, med mindre vi absolutt må. På dette nivået endrer koden seg fort og dermed blir disse diagrammene fort utdaterte og irrelvante.
- Et tips til god bruk av kode-diagrammer i C4 er som bruk og kast diagrammer under en diskusjon om arkitektur enten i første modelleringsfase, eller når man forsøker forbedre en arkitektur.
- Unngå bruk av kode-diagrammer som dokumentasjon.
Som du ser i diagrammene over så driller vi oss ned fra et høynivå perspektiv inn i banksystemene. Vi ser aktører og systemer satt i relasjon til hverandre, også driller vi oss ned i maten for å lære disse systemene, containerne og komponentene å kjenne. Vi følger også Simon sine råd og driller oss ikke helt ned i detaljer slik som programflyt (aktiviteter), sekvenser og klassestruktur.
Da var vi til veis ende. Lagt ved under er noen ressurser for videre læring, og en mal for et container diagram laget med PlantUML - slik at du lett kan komme i gang med avansert modellering.
