En stor kunde beder om en beskrivelse af produktets arkitektur, og det eneste, I har, er en tegning på en tavle og det, lead developeren husker. En arkitekturbeskrivelse er en kort tekst om, hvordan produktet er bygget, hvor data er, og hvad det afhænger af. Tre sider er nok til de fleste kunder, og den samme tekst kan bruges til spørgeskemaer, møder og nye medarbejdere. Her er skabelonen felt for felt, så en ikke-teknisk stifter kan bestille den, og en teknisk stifter kan skrive den på en eftermiddag.
Hvem læser den, og hvad vil de vide?
Læseren er kundens IT-arkitekt, sikkerhedsansvarlige eller indkøber. De vil vurdere, om produktet passer ind hos dem, og om noget kan blive et problem senere. De skal ikke kunne bygge produktet efter beskrivelsen, så kodens detaljer hører ikke med. De har brug for overblik, præcise svar og en ærlig angivelse af, hvor grænserne går.
Skriv kort, i almindeligt fagsprog og uden markedsføring. En sætning som “vores skalerbare, moderne platform” gør læseren mere skeptisk.
Side 1: oversigt
Hvad produktet gør. To til tre linjer om funktion og brugere.
Hoveddelene. En enkel tegning med de få kasser, der betyder noget, fx webklient, app, serverdel, database, baggrundsjob og eksterne tjenester. Pile viser, hvad der taler med hvad. Skriv ved hver kasse, hvilken teknologi den er bygget med.
Hvordan kunder er adskilt. Deler kunderne installation, eller har hver sin? Hvordan holdes deres data adskilt? Valget er beskrevet under fælles eller separate installationer, og kunden spørger næsten altid.
Hvordan brugerne logger ind. Egen brugerstyring eller login via kundens egen løsning, roller og rettigheder.
Side 2: data og hosting
Hvilke data der findes. Grupper dem i kundedata, brugerdata, logfiler og sikkerhedskopier. Nævn, om der ligger personoplysninger, og i hvilke dele.
Hvor data ligger. Cloududbyder, region og land for hver gruppe. Skriv også de tjenester, hvor data kommer forbi, fx mail, support og fejlovervågning, for det er dér, svarene plejer at glippe. Mere om det i hvor ligger data?.
Beskyttelse. Kryptering under transport og lagring, og hvem der har adgang til produktionsmiljøet, altså den installation, kunderne bruger.
Backup og gendannelse. Hvor ofte, hvor længe de gemmes, og hvornår gendannelse sidst blev prøvet.
Drift. Overvågning, hvem der reagerer på alarmer, og hvordan nye versioner bliver udgivet. Skriv kun det, I faktisk gør.
Side 3: afhængigheder og kendte begrænsninger
Afhængigheder. En tabel med de eksterne tjenester, produktet ikke kan fungere uden: formål, leverandør og hvad der sker, hvis tjenesten er nede. Biblioteker i koden hører til en anden liste og behøver ikke stå her.
Integrationer. Hvilke grænseflader der findes, og hvordan kunden kan bruge dem. En grænseflade, på engelsk API, er den indgang, andre systemer bruger til at tale med produktet.
Kapacitet. Det, I har prøvet at belaste produktet med, og hvad det viste. Har I ikke prøvet, så skriv det. Se også det ærlige svar om vækst.
Kendte begrænsninger. Tre til fem linjer om det, produktet ikke kan i dag, og hvad planen er. Feltet virker måske modigt, men en erfaren arkitekt finder begrænsningerne alligevel, og det giver tillid, at I selv har nævnt dem.
Version og ejer. Dato, versionsnummer og navnet på den, der svarer for indholdet.
Hold den ajour
En arkitekturbeskrivelse dør, når ingen ejer den. Læg filen samme sted som koden, så den kan rettes sammen med ændringerne, og gør den til et punkt på tjeklisten, når en ny tjeneste kommer ind eller en region skifter. Gennemgå den fast et par gange om året.
Beskrivelsen er grundlaget for svarene i kundens spørgeskema. Står de samme oplysninger begge steder med forskellig ordlyd, vil en opmærksom kunde finde forskellen. Brug derfor den samme tekst, og lad svarsættet pege på beskrivelsen. De længere begrundelser for valgene kan ligge i jeres interne noter om de tekniske beslutninger.
Det, der ikke skal med
Nogle oplysninger hører ikke hjemme i et dokument, der sendes rundt: adgangskoder og nøgler, interne adresser, detaljer om sikkerhedsopsætning, der hjælper en angriber, og åbne fund fra en test. Bed kunden om at behandle dokumentet fortroligt, og aftal i fortrolighedsaftalen, hvad der gælder. Spørger kunden til noget mere følsomt, kan det gennemgås på et møde.
Sådan kommer I i gang
Lad den, der kender produktet bedst, tale i en time, mens en anden skriver. Læg teksten ind i de tre sider, og marker det, ingen kan svare på. De markeringer er nyttige, for de viser huller i jeres viden om eget produkt. Bed derefter en udvikler, der ikke var med, om at læse det igennem og rette. Til sidst skal en person uden teknisk baggrund kunne forklare side 1 for en anden.
Det skal I lade være med
- At sende interne tegninger, der kun giver mening for udviklerne · læseren giver op eller spørger om det hele.
- At beskrive den arkitektur, I gerne vil have · skriv den, I har, og læg resten under planer.
- At udelade begrænsningerne · de kommer frem i mødet alligevel, og så ser det ud, som om I gemte dem.
Det skal I kræve af den eksterne
- ☐ En arkitekturbeskrivelse på højst tre sider, som kunden kan læse.
- ☐ En tegning, der stemmer med det, der faktisk kører.
- ☐ En komplet liste over tjenester, hvor kundedata kommer forbi.
- ☐ En navngiven ejer og en fast dato for gennemgang.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Kundens IT-arkitekt vil have et møde · Tjeklister og skabeloner
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
