Hoe zorg je dat meerdere gemeenten dezelfde GGM-mappings kunnen hergebruiken?

Ed Kisman · 04 okt 2026

Meerdere gemeenten kunnen dezelfde GGM-mappings hergebruiken door het Gemeentelijk Gegevensmodel als gedeelde basis te gebruiken en de mappings te beheren in een centrale, versiegecontroleerde omgeving. Dit werkt het best wanneer gemeenten gezamenlijke beheersafspraken maken over naamgeving, versiebeheer en wijzigingsbeheer. De vragen hieronder geven een concreet antwoord op hoe je dat in de praktijk organiseert.

Wat maakt GGM-mappings geschikt voor hergebruik tussen gemeenten?

GGM-mappings zijn geschikt voor hergebruik omdat het Gemeentelijk Gegevensmodel is ontworpen als een generiek model dat aansluit bij landelijke standaarden, maar tegelijk breed toepasbaar is voor uiteenlopende gemeentelijke situaties. Het model is niet gemeente-specifiek, maar beschrijft gegevensobjecten en relaties die in vrijwel elke gemeente voorkomen, van mobiliteit en parkeren tot het sociaal domein en de openbare ruimte.

De kern van de herbruikbaarheid zit in de manier waarop het GGM is opgebouwd. Het integreert bestaande landelijke informatiestandaarden zoals RSGB, RGBZ, iWmo, iJw en IMBOR, waardoor mappings niet van nul hoeven te beginnen. Gemeenten die dezelfde standaarden gebruiken, spreken dezelfde gegevenstaal. Dat maakt het mogelijk om mappings die in de ene gemeente zijn ontwikkeld, met beperkte aanpassingen te hergebruiken in een andere.

Daarnaast dekt het GGM een breed spectrum aan domeinen: van Volksgezondheid en Milieu tot Interne organisatie en Dienstverlening. Die breedte betekent dat een mapping voor bijvoorbeeld het Wmo-domein in gemeente A vrijwel identiek is aan wat gemeente B nodig heeft, omdat beide werken met dezelfde iWmo-berichtenstandaard (versie 2.3) en vergelijkbare processtructuren.

Hergebruik is het meest effectief wanneer gemeenten:

Dezelfde bronsystemen of applicatielandschappen gebruiken
Werken binnen hetzelfde domein (bijvoorbeeld Sociaal Domein of Omgevingswet)
Dezelfde landelijke standaarden als uitgangspunt hanteren
Bereid zijn om gezamenlijk beheer te voeren op de gedeelde mappings

Hoe richt je een gedeelde mappingstructuur in voor meerdere gemeenten?

Een gedeelde mappingstructuur voor meerdere gemeenten richt je in door te werken met een gelaagd model: een gemeenschappelijke basislaag met generieke GGM-mappings, aangevuld met gemeente-specifieke uitbreidingslagen. Dit scheidt wat gedeeld wordt van wat lokaal verschilt, zonder dat de gedeelde basis steeds opnieuw moet worden aangepast.

In de praktijk betekent dit dat je de mappings opslaat in een centrale repository, bij voorkeur met versiebeheer. Denk aan een gedeeld databaseschema of een modelleertool die meerdere omgevingen ondersteunt. Gemeenten kunnen vervolgens de basislaag importeren en hun eigen extensies daarbovenop bouwen.

De basislaag: generieke GGM-mappings

De basislaag bevat de mappings die voor alle deelnemende gemeenten gelden. Dit zijn de objectdefinities, relaties en attributen die direct voortvloeien uit landelijke standaarden zoals RSGB of IMBOR. Deze laag wijzigt alleen wanneer een landelijke standaard wordt bijgewerkt, niet bij lokale behoeften van individuele gemeenten.

De uitbreidingslaag: gemeente-specifieke aanpassingen

De uitbreidingslaag bevat lokale toevoegingen: aanvullende attributen, afwijkende naamgeving of koppelingen met gemeente-eigen applicaties. Door deze laag strikt gescheiden te houden van de basislaag, blijft de gedeelde structuur stabiel en kunnen gemeenten onafhankelijk van elkaar hun eigen aanpassingen doorvoeren.

Voor de technische implementatie in databases zoals PostgreSQL databasebeheer of SQL Server databasebeheer kun je denken aan schemascheiding per gemeente binnen dezelfde database-instantie, of aan aparte instanties met een gedeeld referentieschema. Welke aanpak het beste past, hangt af van het aantal gemeenten, de gewenste isolatie en de beschikbare infrastructuur.

Welke beheersafspraken zijn nodig voor gedeeld GGM-gebruik?

Voor gedeeld GGM-gebruik zijn heldere beheersafspraken onmisbaar op het gebied van eigenaarschap, versiebeheer, wijzigingsbeheer en communicatie. Zonder deze afspraken ontstaat al snel fragmentatie: gemeenten passen de basislaag aan voor hun eigen situatie, waardoor de gedeelde basis uiteenvalt in meerdere incompatibele varianten.

De minimale set afspraken die je nodig hebt:

Eigenaarschap: Wie beheert de basislaag en heeft het recht om wijzigingen door te voeren?
Versiebeheer: Welk versienummeringsschema gebruik je, en hoe communiceer je breaking changes?
Wijzigingsprocedure: Hoe dient een gemeente een wijzigingsverzoek in, en wie beoordeelt dat?
Testprotocol: Worden nieuwe versies getest in een acceptatieomgeving voordat ze worden uitgerold?
Documentatie: Hoe wordt bijgehouden welke gemeente welke versie gebruikt en welke uitbreidingen actief zijn?

