Bij het uitwerken van de verschillende patronen zijn diverse onderwerpen naar boven gekomen die eigenlijk generiek voor alle patronen uitgewerkt moeten worden. Veel van deze vragen spelen op de technieklaag.
Bij gebrek aan een aparte technische architectuur in de keten en omdat het toch belangrijk is hierin wat richting mee te geven volgen hierna enkele van deze richtinggevende onderwerpen.
Ook hier zal een groot deel moeten worden geconcretiseerd in verdere uitwerkingen. Bij het opstellen van solutions zullen ongetwijfeld nog meer onderwerpen opduiken waarvoor het goed is om vanuit deze informatiearchitectuur over de patronen heen wat (extra) richting mee te geven.
Stel een API-standaard op voor de Migratieketen die aangeeft hoe we API's op de verschillende onderdelen op een uniforme manier kunnen ontwerpen.
Denk bijvoorbeeld aan het op een uniforme manier omgaan met historie, versies en andere ontwerpkeuzes. Hierbij baseren we ons op de API design rules uit de landelijke API strategie, maar het zal nodig zijn om voor de Migratieketen nog aanvullende afspraken te maken en vast te leggen.
Het gebruik van API's in de keten brengt ook een groot deel nieuwe functionaliteit met zich mee in de Migratieketen. Bestaande berichtenmakelaars worden vervangen door API-managementfunctionaliteit. Er dient te worden afgesproken welke van deze functionaliteit de ketenpartners en centrale voorzieningen minimaal moeten implementeren om samen te kunnen werken op basis van API's. En welke functionaliteit we eventueel gezamenlijk op ketenniveau gaan implementeren, zoals een ketencatalogus of developer-omgeving.
We kiezen hier, overeenkomstig MIRA principe 4A: De keten maakt optimaal gebruik van overheidsbrede afspraken, standaarden en voorzieningen voor de overheidsbrede standaard Digikoppeling, met daarin het REST API profiel. Dit maakt koppeling met niet-JenV keten- en samenwerkingspartners en eventuele toekomstige veranderingen in de keten mogelijk (cfr de MIRA principes 2C en 3C).
In het Digikoppeling REST API-profiel is zeer recent ook de FSC-standaard opgenomen. Deze maakt het mogelijk om veilig verbindingen op te zetten in een netwerk van aanbiedende en afnemende ketenpartners, API's vindbaar en toegankelijk te maken via een directory, verbindingen te beheren en te monitoren en een uniforme, federatieve manier van logging van verwerkingen te faciliteren. Omdat dit zaken zijn die we anders zelf in de keten moeten regelen sluiten we hiervoor aan bij deze standaard. Een standaard manier van authenticeren voor de keten is belangrijk, omdat we voor toegang tot de API's een zero-trust-achtige aanpak willen hanteren.
Aandachtpunt is wel dat we, gezien de recente ontwikkelingen, hiermee relatief voorop lopen. Er wordt echter o.a. vanuit het Federatief Datastelsel en de MIDO Domeinarchitectuur Gegevensuitwisseling ook nadrukkelijk naar deze standaard verwezen, dus bredere adoptie binnen de Nederlandse overheid is zeer waarschijnlijk.
De patronen die in deze informatiearchitectuur zijn geschetst, tonen een ketenlandschap dat communiceert op basis van API's bij zowel de ontvanger en de afnemer. Deze API's kunnen dynamisch gewijzigd worden, zo lang deze wijzigingen maar gepubliceerd worden in de ketenbrede (gegevens)catalogi. Dit maakt dat het toevoegen van nieuwe informatie-uitwisselingen en dus kunnen inspringen over veranderingen in de keten eenvoudig.
Dit werkt alleen maar als op onderliggend netwerkniveau alle nieuwe API's direct bereikbaar zijn en niet alle nieuwe URI's eerst nog handmatig aan een firewall moeten worden toegevoegd of iets dergelijks. Dit stellen we ook als eis aan de netwerkinfructuur van de keten.
Als keuze voor het netwerk kunnen we grofweg kiezen uit 3 smaken:
Niet alle keten- en samenwerkingspartners zitten native op Justitienet, waardoor deze niet aan bovenstaand eis kan voldoen. Internet is niet veilig genoeg. Dus komen we uit op Diginetwerk om alle API's op te kunnen publiceren. Dit is eenvoudig opgeschreven, maar vergt nog behoorlijk wat uitzoek- en specificatiewerk om dit voor elkaar te krijgen.
Bij toegangsverlening hebben we het over het autoriseren van medewerkers of systemen voor een bepaalde set gegevens of een dienst. Dit kan op verschillende manieren, van heel grofmazig tot heel fijnmazig. In de patronen 2A en 2B hebben we hier e.e.a. begeschreven.
Het gebruiken van een eenduidige manier van toegangsverlening in de keten is noodzakelijk. De redenatie dat we achteraf goed loggen is naar verwachting (op niet al te lange termijn) onvoldoende om aan te tonen dat we de AVG naleven. Een standaard die hiervoor in ontwikkeling is is die van Federatieve Toegangsverlening (FTV). Deze zit nog in de ontwikkelfase, maar is een cruciale bouwsteen in een Federatief Datastelsel. Geadviseerd wordt om hier dan ook van uit te gaan. In geval van timings-issues moeten we maximaal keuzes maken die terugbewegen naar deze overheidsbrede standaard-in-wording mogelijk maken.
Deze pagina is voor het laatst bewerkt op 10 mrt 2025 om 15:25.