Copyright © 2026 VNG Realisatie. Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding 4.0 Internationaal-licentie (CC BY 4.0).

Aanleiding en doel

Waar ontbreekt het (nu) aan?

De overheid heeft de bevoegdheid om vergaand in de situatie van burgers en bedrijven in te grijpen. Door automatisering van het inwinnen en verwerken van gegevens kon dit ingrijpen een steeds grootschaliger karakter krijgen. Onze vermogens om overheidshandelen te begrijpen, controleren en daarbij eventueel gemaakte fouten te herstellen hielden met de mogelijkheden van digitalisering echter geen gelijke tred.

Waar het misging werden daardoor niet alleen meer burgers en bedrijven getroffen. Doordat gegevens geautomatiseerd door ketens stroomden, konden op basis daarvan meerdere organisaties handelen. Fouten hadden daardoor voor betrokkenen ook verstrekkender gevolgen.

Deze handreiking beschrijft hoe we overheidsinformatie in registers zodanig kunnen vastleggen en beschikbaar stellen dat we de betekenis en waarde daarvan beter kunnen beoordelen, fouten zoveel mogelijk kunnen voorkomen en die - als dat niet lukt - in ieder geval herstellen.

De happy en de crappy flow

Zo lang burgers en bedrijven dingen willen die wij vooraf hadden bedacht, tijdig de juiste informatie aanleveren, en ‘onze’ overheidsgegevens kloppen - voorwaarden waaraan in de meeste gevallen wordt voldaan - verlopen processen snel en met minimale menselijke tussenkomst.

Maar wat gebeurt er als zo’n burger of bedrijf wordt geconfronteerd met een situatie die niet past binnen de grenzen van de happy flow? Bijvoorbeeld naar aanleiding van een minder vaak voorkomend verzoek of betrokkenheid bij een proces met onvoorspelbaar verloop. Nog lastiger wordt het als iets moet worden aangevochten, onderzocht of gecorrigeerd? Deze handelingen zijn onderdeel van de crappy flow: een werkstroom die vrijwel altijd handwerk vereist, en soms überhaupt niet wordt afgehandeld.

Dit betekent dat resultaten die ontstaan uit happy flows zich gemakkelijk en grotendeels geautomatiseerd door het overheidsapparaat kunnen verspreiden, terwijl uit crappy flows voortkomende twijfelindicaties en correctiehandelingen - als ze al verwerkt worden - nauwelijks de grens oversteken naar vanuit gegevensgebruikperspectief stroomafwaarts liggende domeinen. Waardoor in die domeinen op basis van verkeerde gegevens onjuiste gevolgen geproduceerd kunnen worden.

Parabel: Infrastructuur van Digitalië

De eilanden van het atollenrijk Digitalië zijn met indrukwekkende hogesnelheidsinfrastructuur verbonden. Maar die is alleen toegankelijk voor een selecte meerderheid van contente conformisten.

Pogingen om op deze infrastructuur ook een minderheid van abusievelijke anarchisten toe te laten zijn allemaal mislukt. Want deze groep zonder vaste bestemming negeerde zorgvuldig vastgestelde gewichts- en hoogtebeperkingen, bewoog zich tegen rijrichtingen in en vroeg om afritten op onmogelijke plaatsen.

Terwijl hoog boven de golven contente conformisten voortrazen, zijn abusievelijke anarchisten in hun kleine scheepjes nog altijd overgeleverd aan de stormen van de Analoge zee. “Natuurlijk is dat onrechtvaardig”, bevestigt een beleidsmaker. “Maar er is gewoon geen businesscase.”

Epistemische nederigheid

Het bovenstaande maakt duidelijk dat overheidsinformatie niet altijd klopt. En dit soort onjuistheden zullen altijd overblijven, hoeveel crappy flows we ook in happy flows weten om te zetten. Deze constatering vraagt om epistemische nederigheid; het erkennen dat onze kennis beperkt, voorlopig en mogelijk onjuist is.

Maar naar dit principe handelen is moeilijk als het gereedschap om de waarde van informatie te kunnen beoordelen ontbreekt. Binnen de overheid kunnen we zo’n inschatting op dit moment vaak alleen voor het ‘eigen’ domein maken. Dit betekent dat we niet kunnen achterhalen wie een keten van overheidshandelen in beweging heeft gezet, en wanneer en met welke reden dat is gebeurd. En dat we geen compleet beeld hebben van hoe lang óns handelen verderop in de keten nog doorwerkt.

Om dit op te lossen hebben we meer en beter inzicht in de context van onze informatie nodig. Deze behoefte kunnen we samenvatten in een aantal aspecten:

• Historie: hoe zag de situatie er in het verleden uit en welke veranderingen hebben door de tijd heen plaatsgevonden?
• Aanleiding: welke input initieerde ons handelen?
• Legitimering: welke wet of regel legitimeerde ons handelen en het gevolg dat door dat handelen werd geproduceerd?
• Verklaring: welke (geautomatiseerde) handelingen hebben we uitgevoerd om een gevolg te produceren?
• Zekerheid: in hoeverre, en op grond waarvan kunnen we uitgaan van de (on)juistheid van een gegeven?

Wat is een register?

Betekenis van het begrip ‘register’

Het woord ‘register’ heeft in verschillende contexten uiteenlopende bekentenissen. Een organist zal daarbij denken aan een serie orgelpijpen met dezelfde klankkleur, een auteur ziet een lijst met trefwoorden voor zich, terwijl een werkplekbeheerder zich de editor voorstelt waarmee instellingen van Windowssystemen kunnen worden aangepast.

Associaties van geïnteresseerden in deze handreiking zullen waarschijnlijk dichter bij elkaar liggen. Maar ook als we de betekenisruimte inperken door te stellen dat een register iets te maken moet hebben met het verwerken van informatie binnen de overheid, blijven nog uiteenlopende zienswijzen over. Bijvoorbeeld:

• holistisch: een volledig stelsel gericht op het bijhouden en leveren van bepaalde gegevens, bestaande uit wet- en regelgeving, betrokken organisaties en hun onderlinge afspraken, systemen voor opslag en distributie van gegevens en de technische infrastructuur die hiervoor nodig is;
• universeel: een digitaal of fysiek bijgehouden verzameling geordende informatie;
• afnamegericht: een plaats waar bepaalde gegevens onder bepaalde voorwaarden verkregen kunnen worden, of
• technisch: een database.

Om verwarring te voorkomen, is het belangrijk het begrip register in de context van ‘Uit betrouwbare bron’ betekenis te geven. Wij definiëren een register als volgt:

“Een applicatiecomponent, of een verzameling samenwerkende applicatiecomponenten, gericht op het betrouwbaar vastleggen en presenteren van een geordende verzameling digitale overheidsinformatie.”

Register of registratie?

Binnen de overheid gebruiken we voor aanduiding van een georganiseerde gegevensverzameling zowel het begrip register (Kentekenregister, Register van overheidsorganisaties, BIG-register, UBO-register) als registratie (met name in de context van basisregistraties).

Er zijn twee redenen om binnen ‘Uit betrouwbare bron’ het begrip register te gebruiken. Enerzijds sluit dat het beste aan bij de betekenis in ‘gewoon’ taalgebruik. Een register is volgens het Van Dale-woordenboek een “inschrijvingsboek, naamlijst; goed geordende inhoudsopgave: bevolkingsregister, namenregister”, terwijl registratie wordt gedefinieerd als “inschrijving in een register: de registratie van een koopakte.”

Daarnaast willen we de indruk vermijden dat ‘Uit betrouwbare bron’ gaat over basisregistraties. Hoewel het project niet tot doel heeft een in productieomstandigheden werkend register op te leveren, verwachten we dat in deze handreiking beschreven bevindingen in eerste instantie waardevol zullen zijn binnen domeinen waarbinnen op basis van gedeelde kennis intensief wordt samenwerkt, maar (nog) geen basisregistratie bestaat.

Perspectieven op het register

Een definitie alleen is niet genoeg om duidelijk te maken waarover ‘Uit betrouwbare bron’ gaat. Ook een applicatiecomponent kan je immers vanuit verschillende perspectieven benaderen. Om duidelijk te maken welke daarvan wij innemen, beschrijven we de scope van het project aan de hand van twee elkaar aanvullende architectuurmodellen:

1. De European Interoperability Reference Architecture (EIRA)
2. Het Common Ground-vijflagenmodel

Architectuurlagen en scope UBB

Betere ondersteuning van de crappy flow en het faciliteren van epistemische nederigheid vereist verandering in alle EIRA-lagen: juridisch, organisatorisch en technisch. Deze handreiking richt zich echter primair op de semantische en applicatielaag (het gebied binnen de paarse gestreepte lijn in bovenstaande figuur).

Binnen de applicatielaag kunnen we dankzij het Common Groundmodel preciezer zijn over onze scope: we beperken ons tot de lagen ‘databronnen’, ‘diensten’ en vanwege de relatie tussen bijhoudingsdiensten en processen die deze gebruiken ook een deel van ‘procesinrichting’ (gele gestreepte lijn in bovenstaande figuur). Dit betekent dat we bijvoorbeeld aanbevelingen doen voor:

• welke concepten belangrijk zijn om de werking van het register te begrijpen, welke betekenis we daaraan geven en hoe de samenhang daartussen eruit ziet;
• uit welke conceptuele ‘bouwblokken’ het register bestaat en welke rol die spelen;
• welke generieke (dus onafhankelijk van welke gegevens een register omvat toepasbare) functionaliteit het register moet leveren, en
• hoe deze functionaliteit met behulp van API’s toegankelijk te maken.

Hoewel we andere lagen niet helemaal kunnen en willen negeren - hieronder bespreken we bijvoorbeeld de begrenzing van het register in relatie tot de (organisatorische) domeinen die het ondersteunt - betekent deze scopeafbakening dat we in deze handreiking geen aanbevelingen doen over bijvoorbeeld:

• interpretatie of herziening van wet- en regelgeving;
• verdeling van verantwoordelijkheden over organisaties (wel/niet gescheiden organisaties voor bijhouding en levering, bijhouding en levering wel/niet organisatorisch federatief of juist centraal);
• gebruik van specifieke technische producten (hoewel die bij onze beproevingen wel een belangrijke rol spelen);
• bij concrete implementatie in één technisch product clusteren van applicatiecomponenten (bijvoorbeeld vanwege van efficiëntie- of performanceredenen), en
• het ontwerpen van interfaces om registergegevens aan gebruikers te presenteren.

De overheid verkaveld

Registers staan niet op zichzelf, maar ondersteunen de overheid bij het invullen van haar administratieve behoeften. Die overheid vormt geen homogeen, eenduidig handelend geheel, maar is een pluriform en complex systeem.

Om de verhouding tussen register en overheid te kunnen duiden, moeten we dat systeem - liefst op basis van objectieve criteria - kunnen verkavelen naar logisch samenhangende delen, zonder daarbij al te veel door bestaande indelingen geleid of gehinderd te worden.

Ons streven is dat ieder van die delen groot genoeg is om zelfstandig bestaansrecht te hebben, maar klein genoeg om een ondubbelzinnig begrip van concepten, regels en processen te kunnen waarborgen.

