Een Register is een eenvoudig systeem, een kaartenbak met kaarten, een tabel in een database. Op elke kaart staan gegevens van een object: een huis, een adres, een persoon. Het register is de verzameling kaarten met alle gegevens… toch?
Nee! Voor een OverheidsRegister is meer nodig, behoorlijk wat meer …
Register
 |
|---|
| Figuur 1: Concept van eenvoudig register |
Helaas, zo eenvoudig is zo’n Register / systeem niet, want …
… die gegevens worden vanuit een bepaald proces opgeschreven, bijgehouden en gebruikt. Bij dat (primaire) gebruik worden de gegevens gelezen van de kaart en op een gegeven moment gebruikt. Dat is vaak niet hetzelfde moment, maar ergens ‘later in de tijd’. Vaak is dat nog wel met ‘de kaart bij de hand’ ter controle en eventueel inclusief direct wijzigen / bijwerken van die kaart.
… die gegevens worden ook door andere processen en systemen gelezen en gebruikt. Hier is de afstand tussen het lezen en het gebruik vaak nog veel groter dan in het primaire proces en de terugkoppeling naar de kaart ontbreekt meestal.
… hierin zit inherent de problematiek van tijdigheid. Welke waarde hebben de gegevens op de kaart op een bepaald moment? Hoe ‘waar’ zijn deze gegevens? Hoe oud zijn deze gegevens? En kunnen die bijgewerkt worden in geval deze onjuist en/of achterhaald zijn?
… met digitale middelen worden zowel de afstand van het primaire inwinnen en het gebruik daarvan als de schaal groter. De gegevens vanuit het ene proces staan ‘ergens op het scherm’ in een ander proces. Zonder actualiteitsinformatie. Zonder terugkoppelmogelijkheden. Zonder context van de oorsprong van de gegevens.
… die kaartenbak zit in een database. Voor optimalisatie in het gebruik, met name voor de (uitgebreide variatie van de) ‘afnemende kant’, is het niet één database, maar twee databases. Eén voor het schrijven en één voor het lezen -> nu hebben we extra synchronisatie problematiek geïntroduceerd.
… bovendien zijn die gegevens op een specifiek tijdstip ingegaan, welke meestal niet gelijk is met het tijdstip waarop de gegevens op de kaart zijn bijgeschreven (al helemaal niet als daar nog eens (meerdere) synchronisatie mechanismen tussen zitten)
… dus zo’n kaartenbak is nog zo eenvoudig niet en digitale middelen maken dat niet gemakkelijker … en wel op een veel grotere schaal !!
Een register is (dus) geen eenvoudige kaartenbak en/of tabel, maar een complex systeem. Daarin zijn bijwerken / bijhouden en het gebruik daarvan in andere processen expliciet gescheiden onderdelen -> Hoe kunnen we deze onderdelen goed en robuust verbinden en in sync houden?
Daarvoor heb je een OverheidsRegister nodig 😃
OverheidsRegister
 |
|---|
| Figuur 2: Concept van Handeling -> Gevolgen -> Perspectieven |
In een OverheidsRegister …
… zijn bijhouding (inwinning) en verstrekking (informatievoorziening) strikt gescheiden
- scheiding in verantwoordelijkheden
- scheiding in semantiek en informatiemodellen
- scheiding in techniek, zoals services
… worden regels voor het accepteren van nieuwe wijzigingen tbv bijhouding expliciet uitgedrukt
… worden wijzigingen expliciet gemodelleerd in Gevolgen en bijgehouden als stroom van wijzigingen. Hier kunnen afnemers zich (ook) direct op abonneren
… bestaan (meestal) meerdere verstrekkingen / informatievoorzieningen / informatie- of dataproducten. Er is niet één API, maar data en informatie wordt ontsloten dmv ‘rijke’ APIs of beter: Dataservice. Dat wil zeggen:
een actueel API voor de ontsluiting, ‘de API’ … wat vaak een REST API zal zijn, maar ook een GraphQL API of SPARQL Endpoint zou kunnen betreffen of, als het geo-informatie betreft, een Spatial Data Service (volgens INSPIRE)
een historie API voor de ontsluiting van historische gegevens. Dat kan onderdeel zijn van ‘de API’ of als aparte API beschikbaar worden gesteld (Historische bevraging)
een wijzigingen API voor de ontsluiting van wijzigingen, een [[Event Stream]] tbv abonneren en notificaties. Hier kunnen verschillende patronen mee ondersteund worden, zoals informatierijk en informatiearm notificeren en Gecontroleerde cache en ze zijn bijzonder behulpzaam in het geval van Correctie
een Terugmeldvoorziening in de vorm van een API en een User Interface (webformulier) tbv het kunnen terugkoppelen van fouten en/of Twijfel
de publicatie van Metadata met informatie over en links naar Data kwaliteit, Service kwaliteit, Begrippen, Informatiemodel, voorwaarden en de context (van ontstaan)
… worden regels voor elke informatievoorziening expliciet uitgedrukt. Elk gebruik is expliciet en kent een ontwerp hoe wijzigingen van de inwinningscontext impact hebben op de gebruikerscontext. Dat betekent dat kennis van beide contexten nodig is voor dit ontwerp en dat dit een gedeelde verantwoordelijkheid is. En dat geldt ook voor de operationele uitvoering
… wordt de Lineage bijgehouden van inwinning via Gevolgen naar elke informatievoorziening
… wordt bij elk gebruik en (waarschijnlijk per data-object) een unieke referentie geleverd naar de geleverde versie van dat data-object. Deze is vervolgens ’tot in de eeuwigheid’ later nogmaals op te vragen, a.k.a. Historische bevraging
… bestaan mogelijkheden om feedback te ontvangen en te verwerken. Dat betekent:
dat er terugmelding mogelijk moet zijn (a.k.a. Terugmeldvoorziening)
dat er getwijfeld moeten kunnen worden aan attributen en tijdigheid van het data-object (a.k.a. ‘in onderzoek’ of Twijfel)
dat er correcties gedaan moeten kunnen worden, ook in het verleden: Correctie. Dit zijn nieuwe (functionele) wijzigingen in de reguliere stroom van wijzigingen
die impact hebben op dat verleden en daarom ook om afwegingen vraagt hoe die impact vertaald moet worden in het primaire gebruik en
afnemende processen ook rekening moeten houden met deze feedback(verwerking) en dus expliciet moeten bepalen hoe die correcties verwerkt moeten worden (met terugwerkende kracht?)
 |
|---|
| Figuur 3: Concept van Handeling -> Gevolgen -> Perspectieven met implementaties van wetsanalyse en administratieve uitvoering |
note Als er over Gevolgen wordt gesproken, dan kun je daarin ook lezen Event vanuit Event Sourcing