{Indsæt titel her}

!!! info

**Status**: { Proposed | Under Review | Accepted |  Rejected | Superseded | Deprecated }

**Opdateret**: {YYYY-MM-DD}

Resumé

{Dette er ADR'ens 'kortfattede rapport' eller 'elevator pitch'. I få præcise sætninger (typisk 2-4) skal du tydeligt angive det centrale problem, spørgsmål eller den mulighed, som denne ADR adresserer. Giv et kort hint om den trufne beslutning eller fokusområdet. Målet er at hjælpe læsere med hurtigt at forstå, hvad denne ADR handler om, og om den er relevant for dem, uden at læse hele dokumentet. Tænk på det som et abstract til en teknisk artikel eller en meget kort introduktion til hovedemnet.}

Drivkræfter

{Dette afsnit forklarer hvorfor denne beslutning træffes nu. Gør det klart, hvad de primære motiver, behov eller problemer er, der gør denne arkitekturbeslutning nødvendig. Tænk på de underliggende årsager og pres.}

• {For eksempel: vi udvikler en ny funktion/kapacitet, der kræver ...}

• {For eksempel: vi skal forbedre ydeevne, tilgængelighed, afvikle gæld...}

• {For eksempel: brugerfeedback indikerer, at...}

• {For eksempel: den nuværende tilgang pålægger begrænsninger som...}

Muligheder

{Her angiver du de forskellige muligheder, der overvejes. Hold dig til fakta og undgå meninger; analysen kommer i næste afsnit. Medtag korte beskrivelser og links til relevant dokumentation eller eksempler.

Medtag alle væsentlige alternativer, der blev undersøgt, selv hvis de i sidste ende ikke blev valgt. Målet er at give læseren en klar, uhildet forståelse af hvert alternativ, før evalueringen begynder.}

{Titel på mulighed 1}

{Beskriv muligheden, giv et resumé, angiv fakta, giv links osv.}

{Titel på mulighed n}

...

Analyse af muligheder

{Her vurderer du kritisk hver mulighed, der er præsenteret i afsnittet Muligheder. For hver mulighed skal du give et afbalanceret billede af fordele, ulemper og andre relevante overvejelser eller afvejninger. Vær specifik og knyt til Drivkræfter, hvor det er muligt.

Overvej aspekter som:

• Omkostninger (udvikling, drift, licenser)

• Kompleksitet (implementering, vedligeholdelse, indlæringskurve)

• Risici (tekniske, operationelle, sikkerhed)

• Overensstemmelse med arkitekturprincipper eller eksisterende standarder

• Indvirkning på ydeevne, skalerbarhed, brugbarhed, vedligeholdelighed, sikkerhed osv.

Medtag så mange fordele/ulemper/andre udsagn som nødvendigt. }

{Evaluering af mulighed 1}

• Fordel: {En specifik fordel eller gevinst ved denne mulighed.}

• Ulempe: {En specifik ulempe, risiko eller omkostning ved denne mulighed.}

• Andet: {Et relevant punkt, der strengt taget hverken er en fordel eller en ulempe.}

{Evaluering af mulighed n}

...

Anbefaling

{Her angiver du tydeligt den endelige beslutning og nævner eksplicit den valgte mulighed. Forklar detaljeret hvorfor denne mulighed blev valgt. Gør det klart, hvordan den valgte mulighed bedst imødekommer Drivkræfter og opfylder nøglekravene eller løser det beskrevne problem.}

Konsekvenser

{Dette afsnit er valgfrit.}

{Nu hvor beslutningen er truffet, hvad er de forventede resultater og effekter, både positive og negative? Hvilke kendte begrænsninger, omkostninger eller risici accepteres ved denne beslutning? Hvordan påvirker denne beslutning forskellige interessenter, andre systemer, udviklingspraksis, driftsprocedurer eller brugeroplevelser?}

• Fordel: {Et specifikt forventet positivt resultat eller en fordel ved denne beslutning.}

• Ulempe: {En specifik ulempe, omkostning eller risiko, der accepteres som følge af denne beslutning. }

• Andet: {En konsekvens, der strengt taget hverken er en fordel eller en ulempe.}

Bekræftelse

{Dette afsnit er valgfrit.}

{Skitsér overordnet, hvordan implementeringen af denne beslutning vil blive verificeret, og hvordan fortsat overholdelse vil blive sikret. Det hjælper med at vise, at beslutningen vil blive omsat i praksis og overvåget og ikke blot er teoretisk.

Hvordan bekræfter du, at beslutningen er implementeret korrekt? (f.eks. kodegennemgange, specifikke tests, demonstrationer, peer reviews).

Hvordan opretholdes overholdelsen af denne beslutning over tid? (f.eks. automatiserede kontroller, periodiske revisioner, opdatering af teamretningslinjer, uddannelse).

Er der specifikke målinger eller indikatorer, der vil vise, at beslutningen opnår de tilsigtede positive resultater? (f.eks. ydeevnebenchmarks, adoptionsrate, reduktion af specifikke fejl, brugerfeedbackscorer).

Hvem er ansvarlig for at føre tilsyn hermed, og hvad sker der, hvis beslutningen ikke overholdes?}

Yderligere oplysninger

{Dette afsnit er valgfrit.}

{Brug dette afsnit til at give supplerende oplysninger, der understøtter beslutningen, tilføjer kontekst eller vejleder fremtidige handlinger. Links til andre beslutninger eller ressourcer kan også optræde her.

Du kan kort angive, hvem der var involveret i beslutningsprocessen, og om/hvordan konsensus blev opnået. Du kan også foreslå en tidsramme eller specifikke hændelser, der i fremtiden kan udløse en revurdering af denne beslutning.}