De overheid als producent van gevolgen

Deze handreiking gaat over registers. 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 geldt een pluriform en complex systeem, dat we binnen de context van Uit betrouwbare bron niet in detail kunnen en willen begrijpen. Wel hebben we een conceptueel basisbegrip van de overheid nodig waaraan we de elementen en functionaliteit van onze registers kunnen relateren. Daarom beginnen we deze handreiking met een abstracte en tot publieke dienstverlening in de uitvoering begrensde conceptualisatie van de overheid. Die vertrekt vanuit het idee van overheid als producent van gevolgen.

Gevolg als kernconcept

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 waardevol resultaat van overheidshandelen”.

Om bovenstaande definitie te begrijpen, is het behulpzaam het handelen van de overheid nader te beschouwen. Dat handelen begint bij een 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
• bekendmaking van besluit

Daarbij horen resultaten als:

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

Niet al deze resultaten zijn echter te beschouwen als gevolg. Daarvoor is immers een duurzaam waardevol karakter nodig. Het is niet eenvoudig deze karakteristiek in algemeenheid waterdicht te definiëren. Het is het resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt. Vaak (maar niet per definitie) is dit ook het rechtsgevolg dat als gevolg van dit handelen ontstaat. In het geval van de omgevingsvergunningaanvraag geldt dus het volgende resultaat als gevolg.

• vergunning verleend (of niet verleend)

Hoewel het voor de hand ligt een gevolg te beschouwen als verandering in het fysieke of administratieve domein waarop de bevoegdheid betrekking heeft, 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 vier 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 resultaat van door overheid op basis van een bevoegdheid handelen.
4. Bekendmaking: een communicatie-uiting gerelateerd aan een gevolg.

Fictief voorbeeld: opleggen eenmalige aanschafheffing na aankoop auto

Het team ‘Heffing aanschafbelasting’ (DOW-AB) binnen de ‘Dienst onderhoud weginfrastructuur’ legt aan kopers van auto’s in bepaalde regio’s een eenmalige aanschafheffing op. Het bedrag dat door de koper betaald moet worden, is gebaseerd op het aanschafbelastingmileu-effect van de aangeschafte auto. Een van de ‘grondstoffen’ voor berekening hiervan is het door de dienst ‘Technisch onderhoud’ vastgestelde fysiek milieu-effect. Sam woont in één van de regio’s waarvoor de heffing geldt en heeft een nieuwe auto gekocht. Hij krijgt daarom met de eenmalige aanschafheffing te maken.

1. Signaal: het team ‘Heffing aanschafbelasting’ onvangt bericht van team ‘Technisch onderhoud’ dat voor de auto die Sam gekocht heeft een fysiek milieu-effect van 21 punten is vastgesteld. Het team ‘Heffing aanschafbelasting’ beoordeelt dit ontvangen bericht om te bepalen of naar aanleiding daarvan handelingen moeten worden uitgevoerd.
2. Taak: Omdat Sam in een regio woont waarbinnen de eenmalige heffing wordt opgelegd, is dat het geval. Er ontstaat nu een taak om de hoogte van de eenmalige aanschafheffing vast te stellen.
3. Gevolgen: tijdens het uitvoeren van deze taak onstaan twee gevolgen. Het aanschafbelastingmileueffect is vastgesteld op 33 punten (1), en de hoogte van de eenmalige aanschafheffing is vastgesteld op €2000 (2).
4. Bekendmakingen: deze gevolgen wordt op drie manieren bekendgemaakt. Er wordt een specifiek bericht gepubliceerd over vaststelling van het aanschafbelastingmileu-effect op 33 punten (1) - deze informatie is van belang voor de ‘Nationale Dienst voor Mobiliteitsstromen’, zie ook de volledige casus; het aanschafbelastingmileu-effect wordt samen met het heffingsbedrag gepubliceerd in een referentietabel (2), en Sam krijgt een brief met het verzoek de opgelegde heffing te betalen (3).

De overheid verkaveld

