DiS Geo: Architectuurschets

Geonovum Algemeen
Consultatieversie

Deze versie:
https://docs.geostandaarden.nl/disgeo/cv-al-arch-20200831/
Laatst gepubliceerde versie:
geen
Laatste werkversie:
https://github.com/Geonovum/disgeo-arch
Redacteur:
Jan van Gelder, Geonovum
Auteurs:
Bart-Jan de Leuw, MinBZK
Wim Bakkeren, VNG Realisatie
Marcel Reuvers, Kadaster
Linda van den Brink, Geonovum
Jan van Gelder, Geonovum
Doe mee:
GitHub Geonovum/disgeo-arch
Dien een melding in
Revisiehistorie
Pull requests
Rechtenbeleid:

Samenvatting

Doelstelling

Het opleveren van een complete beschrijving van de componenten, verbindingen en noodzakelijke standaarden voor de Samenhangende Objectenregistratie zodat doorontwikkeling van ICT-voorzieningen in samenhang kan plaatsvinden naar een duidelijke doelsituatie.

Aanpak

De architectuurbeschrijving van de Samenhangende Objectenregistratie wordt stapsgewijs steeds verder gevuld. Daarbij wordt samengewerkt door een kleine groep auteurs met een bredere groep die als klankbord optreedt. Daarom wordt het document op een transparante manier gedeeld. Meekijken mag, bijdragen van suggesties en commentaar kan door het aanmaken van zogeheten issues op https://github.com/Geonovum/disgeo-arch/issues.

Inhoud

De architectuurbeschrijving bevat een inleiding, een afbakening, gehanteerde principes en een inrichting van de componenten en verbindingen van het systeem. De beschrijving blijft op functioneel niveau, ofwel op het niveau van de applicatielaag van het NORA-vijflaagsmodel. De onderscheiden functies (capabilities, "wat moet kunnen") binnen het systeem worden zodanig beschreven dat een opdracht om deze te realiseren inhoudelijk voldoende duidelijk is voor opdrachtgever en opdrachtnemer.

Status van dit document

Deze paragraaf beschrijft de status van dit document ten tijde van publicatie. Het is mogelijk dat er actuelere versies van dit document bestaan. Een lijst van Geonovum publicaties en de laatste gepubliceerde versie van dit document zijn te vinden op https://www.geonovum.nl/geo-standaarden/alle-standaarden.

Dit is een door de werkgroep goedgekeurde consultatieversie. Commentaar over dit document kan gestuurd worden naar geo-standaarden@geonovum.nl.

Versiebeheer

Dit document is aan verandering onderhevig. Het versiebeheer van het document geeft inzicht in wijzigen en de actualiteit ervan.

Versie Datum Status Bewerking Toelichting
0.1 15-mei-2020 concept Initieel document "Kapstok" document aangemaakt
0.2 05-jun-2020 concept Initieel document Hoofdstuk indeling aangepast
0.3 06-aug-2020 concept Initieel document Diverse hoofdstukken aangepast
0.4 14-aug-2020 concept Initieel document Diverse hoofdstukken aangepast
0.4.1 21-aug-2020 concept Initieel document Gereed gemaakt voor overdracht
0.5 31-aug-2020 concept Initieel document Gereed gemaakt voor publicatie eerste reviewversie

1. Inleiding

Dit document is de Architectuurbeschrijving van de Samenhangende Objectenregistratie. Het beschrijft de afbakening, de inrichtingsprincipes en de conceptuele of functionele inrichting (de functionele onderdelen en samenhang) van de Samenhangende Objectenregistratie. Van de De Architectuurbeschrijving beschrijft de Objectenregistratie op de Applicatielaag, laag 4 in het NORA-vijflaagsmodel

nora5laagsmodel
Figuur 1 Het NORA 5 laagsmodel

1.1 Doel en doelgroep

De Architectuurbeschrijving moet het mogelijk maken om keuzes te maken voor de verdere inrichting van de ICT-voorzieningen (of applicaties of systemen) voor de Samenhangende Objectenregistratie. Ook moet de Architectuurbeschrijving het mogelijk maken om de transitiestrategie te bepalen voor de overgang van de huidige voorzieningen van o.a. de BAG, BGT, BRO en BRT en delen van andere voorzieningen naar de ICT-voorzieningen voor de Objectenregistratie. Tot slot moet de Architectuurbeschrijving het mogelijk maken om de technische en organisatorische inrichting voor de ICT-voorzieningen voor de Objectenregistratie te bepalen. De onderscheiden functies (capabilities, "wat moet kunnen") binnen het systeem worden zodanig beschreven dat een opdracht om deze te ontwerpen inhoudelijk voldoende duidelijk is voor opdrachtgever en opdrachtnemer.

De Architectuurbeschrijving geeft richting aan de inrichting van de Objectenregistratie en is daarom met name bedoeld voor degenen die betrokken zijn bij die inrichting. Daarnaast is de Architectuurbeschrijving van belang voor de afstemming over de inrichting van de Objectenregistratie met alle belanghebbenden: beleidsverantwoordelijke(n), bronhouders, verstrekker(s), afnemers, beheerders en (software-)leveranciers en andere belanghebbenden.

