Informatiearchitectuurprincipes

Opmerking: op deze pagina wordt de aanduiding 'GEMMA Gegevenslandschap' gebruikt. Deze term zal worden vervangen, omdat de GEMMA deze term niet meer gebruikt.

1. Inleiding

Het GEMMA Gegevenslandschap is een informatiearchitectuur voor gemeenten voor onder andere het scheiden van processen en gegevens en het gebruiken van gegevens ‘uit de bron’. Het GEMMA Gegevenslandschap is bruikbaar bij ontwikkelingen waarbij nieuwe voorzieningen voor gemeenten worden ontwikkeld (zoals Common Ground).

Deze notitie beschrijft de informatiearchitectuurprincipes van het GEMMA Gegevenslandschap: fundamentele keuzes die richting geven aan ontwikkelingen waarbij gegevens en applicaties zijn betrokken. Doel is om te zorgen dat veranderingen in lijn met het GEMMA Gegevenslandschap verlopen en effectief bijdragen aan het door gemeenten gewenste nieuwe gegevenslandschap.

Bij het ontwerpen van nieuwe voorzieningen geldt een ‘pas-toe-of-leg-uit’ verplichting. Afwijkingen zijn alleen toegestaan als ze met goede argumenten worden onderbouwd en worden vastgelegd om er in een later stadium op terug te kunnen komen. Zo voorkomen we dat belangrijke zaken over het hoofd worden gezien en zorgen we dat verschillende activiteiten in lijn zijn met de uitgangspunten van het GEMMA Gegevenslandschap. VNG Realisatie ziet namens gemeenten toe op naleving van de principes en stelt ze waar nodig bij naar aanleiding van opgedane leerervaringen en voortschrijdend inzicht.

Bij ieder principe wordt toegelicht waarom het belangrijk is en wat de implicaties van gebruik zijn. Bij de formulering van principes is de we-vorm gebruikt. Naast gemeenten worden hiermee ook andere partijen bedoeld die bijdragen aan de ontwikkeling van het GEMMA Gegevenslandschap zoals samenwerkingsverbanden en softwareleveranciers. In veel gevallen zijn de beschreven implicaties voorzien van een voorbeeld ter verduidelijking.

De European Interoperability Reference Architecture (EIRA), de Nederlandse Overheid Referentie Architectuur (NORA) en de Gemeentelijke Modelarchitectuur (GEMMA) zijn referentiearchitecturen voor respectievelijk Europese overheden, de Nederlandse overheid en de Nederlandse gemeenten. De GEMMA Gegevenslandschap-principes zoals beschreven in dit document bouwen voort op de algemene Architectuurprincipes en beschrijven de fundamentele keuzes om te kunnen komen tot het, door gemeenten gewenste, nieuwe type gegevenslandschap. Bijlage 1 beschrijft de relatie tussen principes van referentiearchitecturen, het Gegevenslandschap en lijn daarmee uitgevoerde veranderingen.

2. Informatiearchitectuurprincipes

2.1. COMPONENTGEBASEERD - We werken met ontkoppelde componenten

We werken met componenten die afgebakende functionaliteit kennen, zoveel mogelijk ontkoppeld zijn en met elkaar communiceren via gestandaardiseerde interfaces. We gebruiken een lagenmodel waarin we onderscheid maken tussen functionaliteit voor ‘interactie’, ‘procesinrichting’, ‘integratie’, ‘diensten’ en ‘gegevensbronnen’.

In lijn met de EIRA, NORA en GEMMA wordt gebruik gemaakt van service-oriëntatie als leidende architectuurstijl, aangevuld met inzichten uit nieuwere architectuurstijlen zoals gebeurtenis gedreven architectuur.

Rationale

Werken met autonome ontkoppelde componenten in plaats van met geïntegreerde (silo)systemen draagt bij aan flexibiliteit in de informatievoorziening die gemeenten in staat stelt om wendbaar en snel te opereren.

Implicaties