Domein

Vaak wordt het woord domein gebruikt om binnen het totaal aan taken en verantwoordelijkheden van de overheid een specifiek, samenhangend werkgebied aan te wijzen. Maar anders dan in de wiskunde kent het begrip domein in organisatorische context geen objectieve afbakeningscriteria. Dit blijkt bijvoorbeeld uit de definitie die Eric Evans hanteert in de context van Domain driven design. Evans beschouwt een domein als “een sfeer van kennis, invloed of activiteit”. Hoewel deze definitie een zekere mate van interne samenhang veronderstelt, sluit die niet uit dat binnen één domein:

• dezelfde concepten verschillend geïnterpreteerd worden,
• regels en gedrag niet consistent zijn, en
• bedrijfsprocessen niet op elkaar zijn afgestemd.

Een domein voldoet dus weliswaar aan de eis van zelfstandig bestaansrecht, maar is niet restrictief genoeg om ondubbelzinnig begrip van wat daarbinnen gebeurt te waarborgen.

Bounded context

Binnen een domein kunnen meerdere subdomeinen of taakgebieden bestaan. Daarbij horen verantwoordelijkheden, die zijn toegekend aan specifieke teams, afdelingen of bedrijfseenheden. Zij worden ondersteund door eigen semantiek, processen en regels. Deze zaken kunnen worden beschreven in een model: een systeem van abstracties dat beschrijft hoe men vanuit een taakgebied naar de wereld kijkt en reageert op veranderingen in de buitenwereld. Zo’n model is beschreven in gemeenschappelijke taal die binnen het hele taakgebied begrepen wordt.

Model en taal beschrijven dus een voor betrokkenen herkenbare ‘blauwdruk’ van het taakgebied, die (onder andere) de basis kan vormen voor het ontwerp van een register. Een in gemeenschappelijke taal ondubbelzinnig en samenhangend gemodelleerd taakgebied noemen we een bounded context.

Het belang van het erkennen van bounded contexten wordt door Eric Evans in ‘the Blue Book’ over Domain driven design als volgt beschreven:

“A bounded context delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other contexts. Within that context, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other contexts, other models apply, with differences in terminology, in concepts and rules, and in dialects of the ubiquitous language [red. gemeenschappelijke taal]. By drawing an explicit boundary, you can keep the model pure, and therefore potent, where it is applicable. At the same time, you avoid confusion when shifting your attention to other contexts. Integration across the boundaries necessarily will involve some translation, which you can analyze explicitly.”

Uit dit citaat blijkt dat de ambiguïteiten die we op domeinniveau nog konden tegenkomen binnen een bounded context (idealiter) verdwijnen. Hier geldt (zoveel mogelijk) dat:

• dezelfde concepten eenduidig geïnterpreteerd worden (op basis van gemeenschappelijke taal),
• regels en gedrag consistent zijn, en
• bedrijfsprocessen op elkaar aansluiten.

Contextovergangen

Bounded contexten bestaan zelden in volledige isolatie. Veel vaker zijn ze in ketens of netwerken verbonden met andere bounded contexten. Dit betekent dat een gevolg dat werd geproduceerd in de ene context, in een volgende context wordt beschouwd als aanleiding of trigger voor het produceren van een nieuw gevolg. Bij het oversteken van de grens tussen de twee bounded contexten ontstaat een contextovergang. Hierbij moeten taal en model van de ene context omgezet worden naar taal en model van de andere.

Leveringen kennen daarom geen ‘vaste’ bounded context. Deze kunnen zijn opgesteld in de taal van de context die het gevolg produceerde waarover een levering gaat. In andere gevallen kan een levering echter expliciet bedoeld zijn om een specifieke (afnemende) bounded context te informeren. Op verzoek van deze contexten kunnen vanuit de producerende context daarom leveringen worden geproduceerd die dichter tegen de context van de ‘afnemende bounded context’ aanliggen.

Soms zal een producent van gevolgen ervoor kiezen om beide te doen: naast een of meerdere leveringen die taal en model van de ‘eigen’ context volgen, worden dan ook leveringen gemaakt die aansluiten bij de conventies van bounded contexten van afnemers.

Taak en gevolg hebben wel een vast bounded context en conformeren zich altijd aan de taal en het model van de bounded context waarbinnen ze worden uitgevoerd c.q. geproduceerd.

Uitvoeringscontext van registers

Binnen iedere bounded context wordt gewerkt. Een deel van dat werk slaat neer in onze registers. Om te begrijpen welk deel, moeten we het karakter van dit werk op abstract niveau begrijpen. In dit hoofdstuk beschrijven we daarom een conceptualisering van de overheid als uitvoerder van taken die horen bij publieke dienstverlening. Vertrekt hiervoor is de overheid als producent van gevolgen en consument van leveringen.

De overheid als producent van gevolgen

Het begrip gevolg wordt op Wikipedia beschreven als “een gebeurtenis of omstandigheid die optreedt als resultaat van een of meer oorzaken en bijdragende factoren en omstandigheden”. Binnen de context van deze handreiking hanteren we een wat preciezere betekenis, namelijk het gevolg als “duurzaam betekenisvol resultaat van overheidshandelen”.

Om bovenstaande definitie te begrijpen, is het behulpzaam het handelen van de overheid nader te bekijken. Dat handelen begint bij een taak of bevoegdheid, die ontstaat vanwege attributie (‘toewijzen’) door de wetgever. Artikel 5.8 van de Omgevingswet attribueert bijvoorbeeld aan het college van burgemeester en wethouders de bevoegdheid te beslissen of een omgevingsvergunning al dan niet wordt verleend.

Een bevoegdheid houdt (mits aan een aantal basisvoorwaarden voldaan is) een plicht tot handelen in; het college kan er dus niet zelfstandig voor kiezen de ene aanvraag wel, en de andere niet in behandeling te nemen. Dit betekent dat een aanvraag altijd leidt tot één of meer handelingen, die weer één of meer resultaten opleveren. In het geval van de omgevingsvergunning is aan te denken aan handelingen als:

• beoordelen op indieningsvereisten (juistheid en compleetheid)
• inwinnen advies bij ketenpartner
• besluiten over verlenen vergunning

Daarbij horen resultaten als:

• aanvraag is in behandeling genomen
• advies ingewonnen
• vergunning verleend (of niet verleend)

Niet al deze resultaten zijn echter een gevolg. We hebben immers gesteld dat daarvoor een duurzaam betekenisvol karakter nodig is. Het is niet eenvoudig deze karakteristiek in algemeenheid waterdicht te definiëren. Informeel kunnen we stellen dat het resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt als gevolg gezien moet worden. Vaak (maar niet per definitie) is zo’n gevolg gelijk aan het rechtsgevolg dat naar aanleiding van overheidshandelen ontstaat.

In het geval van de omgevingsvergunningaanvraag beschouwen we op basis hiervan het verlenen (of juist het niet verlenen) van de gevraagde omgevingsvergunning als gevolg. Specifieke voorwaarden waaronder de vergunning is verleend, zoals een maximaal bouwvolume of vereiste goothoogte kunnen van zo’n gevolg onderdeel zijn.

Hoewel het voor de hand ligt een gevolg te beschouwen als verandering in de bounded context waarbinnen gehandeld wordt, maakt het bovenstaande duidelijk dat hiervan niet altijd sprake hoeft te zijn. Het niet-verlenen van de omgevingsvergunning betekent vanwege het gesloten karakter van het omgevingsrecht dat iets wat vóór de aanvraag niet mocht, nu nog steeds niet mag. Hier is dus sprake van een (beargumenteerde) bevestiging van de bestaande situatie, en niet van een verandering. Zo’n verandering zien we wel als de vergunning wordt verleend, waarna iets wat eerst niet mocht, (nu) wel mag.

Productie van een gevolg

Voor een vollediger begrip van hoe een gevolg ontstaat, moeten we het bijbehorende productieproces in meer detail bekijken. Binnen dat proces kunnen we drie belangrijke concepten onderscheiden. Hierbij geldt dat ieder volgend concept afhankelijk is van het voorgaande:

1. Signaal: een indicatie dat er ergens - in de buitenwereld, een andere of de eigen overheidsorganisatie - iets is gebeurd wat aandacht verdient.
2. Taak: de handelingen die naar aanleiding van een signaal moeten worden uitgevoerd.
3. Gevolg: een duurzaam betekenisvol resultaat van overheidshandelen.

De overheid als consument van leveringen

Hierboven benoemden we het signaal als aanleiding voor de productie van één of meerdere gevolgen. Maar we beschreven niet waar zo’n signaal vandaan komt. Omdat binnen de overheid vaak in ketens of netwerken wordt gewerkt, is de bron van zo’n signaal heel vaak óók de overheid. Meer precies een andere bounded context die een gevolg heeft geproduceerd en keten- of netwerkpartners daarover informeert.

Dit betekent dat de productie van een gevolg in heel veel gevallen niet het eindstation van overheidshandelen is. Vrijwel altijd willen we daarover ook anderen informeren - bijvoorbeeld de burger die een omgevingsvergunning heeft aangevraagd uit het voorbeeld hierboven, maar ook bedrijven, partnerorganisaties of collega-overheden. Deze doelgroepen hebben uiteenlopende informatiebehoeften en verwerken informatie op verschillende manieren.

Diversiteit in behoeften en verwerkingsvoorkeuren betekenen dat een informering meer omvat dan alleen de betekenis die een gevolg beschrijft. Die betekenis wordt in een bepaalde vorm overgebracht - denk aan een per mail verzonden besluit in Pdf-formaat, het resultaat van een specifieke query of een voor geautomatiseerde verwerking geschikte notificatie. Dit betekent dat we te maken hebben met een representatie van een gevolg.

Bij die representaties horen verschillende verstrekkingspatronen. Sommige leveringen worden pas verstrekt als daarom wordt gevraagd, bijvoorbeeld na aanroep van een bevragingen-interface (API). Andere leveringen worden juist proactief aangeboden, zoals een systeemnotificatie die naar aanleiding van registratie van een nieuw gevolg automatisch wordt verzonden.

Dat we met het doel anderen daarover te informeren op basis van een gevolg verschillende representaties creëren, rechtvaardigt het toevoegen van een vierde vierde begrip aan de drie concepten die we hierboven opsomden:

4. Levering: een voor consumptie aangeboden doel(groep)specifieke communicatie-uiting over een gevolg.

Met de toevoeging van levering is onze conceptualisatie van overheidshandelen bij publieke dienstverlening in de uitvoering compleet. Hieronder is dit proces volledig geïllustreerd.

Voorwaarden voor succesvol consumeren

Dat overheden elkaars leveringen gebruiken als grondstof voor het produceren van nieuwe - eigen - gevolgen klinkt vanzelfsprekend, maar brengt voor zo’n levering wel eisen met zich mee.