Nu we een beeld hebben van hoe publieke dienstverlening binnen de overheid werkt, en we beschikken over een begrippenkader om haar werking (op hoofdlijnen) te beschrijven, kunnen we ons richten op het volgende vraagstuk. Om de verhouding tussen register en overheid te kunnen duiden, moeten we immers ook begrijpen hoe we zo’n pluriform en complex 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 daarbij enerzijds dat ieder deel groot genoeg is om zelfstandig bestaansrecht te hebben, maar klein genoeg om een ondubbelzinnig begrip van concepten, regels en processen te kunnen waarborgen.

Domein

In het voorgaande gebruikten we al het woord domein om het fysieke of administratieve gebied aan te duiden waarop de bevoegdheid van een overheidsorganisatie betrekking heeft. 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.

Fictief voorbeeld: milieu-effect van auto’s

De overheid wil de impact van auto’s op het milieu begrijpen en daarop kunnen sturen. Binnen het domein ‘Weginfrastructuur’ heeft men het daarom over het ‘milieu-effect’ van een auto. Verschillende taakgebieden leggen dat begrip echter subtiel verschillend uit: voor prioriteren van onderhoud aan wegen en parkeerplaatsen zijn immers alleen gewicht en oppervlakte van een auto relevant, terwijl de eenmalige aanschafheffing ten bate van wegonderhoud ook op CO₂-uitstoot is gebaseerd.

Er is ook nog een heel ander domein waarbinnen het woord ‘milieu-effect’ wordt gebruikt, namelijk dat van ‘Mobiliteitsturing’. Binnen dit domein wordt daarmee een cijfer bedoeld dat wordt gebruikt bij uitvoering van beleid dat aanschaf van milieuvriendelijke auto’s en het delen van auto’s binnen een huishouden stimuleert.

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.

Fictief voorbeeld: milieu-effect van auto’s

Het domein ‘Weginfrastructuur’ waarbinnen het begrip ‘milieu-effect’ twee betekenissen had, wordt gesplitst in twee bounded contexts: ‘Prioritering en planning wegonderhoud’ en ‘Innen aanschafheffing’. In het domein ‘Mobiliteitsturing’ introduceren we de ‘Spitspas’ als bounded context.

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.

Bekendmakingen kennen daarom geen ‘vaste’ bounded context. Deze kunnen zijn opgesteld in de taal van de context die het gevolg produceerde waarover een bekendmaking gaat. In andere gevallen kan een bekendmaking echter expliciet bedoeld zijn om een specifieke (afnemende) bounded context te informeren. Op verzoek van deze contexten kunnen vanuit de producerende context daarom bekendmakingen 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 bekendmakingen die taal en model van de ‘eigen’ context volgen, worden dan ook bekendmakingen 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.

Beperkingen van de digitale overheid

De Newtonpendel van hierboven die op voorspelbare wijze en met minimaal verlies energie doorgeeft is ook een passende metafoor voor een efficïent opererende overheid. Die metafoor sluit in veel situaties ook aan bij de werkelijkheid. Maar sommige gevallen ook helemaal niet. En juist daar worden de beperkingen van de digitale overheid zichtbaar.

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? Wanneer een iets moet worden aangevochten, onderzocht of gecorrigeerd? Deze handelingen horen bij de crappy flow: een werkstroom die vrijwel altijd handwerk vereist, en soms überhaupt niet wordt afgehandeld.

Dit betekent dat gevolgen 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 naar andere bounded contexten oversteken. Waardoor daar 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 ontbreken van mechanismen die de uitkomsten van crappy flows door de overheid verspreiden heeft gevolgen voor de kwaliteit van onze informatie. Het kan best zijn dat we handelen op basis van onjuiste of verouderde inzichten. Dat 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 beoordeling op dit moment vaak voor maar één kogel in de Newtonpendel maken. Dit betekent dat we niet kunnen achterhalen wie het toestel 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 in een aantal aspecten samenvatten:

• 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 als gevolg daarvan 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.