1. De diensten die componenten leveren worden ontworpen en gebruikt volgens gangbare service-oriëntatie principes die bijdragen aan het vergroten van interoperabiliteit:
   
   

   Zowel de EIRA-, NORA- als GEMMA-referentiearchitectuur gebruikt serviceoriëntatie als architectuurstijl. Het GEMMA Gegevenslandschap is bedoeld om gericht benodigde functionaliteit te realiseren. Het kijkt daarbij ook naar wereldwijd gebruikte gangbare standaarden. Voor het typeren van service-oriëntatie principes maken wij daarom gebruik van de beschrijving zoals die is te vinden op serviceorientation.com.

   
   
   1. Autonomie - "Services exercise a high level of control over their underlying runtime execution environment"
      Componenten zijn zelfstandig inzetbaar, schaalbaar en vervangbaar.
      
   2. Losse koppeling - "Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment"
      Componenten zijn onderling onafhankelijk en zelfstandig door te ontwikkelen en gebruiken.
   3. Herbruikbaar - "Services contain and express agnostic logic and can be positioned as reusable enterprise resources"
      Componenten zijn vaker in te zetten door ze in verschillende omgevingen te gebruiken of door een component vaker te instantiëren binnen één omgeving.
   4. Samenstelbaar - "Services are effective composition participants, regardless of the size and complexity of the composition"
      Componenten kunnen worden gecombineerd tot nieuwe componenten.
   5. Abstractie - "Service contracts only contain essential information and information about services is limited to what is published in service contracts"
      Afnemers hoeven alleen de functionaliteit van een component te kennen en niet de interne werking ervan.
   6. Service-contract - "Services within the same service inventory are in compliance with the same contract design standards"
      Een component kent duidelijke voorwaarden en leveringsafspraken over de kwaliteit en het volume van mogelijk gebruik door afnemers.
   7. Vindbaar - "Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted"
      Services zijn voorzien van metadata en zijn goed vindbaar.
   8. Toestandsloos - "Services minimize resource consumption by deferring the management of state information when necessary"
      Componenten die diensten leveren bewaren geen statusinformatie (maar laten dit over aan afnemers of gespecialiseerde componenten).
      
      

      Een voorbeeld hiervan is het ‘Hypermedia as the Engine of Application State’ (HATEOAS) onderdeel van de REST-architectuurstijl waarbij een dienstverlener geen statusinformatie over lopende transacties bijhoudt maar informatie over mogelijke vervolgstappen verstrekt aan dienstafnemers die daarmee zelf vervolgacties kunnen bepalen.

      
      
2. Componenten leveren conform de binnen het GEMMA Gegevenslandschap opgestelde specificaties:
   1. Functies (doet wat beschreven is dat het moet doen).
   2. Interfaces (biedt en gebruikt beschreven interfaces).
   3. Standaarden (gebruikt verplicht gestelde standaarden)
   4. Niet-functionele vereisten (bijvoorbeeld ten aanzien van informatiebeveiliging en logging).
3. Componenten conformeren zich aan het vijf-lagenmodel, wat impliceert:
   1. Componenten beperken zich tot functionaliteit binnen de laag waartoe ze behoren (bijvoorbeeld een frontend-applicatie beperkt zich tot presentatie en kent geen eigen bronregister). Als er goede redenen voor zijn, mag een component conform het pas-toe-of-leg-uit principe ook functionaliteit uit de onderliggende laag realiseren (bijvoorbeeld een front-end-applicatie die ook procesfunctionaliteit bevat omdat daarvoor geen bruikbare component beschikbaar is).
   2. Componenten voor interactie- en procesfunctionaliteit vragen gegevens op bij de bron via gestandaardiseerde interfaces (bijvoorbeeld een app vraagt brongegevens op via aanroep van een gestandaardiseerde API).
   3. Componenten bewerken geen brongegevens anders dan bij de bron (bijvoorbeeld een app corrigeert een opgevraagd brongegeven niet in een lokale schaduwregistratie maar ondersteunt het aanpassen van het betreffende gegeven in het bronregister).
   4. Mobiele componenten zoals apps richten zich op specifieke dienstverlening (bijvoorbeeld een app waarmee inwoners gemakkelijk vrije parkeerplaatsen kunnen vinden).
4. Bij gebruik van componenten wordt voldaan aan de voor gemeenten van toepassing zijnde normen en standaarden voor informatiebeveiliging, authenticatie, autorisatie en audit-logging (bijvoorbeeld de Baseline Informatiebeveiliging Overheid (BIO)). Naast component-gebonden functionaliteit kan hiervoor ook gebruik worden gemaakt van gespecialiseerde voorzieningen in de omgeving waar componenten actief zijn.

2.2. OPEN - We zijn transparant waar mogelijk

We willen transparant zijn in hoe we gegevens en applicaties gebruiken. Het delen en gebruiken van gegevens wordt slechts beperkt door wetgeving en niet door ideeën over het gebruik van gegevens. We bieden andere partijen de mogelijkheid om hierop diensten te ontwikkelen.

Rationale

Vanuit de maatschappij komt steeds meer vraag naar inzicht in hoe de overheid werkt, welke gegevens zij vastlegt en hoe beslissingen tot stand komen. Door als overheid open te zijn waar dit kan, wordt de informatiepositie van klanten versterkt, wordt publiek/private samenwerking gefaciliteerd en neemt het vertrouwen in de overheid toe. Door gemeentelijke gegevens zoveel mogelijk te ontsluiten zijn ze, zowel binnen als buiten de gemeente, efficiënt te gebruiken voor verschillende doelen.

Implicaties

