It-arkitektur i danske virksomheder: Styr principper og beslutninger

Hvorfor principper og beslutninger skal styres sammen

Arkitekturprincipper er ikke et dokumentationsprojekt, men et styringsredskab. Optimum peger på, at mange offentlige myndigheder enten har udarbejdet egne arkitekturprincipper eller taget de fællesoffentlige og fælleskommunale principper til sig. Optimums indtryk er, at udviklingsarbejdet foregår seriøst – i hvert fald i de kredse, Optimum selv bevæger sig i.

Alligevel oplever Optimum, at principperne ikke for alvor kommer til deres ret i praksis, og at de ofte ikke giver den fornødne værdi. Den udfordring skal store danske virksomheder også løse.

Optimums centrale pointe er, at principper skal være styreredskaber. De skal kunne afgøre, om virksomhedens initiativer og beslutninger efterlever de overordnede strategiske mål. Principperne er knyttet til strategien, og man skal klart og entydigt kunne afgøre, om beslutninger og initiativer reelt indfrier dem.

Derfor skal principper og beslutningslog styres sammen. Skal principperne have effekt, skal de føres ned i de konkrete arkitekturbeslutninger i projekter, platformsteams, leverandørvalg og integrationsarkitektur. En beslutningslog viser, hvilke valg der blev truffet, hvorfor, og hvordan de forholdt sig til principperne. Uden den kobling bliver principperne let symbolske, mens beslutningerne træffes efter andre logikker.

Principkvalitet: Færre og skarpere principper, der rent faktisk styrer

Optimum opstiller en række metaprincipper – principper for principper. De kan evaluere kvaliteten af et arkitekturprincip. Udform principperne, så de er handlingsorienterede.

Fat dig i korthed. Brug ikke fagudtryk eller indforståede begreber. Forkast trivielle og irrelevante principper. Principperne skal kunne tælles på to hænder.

Metaprincipperne fungerer som et praktisk kvalitetsfilter. Et handlingsorienteret princip kan bruges til at træffe eller forkaste en beslutning. Et kort princip uden indforståede begreber kan forstås af arkitekter, projektledere, forretning og leverandører.

Et trivielt eller irrelevant princip ændrer ingen beslutninger og bør forkastes. Er principperne for mange, mister de deres kraft i hverdagen.

Optimum understreger samtidig, at principperne er knyttet til virksomhedens strategiske mål. Beslutninger og initiativer skal kunne holdes klart op mod dem.

Derfor bør I jævnligt evaluere hvert princip mod de strategiske mål. Hjælper princippet os med at træffe de rigtige valg? Kan vi entydigt sige, om en beslutning efterlever det? Er svaret nej, er princippet ikke et styreredskab, men en tekst.

Kvalitetsfilter for arkitekturprincipper

Fra overordnede principper til konkrete regler og bevidste valg

Ifølge Digitaliseringsstyrelsen består den fællesoffentlige digitale arkitektur af otte overordnede arkitekturprincipper og 22 understøttende arkitekturregler. Hensigten er at gøre arkitekturbeslutninger i projekter til bevidste valg eller fravalg. Byggeblokken er fastsat i Hvidbog om Fællesoffentlig digital arkitektur og konkretiserer FDA-principperne med arkitekturregler, som projekterne bør følge, når de arbejder med digitale løsninger.

Modellen er dansk inspiration til at omsætte brede principper til mere konkrete regler eller guidelines. Pointen er ikke at kopiere den offentlige sektors styring, men at bruge tankegangen: overordnede principper på strategisk niveau og understøttende regler på løsningsniveau. Så bliver projektets beslutninger bevidste valg og fravalg i stedet for tilfældigheder.

