Hoe integreer je het Gemeentelijk Gegevensmodel met een bestaande gemeentelijke data-architectuur?

Ed Kisman · 11 okt 2026

Het Gemeentelijk Gegevensmodel integreren met een bestaande gemeentelijke data-architectuur doe je stapsgewijs: je brengt eerst de mapping in kaart tussen het GGM en je huidige databronnen, kiest een passende integratiestrategie, lost conflicterende definities op en richt de benodigde technische componenten in. Dit vraagt om zowel inhoudelijke kennis van het GGM als technische expertise op het gebied van databasebeheer en data-integratie. De vragen hieronder geven je een concreet handvat voor elk onderdeel van dit traject.

Wat zijn de grootste integratie-uitdagingen bij het GGM?

De grootste integratie-uitdagingen bij het Gemeentelijk Gegevensmodel zijn de heterogeniteit van bestaande bronsystemen, inconsistente datamodellen per beleidsdomein en het ontbreken van een centrale databeheerder die eigenaarschap over de gemeentelijke informatievoorziening bewaakt. Gemeenten werken doorgaans met tientallen applicaties die elk hun eigen datastructuur kennen, wat directe aansluiting op het GGM bemoeilijkt.

Het GGM beschrijft alle beleidsterreinen van een gemeente, van het sociaal domein tot openbare ruimte en interne organisatie. Die breedte is een kracht, maar ook een uitdaging: elke afdeling heeft jarenlang haar eigen systemen opgebouwd met eigen begrippen, sleutels en registratiemethoden. Wanneer je het GGM als gemeenschappelijk fundament wilt gebruiken, botsen die lokale werkwijzen regelmatig met de generieke structuur van het model.

Daarnaast zijn veel gemeentelijke systemen historisch gegroeid en bevatten ze gegevens die nooit zijn gemodelleerd vanuit een overkoepelend perspectief. Denk aan persoons- en adresgegevens die in meerdere systemen apart worden bijgehouden, zonder dat er een eenduidige koppeling bestaat met basisregistraties zoals de BAG of de BRP. Het GGM gebruikt standaarden als RSGB en RGBZ om juist die verbindingen te leggen, maar dat vereist wel dat bestaande systemen worden aangepast of via een integratielaag worden ontsloten.

Hoe breng je de mapping in kaart tussen het GGM en bestaande databronnen?

De mapping tussen het GGM en bestaande databronnen breng je in kaart door per beleidsdomein een inventarisatie te maken van alle relevante bronsystemen, de daarin opgeslagen entiteiten te vergelijken met de corresponderende GGM-objecten en de verschillen in definitie, granulariteit en sleutels vast te leggen in een mappingdocument. Begin bij de domeinen met de hoogste urgentie of de meeste gegevensoverlap.

Inventariseer per domein de bronsystemen

Start met een domeingerichte aanpak. Kies bijvoorbeeld het sociaal domein als beginpunt, omdat daar standaarden als iWmo, iJw en het Suwi Gegevensregister al zijn verwerkt in het GGM. Breng in kaart welke applicaties gegevens leveren over Wmo, Jeugd, Werk en Inkomen, en welke entiteiten daarin centraal staan. Vergelijk die vervolgens met de GGM-objecten voor hetzelfde domein.

Documenteer de mapping systematisch

Gebruik een gestructureerd mappingdocument waarin je per GGM-entiteit vastlegt: welk bronsysteem de gegevens levert, wat de corresponderende tabel of het veld is, of de definitie overeenkomt en wat de transformatieregels zijn. Noteer ook expliciet de gevallen waar geen directe match bestaat. Dat zijn de plekken waar je later de meeste aandacht aan moet besteden. Een tool voor BI-infrastructuur of een datacatalogus kan dit proces ondersteunen.

Welke integratiestrategie past het beste bij een gemeente?

De integratiestrategie die het beste past bij een gemeente hangt af van de volwassenheid van de bestaande data-architectuur, het beschikbare budget en de gewenste snelheid van implementatie. In de meeste gevallen is een gefaseerde aanpak met een centraal datawarehouse of dataplatform als integratielaag de meest effectieve keuze, waarbij het GGM als logisch referentiemodel dient zonder dat alle bronsystemen direct worden vervangen.

Een volledige “big bang”-migratie waarbij alle systemen tegelijk worden omgezet naar het GGM is voor de meeste gemeenten niet realistisch. Een pragmatischer aanpak is het inrichten van een integratielaag, bijvoorbeeld een datawarehouse of een modern dataplatform, waarin GGM-conforme datamodellen worden gebouwd boven op de bestaande bronsystemen. Zo profiteer je van de voordelen van het GGM voor rapportage en beleidsinformatie, terwijl de operationele systemen voorlopig blijven zoals ze zijn.

Gemeenten die al werken met een business intelligence-omgeving kunnen het GGM gebruiken als semantische laag boven op hun bestaande datastructuur. Dat maakt het mogelijk om gegevens uit verschillende domeinen samen te brengen zonder alle bronsystemen te hoeven aanpassen. De sleutel is dat de GGM-mapping goed is gedocumenteerd en dat er duidelijke afspraken zijn over welk systeem de “bron van waarheid” is voor elk gegeven.