1.2 Leeswijzer

De Architectuurbeschrijving van de Samenhangende Objectenregistratie heeft de volgende opbouw:

Het hoofdstuk Afbakening beschrijft de grenzen van de Objectenregistratie en de bijdragen (de producten en diensten) ervan aan de omgeving. De afbakening brengt in kaart welke rollen en partijen (waaronder bronhouders en afnemers) interactie met de ICT-voorzieningen van de Objectenregistratie hebben en welke soorten interactie er zijn.

Het hoofdstuk ICT-inrichtingsprincipes beschrijft de principes die bepalend zijn voor de functionele en deels ook technische inrichting van de ICT-voorzieningen en de bijbehorende ICT-organisatie van de Objectenregistratie.

Het hoofdstuk Inrichting van de Objectenregistratie beschrijft de conceptuele inrichting van de ICT-voorzieningen van de Objectenregistratie op de applicatielaag van het NORA-vijflaagsmodel.

Het hoofdstuk Uitwerking op onderdelen bevat een uitgebreidere beschrijving die het kader vormt voor de technische inrichting en een basis biedt voor de organisatorische inrichting rond de ICT-voorzieningen.

Noot

Reviewers: In groene kaders stellen de auteurs soms een vraag. In jullie reviewcommentaar lezen we graag antwoorden.

Relevante bijlagen staan in het hoofdstuk Bijlagen

1.3 Het proces

De Architectuurbeschrijving van de Samenhangende Objectenregistratie is een product van een samenwerking van Geonovum, het Kadaster, het ministerie van BZK en VNG Realisatie. Bij de totstandkoming zijn diverse belanghebbenden betrokken, o.a. via een denktank en klankbordgroep.

2. Afbakening

Dit hoofdstuk beschrijft de afbakening en context van de Objectenregistratie. Het doel hiervan is de grenzen van de Objectenregistratie en de bijdragen (de producten en diensten) ervan aan de omgeving te bepalen. De afbakening brengt in kaart welke rollen en partijen (waaronder bronhouders en afnemers) interactie met de Objectenregistratie hebben en welke soorten interactie er zijn.

2.1 Doel van de Objectenregistratie

Voor de Architectuurbeschrijving van de ICT-voorzieningen voor de Objectenregistratie is het goed het doel van de registratie te kennen. In de beleidsvisie voor de samenhangende objectenregistratie is een vijftal doelstellingen geformuleerd voor de Objectenregistratie:

  1. Een betrouwbare, consistente en actuele samenhangende gegevensset voor heel Nederland;
  2. Een efficiëntere inwinning en bijhouding van objecten, ook in drie dimensies (3D);
  3. Een betere inpassing in moderne architecturen;
  4. Meer en eenvoudiger gebruik van deze informatie in maatschappelijke toepassingen. De registratie gedraagt zich voor de gebruiker als één registratie.
  5. De objectenregistratie maakt onderdeel uit van een robuuste geo-informatie infrastructuur binnen de generieke digitale infrastructuur en voldoet aan de 12 eisen voor een basisregistratie

2.2 Context voor de Architectuurbeschrijving

Processtappen Objectenregistratie

Onderstaande afbeelding toont de globale werking van de Objectenregistratie. Bronhouders zorgen voor het inwinnen van bronmateriaal zoals luchtfoto's of bouwwerkinformatiemodellen of maken gebruik van door anderen ingewonnen bronmateriaal. Op basis van dit bronmateriaal stelt de bronhouder objectgegevens samen die voldoen aan de eisen van de Objectenregistratie en registreert deze objectgegevens in de opslag van de Objectenregistratie waar ze worden bewaard. Vanuit de opslag worden gegevens ontsloten richting afnemers die deze gegevens gebruiken in hun (bedrijfs-)processen. Regelmatig worden de objectgegevens verrijkt voordat ze worden gebruikt, bijvoorbeeld door ze te combineren met gegevens uit andere bronnen. Het resultaat van verrijken noemen we informatieproducten. Vanuit de Objectenregistratie worden alleen generieke informatieproducten verstrekt. Dat zijn producten die voor een groot deel van de afnemers relevant zijn. Specifieke informatieproducten waar alleen bepaalde sectoren of afnemers behoefte aan hebben vallen buiten de scope van de Objectenregistratie. Als er bij de afnemers twijfel over de juistheid van de gegevens bestaat dan kunnen zij dat terugmelden waarna de bronhouder zal onderzoeken of die twijfel klopt.

SOReenvoudig
Figuur 2 De globale werking van de Samenhangende objectenregistratie

Samenvattend onderscheiden we de volgende processtappen.