Een leveringsconsument heeft bijvoorbeeld duidelijkheid nodig over de bedoeling en betekenis van zo’n levering, zodat bepaald kan worden of de eigen taken of bevoegdheden het nodig maken naar aanleiding daarvan te handelen. Dit betekent dat bij leveringen verschillende aspecten van interpreteerbaarheid een rol kunnen spelen: wat is de boodschap, op welk moment heeft die betekenis, voor wie is die bedoeld, en in welke omstandigheden is die toepasbaar? Dit noemen we de context van de levering.

Producenten van leveringen kunnen interpretatieverwarring over leveringen deels voorkomen door die te laten aansluiten bij taal en model van consumerende bounded contexten waarbinnen gegevens ontvangen en verwerkt gaan worden.

Onderdeel van deze contextinformatie is ook twijfel over de juistheid van, of andere kwaliteitsvoorbehouden bij de inhoud van de levering. Zulke twijfels kunnen zijn ontstaan na constatering van (vermoedelijke) fouten door een leveringsconsument. Die moet dergelijke fouten dan wel kunnen melden, wat vraagt om betwistbare leveringen - of met andere woorden: leveringen waarop teruggemeld kan worden, waarop onderzoek, en indien nodig, correcties kunnen volgen.

Leveringen moeten daarnaast een onveranderlijk karakter hebben. Het vandaag opvragen van geleverde gegevens moet ook morgen of over een aantal jaar - zolang tenminste dezelfde vraag gesteld wordt - hetzelfde resultaat opleveren. Dit noemen we de herhaalbare vraag.

Toegangsbeperkingen zijn een laatste punt van aandacht. Bijvoorbeeld vanwege het waarborgen van de privacy van betrokkenen mogen sommige afnemers misschien niet kennisnemen van een volledig gevolg - zoals een adoptie - terwijl onderdelen daarvan - zoals een verandering van ouderschap - voor hen wel relevant zijn.

Bespiegeling over de modellering van gevolgen

Bovenstaande roept vragen op over wat nu precies de omvang en granulariteit van gevolgen bepaalt. Hierboven noemden we als uitgangspunt het (handelings)resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt. Dit impliceert dat alléén vanuit het proces dat ze produceert wordt bepaald wat als gevolg wordt beschouwd. Als vervolgens echter blijkt dat afnemers in heel veel gevallen slechts recht hebben een deel van een gevolg in te zien - zoals in het adoptievoorbeeld - is de vraag gerechtvaardigd of voor dat gevolg niet een te grote omvang is gekozen. De metafoor van de januskop helpt hier ook: het gedeelde brein, waarin de belangen van gevolgenproducent en leveringsconsument samenkomen, moet zorgen voor een logische begrenzing van het gevolg.

De ‘datalaag’ van de overheid

Nu we een beeld hebben van hoe publieke dienstverlening binnen de overheid werkt en beschikken over een bijbehorend begrippenkader, kunnen we overstappen naar het onderwerp van deze handreiking: registers. We beginnen die gezamenlijk te beschouwen, als ‘datalaag van de overheid’.

Tekortkomingen van bestaande registers

Bestaande overheidsregisters zijn op basis van ondertussen vaak decennia-oude techniek en inzichten primair ontworpen om administratieve processen efficiënter te maken. Deze inzichten en techniek zijn verrassend veerkrachtig en toekomstigbestendig gebleken. Maar dit vereiste ook dat bijvoorbeeld bijhouding en levering in één model werden samengebracht.

Dit compromis blijkt terugblikkend ongemakkelijk. Registers bevatten daardoor presentaties die niet helemaal voldoen aan de behoeften van afnemers, maar tegelijkertijd vanuit bijhoudingsperspectief ook niet de essentie - ofwel gevolgen representeren.

Veel registers bedienen alle afnemers op basis van één generieke gegevensset. Omdat in dat geval geen onderscheid wordt gemaakt naar taken en bevoegdheden, krijgen sommige afnemers meer informatie dan nodig - en soms zelfs toegestaan - is, terwijl anderen juist gegevens missen.

In veel registers wordt bovendien contextinformatie niet (volledig) vastgelegd. Informatie over de aanleiding van een wijziging, de juridische grondslag of de handelingen die tot het resultaat hebben geleid ontbreekt of is onvolledig. Voor een afnemer is daardoor niet altijd duidelijk wat een gegeven precies betekent, voor welke situatie het geldt en hoe het moet worden geïnterpreteerd.

Historie wordt vaak slechts beperkt bijgehouden. Soms is alleen de actuele toestand beschikbaar, in andere gevallen is die beperkt tot eendimensionale wijzigingshistorie. En als wel volledige historie in twee dimensies wordt bijhouden, zorgt het toestaan van wijzigingen in de registratietijdlijn (bijvoorbeeld als gevolg van rechtelijke uitspraken) dat het stellen van een gegarandeerd herhaalbare vraag moeilijk niet mogelijk is.

Ook het betwisten en corrigeren van gegevens is vaak onvolledig ondersteund. Wanneer een afnemer een mogelijke fout constateert, bestaat er meestal geen gestandaardiseerde manier om die constatering zichtbaar te maken voor andere afnemers. Terugmeldprocessen bestaan meestal wel op organisatieniveau, maar de koppeling tussen deze processen en de registers die betwiste gegevens leveren zijn niet altijd goed ingericht.

Een combinatie van bovenstaande zorgt ervoor dat het vaak niet mogelijk is mutaties met terugwerkende kracht uit te voeren. Dit betekent dat fouten die het nodig maakt niet-actuele informatie te corrigeren, niet kunnen worden hersteld. Dit betekent dat betrokkenen blijvend met de gevolgen van foute gegevens geconfronteerd worden.

Deze beperkingen waren lang onvermijdelijk en werden, afgezet tegen geboekte efficiëntiewinst, als acceptabel beschouwd. Maar nu overheidsorganisaties de ambitie hebben (zie hieronder) veel vaker elkaars gegevens gebruiken als grondstof voor nieuwe besluiten en gevolgen, en dat bovendien bij de bron te doen, wordt het belangrijk dat leveringen ook context, betwistbaarheid, reproduceerbaarheid en passende toegang ondersteunen.

Overheidsbrede ontwikkelingen

De De Architectuur Digitale Overheid 2030 onderkent de belangrijke rol van data bij (proactieve) beleidsontwikkeling en dienstverlening van de overheid. Om wildgroei en kwaliteitsverlies te voorkomen, willen we die data liever vanuit een aangewezen bron hergebruiken dan (steeds) opnieuw inwinnen.

Bovenstaande lukt alleen als partijen in de FDS-rol van data-aanbieder hun data zodanig kunnen vastleggen en beschikbaar stellen dat die een bruikbare basis vormt voor FDS-datadiensten.

Als het gaat om vernieuwing van het fundament van de overheidsinformatievoorziening wordt ook verder in de toekomst gekeken. De geautomatiseerd uitvoerbare regels van Regelrecht zouden veel gegevensopslag overbodig kunnen maken. En Chronolexografie is een manier om heel gestructureerd rechtstoestanden - oftewel “hetgeen juridisch gezien het geval is (geweest)” - vast te leggen en te reproduceren.

Helpende uitgangspunten

De hierboven beschreven aandachtspunten en ontwikkelingen beschrijven een deel van de context waarbinnen deze handreiking tot stand kwam. Onderstaande uitgangspunten helpen te begrijpen hoe we ons tot die context verhouden en wat deze handreiking wel en niet beoogt.

Gegevens betrekken ‘bij de bron’

We kopiëren te veel gegevens zonder mechanismen om kwaliteit en actualiteit van die kopieën te waarborgen. Deze handreiking is erop gericht de noodzaak voor het maken van gegevenskopieën bij uitvoeren van publieke dienstverleningsprocessen waar dat haalbaar is weg te nemen.

Onderscheid maken tussen proces en resultaat

We erkennen een verschil tussen formeel beschreven of informeel uitgevoerde processen en daaruit voortkomende resultaten. Een proces vertelt hoe de overheid handelt. Als resultaat daarvan ontstaat iets met betekenis of waarde. Deze handreiking gaat niet over procesautomatisering, maar beschrijft op welke manier we de resultaten daarvan zo goed mogelijk kunnen vastleggen en beschikbaar stellen.

Onderscheid maken tussen gevolg (betekenis) en levering (representatie)

Als het gaat om bovengenoemde resultaten, erkennen we het verschil tussen betekenis van een resultaat - dat we gevolg noemen, en communicatie daarover, waarvoor een representatie (levering) nodig is. Het verenigen van deze concepten in één artefact - bijvoorbeeld een akte - draagt bij aan ontstaan van ‘vormfouten’ (bijvoorbeeld het onjuist overnemen van een juiste conclusie in een besluit of databasetabel) in de hand.

Hoewel sprake is van een afhankelijkheidsrelatie - de levering is afgeleid van het gevolg - zijn ze vanuit verantwoordingsperspectief van even groot belang. Het gevolg betekenis als ‘kern’ van wat bedoeld werd, en de levering als hetgeen op basis waarvan anderen (mogelijk) hebben gehandeld.

Bij deze conceptualisatie past de metafoor van de januskop of het hoofd met twee gezichten. Janus deelt één brein - dus een gedeelde, onderling verbonden hoeveelheid kennis, met daarop twee perspectieven, ingegeven door twee paar zintuigen. Het ene paar blikt terug op een proces dat een bepaald resultaat - of gevolg opleverde, terwijl het andere paar vooruit kijkt, richting door leveringen van die gevolgen in gang gezette vervolghandelingen.

Janus(kop)

Afbeeldingscredit Igor Gordeev

In de beeldhouwkunst en schilderkunst is een januskop een hoofd met zowel aan de voorzijde als aan de achterzijde een gezicht. Het is genoemd naar de Romeinse god Janus, die in een van zijn verschijningsvormen twee gezichten had.

Janus was een Romeinse god die heerste over alle begin en overgang. Vóór hij door Jupiter tot god met twee gezichten gemaakt werd, heerste hij volgens legende als koning over Latium. Daar werd hij beschouwd als stichter van het maatschappelijke leven en van de maatschappij, die de mensen verloste uit hun barbaarse toestand en tot een ordelijk leven bracht.

Onderscheid maken tussen bijhouding en levering

Gelijktijdig erkennen van het verschil tussen, en gelijkwaardig belang van gevolg en levering, vraagt in registerarchitectuur om onderscheid tussen bijhouding en levering. Dit maakt het mogelijk om op de specifieke informatiebehoefte van bepaalde afnemers (of leveringsconsumenten) toegesneden informatieproducten te leveren.

De wens onnodige kopieën te vermijden vraagt erom deze perspectieven op één onderliggende werkelijkheid beide als bron met zelfstandig bestaansrecht te beschouwen. Aandachtsgebieden voor betrouwbare registers zijn dan ook voor beide perspectieven relevant. De begrippen gevolgenjournaal en leveringenstaat gebruiken we om de gegevensverzamelingen die bij de perspectieven horen te onderscheiden.

Aandachtsgebieden

Als we registers werkelijk capabel en betrouwbaar willen maken, moeten we vanaf het eerste ontwerp met een aantal belangrijke aandachtsgebieden rekening houden.

