Hoe de elementen van een architectuurbeschrijving samenhangen. Het begint bij de zorg van een belanghebbende en loopt via risico en maatregel naar de controle die laat zien dat het werkt. Wat dan nog overblijft, is restrisico, en daarmee begint de cyclus opnieuw.
Elke bewering op deze pagina heeft een label en één of meer referenties. Wat de labels betekenen, waar ze horen en hoe normteksten worden weergegeven, staat in de note Elke bewering zegt hoe zeker ze is.
Lees van boven naar beneden: van waarom naar wat kan misgaan, wat ik eraan doe en hoe ik weet dat het werkt. De grijze stippellijn sluit de cirkel.
Dit schema is view B van het model in Van betekenis tot bewijs. Daar staan waarden, visie, missie, drivers en vermogens, en daar is risico verbreed tot onzekerheid met twee kanten: risico en kans.
Het schema voegt drie bronnen samen: de motivatie-elementen van ArchiMate2, de manier waarop een whitepaper van The Open Group risico en beveiliging in ArchiMate modelleert4 en het risicobehandelingsproces van ISO 310005. Geen van deze bronnen tekent precies deze keten. De samenvoeging is van mij.
ISO 42010 noemt belanghebbende, concern, viewpoint, view, architectuurbesluit en rationale als kernbegrippen van een architectuurbeschrijving.1
Elf elementen en één groepering. Per element: wat de bron zegt, wat ik ervan afleid, en hoe het er in Publicatiehuis uitziet.
Een individu, team of organisatie (of een klasse daarvan) met een belang in het systeem.1
Bij een systeem van één persoon zijn belanghebbenden vooral rollen. De toekomstige zelf is een aparte rol: die heeft geen herinnering aan wat de maker nu weet.1
Voorbeeld: de schrijver, de beheerder, de toekomstige zelf, de lezer, AI als maker.
In ISO 42010 legt een viewpoint vast welke concerns een view behandelt.1
Een thema doet iets vergelijkbaars voor lezers: het bundelt verwante concerns tot één leesroute. Het is een ontwerpkeuze, geen normbegrip.1
Voorbeeld: bij een persoonlijke website bijvoorbeeld schrijven, publiceren en bewaren.
Een belang dat een belanghebbende heeft in het systeem.1
Formuleer een concern als vraag. Dan is te toetsen of de architectuur hem beantwoordt.1
Voorbeeld: “Kan ik mijn werk terughalen na verlies van mijn laptop?”
ArchiMate onderscheidt een goal (een beoogde richting of eindtoestand) van een requirement (een behoefte die een eigenschap van één specifiek systeem vastlegt).2
Zonder doel is er geen risico, omdat ISO 31000 risico definieert ten opzichte van doelstellingen. Doelen mogen positief zijn: beter denken door te schrijven is een doel, geen risico.5
Voorbeeld: binnen een dag weer werken op een nieuwe laptop, met volledige historie.
Een uitspraak over een algemene eigenschap die geldt voor elk systeem binnen een bepaalde context.2 TOGAF beschrijft een principe met naam, uitspraak, rationale en implicaties.8
Een principe is ouder dan elk afzonderlijk risico. Het bepaalt welke maatregelen acceptabel zijn.2 8
Voorbeeld: Single Source of Truth; Recoverability by Design.
In de risicowhitepaper van The Open Group kan vrijwel elk kernelement een bezit zijn: iets van waarde dat bescherming verdient.4
Voorbeeld: bronbestanden, Git-historie, de domeinnaam, de lezerslijst, de notities in de kennislaag.
ISO 31000 definieert risico als het effect van onzekerheid op doelstellingen.5 De whitepaper modelleert risico als een soort assessment, een beoordeling.4 NIST beoordeelt risico als combinatie van waarschijnlijkheid en impact.7
Een risico is een oordeel over een situatie, geen ding. Daarom hangt het altijd aan een doel en aan een bezit.4 5
Voorbeeld: laptop gestolen; synchronisatie verwijdert bestanden.
ISO 31000 noemt zeven opties voor risicobehandeling: vermijden, risico nemen of vergroten om een kans te benutten, de bron wegnemen, de kans veranderen, het gevolg veranderen, delen, en bewust behouden.5 In de whitepaper is een beheersmaatregel een requirement.4
Accepteren is ook een respons. Leg het dan wel vast, met de reden.5
Voorbeeld: Git-repository op GitHub, plus OneDrive als tweede kopie van werk in uitvoering.
Nygard stelt een kort document per belangrijk besluit voor, met context, besluit, status en gevolgen. Vervangen besluiten blijven bewaard.9 ISO 42010 vraagt architectuurbesluiten met hun rationale vast te leggen.1
Voorbeeld: een besluit om OneDrive naast Git en GitHub te gebruiken.
De whitepaper modelleert een uitgevoerde maatregel met de kernelementen die haar realiseren, zoals applicaties, processen en technologie.4
Uitvoering heeft twee vormen: inrichting (hoe het staat) en werkwijze (wat iemand doet).4
Voorbeeld: de rolverdeling OneDrive, Git en GitHub; de herstelroute op een nieuwe laptop.
ISO 31000 maakt monitoring en review tot een vast onderdeel van het risicoproces, in alle fasen.5
Zonder controle is een maatregel alleen een bewering.5
Voorbeeld: een hersteltest op een schone machine; de automatische linkcontrole vóór publicatie.
Het risico dat overblijft na risicobehandeling.6
Voorbeeld: de bron staat veilig op GitHub, maar het account kan worden geblokkeerd.
Dezelfde pijlen als in het schema, als tabel. De kolom Grondslag zegt of een relatie uit een bron komt of uit mijn eigen redenering.
| Van | Relatie | Naar | Betekenis | Grondslag |
|---|---|---|---|---|
| Belanghebbende | heeft | Concern | Elke zorg is van iemand. | Feit 1 |
| Thema | groepeert | Concern | Verwante zorgen vormen één leesroute. | Afgel. 1 |
| Concern | leidt tot | Doel / eis | Wat moet waar zijn om de zorg weg te nemen. | Afgel. 2 |
| Principe | draagt bij aan | Doel / eis | Een algemene regel helpt het doel bereiken. | Feit 2 |
| Risico | raakt | Bezit | Een risico heeft een object. | Feit 4 |
| Risico | bedreigt | Doel / eis | Risico bestaat alleen ten opzichte van een doel. | Feit 5 |
| Principe | stuurt keuze van | Maatregel | Een maatregel die een principe schendt, valt af. | Afgel. 2 8 |
| Maatregel | behandelt | Risico | Vermijden, verminderen, delen of bewust accepteren. | Feit 5 |
| Maatregel | realiseert | Doel / eis | De maatregel maakt het doel waar. | Feit 4 |
| Maatregel | vastgelegd in | ADR | Alleen bij een belangrijke keuze met alternatieven. | Afgel. 9 1 |
| ADR | uitgevoerd in | Uitvoering | Het besluit krijgt een inrichting en een werkwijze. | Afgel. 4 9 |
| Uitvoering | getoetst door | Controle | Bewijs dat de maatregel werkt. | Feit 5 |
| Controle | levert | Restrisico | Wat na behandeling overblijft, wordt zichtbaar. | Feit 6 |
| Restrisico | wordt | Risico | De cyclus begint opnieuw. | Afgel. 5 |
Vier punten waarop dit schema afwijkt van de intuïtieve volgorde: thema → zorg → risico → maatregel → principe.
Het principe staat naast de keten, niet aan het eind. Een principe is een algemene ontwerpregel die al geldt vóór een risico wordt beoordeeld. Het bepaalt welke maatregelen acceptabel zijn. Een betaalde backupdienst kan dataverlies verminderen en toch botsen met het principe dat het werk niet van één leverancier mag afhangen.2 8
Niet elke zorg is een risico. Risico is gedefinieerd ten opzichte van doelstellingen. Een model dat alleen vanuit risico's redeneert, kent alleen verliesvermijding. “Een directe relatie met lezers opbouwen” is een doel dat ontwerpkeuzes stuurt zonder dat er een dreiging aan voorafgaat.5
Accepteren is een volwaardige respons. ISO 31000 noemt bewust behouden als behandelingsoptie. Een risico zonder maatregel is dus niet per se een gat, zolang de acceptatie en de reden zijn vastgelegd.5
ISO/IEC/IEEE 29148 vraagt dat eisen in twee richtingen traceerbaar zijn: terug naar hun herkomst en vooruit naar wat ze realiseert.10 ISO 42010 koppelt via de rationale besluiten aan concerns.1
Van boven naar beneden beantwoordt de vraag waarom doe ik dit? Volg vanaf een inrichting de pijlen terug naar het besluit, de maatregel, het risico en de zorg.10
Van beneden naar boven beantwoordt de vraag wat gebeurt er als ik dit verander? Haal ik OneDrive weg, welke risico's gaan dan weer open? Dat is impactanalyse, en die kan alleen als de koppelingen expliciet zijn vastgelegd.10
Met een kort ID per element (CON-03, R-07, P11, ADR-010) kan de controle bij elke bouw gebroken koppelingen vinden, net zoals ze nu dode links vindt.
Toets: zodra risico's en principes elk een kort ID hebben, de controle draaien en tellen hoeveel koppelingen ze vindt die met de hand gemist waren.
Eén keten als voorbeeld, uit het thema continuïteit, van zorg tot restrisico.
| Element | Voorbeeld |
|---|---|
| Thema | Continuïteit |
| Belanghebbende | De schrijver |
| Concern | Kan ik mijn werk terughalen na verlies van mijn laptop? |
| Doel / eis | Herstelbaar vanaf een andere kopie, zonder eerst iets te reconstrueren |
| Bezit | Bronbestanden en Git-historie |
| Risico | Laptop stuk of gestolen. Kans middel, impact hoog. |
| Principes | Single Source of Truth; Recoverability by Design |
| Maatregel | Repository op GitHub; OneDrive voor werk dat nog niet gepusht is |
| ADR | OneDrive naast Git en GitHub |
| Uitvoering | Rolverdeling en herstelroute: Git installeren, OneDrive koppelen, opnieuw clonen, niet-gecommit werk vergelijken |
| Controle | Een periodieke hersteltest op een schone machine |
| Restrisico | GitHub-account geblokkeerd. Kans laag, impact hoog. |
Het restrisico leidt naar een ander thema: een geblokkeerd account is een vraag van zeggenschap, niet alleen van continuïteit. Een keten blijft dus zelden binnen één thema.
ArchiMate 4 verandert de relaties tussen de motivatie-elementen niet wezenlijk. Bekend is alleen dat Constraint is vervallen.3
Toets: het hoofdstuk over motivatie-elementen in de ArchiMate 4-specificatie naast §04 van deze pagina leggen.
Voor één beheerder volstaan vier soorten vastlegging: doelen, risico's (met bezit, respons, maatregel en restrisico), principes en besluiten.
Toets: bij het inrichten van een eigen systeem nagaan of er gegevens zijn die in geen van de vier passen.
Normen en standaarden zijn waar mogelijk rechtstreeks geraadpleegd. Waar de primaire tekst niet vrij toegankelijk is, staat de gebruikte secundaire bron erbij. Geraadpleegd op 7 oktober 2026.
Deze tekst is gegenereerd met AI en nog niet door mij herschreven. Status: concept.