1. We gebruiken open standaarden die publiekelijk beschikbaar zijn en waarvan de specificaties vrij van licentierechten mogen worden toegepast, gebruikt en gehanteerd. We werken daarbij conform de aanbevelingen van het Forum Standaardisatie (bijvoorbeeld gebruik van OpenAPI Specification en JSON standaard).
2. Gegevens worden conform de geldende bewaar- en vernietigingstermijnen uit de vigerende wet- en regelgeving behandeld en beschikbaar gesteld.
3. Digitale voorzieningen voor het interactief opvragen van gegevens voldoen aan wettelijke eisen rondom digitale toegankelijkheid (bijv. zoals vastgelegd in de Algemene Maatregel van Bestuur ‘Tijdelijk besluit digitale toegankelijkheid overheid’).
4. We geven inzicht in wat we als overheid doen en op basis waarvan keuzes worden gemaakt (bijvoorbeeld door inzage in gegevensgebruik te geven en inzicht te geven in hoe algoritmes werken).
5. Voor open data geldt:
   1. Alle gegevensverzamelingen die maatschappelijk of economisch waardevol zijn en waarvoor geen beperkingen vanuit wetgeving of hun classificatie gelden worden als open data beschikbaar gesteld (bijvoorbeeld gegevens over door de gemeente verstrekte subsidies).
   2. Bij het ontwerpen en implementeren van bronregisters wordt rekening gehouden met het beschikbaar stellen daarvan als open data (bijvoorbeeld door gegevens geanonimiseerd te kunnen verstrekken).
   3. Open data wordt op inhoud, context en techniek gestandaardiseerd zodat gemeenten eenduidig datasets samenstellen en publiceren. We beschrijven data met behulp van het Metamodel voor Informatiemodellen (MIM) en daarin beschreven modellen (bijv. een logisch informatiemodel). Er wordt gebruik gemaakt van landelijke standaarden (bijv. de Lijst open standaarden Forum Standaardisatie) en van reeds bestaande inhoudelijke standaarden (bijv. raadsinfomatie, stembureaus en andere onderwerpen).
   4. Open data wordt (ook) kenbaar gemaakt op de daarvoor beschikbare overheidsbrede publicatiekanalen (bijvoorbeeld data.overheid.nl en het Nationaal Georegister).

2.3. VERTROUWD - We zorgen dat informatiebeveiliging en privacy op orde zijn

We houden ons aan wettelijke richtlijnen, nemen risico mitigerende maatregelen, en verantwoorden naar betrokkenen wat we doen. We zorgen voor een goede beveiliging van gegevens en garanderen privacy door middel van een samenhangend geheel van technische, organisatorische, fysieke en procedurele maatregelen.

Rationale

In een steeds meer informatiegedreven samenleving moeten burgers er op kunnen vertrouwen dat gemeenten rechtmatig handelen en gegevens beschermen tegen onbevoegd gebruik, diefstal en verlies. Permanente aandacht voor informatiebeveiliging en bescherming van de privacy zijn noodzakelijk om aan wettelijke vereisten en de verwachtingen van burgers te kunnen voldoen.

Implicaties