Deze aandachtsgebieden worden hieronder in algemene zin beschreven. In de hoofdstukken hierna beschrijven we hoe ze specifiek doorwerken in het gevolgenjournaal en de leveringenstaat.

Terugmelden

Terugmelden is het proces waarbij een afnemer van gegevens aan de bronhouder meldt dat hij twijfelt aan de juistheid van geleverde gegevens.

De term is afkomstig uit het stelsel van basisregistraties. Binnen dat stelsel zijn overheidsorganisaties verplicht twijfel over de juistheid van gegevens aan de bronhouder te melden.

Functioneel is het principe echter breder toepasbaar: overal waar gegevens worden gedeeld tussen een beheerder en afnemers, kan terugmelden als mechanisme dienen om de kwaliteit van die gegevens gezamenlijk te bewaken.

Onderzoeken

Na een terugmelding moet de bronhouder beoordelen of de gemelde twijfel gegrond is. Daartoe onderzoekt hij of de betreffende projectie inderdaad onjuist is, en zo ja, of die onjuistheid te herleiden is naar een of meer onjuist geregistreerde gevolgen - en mogelijk andere daarvan weer afgeleide projecties.

Dit onderzoek vindt plaats buiten het register, bijvoorbeeld in een zaaksysteem of ander procesondersteunend systeem. Gedurende het onderzoek kunnen in het register wel indicaties van twijfel worden aangebracht, zodat afnemers weten dat over de juistheid van bepaalde projecties of gevolgen onzekerheid bestaat.

Corrigeren

Wanneer het onderzoek onjuistheden aan het licht brengt, corrigeert de bronhouder de betrokken gegevens.

Verwerkingsverantwoording

Een betrouwbaar register legt niet alleen vast wat er is gebeurd, maar ook waarom en hoe dat is gebeurd. Deze contextinformatie hoort bij het aspect dat we verwerkingsverantwoording noemen. Verwerkingsverantwoording stelt afnemers in staat de betekenis en herkomst van een gegeven te beoordelen, en maakt het mogelijk fouten te herleiden en te herstellen. Verwerkingsverantwoording valt in drie onderdelen uiteen:

1. aanleiding
2. legitimering
3. verklaring

Aanleiding

De aanleiding beschrijft wat de productie van een gevolg in gang heeft gezet. In veel gevallen is dat een eerder in de keten geproduceerd gevolg. Als zo’n voorliggend gevolg ontbreekt, is de aanleiding gelegen buiten de overheidscontext, bijvoorbeeld in een handeling of melding van een burger of bedrijf.

Legitimering

Met legitimering bedoelen we het wettelijk of beleidskader dat diende als grondslag voor de productie van een gegeven.

Verklaring

Met de verklaring wordt duidelijk gemaakt op welke manier het legitimerende kader in een specifieke situatie is gehanteerd. Denk daarbij aan informatie over toegepaste procedures, versieaanduidingen van gebruikte algoritmes of de motivatie van een ambtenaar die op basis van discretionaire bevoegdheid van een norm afweek.

Geldigheid

Geldigheid beschrijft wanneer en op wiens gezag iets ‘gold’ of beschouwd werd als ‘juist’ of ‘waar’.

Geldigheid wordt bepaald door het administratieve domein dat gegevens registreert. In tegenstelling tot de registratiecontext is geldigheid een onveranderlijk of ‘intrinsiek’ onderdeel van hetgeen geregistreerde gegevens beschrijven. Gegevens die in meerdere registers gedupliceerd zijn, hebben als logisch gevolg hiervan in ieder van die registers dezelfde geldigheid.

Geldigheid als administratief construct

Hoewel het woord ‘intrinsiek’ anders kan doen lijken, is geldigheidstijd een administratief construct. Niemand zal kersverse ouders immers een kaartje sturen om te ze te feliciteren met de nieuwverworven geldigheid van hun pasgeboren baby. In de ‘echte’ wereld, waar de dingen die we met behulp van gegevens beschrijven daadwerkelijk bestaan, komen we dus hooguit gebeurtenissen tegen die aanleiding geven om gegevens in administratieve context als geldig te gaan beschouwen. In het geval van een persoon kan dat een geboorte zijn, maar bijvoorbeeld ook een immigratie als iemand pas op latere leeftijd in beeld komt van ‘onze’ administratieve werkelijkheid. Overlijden zou aan de andere kant een reden kunnen zijn om de geldigheid van een persoon te beëindigen.

Registratiecontext

Registratiecontext beschrijft wanneer en door wie - welke medewerker of afdeling - iets is vastgelegd.

In tegenstelling tot geldigheid is de registratiecontext niet onverbrekelijk gebonden aan een set gegevens. De registratiecontext wordt ten opzichte van daarvan daarom ook wel als ‘extrinsiek’ beschouwd.

De registratiecontext wordt bepaald en vastgelegd door het systeem waarin gegevens worden bijgehouden. Dit kan een IT-systeem zijn, maar ook het sociotechnische systeem waarin mensen en IT-systemen samenwerken om taken uit te voeren. Dit betekent dat gegevens die in meerdere systemen zijn vastgelegd, in ieder van die systemen verschillende registratiecontexten hebben.

Bespiegeling over tijd

De aandachtsgebieden geldigheid en registratiecontext zijn sterk verbonden met het concept tijd. Over dit onderwerp in relatie tot registers zijn boekenkasten vol geschreven. Daarin worden eindeloos veel verschillende ‘tijdsoorten’ of ‘tijdsassen’ genoemd. Binnen deze handreiking maken we primair onderscheid op basis van wie of wat de waarde van een tijdstip of periode bepaalt.

Bij domeintijd wordt de temporele waarde bepaald op basis van de werkelijkheid, de regelgeving of de bestuurlijke context waarbinnen een registratie werkt. Geldigheidstijd is het bekendste voorbeeld, maar ook ‘event occurrence time’ - het tijdstip waarop een gebeurtenis plaatsvond - valt hieronder, evenals juridische inwerkingtredingsdata of beslistermijnen. Domeintijd is intrinsiek, dus onlosmakelijk onderdeel van en verbonden met de gebeurtenis of toestand die een registratie beschrijft.

Bij systeemtijd wordt de waarde bepaald door het IT- of sociotechnische systeem dat gegevens verwerkt en opslaat. De registratietijd is hiervan het enige voorbeeld: het systeem legt vast wanneer een gegeven beschikbaar kwam, ongeacht wat er inhoudelijk is gebeurd. Systeemtijd is daarmee per definitie extrinsiek; het zegt iets over de verwerking van een registratie binnen een systeem, maar niets inhoudelijks over de gebeurtenis of toestand die een registratie beschrijft.

Zekerheid

Met zekerheid bedoelen we de mate waarin een registratie als feitelijk juist wordt beschouwd. Zekerheid is om twee redenen geen eenvoudig begrip. Ten eerste is het gradueel: een registratie kan geverifieerd en onbetwist zijn, maar ook onbevestigd, in onderzoek, of actief betwist. Ten tweede is zekerheid niet altijd gedeeld: verschillende partijen kunnen op hetzelfde moment een verschillend oordeel hebben over de juistheid van dezelfde registratie.

(On)zekerheid werkt diep door in ketens of netwerken. Als een bedrijfsregel bij het afleiden van een resultaat steunt op een gegeven waaraan getwijfeld is, is immers ook dat resultaat onzeker. Als datzelfde resultaat door andere partijen in de keten gebruikt weer wordt gebruikt als basis voor eigen handelingen, kunnen weer nieuwe op onjuiste gronden gefundeerde resultaten ontstaan, enzovoorts.

Onttrekking

Onttrekking is het logisch ongedaan maken van een registratie in een overheidsregister, zonder dat de bijbehorende gegevens fysiek worden verwijderd.

In een betrouwbaar register verwijderen we geen gegevens die we mogelijk ooit hebben geleverd. Fysiek verwijderen levert op conceptueel niveau geschiedvervalsing op en breekt op functioneel niveau de garantie op de herhaalbare vraag. Om historische vastleggingen gegarandeerd te behouden, hanteren we voor het gevolgenjournaal en de leveringenstaat een append only-patroon: gegevens worden alleen toegevoegd, nooit overschreven of verwijderd.

Aanleidingen voor onttrekking

Om de reden voor het onttrekken van gegevens goed te begrijpen, is het eerst nodig om onderscheid aan te brengen tussen twee verschillende vormen van juistheid:

1. Feitelijke juistheid verwijst naar de mate waarin geregistreerde gegevens een accurate weergave vormen van de fysieke, juridische of administratieve werkelijkheid die ze representeren.
2. Systeemjuistheid verwijst naar de mate waarin het register gegevens verwerkt op de manier waarop wie die verwerking heeft gespecificeerd of bedoeld had, ongeacht of die gegevens zelf feitelijk juist waren.

Vervolgens kunnen we (tenminste) de volgende aanleidingen onderscheiden:

• Feitelijk onjuiste gegevens aangeboden. Door verkeerde informatie, een vergissing of een technisch mankement zijn gegevens aan het register aangeboden die feitelijk onjuist zijn, op basis waarvan feitelijk onjuiste gevolgen en mogelijk feitelijk onjuiste projecties zijn geproduceerd.
• Onjuiste verwerking geconstateerd. Door een gebrek aan systeemjuistheid zijn feitelijk juiste gegevens niet op de bedoelde manier verwerkt, waardoor feitelijk onjuiste gevolgen en/of projecties zijn geproduceerd.
• Verzoek tot vergeten. Een burger heeft op basis van de Algemene verordening gegevensbescherming verzocht een feitelijk juiste registratie te laten verwijderen.
• Bewaartermijn verlopen. De archiefwettelijke bewaartermijn voor een registratie is verstreken.
• Nieuw begrip van feitelijke juistheid. Naar aanleiding van juridische of beleidsmatige heroverweging kunnen gegevens die eerder als feitelijk juist werden beschouwd niet langer als zodanig worden aangemerkt.
• Ethische of maatschappelijke overweging. Het behouden van een feitelijk juiste registratie wordt op basis van ethische of maatschappelijke overwegingen als ongewenst beschouwd.

Gevolgen van onttrekking

Onttrokken gevolgen zijn niet langer beschikbaar voor ‘normaal’ gebruik. Onttrokken gevolgen worden niet meer getoond in standaardprocessen, rapportages of openbare inzage en zijn niet langer beschikbaar voor normaal gebruik door ambtenaren, burgers of geautomatiseerde systemen.

Bespiegeling: is onttrekking een gevolg?

De vraag is of onttrekking zelf als gevolg moet worden beschouwd. Het alternatief is onttrekking te behandelen als een abstract supertype - een op technisch niveau geïmplementeerd begrip dat in de administratieve praktijk verschijnt in herkenbaarder vormen zoals correctie, herstel, herroeping of vergeten in de context van het AVG-recht op vergetelheid.

Gevolgenjournaal

Betekenis en doel

Het gevolgenjournaal is een volledige en onveranderlijke vastlegging van alle gevolgen die binnen een register werden geproduceerd, in de volgorde waarin die gevolgen ontstonden. De naam is ontleend aan het scheepsjournaal, waarin door nauwkeurige waarnemers volledig, chronologisch, zonder weglating én zonder oordeel wordt genoteerd wat is waargenomen.