Beelden van lezers van deze pagina zullen waarschijnlijk meer bij elkaar aansluiten. 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.”

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

Het register in relatie tot EIRA

De EIRA omvat vier lagen. De tabel hieronder beschrijft van iedere laag de betekenis en bedoeling, aangevuld met concrete zaken die binnen zo’n laag thuishoren en voor registers relevant zijn.

Het register in relatie tot het Common Ground-vijflagenmodel

Het Common Ground-vijflagenmodel beschrijft een verdere ontleding van de EIRA-applicatielaag. Iedere laag in dit model vertegenwoordigt een binnen de applicatiearchitectuur duidelijk te onderscheiden verantwoordelijkheidsgebied. De tabel hieronder beschrijft van iedere laag de betekenis en bedoeling, aangevuld met concrete zaken die binnen zo’n laag thuishoren en voor registers relevant zijn.

Architectuurlagen en scope UBB

Aanbevelingen vanuit ‘Uit betrouwbare bron’ hebben primair te maken met de semantische en applicatielaag binnen EIRA (paarse lijn in bovenstaande figuur). In het geval van die laatste kunnen we dankzij het Common Groundmodel preciezer zijn: 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 lijn in bovenstaande figuur). Dit betekent dat we bijvoorbeeld aanbevelingen doen voor:

• benoemen, beschrijven en begrijpen van generieke (dus onafhankelijk van welke gegevens een register omvat toepasbare) functionaliteit. Denk hierbij aan onderwerpen als historie, herkomst en zekerheid;
• welke architectuurpatronen (CQRS, event sourcing) in welke situaties te volgen;
• ontwerp van interacties (bijhouden, corrigeren, bevragen, notificeren), en
• applicatieve structuur en functionaliteit van het register.

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 bijvoorbeeld geen aanbevelingen doen over:

• 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 organistorisch 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.

Registeranatomie

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

Van signaal naar bekendmaking

In de afbeelding hierboven zien we allereerst de eerder geïntroduceerde elementen signaal, taak, gevolg en bekendmaking 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

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 projectie 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 (dataobject) 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 ontstaat een door introductie van een O)Projectiestore* een extra applicatiecomponent.

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

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.

Aspecten / Capability’s

Verwerkingsverantwoording

De verwerkingsverantwoording wordt geformuleerd vanuit een business-perspectief waarbij geredeneerd wordt vanuit een keten van verwerkingen en gevolgen:

Van ieder gegeven moet vanuit diverse perspectieven toegelicht worden waarom en hoe het tot stand is gekomen. Om dat toe te lichten zijn er 3 sub-aspecten benoemd.

Aanleiding

De aanleiding voor het tot stand komen van een gevolg is het gevolg dat hieraan voorafging en de verwerkingsverantwoordelijke voor het eerste deel van het verwerkingsproces dat zich in de “voorliggende” bounded context bevind ¹.

Dus in de bovenstaande figuur is gevolg1 de aanleiding voor gevolg 2 en de verwerkingsverantwoordelijke voor de aanleiding is verwerkingsverantwoordelijke 1.

Legitimering

De legitimering voor de totstandkoming van een gevolg is wet en/of het beleid en/of de procedures waarop de verwerking heeft plaatsgevonden van het gevolg dat de aanleiding was.

Verklaring

Met de verklaring wordt geduid op welke wijze de wet en/of het beleid en/of de procedures zijn toegepast en wie de verwerkingverantwoordelijke binnen de “eigen” bounded context is ². Een voorbeeld hiervan is de beslissing die een ambtenaar heeft genomen binnen zijn/haar discretionaire bevoegdheid. Het is dan ook van belang te weten welke ambtenaar deze beslissing heeft genomen. Deze ambtenaar wordt in het schema aangeduid met verwerkingsverantwoordelijke 2

Gebeurd op