Processtap Omschrijving
Inwinnen Het door waarneming vanuit de werkelijkheid of uitvraag aan burgers en bedrijven vanuit werkprocessen beschikbaar maken van gegevens over objecten en/of eigenschappen daarvan in een gegevensbron.
Samenstellen Het combineren van vanuit verschillende gegevensbronnen afkomstige ruwe of getransformeerde gegevens over objecten en/of eigenschappen daarvan tot een samenhangende beschrijving conform hetgeen daarover is bepaald in inhoudelijke criteria en kwaliteitseisen.
Registreren Het op een gevalideerde wijze vastleggen van gegevens over objecten en/of eigenschappen daarvan in de registratie
Bewaren Het duurzaam beschikbaar houden van de gegevens over objecten en/of eigenschappen daarvan in de registratie.
Ontsluiten Het beschikbaar stellen van de in de registratie opgenomen gegevens op een zodanige wijze dat deze als gegevens eenvoudig door afnemers kunnen worden benaderd.
Verrijken Het zodanig transformeren of presenteren van in de registratie opgenomen gegevens dat een op afnemersbehoeften afgestemd informatieproduct ontstaat.
Gebruiken Het ophalen van de beschikbaar gestelde gegevens en de toepassing daarvan binnen de werkprocessen waarvoor de gegevens zijn benodigd.
Terugmelden Het vastleggen van twijfel over de gegevens.
Onderzoeken Het onderzoeken van de twijfel over de gegevens om terugkoppeling te geven aan de melder en eventuele aanpassingen aan gegevens te doen.

De afbakening van de processtappen is nog in ontwikkeling. Bovenstaande processtappen zijn gebaseerd op de voorlopige beelden mbt de organisatie van de Objectenregistratie op 29 mei 2020.

Onderstaande afbeelding geeft deze processtappen weer in de globale werking van de Objectenregistratie.

soreenvoudigprocesstappen
Figuur 3 De processtappen in de globale werking van de Samenhangende objectenregistratie

Stelselrollen Objectenregistratie

Voor de uitvoering van de procesen rond de Objectenregistratie zijn verschillende rollen verantwoordelijk. Het gaat om de volgende stelselrollen.

Stelselrol Omschrijving
Bronhouder (inwinnen en samenstellen) Verantwoordelijkheid voor samenstellen van gegevens op basis van verzamelde gegevens uit eigen en andere gegevensbronnen conform de gestelde inhoudelijke voorschriften en kwaliteitseisen
Bronhouder (registreren) Verantwoordelijkheid voor registreren van samengestelde gegevens conform gestelde eisen
Verstrekker Verantwoordelijkheid voor levering van gegevens uit de registratie (met de daarbij behorende ondersteuning) en de levering van enkele generieke informatieproducten aan afnemers
Afnemer Verantwoordelijkheid voor al dan niet verplicht gebruik van gegevens in de eigen processen
Toezichthouder Verantwoordelijkheid voor toezicht op het in overeenstemming met eisen, afspraken en wetgeving opereren van het systeem van de objectenregistratie
Beleidsverantwoordelijke Verantwoordelijkheid voor het organiseren van een gezamenlijke systeemsturing op de registratie
Systeemrol Omschrijving
--- ---
Dienst/Beheerder Verantwoordelijkheid voor het houden van de registratie
Standaardbeheerder Verantwoordelijkheid voor het houden van de standaarden waaronder de informatiemodellen

De afbakening van de stelselrollen en systeemrollen is nog in ontwikkeling. Bovenstaande rollen zijn gebaseerd op voorlopige beelden met betrekking tot de organisatie van de Objectenregistratie. Voor Beleidsverantwoordelijke wordt ook wel de rol Eigenaar gehanteerd.

2.3 Scope van de Architectuurbeschrijving

Op basis van de processtappen en stelsel-en systeemrollen is de scope van de Architectuurbeschrijving te bepalen. Onderstaande afbeelding geeft dat weer op basis van het besturingsparadigma van de Leeuw. Dit besturingsparadigma maakt onderscheid tussen een systeem bestaande uit een besturend orgaan en een bestuurd systeem en de omgeving van het systeem. In onderstaande afbeelding zijn de stelselrollen en systeemrollen in het bestuurd systeem weergegeven.

systeemrollen-objectenregistratie.png
Figuur 4 Scope van de rollen

De afbakening van de processtappen en stelselrollen is nog in ontwikkeling. Onderstaande afbakening toont een mogelijke variant.

systeemprocessen-objectenregistratie
Figuur 5 Scope van de processen

Deze architectuurbeschrijving heeft als scope de ICT-voorzieningen voor de uitvoering en de ondersteuning van de Samenhangende Objectenregistratie. In de hier getoonde variant van de afbakening betreft dit de processtappen Registeren, Bewaren, Ontsluiten, (Generiek) Verrijken en Routeren terugmeldingen en de bijbehorende ondersteundende processen. Alleen het verrijken tot generieke informatieproducten behoort tot de scope van (de ICT-voorzieningen voor) de Objectenregistratie, specifieke informatieproducten waarover geen afspraken zijn gemaakt, vallen buiten scope.

Deze architectuurbeschrijving benoemt binnen de scope de functies, componenten en samenhang en de benodigde standaarden. Voor de processen van de rollen bronhouder en afnemer benoemt deze architectuurbeschrijving alleen de functies. De ICT-componenten en de inrichting daarvan is aan de bronhouders en afnemers zelf.

2.4 Interacties met partijen in de omgeving

De Objectenregistratie heeft de volgende interactie met partijen in de omgeving.