Het gevolgenjournaal richt zich uitsluitend op het nauwkeurig vastleggen van wat er is gebeurd: observaties, besluiten en registraties. Afnemers en hun informatiebehoeften spelen daarin geen rol. Het principe is: negeer de afnemer. Dit uitgangspunt geldt zo sterk mogelijk, maar de gevolgen vormen wel de grondstof op basis waarvan de informatiebehoefte van afnemers - voor zover realistisch en redelijk - moet worden ingevuld.

Gevolgen leggen zonder oordeel vast wat er is waargenomen of besloten. Ze drukken daarmee de intentie van een observatie of besluit uit – niet het effect ervan op de toestand van het register. Gevolgen zijn temporeel atomair: ze gebeuren op één moment, en hebben (dus) geen duur. Geboortes, verhuizingen of huwelijken markeren geen toestand, maar beschrijven de verandering die van de ene toestand leidt naar de volgende. Gevolgen zijn daarmee een voorbeeld van wat transitional modeling of overgangsmodellering wordt genoemd.

Vraagstuk: gevolgen feitelijk of administratief formuleren?

Gevolgen kunnen we op twee manieren formuleren:

1. Feitelijk, beschouwd vanuit de werkelijkheid waarop dat handelen betrekking heeft - ongeacht de wijze waarop het administratief is verwerkt of vastgelegd. Bijvoorbeeld "persoon p1 geboren".
2. Administratief, beschouwd vanuit de administratieve context waarbinnen dat handelen heeft plaatsgevonden - dat wil zeggen: de registratie, vastlegging of formalisering van een feitelijk gevolg binnen een specifiek overheidsproces. Bijvoorbeeld: "geboorte persoon p1 geregistreerd".

Welke van de twee we kiezen heeft effect op de aandachtsgebieden geldigheid en zekerheid. Zie de toelichting onder de corresponderende koppen.

Aandachtsgebieden in het gevolgenjournaal

De eerder genoemde aandachtsgebieden hebben impact dan wel invulling in het gevolgenjournaal:

Terugmelden

Terugmelden gebeurt door afnemers op een projectie die onderdeel is van de leveringenstaat, en dus níet op een gevolg in het gevolgenjournaal.

Onderzoeken

Onderzoek(en) naar aanleiding van een terugmelding gebeuren buiten het register. Zo’n onderzoek zelf leidt dus niet tot nieuwe gevolgen in het gevolgenjournaal. Wel kan uit onderzoek blijken dat bij vermoedelijk onjuiste gevolgen binnen het register indicaties van verminderde zekerheid over de juistheid moeten worden aangebracht.

Deze indicaties kunnen in eerste instantie aangebracht worden op gegevens in de leveringenstaat (waar een terugmelding op gedaan is), maar kunnen (bijvoorbeeld lopende het onderzoek) verplaatst worden naar indicaties op gevolgen (die dientengevolge alle leveringenstaten raken waar het geïndiceerde gegeven gebruikt wordt). Een dergelijke indicatie kan ook als basis dienen van correctie.

Corrigeren

Het gevolgenjournaal is append only: gevolgen worden alleen toegevoegd, nooit overschreven of verwijderd. Correctie betekent dus altijd het toevoegen van een nieuw gevolg dat een of meerdere eerdere gevolgen ongedaan maakt of herziet.

Bij of na correctie zijn er twee fundamentele vragen aan de orde:

1. Hoe had het moeten zijn; of: Hoe had mijn gevolgenjournaal moeten zijn?
2. Wat is er (precies) gecorrigeerd en waarom?

Om beide vragen te kunnen beantwoorden dient een correctiegevolg idealiter dan ook 3 dingen te bevatten:

1. Welke gevolgen worden gecorrigeerd?
2. Hoe had de gevolgentijdlijn eruit moeten zien voor deze periode.
3. De exacte hersteloperatie en context

Bij voorkeur gebeurt dat in de taal van de bounded context; een gevolg als "emigratie p1 herroepen" maakt de bedoeling direct duidelijk. Deze aanpak heeft echter een praktische beperking: het is niet goed mogelijk om vooraf alle situaties te voorzien waarin correctie nodig kan zijn. Bovendien vereist ieder domeinspecifiek correctiegevolg dat de bijbehorende bedrijfsregels worden bepaald en geconfigureerd, wat bij een laag correctievolume onevenredig veel ontwerplast met zich meebrengt.

Daarom kan het soms nodig zijn generieke correctiegevolgen te introduceren die domeingevolgen ‘passeren’ en direct inwerken op de begrippen uit de leveringenstand, zoals bijvoorbeeld "verblijfsadres p1 gecorrigeerd". Belangrijk is dat zulke correcties altijd in het gevolgenjournaal worden opgenomen en transactioneel worden afgehandeld, zodat het journaal consistent blijft.

In het uitzonderlijke geval dat niet meer te reconstrueren is hoe een bepaalde toestand is ontstaan, maar wel bekend is hoe die eruit zou moeten zien, kan het nodig zijn op basis daarvan een nieuwe historie op te bouwen. Dit soort ingrijpende correcties moet zoveel mogelijk beperkt blijven omdat daarop nauwelijks (al dan niet geautomatiseerde) integriteitscontrole mogelijk is en op basis daarvan moeilijk geleverd kan worden.

Verwerkingsverantwoording

Op basis van het onderscheid tussen proces en resultaat willen we het register niet de wereld van procesuitvoering in trekken. Maar we willen afnemers wel in staat stellen door het register geleverde gegevens op onder andere betekenis, kwaliteit en juistheid te beoordelen. Verwerkingsverantwoording is daardoor binnen het gevolgenjournaal een belangrijk aandachtsgebied.

Aanleiding

De aanleiding beschrijft wat de productie van een gevolg in gang heeft gezet. In veel gevallen is dat een eerder in de keten geproduceerd gevolg. Of meer precies: een levering, afkomstig uit een voorliggende bounded context, die als signaal is ontvangen en binnen de ‘eigen’ bounded context aanleiding gaf tot handelen. Als zo’n voorliggend gevolg ontbreekt, is de aanleiding gelegen buiten de overheidscontext, bijvoorbeeld in een handeling of melding van een burger of bedrijf.

Vragen bij het vastleggen van aanleiding in het gevolgenjournaal

1. Wat slaan we op? Tenminste een verwijzing naar het voorliggende gevolg of de externe aanleiding, inclusief de partij die verantwoordelijk was voor productie van die aanleiding. Omdat hierbij grenzen tussen bounded contexten worden overgestoken, moeten contextoverstijgende afspraken worden gemaakt over vorm, inhoud en uitwisseling van deze verwijzing.
2. Wat doen we met bijlagen? Aanleidingen kunnen gepaard gaan met ondersteunende documenten, zoals een aanvraagformulier of een bijgevoegd bewijs. Deze bijlagen zijn niet altijd op een volledig gevolg van toepassing. Een te complexe koppelstructuur tussen bijlagen en gegevens is moeilijk te begrijpen en te onderhouden. De vraag is of zulke complexiteit altijd noodzakelijk is, of dat een eenvoudiger benadering (aparte documentopslag waarnaar voor aanleiding verwezen kan worden) volstaat.

Legitimering

Voor ieder gevolg wordt een zo gedetailleerd mogelijke verwijzing naar het wettelijk of beleidskader dat diende als grondslag voor de productie daarvan vastgelegd.

Verklaring

Voor ieder gevolg wordt vastgelegd hoe het legitimerende kader in de betreffende situatie is toegepast. Deze verklaring omvat ten minste:

• een verwijzing naar de gevolgde procedures of - bij geautomatiseerde verwerking - de versie van het gebruikte algoritme;
• de ambtenaar of organisatieafdeling die verantwoordelijk was voor de productie van het gevolg, en
• indien van toepassing: de motivatie waarom op basis van discretionaire bevoegdheid van een norm is afgeweken.

Registratiecontext

Voor ieder gevolg wordt het moment van vastlegging in het gevolgenjournaal vastgelegd.

Geldigheid

Als we kijken naar temporele concepten die bij gegevensopslag een rol spelen, kunnen we in het gevolg een specifieke vorm van een event herkennen. Zo’n event wordt beschreven als een ogenblikkelijk feit, ofwel iets dat in één moment plaatsvindt.

Dit temporeel atomaire karakter maakt dat het gevolg geen (geldigheids)duur heeft. In plaats daarvan kent het één door het domein bepaald moment, dat samenvalt met het moment waarop het gevolg in de echte wereld een verandering tot stand bracht. Dit moment noemen we "gebeurd op".

In veel gevallen (maar niet alle, zie toelichting hieronder) kan van het gebeurd op-moment bij een gevolg een geldig vanaf-moment in een projectie worden afgeleid. Ervan uitgaande dat we het moment van geboorte beschouwen als startpunt voor een geldige inschrijving, kan bijvoorbeeld van het gevolg persoon p1 geboren | gebeurd op 18-07-1985 de volgende projectie worden afgeleid:

Impact van feitelijk of administratief formuleren op aandachtsgebied geldigheid

• Bij feitelijke formulering is het ‘gebeurd op’-moment een logisch startpunt voor geldigheidsperiode(s) in leveringen, terwijl
• bij administratieve forumlering weliswaar sprake blijft van een domeindatum, maar het ‘gebeurd op’-moment meer neigt naar het karakter van een ‘geregistreerd op’-moment.

Zekerheid

Of bij een gevolg twijfel over de feitelijke juistheid mogelijk of zinvol is, hangt af van de wijze waarop het gevolg is geformuleerd (zie toelichting hieronder). Voor zover dit wel mogelijk en zinvol is, maakt het register het mogelijk een zekerheidsindicatie vast te leggen, en biedt het gebruikers de mogelijkheid om hierop te reageren: door een regel situationeel te overrulen, door de verwerkingsengine onzekerheid te laten signaleren, of door bedrijfsregels expliciet te laten omgaan met onzekerheid.

Impact van feitelijk of administratief formuleren op aandachtsgebied zekerheid

• Bij feitelijke formulering beschrijft het gevolg iets wat buiten de context van het register is gebeurd. Deze gebeurtenis kan feitelijk waar, maar ook feitelijk onwaar blijken te zijn. Als we gevolgen feitelijk modelleren, lijkt het dus nodig om aan de juistheid van een gevolg te kunnen twijfelen door daaraan zekerheidskenmerken te verbinden, terwijl
• bij administratieve formulering het gevolg gaat over iets dat door registratie van gevolg zelf feitelijk waar wordt - de geboorteregistratie ontstaat immers door registratie van het bijbehorende gevolg. In dit geval ontstaat de feitelijke juistheid door registratie van het gevolg zelf, en lijkt het niet zinvol om aan de juistheid van een gevolg te kunnen twijfelen.

Onttrekking

Iedere onttrekking begint in een gevolg, tenzij de fout uitsluitend zat in de wijze waarop leveringen uit het gevolgenjournaal werden afgeleid (zie leveringenstaat).

