Gegevens uit meerdere gemeentelijke applicaties combineer je binnen het Gemeentelijk Gegevensmodel (GGM) door gebruik te maken van een gedeeld conceptueel informatiemodel dat alle relevante domeinen beschrijft met gestandaardiseerde definities en relaties. Het GGM fungeert als een gemeenschappelijke taal tussen applicaties, zodat data uit bijvoorbeeld het sociaal domein, de openbare ruimte en vergunningverlening op een eenduidige manier aan elkaar gekoppeld kunnen worden. In dit artikel beantwoorden we de meest gestelde vragen over GGM-gegevensintegratie binnen gemeenten.
Welke gemeentelijke applicaties wisselen data uit via het GGM?
Via het GGM wisselen applicaties uit vrijwel alle gemeentelijke domeinen gegevens uit. Het model dekt domeinen als het Sociaal Domein (Wmo, Jeugd, Inkomen en Werk), Volkshuisvesting en de Openbare Ruimte, Vergunningverlening, Onderwijs, Mobiliteit en Parkeren, en de interne organisatie zoals Financiën en HR. Elke applicatie die binnen een van deze domeinen werkt, kan in principe via het GGM data uitwisselen met applicaties uit andere domeinen.
In de praktijk betekent dit dat een zaaksysteem voor vergunningverlening gegevens kan koppelen aan geo-informatiesystemen die werken met BGT/IMGeo-objecten, terwijl een applicatie voor schuldhulpverlening gegevens deelt met systemen in de keten Werk en Inkomen via het Suwi Gegevensregister (SGR). Applicaties voor meldingen in de openbare ruimte zijn dan weer gekoppeld aan objecten uit het Informatiemodel Beheer Openbare Ruimte (IMBOR).
Wat het GGM bijzonder maakt, is dat het niet alleen de domeinen beschrijft, maar ook de data-integratie tussen die domeinen mogelijk maakt door gedeelde kernobjecten te definiëren, zoals personen, adressen en gebouwen, die in meerdere domeinen voorkomen. Dit voorkomt dat elke applicatie zijn eigen definitie van een “klant” of een “locatie” hanteert.
Hoe werkt gegevensuitwisseling tussen applicaties binnen het GGM?
Gegevensuitwisseling binnen het GGM werkt via landelijke standaarden die in het model zijn verwerkt, zodat applicaties een gemeenschappelijke technische basis delen. In plaats van maatwerk-koppelingen tussen individuele systemen praten applicaties via gestandaardiseerde berichtformaten en informatiemodellen met elkaar. Dit verlaagt de integratielast aanzienlijk en maakt het eenvoudiger om een nieuwe applicatie aan te sluiten.
Concreet zijn in het GGM onder andere de volgende standaarden verwerkt:
- RSGB (versie 2.0.2) voor basisgegevens over personen, adressen en gebouwen
- RGBZ (versie 1.0) voor zaakgericht werken
- iWmo en iJw voor berichtenuitwisseling in het Sociaal Domein
- SGR (versie 4.0) voor de keten Werk en Inkomen
- GML 3.2.1 en NEN3610:2011 voor geo-informatie
- STTR/IMTR en STOP/TPOD voor de Omgevingswet
Door deze standaarden als fundament te gebruiken, sluit het GGM aan bij bestaande afspraken in de Nederlandse overheidsinfrastructuur. Applicaties hoeven dus geen nieuwe standaard te implementeren, maar kunnen voortbouwen op wat al landelijk is vastgelegd. Meer over het belang van een goede data-architectuur lees je op de pagina over data engineering.
Wat zijn de grootste knelpunten bij het combineren van gemeentelijke data?
De grootste knelpunten bij het combineren van gemeentelijke data zijn inconsistente datamodellen tussen applicaties, gebrekkige datakwaliteit en het ontbreken van een centrale regie op gegevensbeheer. Zelfs wanneer een gemeente het GGM als referentiemodel hanteert, is de praktische implementatie in bestaande systemen vaak weerbarstig, omdat applicaties zijn aangeschaft in verschillende perioden en door verschillende leveranciers zijn gebouwd.
Veelvoorkomende knelpunten zijn:
- Verschillende sleutels en identifiers: Applicaties gebruiken eigen identificatoren voor dezelfde entiteiten, zoals burgers of panden, waardoor koppeling handmatig of via complexe mapping moet plaatsvinden.
- Datakwaliteitsverschillen: De ene applicatie houdt adressen bij op straatniveau, de andere op postcodeniveau. Dit maakt directe vergelijking of samenvoeging lastig.
- Verouderde koppelingen: Bestaande interfaces zijn vaak gebouwd op oudere standaarden die niet aansluiten bij de huidige versies van RSGB of andere GGM-standaarden.
- Onvolledige GGM-compliance: Het GGM is nog niet volledig compliant met het Metamodel voor Informatiemodellen (MIM), wat integratie met sommige nieuwere systemen kan bemoeilijken.
- Organisatorische silo’s: Domeinen als het Sociaal Domein en de Openbare Ruimte werken vaak met eigen teams en budgetten, waardoor gegevensintegratie over domeingrenzen heen organisatorisch complex is.
Een goede aanpak begint met het in kaart brengen van de huidige gegevensstromen en het vaststellen waar de grootste inconsistenties zitten, voordat technische koppelingen worden gebouwd.
Welke rol speelt de database bij GGM-gegevensintegratie?
De database speelt een centrale rol bij GGM-gegevensintegratie: het is de plek waar gegevens uit meerdere bronnen samenkomen, worden getransformeerd, opgeslagen en beschikbaar gesteld voor analyse en rapportage. Een goed ingericht datamodel op databaseniveau is de technische vertaling van het conceptuele GGM en bepaalt in hoge mate hoe flexibel en betrouwbaar de integratie werkt.
Bij gemeentelijke gegevensintegratie via het GGM vervult de database doorgaans een van de volgende functies:
Centrale datahub of datawarehouse
Gegevens uit verschillende gemeentelijke applicaties worden naar een centrale database geladen, waar ze worden geharmoniseerd op basis van het GGM. Dit maakt domeinoverstijgende analyses mogelijk, zoals het combineren van Wmo-gegevens met gegevens over schuldhulpverlening om kwetsbare groepen in kaart te brengen.
Operationele integratielaag
In sommige architecturen fungeert de database als een tussenlaag die real-time of near-real-time gegevens uitwisselt tussen applicaties. Hierbij zijn performancebeheer en het bewaken van data-integriteit cruciaal. Slechte databaseprestaties kunnen hier directe gevolgen hebben voor de beschikbaarheid van gemeentelijke dienstverlening.
In beide gevallen geldt dat het databaseontwerp nauw moet aansluiten bij de structuur en de standaarden van het GGM. Een mismatch tussen het logische informatiemodel en de fysieke databasestructuur is een van de meest voorkomende oorzaken van integratiefouten en dataverlies bij gemeentelijke projecten.
Wanneer is externe databaseexpertise nodig voor GGM-integraties?
Externe databaseexpertise is nodig bij GGM-integraties zodra de complexiteit van de gegevensstromen, de vereiste beschikbaarheid of de technische staat van de bestaande databaseomgeving de capaciteit van het interne team overstijgt. Dit is vaker het geval dan gemeenten vooraf inschatten, omdat GGM-integraties meerdere domeinen en standaarden tegelijk raken.
Concrete situaties waarin externe expertise meerwaarde biedt:
- Bij migraties van legacy-systemen naar een nieuwe databaseomgeving die GGM-compliant moet zijn
- Wanneer performanceproblemen optreden doordat grote hoeveelheden domeinoverstijgende data worden gecombineerd
- Als de gemeente een centrale datahub wil inrichten maar intern geen ervaring heeft met het ontwerpen van complexe datamodellen
- Bij het opzetten van betrouwbare backup- en herstelprocessen voor kritieke integratiedatabases
- Wanneer de huidige databaseomgeving niet voldoet aan beveiligings- of privacyvereisten die gelden voor gevoelige gemeentelijke data, zoals gegevens uit het Sociaal Domein
Externe specialisten kunnen ook helpen bij het uitvoeren van een onafhankelijke beoordeling van de bestaande databasearchitectuur, zodat knelpunten worden geïdentificeerd voordat een groot integratieproject van start gaat. Meer over Microsoft Fabric voor de overheid laat zien hoe moderne platformen gemeenten kunnen ondersteunen bij het centraliseren van data.
Hoe DBA helpt met GGM-gegevensintegratie
Wij begrijpen dat GGM-integraties voor gemeenten geen standaard IT-project zijn. Ze raken meerdere domeinen, meerdere applicaties en meerdere standaarden tegelijk, terwijl de beschikbaarheid van gemeentelijke dienstverlening niet in het geding mag komen. Onze senior database administrators helpen gemeenten op de volgende manieren:
- Databaseontwerp en -inrichting die aansluit bij de structuur van het GGM en de toegepaste landelijke standaarden
- Performanceanalyse en -optimalisatie van bestaande integratiedatabases die trager worden naarmate meer domeinen worden gekoppeld
- Migratiebegeleiding bij het overzetten van gegevens naar een nieuwe, GGM-conforme omgeving
- Proactief beheer en monitoring met dagelijkse backup-controles en periodiek onderhoud, zodat de integratie stabiel blijft
- Advies over beveiliging en governance voor gevoelige gemeentelijke data, zoals persoonsgegevens uit het Sociaal Domein
Of je nu een nieuwe datahub wilt inrichten, een bestaande omgeving wilt optimaliseren of gewoon wilt weten waar de knelpunten zitten: we denken graag concreet met je mee. Neem contact met ons op voor een vrijblijvend gesprek over jouw situatie.
Gerelateerde artikelen
- Hoe bepaal je welke data via shortcuts en welke fysiek in OneLake moet worden opgeslagen?
- Hoe ga je om met brondata die niet één-op-één aansluit op het Gemeentelijk Gegevensmodel?
- Hoe voorkom je workspace-wildgroei in Microsoft Fabric?
- Wat doet Microsoft Fabric voor data-analyse?
- Welke software gebruik je voor data-analyse als accountant?
- Scant Oracle Data Safe alleen live databases of ook back-ups?
- Wat kost een Power BI-licentie voor een team van 10 personen?
- Hoe koppel ik mijn ERP-systeem aan Microsoft Fabric?
- Wat levert Power BI concreet op voor mijn organisatie?
- Welke databases werken met Power BI?





