Richtlijnen voor gebruik van het ADR-template¶

Naamgeving en bestandsstructuur¶

Maak voor elke ADR een nieuw Markdown-bestand aan in de map docs/ADRs/ met de volgende naamconventie:

XXXX-Korte-Beschrijvende-Titel.md

waarby XXXX een oplopend viercijferig volgnummer is (bijv. 0001, 0002, 0023). Gebruik docs/Template/0000-ADR-template.md als startpunt en verwijder nooit het originele template.

YAML front matter¶

Begin elk ADR-bestand met een YAML-blok met de volgende velden:

---
title: Korte beschrijvende titel
id: ADR-XXXX
status: Voorgesteld
date: JJJJ-MM-DD
owner: Naam of rol
domain: Enterprise | Data | Solution | Cloud | Domeinoverschrijdend
impacted_systems: Systeem A, Systeem B
Gremium: Architectuurraad
last_review: JJJJ-MM-DD
next_review: JJJJ-MM-DD
related_records: ADR-XXXX, STD-XXXX
tags:
  - ADR-XXXX
  - keyword1
  - keyword2
---

Veld	Beschrijving	Toegestane waarden
`title`	Korte, beschrijvende titel van de beslissing	Vrije tekst
`id`	Uniek identificatienummer	`ADR-0001`, `ADR-0002`, …
`status`	Huidige status van de beslissing	Zie Statussen
`date`	Datum waarop de beslissing is vastgesteld	`JJJJ-MM-DD`
`owner`	Verantwoordelijke eigenaar of rol	Vrije tekst
`domain`	Architectuurdomein van de beslissing	Zie Domeinen
`impacted_systems`	Door de beslissing geraakte systemen of diensten	Vrije tekst, kommagescheiden
`Gremium`	Gremium dat de beslissing heeft goedgekeurd	Vrije tekst
`last_review`	Datum van de meest recente inhoudelijke review	`JJJJ-MM-DD`
`next_review`	Geplande datum voor de volgende review	`JJJJ-MM-DD`
`related_records`	Gerelateerde ADRs en standaarden	Kommagescheiden ADR- en STD-id's
`tags`	Zoekwoorden voor categorisering en filtering; gebruik het ADR-id als eerste tag (bijv. `ADR-0001`) zodat het zichtbaar is op de tags-pagina en doorzoekbaar is	Lijst van strings; eerste waarde altijd het ADR-id

Statussen¶

Een ADR doorloopt de volgende levenscyclus:

Status	Betekenis
`Voorgesteld`	De ADR is opgesteld maar nog niet beoordeeld of goedgekeurd.
`Geaccepteerd`	De ADR is beoordeeld en goedgekeurd door het bevoegde gremium.
`Afgewezen`	De ADR is beoordeeld maar niet goedgekeurd; de voorgestelde richting wordt niet gevolgd.
`Verouderd`	De beslissing is niet langer van toepassing door veranderde context, maar wordt bewaard voor historisch inzicht.
`Vervangen door ADR-XXXX`	De beslissing is ingehaald door een nieuwere ADR. Verwijs altijd naar het opvolgende record.

Domeinen¶

Domein	Beschrijving
`Enterprise`	Beslissingen op het niveau van de gehele organisatie of het IT-landschap, zoals governance, standaarden en principes.
`Data`	Beslissingen over databeleid, data-architectuur, opslag, uitwisseling of kwaliteit.
`Solution`	Beslissingen over specifieke oplossingen, applicaties of diensten binnen het landschap.
`Cloud`	Beslissingen over cloudstrategie, cloudproviders, platformkeuzes en managed services.
`Domeinoverschrijdend`	Beslissingen die meerdere domeinen raken en niet eenduidig onder één domein vallen.

Invulinstructies per sectie¶

Context en Probleemstelling¶

Beschrijf in 3–5 zinnen:

De huidige situatie of aanleiding.
Het concrete probleem of de vraag die beantwoord moet worden.
Waarom de beslissing nu genomen moet worden.

Vermijd technische implementatiedetails; focus op de zakelijke of architecturale behoefte.

Beslissingsfactoren en constraints¶

Benoem de randvoorwaarden die de beslissingsruimte afbakenen. Categoriseer ze als:

Technische beperkingen – bijv. afhankelijkheid van een bestaand systeem of protocol.
Financiële beperkingen – bijv. een budgetplafond of TCO-eis.
Organisationele beperkingen – bijv. beschikbare kennis, capaciteit of contractuele verplichtingen.

Overwogen Opties¶

Beschrijf minimaal twee en bij voorkeur drie alternatieven. Geef elke optie een bondige titel en een korte beschrijving (2–4 zinnen). Bespreek de voor- en nadelen per optie, inclusief de optie "niets doen" wanneer dat relevant is.

Besluitvorming¶

Vermeld expliciet de gekozen optie en de doorslaggevende motivatie. Leg uit waarom deze optie de beslissingsfactoren het beste adresseert en beter scoort dan de alternatieven.

Consequenties¶

Benoem de verwachte gevolgen van de beslissing, zowel positief als negatief. Denk aan: technische schuld, vendor lock-in, licentiekosten, benodigde bijscholing, en impact op andere systemen of teams.