{Tittelen din her}

!!! info

**Status**: { Foreslått | Under gjennomgang | Godtatt |  Avvist | Erstattet | Foreldet }

**Oppdatert**: {ÅÅÅÅ-MM-DD}

Sammendrag

{Dette er «lederoppsummeringen» eller «heisepresentasjonen» for ADR-en din. I noen få konsise setninger (vanligvis 2–4) skal du tydelig angi hovedproblemet, spørsmålet eller muligheten som denne ADR-en tar for seg. Ta med et kort hint om beslutningen som er tatt eller fokusområdet. Målet er å hjelpe leserne raskt å forstå hva denne ADR-en handler om og avgjøre om den er relevant for dem, uten å måtte lese hele dokumentet. Tenk på det som sammendraget av en teknisk artikkel eller en helt kort innledning til hovedtemaet.}

Drivere

{Denne delen forklarer hvorfor denne beslutningen tas nå. Formuler tydelig de viktigste motivasjonene, behovene eller problemene som gjør denne arkitekturbeslutningen nødvendig. Tenk på de underliggende grunnene og presset.}

• {f.eks. Vi utvikler en ny funksjon/evne som trenger …}

• {f.eks. Vi må forbedre ytelse og tilgjengelighet, eller fjerne teknisk gjeld …}

• {f.eks. Tilbakemeldinger fra brukere tyder på …}

• {f.eks. Dagens tilnærming medfører disse begrensningene …}

Alternativer

{Her lister du opp de ulike alternativene du vurderer. Hold deg til fakta og unngå meninger, for den neste delen tar for seg analysen. Ta med en kort beskrivelse og lenker til relevant dokumentasjon eller eksempler.

Ta med alle vesentlige alternativer du undersøkte, selv om de til slutt ikke ble valgt. Målet er å gi leserne en tydelig og objektiv forståelse av hvert alternativ før du går løs på evalueringen.}

{Tittel på alternativ 1}

{Beskriv alternativet, gi et sammendrag, list opp fakta, gi lenker og så videre.}

{Tittel på alternativ n}

...

Alternativanalyse

{Her evaluerer du kritisk hvert alternativ som er presentert i delen Alternativer. For hvert alternativ gir du et balansert bilde av fordeler, ulemper og andre relevante hensyn eller avveininger. Vær konkret og, der det er mulig, knytt poengene tilbake til Driverne.

Vurder forhold som:

• Kostnad (utvikling, drift, lisensiering)

• Kompleksitet (implementering, vedlikehold, læringskurve)

• Risikoer (tekniske, operative, sikkerhet)

• Samsvar med arkitekturprinsipper eller eksisterende standarder

• Innvirkning på ytelse, skalerbarhet, brukervennlighet, vedlikeholdbarhet, sikkerhet og så videre.

Ta med så mange utsagn om fordel/ulempe/annet som nødvendig. }

{Vurdering av alternativ 1}

• Fordel: {En konkret fordel eller nytte ved dette alternativet.}

• Ulempe: {En konkret ulempe, risiko eller kostnad ved dette alternativet.}

• Annet: {Et relevant poeng som ikke strengt tatt er en fordel eller ulempe.}

{Vurdering av alternativ n}

...

Anbefaling

{Her angir du tydelig den endelige beslutningen og nevner uttrykkelig alternativet som er valgt. Forklar i detalj hvorfor dette alternativet ble valgt. Du bør tydelig vise hvordan det valgte alternativet best tar for seg Driverne og oppfyller de viktigste kravene eller løser det angitte problemet.}

Konsekvenser

{Denne delen er valgfri.}

{Nå som en beslutning er tatt, hva er de forventede utfallene og virkningene, både positive og negative? Hvilke kjente begrensninger, kostnader eller risikoer godtas ved å ta denne beslutningen? Hvordan vil beslutningen påvirke ulike interessenter, andre systemer, utviklingspraksis, driftsrutiner eller brukeropplevelse?}

• Fordel: {Et konkret positivt utfall eller en nytte som forventes av denne beslutningen.}

• Ulempe: {En konkret ulempe, kostnad eller risiko som godtas som følge av denne beslutningen. }

• Annet: {En konsekvens som ikke strengt tatt er en fordel eller ulempe.}

Bekreftelse

{Denne delen er valgfri.}

{Beskriv hvordan gjennomføringen av denne beslutningen skal verifiseres og hvordan løpende etterlevelse skal sikres. Det hjelper til å vise at beslutningen ikke bare er teoretisk, men aktivt settes ut i livet og følges opp.

Hvordan skal du kontrollere at beslutningen er gjennomført riktig? (f.eks. kodegjennomganger, bestemte tester, demonstrasjoner, fagfellevurdering).

Hvordan skal etterlevelsen av beslutningen opprettholdes over tid? (f.eks. automatiske kontroller, periodiske revisjoner, oppdateringer av teamets retningslinjer, opplæring).

Finnes det bestemte måleverdier eller indikatorer som viser at beslutningen gir de tiltenkte positive resultatene? (f.eks. ytelsesmålinger, grad av bruk, nedgang i bestemte feil, tilbakemeldingsscore fra brukere).

Hvem er ansvarlig for å følge dette opp, og hva skjer hvis beslutningen ikke følges?}

Mer informasjon

{Denne delen er valgfri.}

{Bruk denne delen til å gi tilleggsinformasjon som underbygger beslutningen, gir kontekst eller veileder framtidige handlinger. Lenker til andre beslutninger og ressurser kan også stå her.

Du kan kort nevne hvem som var med i beslutningsprosessen og om og hvordan man ble enige. Du kan også foreslå en tidsramme eller bestemte hendelser som kan føre til at beslutningen vurderes på nytt i framtiden.}