Los van de mate waarin een onttrekkingsgevolg aansluit bij de taal van de bounded context (zie corrigeren) beschrijft zo’n gevolg altijd de onttrekkingscontext. Die maakt achteraf reconstrueerbaar waarom en wanneer een gevolg niet langer beschikbaar is en omvat tenminste:

• een verwijzing naar het onjuiste, te onttrekken gevolg;
• het tijdstip waarop tot onttrekking is besloten (‘gebeurd op’);
• de reden voor de onttrekking, en
• een verwijzing naar het onderzoeksdossier waarin meer informatie over de aanleiding voor onttrekking terug te vinden is.

Als een onttrekking betrekking heeft op identiteitdragende kenmerken van een gevolg of levering, wordt het volledige gevolg of de volledige levering onttrokken. Bij niet-identiteitshoudende kenmerken kan onttrekking beperkt blijven tot die kenmerken, mits de implementatie dit technisch toelaat.

Ontwerpafwegingen voor het gevolgenjournaal

In het ontwerpen van gevolgen in het gevolgenjournaal zijn een aantal afwegingen van belang. Welke het zwaarst wegen, verschilt per domein. De onderstaande afwegingen bieden houvast bij het maken van weloverwogen keuzes.

• Intentie: Gevolgen dienen de intentie van de observatie, het besluit of de vastlegging uit te drukken
• Negeer de afnemer als het gaat om vorm en omvang: Het domein bepaalt onafhankelijk van afnemerbehoeften de vorm en omvang van gevolgen die binnen de bounded context worden geproduceerd
• Respecteer de afnemer als het gaat om inhoud: Alle gevolgen die een bounded context produceert samen, moeten voldoende informatie leveren om (redelijke en realistische) afnemersbehoefte aan informatie vanuit de bounded context in te kunnen vullen
• Herkenbaar voor de business: Gevolgen worden gedefinieerd op basis van functionele (business)behoefte. Dit betekent dat ieder gevolg in het gevolgenjournaal een relatie heeft met een besluit of andere betekenisvolle gebeurtenis uit de business
• Hergebruik: Gevolgen kunnen als bouwsteen worden hergebruikt binnen omvangrijkere gevolgen, zonder dat ze daarmee hun zelfstandig bestaansrecht verliezen

Vraagstuk: gevolgen feitelijk of administratief formuleren?

Om de intentie zo scherp mogelijk uit te drukken, stellen we de volgende richting voor:

1. Administratief voor fysieke waarnemingen: Gevolgen van fysieke waarnemingen of fysieke gebeurtenissen worden vanuit een register als administratieve gevolgen verwoord. Een gevolg "geboorte persoon p1 geregistreerd" prevaleren we boven "persoon p1 geboren". De persoon is namelijk ook geboren als dat niet in de registratie als gevolg is vastgelegd
2. Feitelijk voor registratieve beslissingen: Gevolgen die inherent, vaak juridische, consequenties hebben doordát deze zijn vastgelegd, kunnen als feitelijk worden uitgedrukt. Met "parkeervergunning pg1 vastgesteld" vastgelegd gevolg, ís deze parkeervergunning vastgesteld / besloten. Uiteraard kan een "bewijs voor parkeervergunning uitgegeven" volgen als een fysiek bewijs is uitgegeven

Bij het modelleren van gevolgen kunnen onder andere de volgende constructen worden ingezet:

• Naamgeving van de gevolgen drukt zoveel mogelijk de intentie en context uit, bijvoorbeeld in GeboorteGeregistreerd, NaamGewijzigdNaarAanleidingVanAdoptie, WozObjectOntstaatNaarAanleidingVanPerceelsplitsing

• Typering als attribuut van een gevolg kan additioneel gebruikt worden, bijvoorbeeld door een enumeratie in het veld typeGevolg op te nemen

• Hergebruik/decompositie/interfacing: een gevolg kan kenbaar maken dat het een bepaald type wijziging omvat, zodat afnemers daarop kunnen aansluiten zonder de specifieke aanleiding te hoeven kennen. Een verhuizing en een adoptie leiden allebei tot een adreswijziging - door beide gevolgen een gemeenschappelijk “adreswijziging”-contract te laten vervullen, kunnen afnemers die alleen de adreswijziging nodig hebben op beide reageren.

  In object-georiënteerde talen wordt dit gerealiseerd via interface of abstract class (inheritance en composition); in functionele talen via een trait. Het concept is ook herkenbaar in UML.

Voorbeeld – adoptie in de BRP

Een adoptie brengt doorgaans drie wijzigingen tegelijk met zich mee: een naamswijziging, een adreswijziging en een wijziging van gezag. Elk van die drie kan echter ook zelfstandig voorkomen – door een eigen naamskeuze, een verhuizing, of een rechterlijke uitspraak die niets met adoptie te maken heeft.

Door gevolgen als AdoptieGeregistreerdNaRechterlijkeBeschikking en VerhuizingGeregistreerd allebei de interface AdresGewijzigd te laten implementeren, kunnen afnemers die alleen de adreswijziging nodig hebben op beide reageren – zonder de onderliggende aanleiding te hoeven kennen. In het BRP-stelsel speelt ook een autorisatiereden mee: afnemers zonder adoptie-autorisatie mogen PersoonGeadopteerd niet ontvangen, maar wel AdresGewijzigd.

interface NaamGewijzigd {
    val nieuweGeslachtsnaam: String
}

interface AdresGewijzigd {
    val nieuwAdres: Adres
}

interface GezagGewijzigd {
    val nieuweOuders: List<Persoon>
}

data class AdoptieGeregistreerdNaRechterlijkeBeschikking(
    override val nieuweGeslachtsnaam: String,
    override val nieuwAdres: Adres,
    override val nieuweOuders: List<Persoon>,
    // ...
) : NaamGewijzigd, AdresGewijzigd, GezagGewijzigd

data class VerhuizingGeregistreerd(
    override val nieuwAdres: Adres,
    // ...
) : AdresGewijzigd

Leveringenstaat

Betekenis en doel

De leveringenstaat is de volledige verzameling van projecties die op basis van het gevolgenjournaal afleidbaar zijn, en waaruit concrete leveringen aan afnemers worden gegenereerd. De naam is ontleend aan gebruik van het woord staat in samenstellingen als ‘staat van dienst’ of ‘urenstaat’, waarbinnen het zoiets betekent als “geformaliseerd, geordend overzicht”.

Waar het gevolgenjournaal nauwkeurig documenteert wat er is gebeurd, beantwoordt de leveringenstaat primair vragen als “leeft persoon p1 nog?”, “wat is zijn burgerlijke staat?”, en “heeft hij gezag over p3?” Zulke vragen veronderstellen een stand (ook wel toestand of state), ofwel een beeld van de wereld dat gedurende een bepaalde periode geldig is.

Niet alle projecties beschrijven een stand. Een notificatiebericht is daarvan een voorbeeld: het informeert een afnemer over een verandering die door registratie van een gevolg is veroorzaakt. Net als het onderliggende gevolg is zo’n bericht temporeel atomair - het beschrijft wat er is gebeurd, niet welke toestand na die gebeurtenis geldig werd.

Iedere concrete levering is een op de informatiebehoefte van een specifieke afnemer of doelgroep toegesneden uitsnede uit de leveringenstaat. Daarbij kan niet alleen de actuele state worden geleverd, maar op basis van selecties over meerdere tijdsassen eventueel ook historische toestanden.

Hoe de leveringenstaat technisch wordt bijgehouden is een implementatiekeuze: daarbinnen beschikbare projecties kunnen vooraf worden berekend en opgeslagen, of op het moment van bevraging worden gegenereerd op basis van de gevraagde parameters.

De herhaalbare vraag

Zoals eerder in dit document genoemd is het een belangrijke eis van een betrouwbaar register om, zoveel als mogelijk, de herhaalbare vraag te kunnen beantwoorden. Een afnemer moet, nadat deze op tijdstip T1 een gegeven heeft opgevraagd, op tijdstip T2 nog steeds de vraag kunnen stellen wat dit gegeven op tijdstip T1 was. Een betrouwbaar register dient dit te kunnen nadat:

1. Er nieuwe gevolgen zijn toegevoegd aan de registratie.
2. Een gegeven hersteld is doordat het geldigheidstijdvak is veranderd vanwege een foutieve registratie.
3. Een softwarebug in de opvraging is hersteld waardoor de initiële opvraging fout was.

Criterium 1 en 2 introduceren bitemporaliteit in de registratie. Criterium 3 vereist dat er mechanismen zijn die het mogelijk maken softwareaanpassingen te doen met behoud van de eerdere gegevensrepresentatie.

Inherente beperkingen aan de herhaalbare vraag

Elke registratie loopt tegen inherente beperkingen aan. Zowel geldigheids- als gevolgtijdstippen hebben te maken met eventual consistency: er zit altijd tijd tussen het begin van een registratie en het einde daarvan, en er zit altijd tijd tussen een opvraging en de zichtbaarheid van deze gegevens voor de afnemer. Dit betekent dat een afnemer altijd in potentie naar verouderde informatie kijkt.

Daarnaast heeft een registratie meestal niet de volledige controle over de aflevering van informatie. Entiteiten verlaten op een bepaald moment de registratie om elders te worden gepresenteerd — in een browser, een API-response, of een ander systeem dat de registratie niet kent.

Herhaalbaarheid van opvraging is dus hoogstens te behalen tot op het niveau van de gegevensrepresentatie net voordat deze het systeem verlaat.

De tijdsassen van een projectie

• Geldigheidstijdstip — (zie geldigheid)
• Gevolgtijdstip — wanneer het gevolg in de registratie is vastgelegd
• Projectietijdstip — wanneer het snapshot zichtbaar is geworden in de projectie

Door deze drie assen te combineren in een query is tijdreizen mogelijk: “hoe zag dit gegeven eruit op tijdstip X, zoals vastgelegd op tijdstip Y, zichtbaar in de projectie op tijdstip Z?”

Aandachtsgebieden in de leveringenstaat

Terugmelden

Terugmeldingen hebben altijd betrekking op een projectie - een concrete uitsnede uit de leveringenstaat zoals die aan een afnemer is geleverd. De afnemer meldt dat hij twijfelt aan de juistheid van (een deel van) die projectie.

Omdat projecties over uiteenlopende samenstellingen van gegevens kunnen gaan en de aard van geconstateerde onjuistheden sterk kan verschillen, kan een terugmelding vele vormen aannemen. Daarbij past geen beperkend ‘terugmeldformulier’, maar (vorm)vrijheid en veel ruimte voor toelichting in vrije tekst.

Als een bronhouder regelmatig terugmeldingen van dezelfde strekking ontvangt, kan hij overwegen daarvoor een specifieke, meer gestructureerde interface aan te bieden. Dit verlaagt de drempel voor de terugmelder en maakt de verwerking aan de kant van de bronhouder efficiënter.

Een terugmelding bevat in ieder geval:

• Verwijzing naar de betreffende gegevens. De terugmelder geeft aan op welke projectie of welk onderdeel daarvan de melding betrekking heeft. Hoe die verwijzing er precies uitziet, is afhankelijk van hoe projecties identificeerbaar zijn gemaakt - bijvoorbeeld via een uniek kenmerk van de levering of een combinatie van subject en tijdstip
• Toelichting. De terugmelder beschrijft in vrije tekst wat hij als onjuist beschouwt en waarom. Dit biedt de bronhouder de context die nodig is om het onderzoek gericht te kunnen starten.
• Contactgegevens van de terugmelder. Zodat de bronhouder, indien het onderzoek daarom vraagt, contact kan opnemen voor nadere toelichting of terugkoppeling.

Open vragen

• Terugmelden is binnen het stelsel voor basisregistraties een voorwaarde voor afwijken van gegevens in de bron. Zouden terugmeldende afnemers dan voor eigen gebruik en hangende een onderzoek hun eigen, vermoedelijk juistere ‘alternatieve’ gegevens in het register moeten kunnen zetten?
• Hoe wijzen we gegevens waarover we terugmelden voor de bronhouder (historisch) onderscheidbaar aan?

Onderzoeken

Onderzoek naar aanleiding van een terugmelding vindt plaats buiten het register en leidt niet tot nieuwe projecties in de leveringenstaat. Wel kan uit onderzoek blijken dat bij vermoedelijk onjuiste projecties indicaties van verminderde zekerheid over de juistheid moeten worden aangebracht.

Corrigeren

In de meeste gevallen is een levering foutief omdat 1 of meerdere gevolgen die de basis vormen van deze projectie foutief waren. Het corrigeren van een dergelijke levering begint dan met correctiegevolgen in het gevolgenjournaal. Een correctiegevolg bevat de gevolgen ‘hoe ze hadden moeten zijn’, en op basis van deze subgevolgen kan een projectie hersteld worden. Er wordt bepaald vanaf welk moment een bestaande projectie niet langer geldig is. Die projectie krijgt daarna een vervallen op-indicatie, waarmee de levering voor actief gebruik wordt afgesloten. En daarnaast worden nieuwe projecties gemaakt, die met terugwerkende kracht de foutieve projecties bovenschrijven.

Het is ook mogelijk dat uit onderzoek blijkt dat de oorspronkelijk vastgelegde gevolgen correct waren, en dat de fout hem in de afleiding van de projectie zit. Een dergelijke softwarefout zal hersteld moeten worden, waarna een volledige of selectieve replay gedaan moet worden: Ook in dit scenario moet bepaald worden vanaf welk moment een bestaande foutieve snapshot niet langer geldig is, en dat deze moet vervallen. Foutieve snapshots worden geïdentificeerd en opnieuw opgebouwd, waarna ze toegevoegd worden aan de leveringenstaat en de oude snapshot bovenschrijven.

Verwerkingsverantwoording

Omdat projecties direct worden afgeleid uit gevolgen in het gevolgenjournaal, is verwerkingsverantwoording aan de kant van de leveringenstaat beperkter van omvang dan aan de journaalkant. De voornaamste verantwoording ligt immers al besloten in de gevolgen waarop een projectie is gebaseerd.

Aanleiding

De aanleiding verwijst naar het gevolg of de gevolgen die als basis dienden voor de productie van de projectie. Daarmee is de herkomst van een projectie altijd herleidbaar naar het gevolgenjournaal.

Legitimering

Voor zover van toepassing wordt een verwijzing vastgelegd naar het wettelijk of beleidskader dat diende als grondslag voor de productie van de projectie - bijvoorbeeld als regelgeving voorschrijft welke gegevens aan welke afnemers geleverd mogen of moeten worden.

Verklaring

De verklaring omvat een verwijzing naar het algoritme of de algoritmes die zijn gebruikt om van één of meer gevolgen een projectie af te leiden, inclusief de versie daarvan. Zo is achteraf reconstrueerbaar op welke manier de projectie tot stand is gekomen.

Registratie

Bij iedere concrete levering kan het moment van opname in de leveringenstaat worden meegeleverd. Of dat wenselijk is, hangt af van de situatie. Bij een vraag naar de actuele stand is registratietijd vaak niet relevant. In andere gevallen kan het meesturen ervan juist ongewenst zijn, omdat het informatie kan onthullen die niet met iedereen gedeeld mag worden, zoals het feit dat een correctie heeft plaatsgevonden.

Geldigheid

Bij projecties die zijn opgebouwd uit meerdere gevolgen, is het belangrijk onderscheid te maken tussen de geldigheidsdatum van de projectie zelf en de domeindatums van de gegevens daarbinnen.

De geldigheidsdatum van een projectie geeft aan vanaf welk moment deze weergave in deze vorm als ‘juist’ of ‘waar’ beschouwd wordt. Die datum zegt (dus) niets over de ouderdom van in de projectie betrokken objecten of andere daarin opgenomen gegevens.

Neem als voorbeeld de volgende gevolgen:

• woz-object w1 ontstaan | gebeurd op 15-08-1994
• belanghebbende bij woz-object w1 is p1 | gebeurd op 23-08-1994
• belanghebbende bij woz-object w1 is p2 | gebeurd op 19-10-2009
• belanghebbende bij woz-object w1 is p3 | gebeurd op 07-03-2023

Het WOZ-object bestaat al sinds 15-08-1994, maar de projectie is voor het laatst bijgewerkt naar aanleiding van het gevolg van 07-03-2023. Die datum markeert dus niet het ontstaan van het object, maar het meest recente domeinmoment dat de huidige vorm van de projectie heeft bepaald.

Zonder die toelichting riskeert een afnemer de datum verkeerd te interpreteren. Uit de projectie moet de betekenis daarom voldoende duidelijk blijken - bijvoorbeeld door de geldig vanaf-datum expliciet aan de projectie te koppelen (zie het voorbeeld hieronder), of door aan te geven dat die datum de laatste relevante wijziging in het domein betreft.

projectie l1
  geldig vanaf 07-03-2023
  woz-object w1
    eerste registratie 15-08-1994
    belanghebbenden
      p1
        start belang 23-08-1994
        einde belang 18-10-2009
      p2
        start belang 19-10-2009
        einde belang 06-03-2023
      p3
        start belang 07-03-2023

Zekerheid

Zekerheidsaanduidingen zijn in de eerste plaats relevant voor afnemers. Zekerheid moet daarom zichtbaar zijn in leveringen en (dus) onderdeel zijn van projecties.

Omdat onzekerheid diep kan doorwerken in ketens, is het niet altijd voldoende alleen de zekerheid van een projectie als geheel aan te geven. Een daartoe geautoriseerde afnemer moet ook kunnen zien welk onderliggend gevolg de bron van twijfel is, zodat hij kan beoordelen in hoeverre zijn eigen verwerking daarop steunt en hoe hij daarmee wil omgaan.

Afhankelijk van de situatie kan een afnemer er bijvoorbeeld voor kiezen een bedrijfsregel situationeel buiten werking te stellen, onzekerheid door te geven aan zijn eigen afnemers, of processen die op de gegevens steunen expliciet te laten waarschuwen wanneer zij onzekere gegevens tegenkomen.

Onttrekking

Of een onttrekking ingrijpt in het gevolgenjournaal, de leveringenstaat, of beide, hangt af van waar de fout zat. Zat deze fout uitsluitend in de wijze waarop leveringen uit het gevolgenjournaal werden afgeleid - en niet in de gevolgen zelf - dan volstaat het de afleidingswijze te corrigeren en nieuwe projecties te produceren.

In alle gevallen resulteert een onttrekking in opname van een vervallen op-moment (zie ook corrigeren) bij de door de onttrekking geraakte projecties. Daarmee wordt de projectie voor actief gebruik afgesloten, zonder dat de oorspronkelijke vastlegging verdwijnt. De onttrokken projectie blijft om de herhaalbare vraag te waarborgen technisch behouden. Die is daarna echter alleen onder specifieke voorwaarden - bijvoorbeeld voor juridisch of historisch onderzoek - toegankelijk.

Als de onttrekking betrekking heeft op identiteitsdragende kenmerken van een projectie, wordt de volledige projectie onttrokken. Bij niet-identiteitsdragende kenmerken kan onttrekking beperkt blijven tot die kenmerken, mits de implementatie dit technisch toelaat.

Resultaat voor onttrokken gegevens moet in normaal verkeer hetzelfde resultaat zijn als bevragingen van niet-bestaande gegevens.

Ontwerpafwegingen

Temporaliteit

Een belangrijke factor voor een projectie is de keuze voor wat betreft temporaliteit. Voor het kunnen beantwoorden van de herhaalbare vraag is bitemporaliteit een eis: Als ingegrepen wordt op de tijdlijn, bijvoorbeeld als gevolg van een correctie, dient de projectie nog steeds de oorspronkelijke snapshot te kunnen reproduceren.

Bitemporaliteit brengt op zichzelf echter complexiteit met zich mee die niet in alle gevallen nodig is. Wanneer een herhaalbare vraag kunnen stellen minder of niet van belang is, zou een specifieke temporele projectie op de geldigheidstijdlijn of alleen een actuele state projectie ook kunnen voldoen.

Query-complexiteit versus query-flexibiliteit

De keuze van gegevensrepresentatie van een projectie en de gewenste informatie die een afnemer blieft bepaalt de complexiteit van de (database)query die gedaan moet worden om in een informatiebehoefte te voorzien. In het voorgestelde patroon, waarin we commando’s, gevolgen en projecties van elkaar scheiden, hebben we niet meer de ‘ballast’ van de commandokant, en kunnen we onze projecties specifieker optimaliseren voor de afnemer(s).

Hier zijn echter nog steeds afwegingen in te maken. Een projectie kan dusdanig gebouwd worden op een manier dat de payload response van een query as is (in bijvoorbeeld een json of xml structuur) opgeslagen wordt in de database. We noemen dit snapshotting. Deze wijze van opslaan heeft een aantal voordelen:

1. Dit is de best mogelijke manier om de herhaalbare vraag te kunnen beantwoorden: De payload wordt as-is opgeslagen, en veranderende code beïnvloedt deze payload niet.
2. Omdat de structuur van het bericht vast ligt, ook nadat er codewijzigingen gedaan worden, kan er in terugmeldingen en onderzoeken via bijvoorbeeld xpath of jsonpath hard verwezen worden naar entiteiten of velden waarover getwijfeld wordt.
3. De (database)query is eenvoudig: Op basis van tijdstippen en een index dient een payload opgezocht te worden. Dit voorkomt grotendeels het leveren van foutieve informatie als gevolg van foutief geïmplementeerde queries.

Zeker in combinatie met bitemporaliteit zien wij snapshotting als een goede keuze voor wat betreft informatielevering. Bitemporaliteit kan, in combinatie met bijvoorbeeld ingewikkelde correcties, zeer ingewikkelde situaties opleveren die zelfs voor experts moeilijk te doorgronden zijn. Het feit dat de query eenvoudig is en de payload statisch is bij snapshotting, zelfs in bitemporele vorm, maakt dat deze projectievorm uitermate robuust is voor het beantwoorden van de herhaalbare vraag.