interacties-objectenregistratie
Figuur 6 Interacties
Partij Interacties
Bronhouder(inwinnen/samenstellen) Objectgegevens (INVOER). De bronhouder registreert objectgegevens.
Meldingen: De bronhouder verwerkt terugmeldingen van Afnemers.
Catalogus. De bronhouder gebruikt de gegevenscatalogus om kennis te nemen van de gegevensdefinities van de Objectenregistratie.
Support. De bronhouder ontvangt ondersteuning bij het gebruik van de Objectenregistratie, zoals bijvoorbeeld een catalogus van beschikbare producten en diensten.
Hulpvraag. De bronhouder kan om ondersteuning vragen bij het gebruik van de Objectenregistratie.
Afnemer Objectgegevens (UITVOER). De afnemer neemt objectgegevens en generieke informatieproducten af.
Meldingen. De afnemer levert terugmeldingen bij twijfel over de juistheid van de objectgegevens.
Catalogus. De afnemer gebruikt de gegevenscatalogus om kennis te nemen van de gegevensdefinities van de Objectenregistratie.
Support. De afnemer (mens of computer) ontvangt ondersteuning bij het gebruik van de Objectenregistratie, zoals bijvoorbeeld een catalogus van beschikbare producten en diensten.
Hulpvraag. De afnemer kan om ondersteuning vragen bij het gebruik van de Objectenregistratie. Hier wordt zowel geautomatiseerde ondersteuning als menselijke ondersteuning bedoeld.
Toezichthouder De toezichthouder bepaalt binnen het systeem de kwaliteitsindicatoren voor het monitoren van het systeem. Hiertoe ontvangt de toezichthouder sturing vanuit de Eigenaar/Beleidsverantwoordelijke en diens Overleg met Bronhouders en Afnemers.
Standaardbeheerder Catalogus De standaardbeheerder beheert de gegevensdefinities van de Objectenregistratie ten behoeve van bronhouders en afnemers. Deze rol biedt de gegevenscatalogus aan alle andere rollen.
Dienst/Beheerder De Dienst/Beheerder is de houder van de registatie. Deze rol biedt de beschikbare producten en diensten, en de suppport die daarbij benodigd is.
Beleidsverantwoordelijke De beleidsverantwoordelijke vormt het Besturend Orgaan van het systeem. Deze bepaalt met name de inhoud van het systeem, dat wil zeggen welke gegevens tot de basisgegevens behoren. Sturing op die inhoud geschiedt in Overleg met Bronhouders en Afnemers.

Buiten de afbakening: De rol Bronhouder(inwinnen/samenstellen) is gepositioneerd als een partij in de omgeving die gebruik maakt van eigen diensten om objectgegevens samen te stellen. De rol Afnemer is gepositioneerd als een partij in de omgeving die gebruik maakt van de diensten van de Objectenregistratie om objectgegevens af te nemen.

Binnen de afbakening: De rol Bronhouder (registreren) valt binnen de afbakening van de Objectenregistratie. Het is de rol die de objectgegevens registreert en beheert (vergelijkbaar met de huidige BAG-beheerder, BGT-beheerder, BRT-beheerder, enz.) en bijdraagt aan de routering van terugmeldingen naar de juiste Bronhouder(inwinnen/samenstellen). De rol Verstrekker valt binnen de afbakening van de Objectenregistratie. Het is de rol die zorgt voor de ontsluiting en (generieke) verrijking van objectgegevens, en bijdraagt aan de routering van terugmeldingen. Ook de rollen Standaardbeheerder, Toezichthouder en Dienst/Beheerder

Noot

REVIEW: De interacties komen overeen met de pijlen in de afbeelding. Opmerkingen op de tabel en op de afbeeldingen zijn in samenhang welkom.

NB. Alle genoemde partijen maken gebruik van ondersteunende partijen zoals ICT-leveranciers en kunnen taken uitbesteden aan derden, zoals samenwerkingsverbanden en gegevensleveranciers. De beschreven interacties hebben deels ook betrekking op deze ondersteunende partijen. Zo zullen softwareontwikkelaars ook gebruik maken van de gegevens- en de dienstencatalogus van de Objectenregistratie.

3. ICT-inrichtingsprincipes

Dit hoofdstuk beschrijft de principes die richtinggevend zijn voor de functionele inrichting van de ICT-voorzieningen voor de Objectenregistratie en de bijbehorende ICT-organisatie.

3.1 Beleid Samenhangende Objectenregistratie

De overkoepelende Architectuurvisie DiS-Geo geeft de richtinggevende kaders waarbinnen de bestaande geo basisregistraties worden doorontwikkeld tot een samenhangende objectenregistratie.

De Beleidsvisie Samenhangende Objectenregistratie beschrijft de doelstellingen en beleidscontouren.

De volgende uitgangspunten voor de architectuur van de objectenregistratie zijn afgeleid uit beide bovenstaande documenten.

vanuit Architectuurvisie DiS-Geo

  1. Bronhouders zijn verantwoordelijk voor basisgegevens
  2. Bronhouders kunnen leveranciers machtigen
  3. Gegevens aanpassen kan makkelijk en goed
  4. Gegevens passen bij elkaar: relaties tussen gegevens zijn voor gebruikers duidelijk, en gegevens zijn in samenhang bruikbaar
  5. De gegevensstructuur kan snel genoeg meegroeien met de gebruiksbehoefte