KL’s fælleskommunale arkitekturprincipper peger i samme retning. Ved udarbejdelsen og prioriteringen har det været vigtigt, at principperne reelt skulle være med til at flytte gældende praksis. For store danske virksomheder betyder det, at I bør prioritere de principper og regler, der faktisk flytter arkitekturpraksis. Den offentlige model kan bruges som mønster for at gøre principper anvendelige i jeres egen kontekst.

Architecture Decision Records: En kort og sporbar beslutningslog

Martin Fowler beskriver en Architecture Decision Record, ADR, som et kort dokument, der fanger og forklarer én beslutning, som er relevant for et produkt eller et økosystem. Dokumentet bør være kort – kun et par sider – og indeholde beslutningen, konteksten for at træffe den og de væsentlige konsekvenser. Fowler anbefaler en omvendt pyramide kendt fra nyhedsartikler: det vigtigste først, detaljerne længere nede.

En ADR indeholder ikke kun beslutningen, men også en kort begrundelse. Den bør opsummere problemet, der gjorde beslutningen nødvendig, og de trade-offs, der blev overvejet. Fowler peger på, at det er værdifuldt eksplicit at liste de alvorlige alternativer, der blev overvejet, med deres fordele og ulemper. Beslutninger har konsekvenser, og de bør fremgå.

Hver ADR har en status. Fowler nævner 'proposed', mens beslutningen diskuteres; 'accepted', når teamet accepterer den; og 'superseded', når den ændres væsentligt eller erstattes, med et link til den nye ADR. Når en ADR først er accepteret, bør den aldrig genåbnes eller ændres – den skal afløses af en ny. Så bevarer man en klar log over beslutninger og over, hvor længe de styrede arbejdet.

Fowler fremhæver også, at skriveprocessen har to formål. Dels fungerer ADR’en som et spor, så man måneder eller år senere kan forstå, hvorfor systemet er bygget, som det er. Dels skærper skrivningen tænkningen, især når man skriver sammen. Et dokument af betydning bringer ofte forskellige synspunkter frem og tvinger forskellene op til diskussion – og forhåbentlig til en afklaring.

ADR-statusforløb

Sådan etablerer og skalerer I ADR-praksissen i hverdagen

Start med at tale med teamet om, hvordan I identificerer beslutninger. ADR-fællesskabets materiale peger på, at man bør drøfte, hvor presserende og hvor vigtig en arkitekturbeslutning er. Skal den træffes nu, eller kan den vente, til man ved mere? Den samtale hjælper med at sikre, at I ikke skriver ADR’er om alt, men om de beslutninger, der reelt styrer arkitekturen.

Brug en fast skabelon. ADR-fællesskabet har flere eksempler på templates, og Fowler beskriver indholdet: beslutning, kontekst, begrundelse, alternativer og konsekvenser. Vælg en enkel skabelon, der kan udfyldes hurtigt, og som passer til jeres modenhed. Skabelonen skal gøre det lettere at skrive, ikke sværere.

Fowler anbefaler, at hver ADR er sin egen fil, nummereret i en monoton sekvens som en del af filnavnet. Navnet skal fange beslutningen, så filen er nem at læse i en mappeliste. Han nævner eksemplet 0001-HTMX-for-active-web-pages.

Den almindelige anbefaling er at opbevare ADR’er i kildekodens repository tæt på den kode, de gælder, typisk i doc/adr. De bør skrives i et letvægtigt markup-sprog som markdown, så de kan læses og diffes som kode.

Hvis jeres beslutninger dækker et bredere økosystem end én kodebase, kan et produkt-repository være for snævert. Nogle foretrækker derfor en mere central placering, mens andre oplever, at git gør det svært for ikke-udviklere at arbejde med ADR’er. Uanset valget bør I undgå, at beslutningerne ender i præsentationer, mailtråde eller i hovedet på en enkelt arkitekt.

En praktisk tilgang er at bruge Markdown og Git og lægge ADR’erne i en dedikeret mappe som /docs/adr/ eller /architecture/decisions/, med filnavne som 003-use-kafka-for-event-streaming.md. Pointen er at gøre implicit viden eksplicit og holde beslutningerne tæt på det arbejde, de vedrører.