Snapshotting heeft echter ook nadelen: Omdat de datastructuur zo rigide vast ligt kun je moeilijker, of niet, meerdere soorten vragen beantwoorden met dezelfde projectie. Ook leent deze vorm van opslag zich minder voor joins (het combineren van verschillende payloads/entiteiten). Dit alles maakt deze structuur minder flexibel, en dit dwingt je tot het maken van veel hele afnemerspecifieke projecties.

Het meer traditionele relationele model kan naargelang behoefte dan nog steeds een goede keuze zijn. Een relationeel model, en zeker een bitemporeel relationeel model, is veel flexibeler in het kunnen beantwoorden van allerhande soorten queries. De aard van de datarepresentatie maakt echter wel de queries en de mapping naar de doelstructuur van de payload complexer, wat de herhaalbaarheid van vragen doet afnemen.

Betrouwbare modellen versus onbetrouwbare realiteit

Een goed datamodel beschrijft structuren, entiteiten en properties van een domein. Een huisnummer is een getal, terwijl een adres een straatnaam bevat als string met een maximaal aantal karakters. Deze eigenschappen worden idealiter goed gevalideerd aan de commandokant, en door dat te doen kun je duidelijke contracten afspreken met je afnemers over wat voor data je levert en in welke vorm. Dergelijke modellen bepalen databasestructuren en beperkingen voor wat betreft gegevensopslag.

De realiteit is echter vaak weerbarstig: Ooit verkeerd geïmplementeerde validaties, oude data uit migraties of veranderingen in het datamodel naar verloop van tijd kunnen er in veel gevallen voor zorgen dat de data die je hebt niet altijd voldoet aan het voorgeschreven gegevensmodel. Huisnummers met letters, te lange straatnamen… Als je gebonden bent aan het principe van het kunnen beantwoorden van de herhaalbare vraag zal deze data altijd foutief blijven.

Een relationeel model biedt duidelijkheid over het datamodel, maar is minder flexibel als het gaat om data die niet aan dit model voldoet. Er moet altijd een keuze gemaakt worden: voor zeldzame uitzonderingen dient het model aangepast te worden, of deze uitzonderingen kunnen niet verwerkt worden. Hetzelfde probleem geldt vaak voor berichtvalidaties via bijvoorbeeld XSD’s.

De consequenties van bijvoorbeeld een verhuizing niet doorgeven omdat een straatnaam te lang bevonden wordt zien wij als zeer onwenselijk. Afhankelijk van de datakwaliteit kan het dan een betere keuze zijn om data-opslag en berichtverkeer flexibeler te maken zodat afwijkingen van het datamodel wel opgeslagen en gecommuniceerd kunnen worden. Richting een afnemer kan het dan wenselijk zijn deze communicatie te doen met een extra melding: “in dit bericht voldoen we niet aan het datamodel”.

Generaliseerbaar versus specifieke implementatie

Moet nog verder ingevuld worden.

Varianten

Hieronder volgt een niet-uitputtende lijst van varianten van projecties die gebruikt kunnen worden. Elke projectievariant heeft voor- en nadelen die, afhankelijk van de use case, sterker of minder sterk gelden. Het is niet ons doel om te stellen welk van deze varianten de voorkeur geniet. Wel willen we voor- en nadelen van projectievarianten benoemen.

Transactionaliteit

Een gevolg legt 1 besluit of gebeurtenis vast. Dit besluit kan bestaan uit deelbesluiten of anderszins opdeelbare elementen, maar uiteindelijk betreft het nog steeds 1 besluit, dat (voor zover relevant voor de projectie) in zijn geheel wel of niet verwerkt dient te worden in een projectie, wat in databasetermen betekent dat een gevolg altijd in precies 1 databasetransactie verwerkt dient te worden. Het verwerken van een door de business erkend gevolg in meerdere (database)transacties kan er namelijk toe leiden dat datacorruptie optreedt: als een gevolg in twee transacties verwerkt wordt, zou de tweede transactie mis kunnen gaan, waarbij een illegale situatie ontstaat.

Registeranatomie

In het voorgaande is de context beschreven. Hieronder beschrijven we de elementen waaruit het register bestaat.

Contextuele elementen

In de afbeelding hierboven zien we allereerst de eerder geïntroduceerde elementen signaal, taak, gevolg en levering terug. Deze elementen zijn geïllustreerd als bedrijfsobject.

Om op basis van het ene het opvolgende bedrijfsobject te kunnen produceren (bijvoorbeeld een gevolg op basis van een taak) zijn handelingen (bijvoorbeeld taak uitvoeren) nodig. Deze werden eerder impliciet benoemd, maar worden nu expliciet als bedrijfsprocessen opgenomen.

De wijze waarop bedrijfsprocessen worden uitgevoerd is beschreven in het model van de bounded context. De inhoud hiervan is vaak gebaseerd op andere kaders, zoals wet- en regelgeving, beleid en bedrijfs- of uitvoeringsregels. Het bindende karakter van het model wordt benadrukt door de illustratie als contract.

Het register zelf is geïllustreerd als element van het type application-collaboration om aan te geven dat het register niet per se één applicatieve component hoeft te zijn, maar ook - en misschien zelfs meestal - kan bestaan uit een samenhangende verzameling applicatiecomponenten.

Van commando naar gevolg

De elementen die bijdragen aan de verwerking van commando’s en productie van gevolgen op basis daarvan vormen de bijhoudingskant (‘C’ in CQRS) van het register.

Het register wordt bediend door het aanbieden van commando’s. Deze data-objecten volgen altijd de taal en het model van de bounded context waarbinnen ze worden gemaakt en verwerkt.

Zowel de semantische en syntactische eisen aan commando’s als de wijze waarop die verwerkt moeten worden, zijn beschreven in het bijhoudingsmodel (data-object). Dit vormt dus het contract op basis waarvan commando’s worden verwerkt.

De Commandoverwerkingsservice (applicatieservice) controleert of aangeboden commando’s aan het contract voldoen.

Het bijhoudingsmodel en Commandoverwerkingsservice horen bij de Commandoprocessor (applicatiecomponent) die met het commando als input op basis van in het bijhoudingsmodel beschreven regels gevolgen (data-objecten) produceert.

Voor ieder bedrijfsobject van het type Gevolg dat wordt geproduceerd als resultaat van het bedrijfsproces ‘Taak uitvoeren’, wordt door het verwerken van een commando een equivalent data-object van het type gevolg geproduceerd. Dit data-object is een directe representatie van het bijbehorende bedrijfsobject. Zo registeren we (tenminste) de essentie van het overheidshandelen.

Gevolgen worden opgeslagen in de Gevolgenstore (applicatiecomponent).

De Gevolgenstore biedt toegang tot gevolgen via de Gevolgen-bevrageninterface (applicatie-interface). Deze interface wordt gebruikt door de Commandoprocessor als gegevens uit eerder vastgelegde gevolgen nodig zijn om te beoordelen welk gevolg moet worden geproduceerd.

Van gevolg naar projecties

De elementen die bijdragen aan de verwerking van gevolgen en productie van projecties op basis daarvan vormen de leveringskant (‘Q’ in CQRS) van het register.

Een gevolg dient als input voor de Gevolgenverwerkingsservice (applicatieservice).

De Gevolgenverwerkingsservice is onderdeel van de Gevolgenprocessor (applicatiecomponent) die projecties (data-objecten) produceert.

Projecties worden opgebouwd op basis van het leveringsmodel (data-object) dat beschrijft welke gegevens in welke vorm in een bepaalde projectie worden opgenomen.

Een projectie is een data-object, bedoeld om afnemers binnen en buiten ‘onze’ bounded context te informeren over wat binnen onze context is gebeurd. Een projectie kan allerlei vormen hebben: een databaserelatie, een notificatie(bericht) of een (digitaal) document.

Van het ‘setje’ Gevolgenverwerkingsservice, Gevolgenprocessor en leveringsmodel kunnen er meerdere naast elkaar bestaan. Dit betekent dat één gevolg door meerdere Gevolgenprocessoren wordt verwerkt om verschillende projecties op te bouwen.

Projecties kunnen ‘on demand’ (op aanvraag) worden gegenereerd of worden gepersisteerd. In dat laatste geval is in de vorm van een Projectiestore een extra applicatiecomponent nodig.

Toegang tot projecties wordt geleverd door de Projectietoegangsinterface (applicatie-interface).

Anders dan bij de relatie tussen Gevolg (bedrijfsobject) en gevolg (dataobject), vormt de projectie (dataobject) niet de volledige representatie van de Levering (bedrijfsobject). De projectie bestaat immers direct nadat die is geproduceerd, terwijl van een Levering pas sprake is nadat de projectie of een selectie daaruit aan iets of iemand is beschikbaar gesteld. Een Levering is daarom een voor consumptie aangeboden projectie.

Bespiegeling over projectie op basis van gevolg versus gevolg volgend op eerder gevolg

Bovenstaande laat ruimte voor discussie over de vraag in welke gevallen sprake is van een projectie op basis van een gevolg en een gevolg op basis van een eerder geproduceerd gevolg. Hiernaar kunnen we op ten minste drie manieren kijken:

1. Iedere bewering die op basis van een gevolg (geautomatiseerd) binnen het register kan worden gecreëerd, beschouwen we als projectie. De binnen het register geproduceerde bewering met een ‘happened’, of gebeurtenisachtig karakter “aanschrijfvorm van persoon p1 gewijzigd in ‘mevrouw’” op basis van gevolg “geslacht van persoon p1 gewijzigd in ‘vrouw’” wordt in dit geval beschouwd als projectie.
2. We beschouwen alleen representaties van een gevolg zelf, of daarvan afgeleide stand (of state-)informatie als projecties. Vervolgbeweringen met een ‘happened’-karakter beschouwen we als nieuwe gevolgen. De binnen het register geproduceerde bewering “aanschrijfvorm van persoon p1 gewijzigd in ‘mevrouw’” op basis van gevolg “geslacht van persoon p1 gewijzigd in ‘vrouw’” is in dit geval als nieuw gevolg. De op basis van hetzelfde gevolg geproduceerde standbewering “geslacht van p1 is ‘vrouw’” beschouwen we wél als projectie.
3. We maken helemaal geen onderscheid tussen gevolgen en projecties. Iedere nieuwe bewering zien we als gevolg.

Niet geïllustreerd: van signaal naar commando

Het verwerken van signalen kan uiteraard ook applicatief ondersteund en eventueel geautomatiseerd worden. Dit geldt zeker als een signaal in de vorm van een notificatie wordt ontvangen. Omdat zo’n notificatie (ten opzichte van het register) veelal van buiten de ‘eigen’ bounded context afkomstig is, en vanuit het register dus geen controle bestaat over de vorm en inhoud daarvan, beschouwen we de elementen in de applicatiearchitectuur die hiervoor nodig zijn niet als onderdeel van het register. Deze elementen zijn daarom hierboven niet geïllustreerd. Omdat deze stap bij contextovergangen een belangrijke rol kan spelen, is het echter wel belangrijk deze te benoemen.