vanuit Beleidsvisie Samenhangende Objectenregistratie

  1. We laten ons bij het ontwerp en de verdere uitwerking niet beperken door de nu bestaande juridische kaders (deze kunnen in principe worden aangepast, via een traject aanpassing wet- en regelgeving).
  2. In het ontwerp van een samenhangende objectenregistratie is sprake van een nadrukkelijke scheiding tussen de vastlegging van gegevens en de functionaliteit voor het bewerken, opvragen en presenteren daarvan.
  3. Er wordt gebruik gemaakt van standaard infrastructurele voorzieningen die beschikbaar zijn bij de bronhouders en de gebruikers (denk hierbij aan standaardnetwerken, netwerkprotocollen en beveiligingsmechanismen).
  4. Er wordt in de eindsituatie zoveel mogelijk uitgegaan van ‘bevragen bij de bron’. Hierbij is van belang dat de gebruiker voor verstrekkingen zoveel mogelijk uit kan gaan van één loket. Een belangrijk aandachtspunt hierbij is het gebeurtenis georiënteerd werken (nader uit te werken). Of de bronhouders gedistribueerd en decentraal werken of direct inwinning en bijhouding in een (of meerdere) voorziening(en) uitvoeren via gestandaardiseerde services moet nader bepaald worden (nadere uitwerking in kader van DiS GEO/beleidsvisie: leveranciers, bronhouders, Kadaster, VNG-R, BZK).
  5. Er wordt ingewonnen op het niveau van de huidige schaalniveaus van BAG en BGT. De gegevens kunnen gepresenteerd worden op verschillende schaalniveaus (meest gedetailleerde weergave: 1:1.000). Autogeneralisatie voor informatie op hogere schaalniveaus moet mogelijk zijn (op basis van logica en functies). Bijvoorbeeld het (deels) afleiden van de informatie voor de BRT uit de BGT, maar ook voor het definiëren van een wegennetwerk met alle rijkswegen op basis van het gehele wegennetwerk.
  6. Keuzen voor een technische inrichting van de registratie worden pas later in het traject gemaakt, zodat oplossingen gebaseerd zijn op recente inzichten in oplossingsmogelijkheden.
  7. Vanuit andere (basis)registraties, zoals de subjectenregistraties BRP of HR, moeten eenvoudig relaties gelegd kunnen worden naar de samenhangende objectenregistratie.
  8. De registratie gedraagt zich voor gebruikers zoveel mogelijk als één registratie, of het daadwerkelijk één registratie wordt, is nog niet bepaald (nader uit te werken). Daarnaast kunnen er uit de registratie (informatie)producten afgeleid worden en beschikbaar gesteld worden.
  9. De kerngegevens en aanvullende gegevens worden in principe ontsloten als open data (waar nodig ontsloten op basis van autorisaties), dus het “open data, tenzij” regime geldt.
  10. In principe kan de informatie via meerdere kanalen, afgestemd op gebruikersbehoefte, uitgeleverd worden (nadere uitwerking in kader van DiS GEO).

3.2 Inrichtingsprincipes vergelijkbare domeinen

Binnen andere domeinen is veel kennis en kunde opgebouwd over inrichtingsprincipes van dit soort ICT-voorzieningen. We hebben hier met name gebruik gemaakt van de volgende groepen met ervaring en vastgelegde kennis:

3.3 ICT-inrichtingsprincipes Samenhangende Objectenregistratie

Voor de ICT-inrichting van de Samenhangende Objectenregistratie hanteren we de onderstaande principes. Met 'de oplossing' bedoelen we steeds de ICT-voorzieningen die de Samenhangende Objectenregistratie realiseren.

Inrichtingsprincipe 1: Gegevens worden gescheiden van applicaties bewaard, zodat het beheren en afnemen van gegevens onafhankelijk is van de gebruikte applicaties en gegevens te (her)gebruiken zijn in verschillende applicaties voor verschillende doeleinden.

Grondslag: Uitgangspunten (7, 9), Common Ground

Inrichtingsprincipe 2: Ieder gegeven wordt op precies één plek bijgehouden, zodat altijd duidelijk is wat het actuele brongegeven is en waar dat wordt beheerd. Dit principe heeft de volgende onderliggende principes in zich: - Dubbele opslag betekent synchroniseren, zodat partijen altijd naar dezelfde gegevens kijken. Dit geldt zowel binnen als buiten de oplossing, dus ook voor eventuele afgeleide opslag die geoptimaliseerd is ten behoeve van verstrekking.

Grondslag: Uitgangspunten (9, 11, 15), Common Ground (04)

Inrichtingsprincipe 3: Gegevens zijn alleen te benaderen via dataservices, zodat deze services kunnen garanderen dat de gegevens, metagegevens en de toegang ertoe altijd voldoen aan de eisen en dat logging altijd plaatsvindt. Dit principe heeft de volgende onderliggende principes in zich:

Om te garanderen dat de gegevens blijven voldoen aan de gestelde kwaliteit en actualiteit kunnen ze alleen benaderd worden via (data)services. Dit principe zorgt ervoor dat gegevens blijven voldoen aan de (integriteits-)eisen, doordat de dataservices dit waarborgen. Ook zorgt dit principe ervoor dat er een ontkoppeling is tussen de gegevens en de ontsluiting ervan. Applicaties benaderen de gegevens via de dataservices en niet direct. Dat maakt het mogelijk om veranderingen aan te brengen in de gegevensopslag of in de dataservices zonder dat deze elkaar beïnvloeden. Hierdoor kunnen we flexibel omgaan met aanpassingen in het gegevensmodel. De service controleert of de gebruiker wel de toegangsrechten heeft om de gegevens te maken, te lezen of aan te passen. Alle transacties op de gegevens worden gelogd. Dit is nodig om een audit-trail te kunnen opbouwen.

Grondslag: Uitgangspunten (1, 2, 3, 5, 7, 8, 9), DSO (05)

Inrichtingsprincipe 4: We bewaren en ontsluiten informatie op betrouwbare en veilige wijze, zodat we kunnen aantonen dat data niet bedoeld of onbedoeld gemanipuleerd is. Om op data te kunnen vertrouwen zorgen we ervoor dat data bij alle handelingen vanaf het moment van ontstaan tot het moment van gebruik veilig is. We wijzigen de actuele versie van data daarom alleen op basis van een brondocument of mutatieverwijzing en leggen die vast. We bewaken integriteit en consistentie van data. We bewaren data conform de eisen van de wet (w.o. archiefwet, etc.).

Grondslag: Uitgangspunten (3, 7, 9), DSO (09), Common Ground (03)

Inrichtingsprincipe 5: We maken samenhangend gebruik van data makkelijk mogelijk, zodat data uit verschillende gegevensverzamelingen te combineren is. Zo maken we mogelijk dat er samengestelde producten over het geheel van het gegevenslandschap kunnen worden gerealiseerd. Dit principe heeft de volgende onderliggende principes in zich:

Grondslag: Uitgangspunten (4, 12, 13, 15), DSO (05)

4. Inrichting van de Objectenregistratie

4.1 Inleiding

Dit hoofdstuk beschrijft de functionele (of conceptuele) inrichting van de Samenhangende Objectenregistratie op de applicatielaag van het NORA-vijflaagsmodel. Het doel ervan is om sturing te kunnen geven aan de transitie naar de Objectenregistratie en te dienen als kader voor technische inrichting van de Objectenregistratie. Ook biedt het een deel van de basis voor de organisatorische inrichting van de Objectenregistratie.

Dit hoofdstuk beschrijft de onderdelen (of componenten) van de Objectenregistratie en de verbindingen daartussen en het wijst de functies van de Objectenregistratie toe aan deze onderdelen.

Noot

Een nadere uitwerking van de onderdelen volgt in het hoofdstuk Uitwerking van onderdelen. Dit wordt toegevoegd parallel aan de review op de afbakening en inrichting.

4.2 Functionele lagen in de inrichting

We onderscheiden drie lagen in de functionele indeling van de Objectenregistratie, zoals de afbeelding hieronder toont. Daarmee duiden we alleen het doel van de functies (bijvoorbeeld beheren of afnemen van objectgegevens) en doen we geen uitspraak over de de technische inrichting of de verdeling ervan over verschillende ICT-voorzieningen.

functionele lagen
Figuur 7 Functionele lagen in de inrichting van de Objectenregistratie

De laag Metabeheer bevat de functies die betrekking hebben op het beheren van gegevens over de gegevensmeta-data en bestaat uit twee lagen, te weten Meta-gegevensbeheer en 'Inzicht in kwaliteit'. Meta-gegevensbeheer bevat de functies die nodig zijn om informatiemodellen en gegevensregels te beheren evenals het beheren van de gegevenscatalogi om die informatiemodellen en gegevensregels te kunnen toepassen. 'Inzicht in kwaliteit' bevat de functies om kwaliteitsindicatoren te beheren en kwaliteitsmetingen te doen.

De Uitvoeringslaag bevat de functies die nodig zijn voor het voor het beheren en afnemen van objectgegevens, zoals voor het registreren en wijzigen van gegevens en voor het raadplegen ervan. Op deze laag maken we onderscheid tussen de functies ten behoeve van het beheren van objectgegevens door bronhouders en het afnemen ervan door afnemers van de Objectenregistratie.

De Ondersteuningslaag bevat de functies die nodig zijn om bronhouders en afnemers te ondersteunen bij het beheren en afnemen van gegevens, zoals het beheren van autorisaties en het raadplegen van gegevens- en dienstencatalogi.

Naast de drie lagen voor Metabeheer, Uitvoering en Ondersteuning, is ook functionaliteit nodig in het kader van Voorzieningenbeheer. De beheerfuncties voor het beheren van de ICT-voorzieningen op het platform, of de platformen, die het beheren en afnemen van objectgegevens en meta-gegevens mogelijk maken. Deze beheerfuncties maken we zichtbaar in een totaaloverzicht.

4.3 Functies in de laag Metabeheer

Onderstaande afbeelding toont de clusters van functionaliteiten op de laag Metabeheer. Deze clustering is een functionele indeling, geen technische. Het groepeert functies die bijdragen aan hetzelfde doel.