Hoe ga je om met conflicterende definities tussen het GGM en bronregistraties?

Conflicterende definities tussen het GGM en bronregistraties los je op door eerst het verschil te categoriseren: gaat het om een terminologisch verschil, een inhoudelijk verschil of een structureel verschil? Op basis van die categorisering kies je voor harmonisatie, een vertaalregel of een expliciete uitzondering die je vastlegt in je datadictionary.

Terminologische conflicten zijn het eenvoudigst op te lossen. Als een bronsysteem “cliënt” gebruikt waar het GGM “betrokkene” hanteert, volstaat een vertaalregel in de integratielaag. Inhoudelijke conflicten zijn lastiger: als de definitie van een “melding” in het ene systeem breder is dan in het GGM, moet je bepalen welke definitie leidend is en hoe je de gegevens filtert of aanvult.

Structurele conflicten, waarbij een bronsysteem een concept op een fundamenteel andere manier modelleert dan het GGM, vereisen de meeste aandacht. Hier is het verstandig om domeinexperts te betrekken die zowel het bronsysteem als het GGM kennen. Leg alle beslissingen vast in een centraal beheerde datadictionary, zodat toekomstige wijzigingen in bronsystemen of het GGM eenvoudig kunnen worden doorgevoerd. Goede datagovernance is hierbij onmisbaar.

Welke technische componenten zijn nodig voor een GGM-integratie?

Een GGM-integratie vereist minimaal vier technische componenten: een ETL- of ELT-laag voor het ophalen en transformeren van brongegevens, een centraal dataopslagplatform waarin het GGM-model wordt geïmplementeerd, een datacatalogus voor het beheren van definities en mappings, en monitoring- en kwaliteitscontroles om de integriteit van de gegevens te bewaken.

ETL/ELT-laag: Haalt gegevens op uit bronsystemen, past de transformatieregels toe op basis van de GGM-mapping en laadt de resultaten in het centrale platform.
Centraal dataplatform: Dit kan een datawarehouse zijn op basis van Microsoft SQL Server, Oracle of PostgreSQL, of een modern cloudplatform. Hier worden de GGM-entiteiten als tabellen of views geïmplementeerd.
Datacatalogus: Beheert de definities, eigenaarschappen en mappings van alle GGM-entiteiten. Dit is de ruggengraat van je datagovernance.
Monitoring en datakwaliteit: Controleert doorlopend of gegevens voldoen aan de verwachte definities, of er geen duplicaten ontstaan en of de koppeling met basisregistraties actueel blijft.

Voor geo-informatie, die een belangrijk onderdeel vormt van het GGM, zijn aanvullende componenten nodig die overweg kunnen met standaarden als GML, NEN 3610 en IMBGT/IMGeo. Zorg dat het gekozen dataplatform deze formaten ondersteunt of dat er een aparte geo-integratielaag wordt ingericht.

Wanneer is externe DBA-expertise nodig bij een GGM-traject?

Externe DBA-expertise is nodig bij een GGM-traject zodra de complexiteit van de databaseomgeving de interne capaciteit overstijgt. Dat is het geval bij het ontwerpen van een schaalbaar datamodel op basis van het GGM, het optimaliseren van queryprestaties bij grote gegevensvolumes, het uitvoeren van migraties van bestaande databases naar een GGM-conforme structuur, of wanneer de beschikbaarheid en integriteit van gegevens moeten worden gegarandeerd met 24/7 monitoring.

Gemeenten beschikken zelden over gespecialiseerde databasekennis in eigen huis. De vertaling van het GGM naar een fysiek databasemodel, het inrichten van indexen, partitionering en back-upstrategieën, en het bewaken van de performance bij groeiende gegevensvolumes zijn taken die specifieke expertise vereisen. Externe ondersteuning voorkomt dat technische schuld ontstaat die later dure hersteloperaties nodig maakt.

Hoe DBA helpt bij GGM-integratie in jouw gemeente

Wij ondersteunen gemeenten bij het vertalen van het Gemeentelijk Gegevensmodel naar een robuuste, goed presterende databaseomgeving. Of het nu gaat om Oracle, Microsoft SQL Server of PostgreSQL: onze senior database administrators kennen de uitdagingen van gemeentelijke data-architecturen en pakken die praktisch aan. Wat wij concreet bieden:

Analyse van de bestaande databaseomgeving en vertaling naar een GGM-conform datamodel
Begeleiding bij de mapping tussen bronsystemen en GGM-entiteiten
Inrichten en optimaliseren van het centrale dataplatform voor GGM-data
Migratie van bestaande databases naar een GGM-conforme structuur, met minimale verstoring van de bedrijfsvoering
24/7 monitoring, dagelijkse back-upcontroles en proactief onderhoud van de GGM-databaseomgeving
Advies over datagovernance, beveiliging en datakwaliteit in het kader van gemeentelijke informatievoorziening

Wil je weten hoe wij jouw gemeente kunnen helpen bij een GGM-traject? Neem contact met ons op voor een vrijblijvend gesprek.