Etabler ADR-praksis i hverdagen

Styringsmodel: Roller, beslutningsrettigheder og arkitekturreview

En styringsmodel skal beskrive, hvem der ejer arkitekturprincipperne, hvordan de vedligeholdes, og hvem der kan ændre dem. Den skal også beskrive, hvordan arkitekturbeslutninger identificeres, hvem der beslutter, og hvornår en beslutning skal eskaleres. Uden den fordeling bliver principperne let en arkitekturopgave uden forretningsmæssig forankring, og beslutningerne træffes uden fælles reference.

Arbejdet med at identificere beslutninger bør følge en simpel logik: Hvor presserende og hvor vigtig er beslutningen? Skal den træffes nu, eller kan den vente, til der er mere viden? Det er samme overvejelse, som ADR-fællesskabet anbefaler at tage med sit team. I en stor dansk virksomhed kan det føre til en beslutningsmodel, hvor nogle beslutninger tages i teamet, andre i et arkitekturforum, og atter andre løftes til et tværfagligt beslutningsforum.

ADR’er bør indgå i arkitekturreview og i tværfaglige beslutningsfora. Fowler peger på, at skrivningen af et beslutningsdokument ofte bringer forskellige synspunkter frem og tvinger forskellene op til diskussion. Det er en styrke i reviewet: I kan se, om alternativerne var reelt belyst, om konsekvenserne er beskrevet, og om beslutningen kan holdes klart op mod principperne. Optimum understreger netop, at beslutninger og initiativer skal kunne afgøres klart og entydigt mod principperne.

I praksis kan arkitekturreviewet bruge ADR’en som samtalegrundlag: Hvilke principper understøtter beslutningen? Hvilke alternativer blev overvejet? Hvilke konsekvenser har valget, og hvem er berørt? Kan beslutningen ikke vurderes mod et princip, er det et signal om, at enten princippet eller beslutningsloggen mangler klarhed.

Eskalering af arkitekturbeslutninger

Hold principper og beslutningslog levende over tid

En ADR er ikke et levende dokument, der løbende redigeres. Fowler anbefaler, at en accepteret ADR aldrig genåbnes eller ændres. Ændres beslutningen væsentligt eller erstattes den, skal den superseded-markeres med et link til den nye ADR.

Det giver en klar historik over, hvad der blev besluttet, hvornår det blev afløst, og hvor længe beslutningen styrede arbejdet. Statusfeltet og superseding-links er derfor ikke formalia; de gør beslutningsloggen brugbar over tid.

Principperne skal også holdes levende. Optimum peger på, at principper er knyttet til virksomhedens strategiske mål. Beslutninger skal kunne afgøres klart op mod dem.

Derfor bør I med jævne mellemrum evaluere principperne mod de strategiske mål. Flytter de fortsat de rigtige beslutninger? Er de stadig handlingsorienterede, korte og fri for indforståede begreber?

Er der for mange? KL’s fælleskommunale principper understreger samme pointe: Principperne skal reelt medvirke til at flytte gældende praksis.

Brug beslutningsloggen aktivt. Den kan bruges ved onboarding af nye arkitekter og teams, i arkitekturreview, når en løsning skal videreudvikles, og når I skal lære af tidligere valg. Så bliver ADR’erne ikke bare arkiv, men et arbejdsredskab, der forklarer, hvorfor systemet ser ud, som det gør.

Optimums pointe er, at arkitekturprincipper ofte ikke kommer til deres ret i praksis og ikke giver den fornødne værdi. Vejen ud af det er at koble principperne tæt til beslutningerne, skrive dem kort og handlingsorienteret og løbende afløse dem, når virkeligheden ændrer sig. Så bliver principper og beslutningslog tilsammen et styringsredskab, der skaber værdi.