Met gebeurd op wordt het moment aangeduid waarop het event heeft plaatsgevonden. Dit heeft een sterke relatie met de wijze waarop events worden gedefinieerd. Bijvoorbeeld, naar aanleiding van het verwerken van een commando waarin de geboorteaangifte ter registratie wordt aangeboden aan de Basis Registratie Personen zou je drie events kunnen definieren: - Het kind is geboren. - Er is een akte van geboorte opgesteld. - De akte van geboorte is geregistreerd in de Basis Registratie Personen. Deze drie events hebben ieder hun eigen “gebeurd op” moment.

Registratie

Dit aspect betreft wanneer en door wie iets is vastgelegd. Het systeem houdt bij op welk moment (en eventueel door welke medewerker of instantie) een gegeven is geregistreerd. Dit is van belang voor audit-trails en om vragen te beantwoorden als: “Sinds wanneer weten we dit?” Met registratie-informatie kun je een administratieve tijdlijn opbouwen – los van de inhoudelijke geldigheid.

Geldigheid

Veel gegevens kennen een periode van geldigheid of relevantie. Een adres is vanaf een bepaalde datum geldig, een inschrijving heeft een begin- (en soms eind)datum. Capabele registers leggen expliciet vast vanaf wanneer een gegeven geldig is en tot wanneer (indien van toepassing). Zo ontstaat er een historie in twee dimensies: één dimensie is wanneer iets gold in de werkelijkheid, de andere is wanneer het geregistreerd werd. Dit voorkomt verwarring over tijdreizen in data (bijv. late registratie van een gebeurtenis in het verleden).

Zekerheid

Ieder gegeven draagt informatie over de (on)zekerheid. Is het een bevestigd gegeven, of is er nog twijfel of een lopend onderzoek? In traditionele registers ontbreekt dit vaak, maar in een capabel register kunnen we bijvoorbeeld een “twijfel” annotatie toevoegen als iets betwist wordt. Zo weten afnemers of ze het gegeven voorzichtig moeten behandelen. Deze filosofie – data zien als “claims” in plaats van absolute feiten – is cruciaal. Het betekent dat het systeem beseft: “We denken dat dit waar is, maar het kan in de toekomst gecorrigeerd worden.” Door onzekerheid expliciet te modelleren, voorkom je dat één foutje doorwerkt als harde waarheid in allerlei ketens.

Degistratie

Van gegevens moet kunnen worden vastgelegd dat deze helemaal niet geregistreerd hadden moeten worden. Daarbij moet worden vastgelegd wat het moment is waarop is vastgesteld dat deze gegevens niet vastgelegd hadden moeten worden. Vanaf dat moment dat dit is vastgesteld zijn deze gegevens niet meer beschikbaar voor de business-processen. Deze gegevens niet fysiek verwijderd omdat er vanuit historische perspectief bekend moet blijven dat er ooit een moment was waarop deze gegevens wel gereistreerd zijn geweest. .

Componenten

Commando

Een commando is een opdracht aan het register, aangeboden met de intentie daarin een verandering aan te brengen, die door het register volledig en ineens (of in het geheel niet) verwerkt moet worden.

Verwerking van een [=commando=] kan leiden tot 0, 1 of meerdere ‘effecten’

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style cm1 stroke:#2962FF style cm2 stroke:#2962FF

Transactionele verwerking

Een commando moet door het register “volledig en ineens (of in het geheel niet) verwerkt worden”. Dit betekent dat de hele inhoud van het commando in één transactie verwerkt moet worden.

Taal

• Omdat een commando geldt als opdracht, wordt bij de naam daarvan de gebiedende wijs gebruikt (registreer..., vernietig...).
• De naam van het commmand beschrijft altijd iets wat gebeurt door verwerking in het register.
  • Als een commando gaat over iets met zelfstandig bestaansrecht, dus iets wat ook zonder registratie bestaat, geeft de naam van het commando uitdrukking aan een registratieve intentie.
    • Bijvoorbeeld: registreer uitgifte rijbewijs, en niet geef rijbewijs uit. De daadwerkelijke uitgifte van het rijbewijs vond immers plaats aan de balie of per post, niet binnen het register. Het rijbewijs zou dus ook zonder registratie zijn uitgegeven.
  • Als een commando gaat over iets dat zonder registratie niet bestaat, geeft de naam van dat commando uitdrukking aan een producerende of wijzigende intentie.
    • Bijvoorbeeld: creëer zaak, en niet registreer zaakcreatie. De daadwerkelijke zaakcreatie vindt immers binnen het register plaats. En zonder die registratie was de zaak niet gecreëerd.