inrichting metabeheer
Figuur 8 De capability-clusters op de laag Metabeheer

De laag Metabeheer bestaat uit de delen Metagegevensbeheer en Inzicht in kwaliteit.

Het deel Metagegevensbeheer bevat de volgende clusters aan functionaliteiten:

Het deel 'Inzicht in kwaliteit' bevat de volgende clusters aan functionaliteiten:

4.4 Functies in de laag Uitvoering

Onderstaande afbeelding toont de clusters van functionaliteiten op de laag Uitvoering. Deze clustering is een functionele indeling, geen technische. Het groepeert functies die bijdragen aan hetzelfde doel.

functiesuitvoering
Figuur 9 De capabilities op de laag Uitvoering

De laag Uitvoering bevat de functies voor het beheren van objectgegevens en voor het afnemen van objectgegevens

Op de Uitvoeringslaag onderkennen we de volgende clusters voor beheer van objectgegevens:

Op de Uitvoeringslaag onderkennen we daarnaast de volgende clusters voor het afnemen van objectgegevens :

4.5 Functies in de laag Ondersteuning

Onderstaande afbeelding toont de clusters van functionaliteiten op de laag Ondersteuning. Deze clustering is een functionele indeling, geen technische. Het groepeert functies die bijdragen aan hetzelfde doel.

functiesondersteuning
Figuur 10 De capabilities op de laag Ondersteuning

Op de Ondersteuningslaag onderkennen we de volgende clusters voor de ondersteuning van bronhouders en afnemers en hun gemachtigden en leveranciers:

Noot

We maken onderscheid tussen abonnementen op notificaties van gebeurtenissen die betrekking hebben op gegevens (voor bronhouders en afnemers) en abonnementen op notificaties van andersoortige gebeurtenissen (bijvoorbeeld ontwikkelingen die relevant zijn voor ontwikkelaars en beheerders van ICT-voorzieningen voor en bij bronhouders en afnemers)

4.6 Overzicht

Onderstaande afbeelding toont de functionaliteiten per cluster op de drie lagen. Deze functionaliteiten zijn beschreven in het hoofdstuk Uitwerking van onderdelen.

inrichting metabeheer uitvoering ondersteuning
Figuur 11 De capability-clusters op de lagen Metabeheer en Uitvoering en Ondersteuning
Noot

Het hoofdstuk "Uitwerking van onderdelen" met de detail beschrijving van de functionaliteiten per cluster zal worden opnemen in de volgende versie van de architectuurbeschrijving.

4.7 Functies in de aparte architectuurlaag Voorzieningenbeheer

De laag Voorzieningenbeheer bevat de volgende clusters aan functionaliteiten:

Als we alle clusters met functionaliteiten in één overzicht plaatsen, wordt het geheel minder overzichtelijk. Het kan mogelijk wel nuttig zijn zo'n overzicht als praatplaat-aan-de-wand te gaan gebruiken bij de beheerorganisatie(s) bijvoorbeeld in workshops die bij de gezamenlijke inrichting worden gehouden.

alles in een plaat
Figuur 12 Alle capability-clusters in een plaat
Noot

Omdat veel gebruik wordt gemaakt van standaard voorzieningen van de overheid is het beheer soms enkel organisatorisch en soms zowel organisatorisch als technisch.

5. Uitwerking onderdelen inrichting Objectenregistratie

5.1 Inleiding

Dit hoofdstuk beschrijft de nadere uitwerking van de functionele onderdelen van de Objectenregistratie en hun interne en externe verbindingen.

Noot

Deze nadere uitwerking volgt. Beschrijving vindt plaats parallel aan de review op de afbakening en inrichting.

6. Bijlagen principes

6.1 Inrichtingsprincipes Digitaal Stelsel Omgevingwet

Aan de kolommen met de regel en het principe zijn twee kolommen toegevoegd: Data en Functies.
Data: Een ja in deze kolom moet worden gezien als 'Ja' dit principe is relevant voor de gegevens in de samenhangende objectenregistratie. Scope zijn de gegevens zelf, oftewel het hart van het systeem. Functies: Een ja in deze kolom moet worden opgevat als 'Ja' dit principe is relevant voor de functionaliteit van de Samenhangende Objectenregistratie. Scope is de functionaliteit waarmee de gegevens en/of de informatie aan de gebruikers wordt aangeboden.

Regel Principe Data Functies

01

De klant staat centraal Ja

02

Het stelsel functioneert als één geheel voor zowel personen als systemen Ja

03

Data is de brandstof van het stelsel Ja

04

Oplossingen zijn eenvoudig, generiek en kosten effectief Ja

05

Alles is een service Ja

06

Het stelsel is open, transparant en innoverend Ja Ja

07

Hergebruik voor koop voor maak

08

Continuïteit en compliance is geborgd

09

Passende beveiliging & privacy op basis van reële risico’s

10

Beheerfunctionaliteit is primaire functionaliteit Ja

Bron: DSO-LV, bijlage G

6.2 Inrichtingsprincipes Common Ground

Principe Omschrijving

01

COMPONENTGEBASEERD: We werken met componenten