1. Informatiebeveiliging en privacy worden integraal meegenomen bij ontwerp en inrichting van applicaties en infrastructuur (bijvoorbeeld door hier vanaf de start aandacht aan te besteden en niet pas aan het einde (‘privacy en security by design’).
2. De wettelijke grondslag en het doel waarvoor gegevens gebruikt mogen worden is vastgelegd in wet- en regelgeving. We verwerken gegevens conform wet en regelgeving (bijvoorbeeld door controles op doelbinding en voldoen aan de beginselen van subsidiariteit en proportionaliteit voordat gegevens worden verstrekt).
3. Bij nieuwe voorzieningen zijn de meest veilige instellingen het uitgangspunt (‘security en privacy by default’) (bijvoorbeeld door niet benodigde functionaliteit uit te schakelen).
4. Als verwerker van gegevens nemen we maatregelen om risico's te beperken zoals het minimaliseren, scheiden, abstraheren of verbergen van gegevens (bijvoorbeeld door niet meer gegevens te verstrekken dan nodig is voor het betreffende doel).
5. Als verwerker van informatie laten we zien zorgvuldig om te gaan met gegevens (bijvoorbeeld door het actief informeren van betrokkenen, het transparant zijn over plaatsgevonden gegevensgebruik en afleggen van verantwoording).
6. Private en openbare netwerken voor gegevensuitwisseling worden, passend bij het vereiste betrouwbaarheidsniveau van diensten, afdoende beveiligd, gemonitord en geanalyseerd (bijvoorbeeld door gebruik te maken van certificaten om de identiteit van partijen vast te stellen).
7. Als gegevenshouder bewaken we de toegang tot vertrouwelijke gegevens en maken afspraken met afnemers van gegevens over toegestaan gebruik daarvan. Bij afwijking van de afspraken nemen we passende maatregelen (bijvoorbeeld door toegang tot gegevens te blokkeren en melding te maken van misbruik van gegevens).
8. Afnemers van gegevens zijn verantwoordelijk voor behoorlijk gegevensgebruik (bijvoorbeeld geëxpliciteerd door een toestemmingsverklaring te eisen voorafgaand aan levering van gegevens).
9. Bij uitwisseling van gegevens vindt authenticatie plaats op het niveau van de identiteit van de afnemende organisatie (‘gedelegeerde autorisatie’). De afnemende organisatie is binnen haar eigen organisatie verantwoordelijk voor afdoende authenticatie en autorisatie (bijvoorbeeld door op basis van aanwezige doelbinding te bepalen tot welke gegevens een gebruiker of applicatie toegang krijgt).
10. Een afnemende organisatie is verplicht een verwerkingenregister conform de AVG te gebruiken.
11. Bij ieder verzoek om gegevens wordt een ‘doelbindingsclaim’ vastgelegd om te kunnen vaststellen of een plaatsgevonden verwerking rechtmatig was (bijvoorbeeld bij het gebruik van persoonsgegevens tijdens een administratieve handeling).
12. Activiteiten van gebruikers, uitzonderingen en informatiebeveiligings-gebeurtenissen worden vastgelegd in audit-logbestanden. Gegevensuitwisselingen worden gelogd om een sluitende audit-trail van informatietransacties te vormen (bijvoorbeeld door zowel bij de dienstenaanbieder als dienstenafnemer in samenhang gegevens vast te leggen over plaatsgevonden gegevensuitwisselingen).
13. De integriteit van audit-logbestanden wordt bewaakt (bijvoorbeeld door toegang te beperken of technische maatregelen zoals het gebruik van checksums).
14. Audit-logbestanden zijn gestandaardiseerd, duurzaam toegankelijk en geschikt voor audits en het kunnen inzien van persoonsgebonden informatie door burgers (bijvoorbeeld door via portalen zoals MijnOverheid of een gemeentelijk portaal inzage te bieden in het plaatsgevonden gebruik van persoonlijke gegevens).
15. Gegevens worden conform de geldende bewaar- en vernietigingstermijnen uit de vigerende wet- en regelgeving behandeld. Gegevens worden waar nodig gearchiveerd, vernietigd en/of duurzaam opgeslagen en beschikbaar gesteld (bijvoorbeeld door al bij de vastlegging van gegevens maatregelen te nemen die een juiste bewaring of vernietiging mogelijk maken).
16. Naast het toepassen van architectuurprincipes moeten bij de implementatie van voorzieningen binnen de context toe te passen beveiligingsmaatregelen worden getroffen (op hoofdlijnen beschreven in de Baseline Informatiebeveiliging Overheid) of privacymaatregelen (bijv. conform de Algemene verordening gegevensbescherming (AVG), de Uitvoeringswet AVG (UAVG) of de Wet basisregistratie personen (BRP).

2.4. EENMALIGE VASTLEGGING - We leggen gegevens eenmalig vast en vragen op bij de bron

We winnen gegevens eenmalig in, leggen ze eenmalig vast en gebruiken ze meervoudig. Net zoals bij de landelijke basisregistraties is gebeurd, standaardiseren we ook andere soorten brongegevens en leggen die vast in registers. Brongegevens worden alleen bewerkt bij de bron. Processen slaan geen kopieën van die gegevens op, maar vragen ze op via gestandaardiseerde interfaces uit registers.

Rationale

Eenmalig gestandaardiseerd vastleggen en (her)gebruiken van gegevens maakt het mogelijk om te voldoen aan geldende eisen vanuit wet- en regelgeving en verhoogt de effectiviteit en efficiency van gegevensgebruik.

Implicaties

In de GEMMA Gegevenslandschap informatiearchitectuur wordt een bronregister beschreven als: “de bron waar de gegevens authentiek zijn opgeslagen”. Bronregisters zijn nodig voor vastlegging van basisregistratiegegevens, kernregistratiegegevens en sectorale gegevens. Ook voor taak-specifieke gegevens geldt in toenemende mate dat vastlegging in een bronregister en gestandaardiseerde ontsluiting nodig is (bijvoorbeeld om ze voor meerdere doelen en via verschillende interactievoorzieningen beschikbaar te stellen).

1. Ten aanzien van bronregisters geldt:
   1. Gegevens kennen één bron (bijvoorbeeld een basisregistratie of gemeentelijke kernregistratie).
   2. Bij ieder gegeven is aangegeven welke kwaliteit het heeft om de bruikbaarheid te kunnen vaststellen (bijvoorbeeld in de vorm van een inwinningsdatum).
   3. Bij bronregisters standaardiseert de bronhouder in overleg met stakeholders de semantiek, syntax en samenhang van gegevens (bijv. in de vorm van een begrippen- en informatiemodel).
   4. Standaardisatie van gemeentelijke bronregisters vindt plaats onder regie van gemeenten (bijvoorbeeld bij het opstellen van nieuwe informatiemodellen).
   5. Daar waar landelijk vastgestelde catalogi bestaan ten aanzien van gegevens worden deze gevolgd (bijvoorbeeld de basisregistraties en het Suwi gegevensregister.
   6. Bronregisters worden beschreven met behulp van het Metamodel voor Informatiemodellen (MIM) en de daarin beschreven modellen (begrippenmodel, conceptueel informatiemodel, logisch informatie- of gegevensmodel, fysiek- of technisch gegevens- of datamodel).
   7. Iedere gegevensbron heeft een eigenaar die verantwoordelijk is voor beschikbaarheid, integriteit, vertrouwelijkheid, volledigheid en kwaliteit. Voor andere verantwoordelijkheden rondom beheer en gebruik van gegevens verwijzen we naar het GEMMA Gegevensfunctiehuis waarin met behulp van een RACI-matrix rollen en verantwoordelijkheden zijn beschreven in relatie tot gegevensmanagement, privacy en informatiebeveiliging.
   8. Bronregisters en daarvan gebruikmakende diensten ondersteunen formele historie (dat wat wijzigt in de registratie) en materiële historie (dat wat wijzigt in de werkelijkheid) (bijvoorbeeld om te kunnen constateren vanaf welk moment een nieuw gegeven administratief was vastgelegd).
   9. Bij gegevensuitwisseling maken bronhouder en gebruiker afspraken door middel van een gegevensleveringsovereenkomst en verwerkersovereenkomst (bijvoorbeeld over doel en gebruikstermijn).
   10. Vermeende onjuistheden in gegevens worden door afnemers terug gemeld aan de bronhouder.
2. Ten aanzien van uitwisseling en beschikbaarstelling geldt:
   1. Brongegevens worden niet als kopie-gegeven opgeslagen.
   2. Processen worden genotificeerd over een gebeurtenis waarna de eventueel benodigde gegevens daarover zijn op te vragen (“informatie-arm notificeren”); er vindt geen gegevensdistributie plaats.
      
      

      De manier waarop processen de beschikking kunnen krijgen over brongegevens via het mechanisme van ‘abonneren en notificeren’ is een afzonderlijke notitie beschreven.

      
      
   3. Brongegevens worden, bij voorkeur real-time, opgehaald bij de bron op het moment dat ze nodig zijn (bijvoorbeeld via aanroep van een gestandaardiseerde API van een gegevensdienst).
   4. Gegevensuitwisselingen zijn uniek identificeerbaar, worden gelogd en voorzien van relevante contextinformatie en metadata; dit alles binnen wettelijke kaders en mogelijke afwijking in bijzondere gevallen (bijvoorbeeld bij criminaliteitsbestrijding, terrorisme, ondermijning, fraudebestrijding).
   5. Voor uitwisseling van gegevens wordt gebruik gemaakt van diensten met gestandaardiseerde API’s (bijvoorbeeld een RESTful API die brongegevens in JSON-formaat levert).
   6. De manier waarop gegevens worden geleverd past bij de gevoeligheid van betrokken gegevens (bijvoorbeeld vertrouwelijke gegevens alleen via veilige kanalen en netwerken, belangrijke transactiegegevens met gegarandeerde aflevering).
   7. Gegevens en bedrijfsregels worden beschikbaar gesteld via diensten die beschikken over gestandaardiseerde interfaces die:
      1. Beschreven zijn met standaard beschrijvingstalen (bijvoorbeeld het Open API Specification protocol).
      2. Vindbaar zijn in een centrale catalogus (bijvoorbeeld de website developer.overheid.nl waar door (semi-)overheidsorganisaties aangeboden API’s zijn vermeld).
      3. Aangeboden worden via integratievoorzieningen (bijvoorbeeld een API-gateway).
      4. Alleen bruikbaar zijn na afdoende authenticatie en autorisatie (bijvoorbeeld via het gebruik van certificaten of tokens).
   8. Gegevensdiensten zijn atomair, consistent, isoleerbaar en duurzaam (ACID) (bijvoorbeeld bij transacties waarbij gegevens uit verschillende bronnen betrokken zijn).
   9. Informatie- en gegevensdiensten verstrekken gegevens proportioneel en subsidiair. Ze bevatten niet meer gegevens dan wat minimaal noodzakelijk is voor het verwerkingsdoel (bijvoorbeeld door persoonsgegevens bij een verstrekking te minimaliseren).
   10. Gegevens moeten zodanig beschikbaar zijn dat interactie tijd-, plaats- en apparaat-onafhankelijk kan plaatsvinden (bijvoorbeeld door brongegevens 24x7 beschikbaar te stellen en interfaces te bieden die voor verschillende typen interactie-applicaties bruikbaar zijn).
   11. Bij interactie-applicaties waar ophalen van brongegevens niet mogelijk is, en lokale opslag om functionele redenen vereist is, moeten bij gebruik van vertrouwelijke gegevens hoge beveiligingsmaatregelen worden getroffen (bijvoorbeeld bij apps die gebruikt worden in omstandigheden waarin geen netwerk beschikbaar is).

2.5. REGIE OP GEGEVENS - We faciliteren regie op gegevens

We verbeteren de informatiepositie van burgers en bedrijven door relevante gegevens te ontsluiten en inzicht te geven in wie welke gegevens gebruikt en uitwisselt. Burgers en bedrijven krijgen de mogelijkheid om toestemmingen ten aanzien van de uitwisseling van gegevens te beheren en, waar mogelijk, gegevens die op hen betrekking hebben te wijzigen.

Rationale

Partijen die daartoe gerechtigd zijn, moeten regie kunnen voeren op welke gegevens aan wie, op welk moment en voor welk doel, worden verstrekt. Persoonlijk datamanagement draagt bij aan transparantie, inzage en correctie, digitale zelfbeschikking, privacy, dataminimalisatie, kwaliteitsverbetering van gegevens en de zelfredzaamheid van mensen.

Implicaties

1. Ten aanzien van burgers en bedrijven als partijen met zeggenschap over hun gegevens geldt:
   1. We stellen burgers in staat om hun AVG-conforme rechten op informatie, kopie, vergetelheid en beperking uit te oefenen waar dit juridisch mogelijk is, bij:
      1. Hun eigen gegevens (incl. inhoudelijke dossiers en gegevens in sectorale registraties);
      2. Gegevens die zijn gebruikt om tot een besluit te komen en de regels die daarbij zijn gehanteerd (traceerbaarheid);
      3. Gegevens die zijn ingezien en gebruikt (transparantiebeginsel): burgers krijgen direct online inzicht in de actuele verwerking van hun gegevens en de daarvoor gehanteerde doelbindingsclaims.
   2. Burgers kunnen toestemming geven voor het gebruik van hun eigen gegevens bij taken waarvoor geen expliciete wettelijke grondslag bestaat (bijvoorbeeld door na een helder toegelicht verzoek met een digitale handtekening akkoord te geven voor een welomschreven gebruik van een set persoonsgegevens).
   3. Burgers en bedrijven worden proactief geïnformeerd over zaken waarvan zij hebben aangegeven dat zij er over geïnformeerd willen worden (bijvoorbeeld door notificaties te versturen als zich bepaalde gebeurtenissen voordoen).
2. Ten aanzien van de gemeente als gegevensverwerker geldt:
   1. Gemeenten beslissen binnen wettelijke kaders voor wie, welke gegevens beschikbaar worden gesteld (bijvoorbeeld door via attribuut gebaseerde toegangscontrole in te stellen wie tot welke gegevens toegang kan krijgen).
   2. Gemeenten bepalen hoe zij gegevens beschikbaar stellen voor gebruik door applicaties (bijvoorbeeld door standaard API’s die via een gemeenschappelijke integratievoorziening voor gebruik door derden beschikbaar worden gesteld).

2.6. STANDAARD - We standaardiseren maximaal

We gebruiken zoveel mogelijk, bij voorkeur open, standaarden. Waar ze nodig zijn maar nog ontbreken gaan we ze samen met leveranciers ontwikkelen. Standaardiseren is van belang bij alle soorten functionaliteit die binnen het GEMMA Gegevenslandschap wordt onderscheiden.

Rationale

Gemeenten werken samen met steeds meer partijen. Afspraken en standaarden zijn nodig om effectief, efficiënt en veilig samen te kunnen werken en informatie uit te wisselen. Ze zijn ook nodig om voldoende onafhankelijk te blijven van partijen en de juiste samenwerkingspartners te kunnen kiezen.

Implicaties

1. We gebruiken open standaarden conform de richtlijnen van het Forum Standaardisatie.
2. We gebruiken ook niet-verplichte standaarden (bijvoorbeeld de door het Forum Standaardisatie aanbevolen JSON-standaard voor uitwisselen van gegevens).
3. Als er behoefte aan is gaan we samen met leveranciers nieuwe standaarden ontwikkelen (bijvoorbeeld informatiemodellen en API-specificaties).
4. We gebruiken ook niet-verplicht te gebruiken landelijke catalogi, voorzieningen en bouwstenen (bijvoorbeeld de bouwsteen Samenwerkende Catalogi).
5. We standaardiseren gegevensmodellering, ontsluiting en integratie van gegevens (bijvoorbeeld door gezamenlijk gestandaardiseerde bronregisters, API’s en integratievoorzieningen te ontwikkelen).
6. Logging en auditing zijn gestandaardiseerd (bijvoorbeeld door standaardisering van het verwerkingsregister en gestandaardiseerde vastlegging van verwerkingsgegevens).
7. Standaarden moeten in de praktijk eenvoudig bruikbaar zijn (bijvoorbeeld door gebruik te maken van relatief eenvoudig te gebruiken stijlen zoals REST en het JSON-gegevensformaat).
8. We gebruiken en ontwikkelen (ook) domein en taak-specifieke standaarden (bijvoorbeeld voor vastlegging en ontsluiting van domein-specifieke gegevens)
9. De API-strategie voor de Nederlandse overheid is leidend bij het ontwikkelen en gebruiken van API’s (bijvoorbeeld API’s te ontwikkelen conform de daarin gedane aanbevelingen).
10. Bij beschrijving van API’s worden ook authenticatiemogelijkheden en testfaciliteiten beschreven (bijvoorbeeld door aan te geven welke authenticatiemechanismen worden ondersteund en hoe testfaciliteiten zijn te gebruiken).
11. Bij standaardisatie van gemeentelijke processen maken we maximaal gebruik van gestandaardiseerde API’s (bijvoorbeeld door bij modelleren van processen rekening te houden met de beschikbaarheid van API’s).

Bijlage 1: Relaties tussen architecturen

De European Interoperability Reference Architecture (EIRA), de Nederlandse Overheid Referentie Architectuur (NORA) en de Gemeentelijke Model Architectuur (GEMMA) zijn referentiearchitecturen voor respectievelijk Europese overheden, de Nederlandse overheid en de Nederlandse gemeenten. De EIRA is te zien als de Europese moeder van NORA, NORA als de Nederlandse moeder van GEMMA. Zowel de EIRA, de NORA, de GEMMA en het Gegevenslandschap gebruiken de service-georiënteerde architectuurstijl.

Voor een dochter-architectuur geldt dat haar architectuurprincipes in lijn moeten zijn met de principes van de moeder-architectuur. Voor gemeenten betekent dit dat door gebruik te maken van de GEMMA-principes er impliciet in lijn met de NORA- en EIRA-principes wordt gewerkt.

De GEMMA Gegevenslandschap informatiearchitectuurprincipes bouwen voort op de GEMMA-architectuurprincipes. Ze beschrijven de fundamentele keuzes van het GEMMA Gegevenslandschap om te kunnen komen tot het nieuwe, door gemeenten gewenste, gegevenslandschap.

De GEMMA is ‘neutraal’ van karakter en door gemeenten op verschillende manieren te gebruiken bij het inrichten van hun eigen lokale informatievoorziening. Het GEMMA Gegevenslandschap is gericht op het collectief van gemeenten en sterker sturend dan de GEMMA in hoe de informatievoorziening moet worden ingericht.

De architectuurprincipes van het Gegevenslandschap zijn concreter van aard en geven meer richting aan hoe realisatie van voorzieningen plaats moet vinden. GEMMA kent het principe: ‘Onze gemeente hergebruikt gegevens’ waarbij iedere gemeente zelf bepaalt hoe zij dit principe toepast. Het Gegevenslandschap bouwt voort op het algemene GEMMA-principe en maakt het concreter: ‘We leggen gegevens eenmalig vast en vragen op bij de bron’. Een implicatie van dit principe is dat gemeenten collectief moeten werken aan het ontwikkelen en standaardiseren van bronregisters en de verstrekking van daarin opgeslagen gegevens via informatie-arme notificaties.

De GEMMA Gegevenslandschap architectuur is richtinggevend voor nieuwe ontwikkelingen waarbij gemeenten, vaak collectief, nieuwe vormen van informatievoorziening realiseren. Afhankelijk van de context kunnen, aanvullend op de Gegevenslandschap principes, eigen context-specifieke principes worden opgesteld. Zo gebruikt Common Ground de informatiearchitectuurprincipes van het GEMMA Gegevenslandschap. Aanvullend zijn er ook eigen (realisatie)principes opgesteld die beschrijven welke fundamentele keuzes de Common Ground heeft gemaakt met betrekking tot hoe zij haar doelen wil realiseren. Het Gegevenslandschap kent bijvoorbeeld het principe ‘We werken met componenten’. Common Ground concretiseert dit en kent als realisatieprincipe: ‘We ontwikkelen en gebruiken NLX als gateway’.

Er is dus sprake van een gelaagd model van architectuurprincipes waarbij principes uit een hoger gelegen laag het kader vormen voor principes in daaronder gelegen lagen. In onderstaande afbeelding is afgebeeld hoe deze zich globaal tot elkaar verhouden.

Relaties tussen verschillende architectuurprincipes

De architectuurprincipes van de GEMMA-referentiearchitectuur en de architectuurprincipes van het GEMMA Gegevenslandschap moeten uiteraard op elkaar zijn afgestemd. In onderstaande afbeelding is aangegeven hoe de algemene architectuurprincipes van de GEMMA-referentiearchitectuur zijn gerelateerd aan de architectuurprincipes van het GEMMA Gegevenslandschap.

Relatie tussen algemene GEMMA principes en GEMMA Gegevenslandschap principes

Een tweetal constateringen op basis van de weergegeven relaties:

• Er zijn veel relaties tussen GEMMA-principes en de Gegevenslandschap-principes ‘We werken met componenten’, ‘We zorgen dat informatiebeveiliging en privacy op orde zijn’, ‘We leggen gegevens eenmalig vast en vragen op bij de bron’ en ‘We standaardiseren maximaal’.  Werken in lijn met deze principes om te komen tot een vernieuwde informatievoorziening draagt dus ook in sterke mate bij aan realisatie van de doelen van de GEMMA-referentiearchitectuur.
• De principes 'We zijn transparant waar mogelijk' en 'We faciliteren regie op gegevens' zijn sterk gerelateerd aan GEMMA-principes waarbij het belang van burgers voorop staat. De Gegevenslandschap-principes helpen gemeenten om te kunnen voldoen aan de toenemende eisen en wensen op het gebied van privacy en transparantie. Daarmee kunnen gemeenten GEMMA-doelen als ‘het denken vanuit de klant’, ‘verbeteren van de informatiepositie van burgers’ en ‘borgen van vertrouwelijkheid’ in de praktijk realiseren.

Bijlage 2: Infographic met informatiearchitectuurprincipes

Op deze pagina is een infographic afgebeeld met daarop de informatiearchitectuurprincipes van het GEMMA Gegevenslandschap.

Doel van de infographic is om de architectuurprincipes op een compacte, meer visuele manier, weer te geven zodat ook voor niet-architecten duidelijk is welke principes het GEMMA Gegevenslandschap kent en wat de kernboodschap van ieder principe is.

Infographic met informatiearchitectuurprincipes

De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.

De fundamentele concepten of eigenschappen van een systeem in zijn omgeving belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.

Sjabloonoplossing voor de architectuur van een bepaald domein. (Synoniem van: Referentiearchitectuur )

Interactie in de context van overheidsdienstverlening betreft de (digitale) gegevensuitwisseling en wisselwerking tussen burgers en bedrijven en de overheid(sorganisaties).

Een manier van denken in termen van services, service-based ontwikkeling en de uitkomsten van services.

Het geheel van mensen, middelen en maatregelen, gericht op de informatiebehoefte van de organisatie.

Sjabloonoplossing voor de architectuur van een bepaald domein.

Een door een applicatie geleverde dienst (te gebruiken via applicatieinterfaces).

Een door een applicatie geleverde dienst (te gebruiken via applicatieinterfaces).

Afkorting voor de Representational State Transfer architectuurstijl voor gedistribueerde hypermedia systemen

De persoon of organisatie die voorziet in het leveren van een afgebakende prestatie (dienst) aan haar omgeving (de afnemers).

Betekenisvolle gegevens.

Het proces van vaststellen van de vereiste betrouwbaarheid van informatiesystemen in termen van vertrouwelijkheid, beschikbaarheid en integriteit alsmede het treffen, onderhouden en controleren van een samenhangend pakket van bijbehorende maatregelen.

Een computerprogramma om een specifieke taak uit te voeren die geen betrekking heeft op de werking van de computer zelf.

Afkorting van 'application programming interface': een manier om twee of meer computerprogramma's met elkaar te laten communiceren. Het is een soort software-interface die een dienst aanbiedt aan andere stukjes software.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.

Het aantonen dat degene die zich identificeert ook daadwerkelijk degene is die zich als zodanig voorgeeft: ben je het ook echt? Authenticatie noemt men ook wel verificatie van de identiteit.

Het proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen.

Het proces van vaststellen van de vereiste betrouwbaarheid van informatiesystemen in termen van vertrouwelijkheid, beschikbaarheid en integriteit alsmede het treffen, onderhouden en controleren van een samenhangend pakket van bijbehorende maatregelen.

Een document met erkende afspraken, specificaties of criteria over een product, een dienst of een methode.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. (Synoniem van: Data )

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.

Gestructureerde beschrijving van de structuur, semantiek en de eigenschappen van informatie over dingen in de werkelijkheid.

Het geheel van voorzieningen dat nodig is om een land of organisatie, zoals een bedrijf of een instelling, goed te laten functioneren.

Het verstrekken aan en ontvangen van gegevens tussen (informatiesystemen van) overheidsorganisaties onderling en (informatiesystemen van) andere organisaties of personen.

Mate waarin vertrouwen kan worden gesteld in een identificatiemiddel, gebaseerd op de mate van zekerheid waarmee attributen, identiteiten, identificatiemiddelen en/of bevoegdheden zijn vastgesteld.

De eenheid van wezen, volkomen overeenstemming en gelijkheid. Dat wat uniek of eigen is aan iets of iemand. Het kan daarbij gaan om zowel personen als organisaties of landen.

Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem.

Een door de overheid officieel aangewezen registratie met daarin gegevens van hoogwaardige kwaliteit, die door alle overheidsinstellingen verplicht en zonder nader onderzoek, worden gebruikt bij de uitvoering van publiekrechtelijke taken.

Een door een organisatie tot bronregistratie benoemde registratie. Kernregistraties zijn bronregistraties.

Leer van de betekenis van woorden en woordgroepen

Het opleggen van een bepaalde norm of standaard voor het ontwerp, de constructie, het testen of gebruiken van een product of proces.

Het integraal en beheerst verwerken van gegevens in een organisatie zowel op strategisch tactisch als operationeel niveau met als doel de gewenste kwaliteit en beschikbaarheid te realiseren.

Iets dat binnen of buiten een organisatie is gebeurd en binnen die organisatie of daarbuiten gevolgen heeft.

JavaScript Object Notation (JSON) is een lichtgewicht, op tekst gebaseerd, taalonafhankelijk gegevensuitwisselingsformaat.

Alle belanghebbenden van overheidsdienstverlening in de ruimste zin van het woord.

Alle belanghebbenden van overheidsdienstverlening in de ruimste zin van het woord.

Systematische en meestal in een informatiesysteem opgeslagen beschrijvingen van instanties van concepten.

Het opleggen van een bepaalde norm of standaard voor het ontwerp, de constructie, het testen of gebruiken van een product of proces.

De fundamentele concepten of eigenschappen van een systeem in zijn omgeving belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.