• Concepten die de naam en inhoud van commandos beschrijven zijn onderdeel van de gemeenschappelijke taal van de bounded context die het register ondersteunt. De bedoeling van een commando wordt daarom in deze taal gedocumenteerd.
  • Hoewel een wijziging in het WOZ-objectenregister veroorzaakt kan worden door een verandering in de Basisregistratie Kadaster, gaat een commando binnen de bouded context van WOZ-objectenbeheer dus niet over eigenaren van kadastrale onroerende zaken, maar over belanghebbenden bij WOZ-objecten.

Effect

Nadere uitwerking volgt.

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style eff stroke:#2962FF

Projectie

Nadere uitwerking volgt.

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style prj stroke:#2962FF

Notificatie

Nadere uitwerking volgt.

Fictief voorbeeld: milieu-effect van auto’s

--- config: look: neo --- flowchart LR subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc1["BC 'Prioritering wegonderhoud'"] no1("**Notificatie**: Fysiek milieu-effect auto Sam ten behoeve van wegonderhoud vastgesteld op 21 punten") end subgraph bc2["BC 'Aanschafheffing'"] cm1("**Commando**: Stel milieu-effect voor aanschafheffing vast input: 21 pt") eff("**Effect**: Aanschafbelastingmilieu-effect vastgesteld op 33 punten") prj("**Projectie**: | Eigenaar | ME | kosten | | Sam | 33pt | €2000 |") no2("**Notificatie**: Aanschafbelastingmilieu-effect auto Sam vastgesteld op 33 punten") end end subgraph do2["Domein Mobiliteitsturing"] subgraph bc3["BC Mobiliteitsturing"] cm2("**Commando**: Stel milieu-effect voor huishouden vast input: 33 pt") end end no1 -.-> cm1 cm1 -.-> eff eff -.-> prj prj -.-> no2 no2 -.-> cm2 style no1 stroke:#2962FF style no2 stroke:#2962FF

Illustratieve casus: Verwerking auto-aankoop

De fictieve casus hieronder beschrijft een aantal binnen ‘Uit betrouwbare bron’ relevante aspecten rondom registratie en levering van informatie informatieflow binnen de overheid, te weten:

• Hoe één aanleiding (de koop van een auto) een serie overheidshandelingen in gang kan zetten;
• hoe overheidsorganisaties voor hun handelen (soms) afhankelijk zijn van resultaten van andere overheidsorganisaties, en
• hoe één concept (milieu-effect) door verschillende organisaties en personen binnen de overheid verschillend begrepen en berekend wordt.

Aanleiding

Sam koopt een nieuwe auto met de volgende kenmerken:

Zoals verplicht verzekert Sam direct na aankoop de nieuwe auto. De verzekeraar meldt de aankoop van de auto aan de Dienst onderhoud weginfrastructuur (DOW).

Behandeling door DOW-team ‘Technisch onderhoud’

Binnen de DOW belandt de melding van Sam eerst bij het team ‘Technisch onderhoud’ (DOW-TO). Deze afdeling heeft als taak het prioriteren van onderhoud aan wegen en parkeerplaatsen. Om deze taak uit te kunnen voeren bepaalt men voor iedere in de regio aangeschafte auto het mileu-effect.

Binnen het DOW-team ‘Heffing aanschafbelasting’ definieert men het concept milieu-effect als volgt:

Het milieu-effect is een maat voor de fysieke belasting die een voertuig op de weginfrastructuur uitoefent, berekend als de som van (a) een massacomponent gebaseerd op voertuiggewicht en (b) een ruimtecomponent gebaseerd op voertuigoppervlak.

