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

Figuur 1: Architectuurmodellen EIRA en Common Ground in relatie tot elkaar

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 figuur 1). 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 figuur 1). 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.

TODO: Deze punten zijn placeholders. Mijn bedoeling is dat we deze punten, net als de elementen in de tabellen voor de lagen waaraan we werken, op termijn kunnen vervangen door verwijzingen naar onze eigen aanbevelingen.

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.

Registergrenzen

Register en domein

Een register is een verzameling geordende informatie. De grenzen van de verzameling worden net als de betekenis en samenhang van de in het register opgeslagen informatie bepaald vanuit het domein dat voor het register verantwoordelijk is. Anders dan in de wiskunde kunnen we voor registers niet precies aangeven waar het ene domein ophoudt en het volgende begint. Analoog aan de definitie van Eric Evans in de context van Domain Driven Design beschouwen we een domein daarom als “een sfeer van kennis, invloed of activiteit”. Deze definitie veronderstelt een zekere mate van samenhang. Tegelijkertijd kan het binnen één domein voorkomen dat:

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

Fictief voorbeeld: milieu-effect van auto’s

De overheid wil de impact van auto’s op het milieu te 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 aandschaf van milieuvriendelijke auto’s en het delen van auto’s binnen een huishouden stimuleert.

--- config: look: neo --- flowchart TD subgraph do2["Domein 'Mobiliteitsturing'"] de3("**Milieu-effect**: de potentiële milieu-impact van gebruik van een auto door een huishouden") end subgraph do1["Domein 'Weginfrastructuur'"] de1("**Milieu-effect**: de milieubelasting van een motorvoertuig, berekend uit gewicht en oppervlakte.") de2("**Milieu-effect**: de milieubelasting van een motorvoertuig, berekend uit gewicht, oppervlakte en CO₂-uitstoot") end style do1 stroke:#2962FF style do2 stroke:#2962FF

Voor wie zoekt naar aanknopingspunten over welke informatie binnen ‘hoort’ binnen een te ontwerpen register en welke buiten de registergrenzen zou moeten vallen, biedt het denken in ‘sferen’ onvoldoende aanknopingspunten. We moeten dus op zoek naar formeler en objectiever grensbeschrijvingen.

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’ 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 het 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’ vallen de grenzen van domein en bounded context samen.

--- config: look: neo --- flowchart TD subgraph do2["Domein 'Mobiliteitsturing'"] subgraph bc3["Bounded context 'Mobiliteitsturing'"] de3("**Milieu-effect**: de potentiële milieu-impact van gebruik van een auto door een huishouden") end end subgraph do1["Domein 'Weginfrastructuur'"] subgraph bc2["Bounded context 'Aanschafheffing'"] de2("**Milieu-effect**: de milieubelasting van een auto, berekend uit gewicht, oppervlakte en CO₂-uitstoot") end subgraph bc1["Bounded context 'Prioritering wegonderhoud'"] de1("**Milieu-effect**: de milieubelasting van een auto, berekend uit gewicht en oppervlakte.") end end style bc1 stroke:#2962FF style bc2 stroke:#2962FF style bc3 stroke:#2962FF

‘Wellbounded’ registers

Op basis van het bovenstaande kunnen we het volgende concluderen:

1. De taal van het domein bepaalt het model.
2. In het model wordt de taal gemeenschappelijk.
3. Het model bepaalt de bounded context.3

Hieraan voegen we deze aanbeveling toe:

4. Een ‘wellbounded’ register valt samen met één bounded context.

Als we ervan uitgaan dat dit aandachtspunt ten opzichte van bestaande registers grosso modo kleinere, meer doelgerichte registers betekent, dan hoort bij deze aanbeveling één belangrijk nadeel:

• Integratiecomplexiteit (). Registers moeten worden verbonden middels API’s, events of gegevenssynchronisatie.

Daartegenover staat echter een drietal belangrijke voordelen, die de bijzondere eisen ondersteunen die we op het gebied van kwaliteit en betrouwbaarheid aan overheidsregisters stellen:

• Duidelijkheid. Registers die horen bij één bounded context omvatten ondubbelzinnige terminologie en logica.
• Consistentie. Registers die horen bij één bounded context omvatten logisch consistente set regels en modellen.
• Autonomie. Registers die horen bij één bounded context onafhankelijk van registers in andere bounded contexten werken en (door)ontwikkeld worden.

Controleren van de ‘bounds’

In de praktijk laten de ‘bounds’ van een context zich niet altijd gemakkelijk herkennen en afbakenen. Bovendien kunnen bounded contexten onder invloed van impliciete of uitgesproken belangen worden ‘opgerekt’ of juist verkleind. In algemene zin is moeilijk te zeggen wanneer voor een register de ‘ideale’ bounded context is gevonden. Wel zijn enkele aanwijzingen voor een te ruime of te krappe afbakening te geven. Deze zijn hieronder beschreven.

Indicatoren en symptomen (van sterk naar zwakker) voor een te ruime bounded context:

1. Gebrek aan gemeenschappelijke taal. Er is discussie over concepten en betekenis, betrokkenen hanteren verschillend jargon.
2. Regels en gedrag niet in samenhang te brengen. Het lukt niet tot een samenhangend model te komen.
3. Afwijkende werkwijze(n). Bedrijfsprodcessen zijn niet te verenigen.
4. Ontwerp-/owikkeltraject heeft onwenselijke overhead. Het ontwerp-/ontwikkelteam is te groot (geworden).
5. (Vermijdbare) overschrijding van team- en/of organisatiegrenzen. Conflict tussen eigenaren en/of verantwoordelijken.
6. Registeronderdelen vereisen verschillende opslag- en/of integratietechniek. Niet-verenigbare technische vereisten.

Indicatoren en symptomen (van sterk naar zwakker) voor een te krappe bounded context:

1. Registeroverstijgende consistentiewaarborgen vereist. Saga’s zijn nodig om transacties gedistribueerd af te handelen.
2. Model beschrijft domein zonder zelfstandig bestaansrecht. Gegevens in een register hebben ‘los’ geen enkel bestaansrecht en zijn niet te generaliseren voor gebruik in andere domeinen.

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 het aan binnen de regio wonende autokopers opleggen van een eenmalige aanschafheffing als taak. 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.

Voor de auto van Sam maakt het team ‘Heffing aanschafbelasting’ 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.