Een besluit dat kan veranderen

Een Architecture Decision Record, of ADR, beschrijft context, overwogen opties, criteria, besluit en consequenties. Voeg voor deze opleiding bronverwijzingen, onbekenden, eigenaar en herijkmoment toe. De toegevoegde waarde zit niet in het formulier maar in de redenering: een reviewer moet kunnen volgen waarom één optie onder deze omstandigheden beter past.

Een harde eis toets je eerst als toelatingsvoorwaarde. Daarna kunnen zachte criteria de overgebleven opties vergelijken. Een gewogen score kan niet compenseren dat een optie de vastgestelde hersteldoelen niet haalt. Vermijd schijnprecisie: een score 4 voor “veilig” heeft pas betekenis als je het beoordeelde control en bewijs benoemt.

Voor Noordhaven lijkt replatform naar een beheerde webdienst en relationele database een plausibele hypothese. Die sluit aan op teamvaardigheden en beperkt de wijzigingsscope. Rehost blijft een serieus alternatief als ongedocumenteerde applicatieafhankelijkheden tijdige replatforming blokkeren. Een volledige microservicesherbouw vraagt eerst bewijs dat de extra veranderlast vóór het contracteinde beheersbaar is.

Een voorwaardelijk besluit kan luiden: kies replatform als een representatieve proef het ontvangstnummer, de piekbelasting, het herstel en de ERP-integratie bewijst. De product owner accepteert de gebruikersmeting, operations de herstelproef. Herijk uiterlijk na de proef: als kritieke afhankelijkheden niet oplosbaar zijn binnen het migratievenster, vergelijk een tijdelijke rehost opnieuw. Zo wordt onzekerheid een beheersbare beslispoort.

Eerst toelaatbaarheid, daarna voorkeur

Maak een onderscheid tussen een optie die bewezen niet aan een harde eis voldoet en een optie waarvoor bewijs ontbreekt. De eerste valt af tenzij de bevoegde eigenaar de eis wijzigt. De tweede blijft een onderzoekskandidaat met een concrete bewijsopdracht. Schrijf bij herstel bijvoorbeeld niet voldoet aan zestig minuten als er alleen een productbeschrijving bestaat; schrijf dat de volledige herstelproef ontbreekt en welke onderdelen je daarin gaat meten.

Vervolgens vergelijk je serieuze opties op dezelfde bedrijfsfunctie en tijdshorizon. Een kale VM-prijs naast een PaaS-prijs inclusief back-up en beheer geeft geen eerlijke vergelijking. Maak ontbrekende posten zichtbaar, ook als het bedrag nog onbekend is. Bij veranderbaarheid beschrijf je welk scenario eenvoudiger wordt: een runtime vervangen, een tweede team aansluiten of data naar een andere uitvoerder verplaatsen. Het losse woord flexibel geeft de reviewer geen houvast.

Omgaan met afhankelijk bewijs

Een proef moet de beslissing kunnen veranderen. Als je vooraf altijd voor dezelfde provider kiest, is het vergelijken van namen geen architectuuronderzoek. Formuleer een falsificeerbare hypothese: deze runtime ondersteunt de vereiste databasefuncties en het team kan de herstelprocedure uitvoeren. Leg uit welke test een afwijzing oplevert en welke terugvaloptie dan beschikbaar blijft. Controleer de doorlooptijd van die terugval; een alternatief dat pas na de contractdeadline klaar kan zijn is geen bruikbaar vangnet.

Niet ieder risico vraagt meteen een groot onderzoek. Rangschik onbekenden op hun effect op het besluit en op de tijd die herstel van een verkeerde keuze kost. Een niet ondersteunde databasefunctie kan replatform blokkeren en verdient vroeg onderzoek. Een definitieve naam voor een niet kritieke tag kan wachten. Deze volgorde voorkomt dat veel laagrisicodetails de onzekerheid rond het kernontwerp verhullen.

Leg ook de prijs van het besluit vast

Een voorkeur is overtuigender wanneer de ongewenste gevolgen expliciet zijn. Replatform kan beheer verminderen terwijl leveranciersafhankelijkheid toeneemt en compatibiliteit werk vraagt. Accepteer die gevolgen bewust met eigenaar en maatregel. N15 kan bijvoorbeeld leiden tot een periodieke export- en herstartproef. Het besluit is dan navolgbaar zonder te doen alsof de gekozen optie op ieder criterium de beste is.

Kernpunt

Een goed besluit vermeldt ook welk nieuw bewijs de voorkeur verandert.

Denk zelf na

Waarom is “PaaS scoort 23 punten en IaaS 21” op zichzelf onvoldoende?

Uitgewerkt voorbeeld

De schaal, weging, harde eisen en bewijssterkte ontbreken. Controleer eerst haalbaarheid, verklaar daarna de afweging en test of een kleine wijziging in aannames de voorkeur omdraait.