02

OPEN: We zijn transparant waar mogelijk

03

VERTROUWD: We zorgen dat informatiebeveiliging en privacy op orde zijn

04

EENMALIGE VASTLEGGING: We leggen gegevens eenmalig vast en vragen op bij de bron

05

REGIE OP GEGEVENS: We faciliteren regie op gegevens

06

STANDAARD: We standaardiseren maximaal

Bron: Common Ground

6.3 Basisprincipes NORA

De principes van de NORA zijn bedoeld om overheidsorganisaties richting te duiden bij het inzetten van veranderingen en het uitvoeren van projecten. Met name bij het ontwerpen van nieuwe of aangepaste diensten is het noodzaak zichtbaar te maken hoe invulling wordt gegeven aan de principes en welke overwegingen daarbij worden gemaakt. Hier geldt het pas-toe-of-leg-uit- principe, waarbij afwijkingen dus zijn toegestaan mits dat met goede argumenten wordt onderbouwd en vastgelegd om daar in een later stadium op terug te kunnen komen. Zo wordt voorkomen dat belangrijke zaken over het hoofd worden gezien. Bron: https://www.noraonline.nl/wiki/Principes

6.4 Afgeleide principes NORA

Afgeleide principes geven meer concrete invulling aan de basisprincipes. Ze zijn te beschouwen als een checklist van kwaliteitskenmerken van de diensten van de overheid en geven handvatten voor operationeel niveau door hun uitwerking in concrete implicaties. Bron: https://www.noraonline.nl/wiki/Principes

6.5 Inrichtingsprincipes GEMMA

GEMMA kent 8 inrichtingsprincipes. Bron: https://www.vngrealisatie.nl/gemma

6.6 Eisen aan basisregistraties

Er zijn 12 eisen aan basisregistraties waaraan een basisregistratie moet voldoen. Bron: https://www.noraonline.nl/images/noraonline/c/c0/Stelselarchitectuur_heden.pdf

6.7 10 golden rules data

Deze 10 golden rules zijn tot stand gekomen vanuit de best-practices rondom data management.

Regel Omschrijving Opmerkingen Data Functies
01 Data is het hart van het systeem Data blijft jaren bewaard, applicaties bestaan hoogstens 15 jaar. We denken niet meer vanuit applicaties, maar vanuit de data zelf! Ja
02 Data wordt op één plek bijgehouden Er is maar 1 plek waar data wordt gecreëerd, gewijzigd en verwijderd (beëindigd). Dit is randvoorwaardelijk voor een "Single Version of the Truth" Ja
03 Dubbele opslag is niet erg, dubbel bijhouden wel Dubbel opslaan (bijvoorbeeld op een lokale kopie) kan soms nodig zijn. Het is ook helemaal niet erg, zolang de data read-only is, en je je realiseert dat je niet naar de allerlaatste versie kijkt. Dubbel bijhouden is wél erg want dan weet je niet meer "Wat is de waarheid?". Een lokale kopie is soms nodig om de beschikbaarheid van data te garanderen. Denk aan crisisorganisaties. Ja
04 Dubbele opslag betekent synchroniseren! Dubbel opslaan vereist toepassing van spelregels. Als je dubbel opslaat, moet je vastleggen welke dataset de 'master' is, en welke dataset de 'slave'. Ook moet je bedenken hoe je synchroniseert. 1x per dag, 1x per uur, near-real-time, real-time. Vuistregel: Hoe actueler de kopie, hoe duurder de oplossing. Ja
05 Data is zelf-loggend Alle transacties die worden gedaan met de data worden gelogd. Tijdstip plus wie (of wat) de data heeft gewijzigd. Hierdoor kan een wijziging triggers veroorzaken voor afnemers die in hun proces create/update/delete triggers nodig hebben. Loggen gebeurt in ieder geval niet via een bovenliggende applicatie. Dit is nodig voor een audit-trail. Ja
06 Data is zelf-autoriserend De data zelf bepaalt wie (of wat) de data mag wijzigingen, en niet een bovenliggende applicatie. Applicaties worden vervangen, en kunnen worden omzeild. Ja
07 Data is zelf-controlerend De data (definitie) bepaalt welke waarden attributen kunnen krijgen, en niet bovenliggende applicaties. Applicaties worden vervangen, en kunnen worden omzeild. Ja
08 Data is zelf-historiserend In de data wordt een THT-datumtijd ("tenminste houdbaar tot") vastgelegd. Data heeft een houdbaarheidsdatum. Niet alle data hoeft even lang op dezelfde manier bewaard te blijven. Met een THT kun je kiezen voor geschikte opslag (qua toegang en opslagmedium (online/offline)) én kun je invulling geven aan archiveringsbeleid. Ja
09 Data wordt bijgehouden aan de bron De data wordt bijgehouden daar waar ze ontstaat. Achterliggende reden: aan de bron is de noodzaak en de mogelijkheid voor het hebben van goede kwalitatieve data het grootst. Ja Ja
10 Data en Informatie zijn twee verschillende dingen Informatie is "bewerkte data", met andere woorden, informatie is data waaraan kennis is toegevoegd.

7. Lijst met figuren