Softwarearkitektur har et klassisk problem: Den arkitektur, vi beskriver, og den arkitektur, vi faktisk bygger, er ikke nødvendigvis den samme.

Et arkitekturdiagram kan være præcist den dag, det bliver tegnet. Men systemet fortsætter med at udvikle sig. Nye services kommer til, afhængigheder ændrer sig, teams træffer lokale beslutninger, og dokumentationen følger ikke nødvendigvis med.

Over tid kan forskellen mellem den intenderede arkitektur og den implementerede arkitektur derfor vokse. Det kaldes ofte architecture drift eller architecture erosion.

Men problemet handler ikke kun om dokumentation. Det handler også om, hvorvidt arkitekturen overhovedet kan opdages og forstås ud fra det system, udviklerne arbejder med.

 

Kan udviklerne finde arkitekturen?

Architecture discoverability handler grundlæggende om at gøre systemets arkitektur tilgængelig for dem, der skal arbejde med den.

Hvis forståelsen af arkitekturen primært findes hos enkelte erfarne udviklere eller arkitekter, bliver den vanskelig at bruge som fælles arbejdsgrundlag. Det samme gælder, hvis den findes i diagrammer og dokumenter, som ikke længere afspejler kodebasen.

En mere levende arkitekturbeskrivelse kan blandt andet bygge på kode, dependencies, interfaces, repositories, deployment-information og eksplicitte arkitekturbeslutninger.

Det ændrer også arkitektens spørgsmål. Det bliver ikke kun: Hvordan skal systemet være bygget? Men også: Hvordan kan en udvikler se, hvordan det faktisk er bygget?

 

Fra dokumentation til Architecture as Code

Et af svarene er Architecture as Code. Princippet minder om Infrastructure as Code: Arkitekturen beskrives i et maskinlæsbart format, som kan versionsstyres sammen med resten af udviklingsarbejdet.

Det betyder ikke nødvendigvis, at diagrammer forsvinder. De kan i stedet genereres fra en underliggende model, så modellen, og ikke et manuelt vedligeholdt billede, bliver udgangspunktet.

Et aktuelt eksempel er FINOS’ Common Architecture Language Model (CALM), der beskriver softwarearkitektur i et standardiseret, versionsstyret og maskinlæsbart format, som samtidig kan valideres.

Det åbner for noget andet end traditionel arkitekturdokumentation: Arkitekturen kan blive en del af den samme arbejdsproces som koden.

 

Men følger koden så arkitekturen?

Discoverability løser kun den ene halvdel af problemet. Selv hvis den ønskede arkitektur er tydeligt beskrevet, er der stadig spørgsmålet om, hvorvidt implementeringen faktisk følger den.

Her kommer architecture verification ind.

En eksplicit arkitekturmodel kan sammenholdes med strukturen og afhængighederne i den faktiske kode. Dermed bliver det muligt at identificere eksempelvis dependencies, der ikke burde eksistere, eller forventede relationer, der mangler. Metoden bygger blandt andet videre på idéen om reflexion models, hvor en high-level arkitekturmodel sammenholdes systematisk med source code-modellen.

Arkitekturregler kan også gøres eksekverbare som tests eller fitness functions og indgå i CI/CD. Så opdages bestemte arkitekturbrud, når de introduceres, frem for ved en senere arkitekturgennemgang.

 

Arkitektur som en del af udviklingsarbejdet

Det interessante er derfor ikke nødvendigvis endnu et værktøj til at tegne arkitektur. Det er bevægelsen fra arkitektur som statisk dokumentation til arkitektur som noget, der kan være synligt, versionsstyret og verificerbart.

Det kan gøre det lettere for udviklere at forstå et eksisterende system, men også gøre arkitekturens grænser mere konkrete i det daglige udviklingsarbejde.

For hvis arkitekturen kun findes i et diagram, kan vi beskrive, hvordan systemet burde hænge sammen.

Hvis den også kan aflæses og verificeres mod den faktiske implementering, kan vi begynde at undersøge, om det stadig gør det.

 

Hvordan kan Lund&Bendsen hjælpe?

Hos Lund&Bendsen arbejder vi med softwarearkitektur både som teknisk disciplin og som en del af den praktiske softwareudvikling.

Vi tilbyder kurser og rådgivning inden for softwarearkitektur, arkitekturprincipper og moderne udviklingspraksis, hvor fokus er på at gøre arkitekturen anvendelig i de systemer og organisationer, der skal leve med den.