Omdat het begrip milieu-effect door andere teams en organisaties met andere betekenissen wordt gebruikt, noemen we het milieu-effect zoals gebruikt binnen het Team ‘Technisch onderhoud’ verder het fysiek milieu-effect.

Voor de auto van Sam maakt het team ‘Technisch onderhoud’ de volgende berekening:

Gevolg: de wijk van Sam komt (een heel klein stapje) hoger op de wegonderhoudsplanning.

Behandeling door DOW-team ‘Heffing aanschafbelasting’

Het team ‘Heffing aanschafbelasting’ (DOW-AB) valt eveneens binnen de Dienst onderhoud weginfrastructuur. Dit team heeft als taak het opleggen van een eenmalige aanschafheffing aan autokopers die binnen bepaalde regio’s wonen. Deze heffing is bedoeld om het onderhoud van wegen te bekostigen en tegelijkertijd het aanschaffen van milieubelastende auto’s te ontmoedigen. Om deze taak uit te kunnen voeren bepaalt men voor iedere in de regio aangeschafte auto het mileu-effect.

Binnen het DOW-team ‘Heffing aanschafbelasting’ definieert men het concept milieu-effect als volgt:

Het milieu-effect is een samengestelde maat die de totale milieubelasting van een motorvoertuig weergeeft, berekend als de som van (a) het milieu-effect zoals vastgesteld door DOW-TO en (b) een uitstootcomponent gebaseerd op door de fabrikant opgegeven CO₂-uitstoot per kilometer.

Omdat het begrip milieu-effect door andere teams en organisaties met andere betekenissen wordt gebruikt, noemen we het milieu-effect zoals gebruikt binnen het team ‘Heffing aanschafbelasting’ verder het aanschafbelastingmilieu-effect.

Sam woont in een regio waarbinnen de aanschafheffing wordt opgelegd. Voor de auto van Sam maakt het team ‘Heffing aanschafbelasting’ daarom de volgende berekening:

De te betalen aanschafheffing wordt aan de hand van de volgende tabel bepaald:

Gevolg: Sam betaalt een eenmalige aanschafheffing van €2000.

Behandeling door Nationale Dienst voor Mobiliteitsstromen

De Nationale dienst voor mobiliteitsstromen (NDM) heeft het verstrekken van spitsdoorrijpassen als taak. Met deze passen kunnen via speciale rijbanen tijdens spitsuren files worden vermeden. Spitsdoorrijpassen moeten het rijden van milieuvriendelijke auto’s en het delen van voertuigen binnen een huishouden bevorderen. Huishoudens die één milieuvriendelijke auto delen, krijgen een per maand het maximale aantal passen. Huishoudens waarin iedere volwassene een eigen, zeer vervuilende auto bezit krijgen daarentegen geen spitsdoorrijpassen.

Binnen de Nationale dienst voor mobiliteitsstromen definieert men het concept milieu-effect als volgt:

Het mileu-effect is een maat voor de potentiële milieu-impact van het gebruik van een auto door een huishouden, berekend door het fysiek milieu-effect (zoals bepaald door DOW-AB) van alle auto’s in een huishouden op te tellen, en het resultaat te delen door het aantal volwassen personen in het huishouden.

Omdat het begrip milieu-effect door andere teams en organisaties met andere betekenissen wordt gebruikt, noemen we het milieu-effect zoals gebruikt binnen de Nationale dienst voor mobiliteitsstromen verder het huishoudelijk milieu-effect.

Sam heeft een vriendin. Samen vormen zij een huishouden, dat naast de nieuwe auto van Sam geen voertuigen bezit. Voor de auto van Sam maakt Nationale dienst voor mobiliteitsstromen daarom de volgende berekening:

Het aantal te verstrekken spitspassen wordt aan de hand van de volgende tabel bepaald:

Gevolg: Sam’s huishouden heeft per maand recht op 3 spitsdoorrijpassen.