In de praktijk kiezen gemeenten die intensief samenwerken vaak voor een gezamenlijk beheersorgaan of een aangewezen lead-gemeente die de basislaag beheert. Andere gemeenten krijgen dan een formele rol als reviewer of afnemer. Dit voorkomt dat iedereen tegelijk wijzigingen doorvoert zonder afstemming.

Wat zijn de meest voorkomende problemen bij het delen van GGM-mappings?

De meest voorkomende problemen bij het delen van GGM-mappings zijn versiedrift, naamgevingsconflicten en onvoldoende scheiding tussen de generieke basislaag en gemeente-specifieke uitbreidingen. Deze problemen ontstaan vrijwel altijd door het ontbreken van de beheersafspraken die in de vorige sectie zijn beschreven.

Versiedrift treedt op wanneer gemeenten de basislaag lokaal aanpassen zonder dit terug te koppelen naar de centrale repository. Na verloop van tijd zijn er dan meerdere versies in omloop die niet meer compatibel zijn met elkaar. Dit maakt gegevensuitwisseling tussen gemeenten moeilijker in plaats van makkelijker.

Naamgevingsconflicten ontstaan wanneer twee gemeenten hetzelfde concept anders hebben benoemd in hun uitbreidingslaag, of wanneer een attribuut in de basislaag een andere betekenis heeft gekregen in de lokale context. Dit is een klassiek probleem bij gegevensuitwisseling en wordt verergerd wanneer er geen centraal begrippenkader is.

Onvoldoende laagscheiding is misschien wel het meest structurele probleem. Wanneer gemeente-specifieke logica in de basislaag terechtkomt, wordt het steeds moeilijker om updates van landelijke standaarden te verwerken zonder lokale aanpassingen te breken. De oplossing is consequent werken met de gelaagde structuur zoals beschreven in de vorige sectie.

Daarnaast speelt gebrek aan testinfrastructuur een rol. Wijzigingen in gedeelde mappings worden soms direct in productie doorgevoerd, met alle risico’s van dien. Een gedeelde acceptatieomgeving is geen luxe maar een noodzaak wanneer meerdere gemeenten afhankelijk zijn van dezelfde mappingstructuur. Meer weten over het bewaken van de kwaliteit van je database-omgeving? Een healthcheck van je databaseomgeving kan helpen om kwetsbaarheden vroegtijdig te signaleren.

Wanneer is een centrale DBA-beheerpartij de juiste keuze?

Een centrale DBA-beheerpartij is de juiste keuze wanneer de technische complexiteit van de gedeelde mappingstructuur de interne capaciteit van de betrokken gemeenten overstijgt, of wanneer continuïteit en proactief beheer niet intern geborgd kunnen worden. Dit geldt in het bijzonder wanneer meerdere databaseplatforms zoals Oracle, SQL Server of PostgreSQL tegelijk in gebruik zijn.

Gemeenten die gezamenlijk GGM-mappings beheren, lopen tegen technische vragen aan die specialistische kennis vereisen: hoe richt je schemascheiding correct in, hoe beheer je versies over meerdere database-instanties, en hoe zorg je dat een wijziging in de basislaag niet onverwacht een gemeente-specifieke uitbreiding breekt? Dit zijn geen eenmalige vragen maar terugkerende uitdagingen die structureel aandacht vragen.

Een externe DBA-beheerpartij voegt waarde toe wanneer:

Er geen interne DBA-expertise beschikbaar is die alle betrokken platforms beheerst
24/7 beschikbaarheid en monitoring vereist is voor de gedeelde omgeving
Migraties of upgrades van landelijke standaarden technisch complex zijn
Gemeenten een neutrale partij willen die het beheer onafhankelijk van individuele belangen uitvoert
De kosten van een eigen beheerteam niet opwegen tegen de schaal van het gebruik

Een gedeelde beheerpartij kan ook fungeren als technisch secretariaat voor het beheersorgaan: het bijhouden van de versiehistorie, het uitvoeren van impactanalyses bij wijzigingsverzoeken en het testen van nieuwe versies in een gedeelde acceptatieomgeving. Dat ontlast de gemeenten en zorgt voor consistentie.

Hoe DBA helpt met gedeeld GGM-beheer voor gemeenten

Wij ondersteunen gemeenten bij het opzetten en beheren van gedeelde GGM-omgevingen, van de initiële inrichting tot het dagelijkse beheer van de onderliggende databasestructuren. Onze senior database administrators hebben ruime ervaring met de platforms die in de gemeentelijke praktijk het meest worden gebruikt: Oracle, Microsoft SQL Server en PostgreSQL.

Wat wij concreet bieden voor gemeenten die GGM-mappings willen delen:

Inrichting van een gelaagde mappingstructuur met scheiding tussen basislaag en gemeente-specifieke uitbreidingen
Versiebeheer en impactanalyse bij wijzigingen in landelijke standaarden
Beheer van gedeelde database-omgevingen op Oracle, SQL Server of PostgreSQL
Dagelijkse monitoring, back-upcontroles en proactief onderhoud
Ondersteuning bij migraties wanneer een gemeente overstapt naar een ander platform of een nieuwe versie van het GGM
24/7 ondersteuning op afstand of op locatie, ook voor urgente situaties

Wil je weten hoe wij jouw gemeente of samenwerkingsverband kunnen ondersteunen bij het hergebruik van GGM-mappings? Neem contact met ons op en we denken graag met je mee over de beste aanpak voor jouw situatie.