There are 342 municipalities in the Netherlands. Each one is legally independent and responsible for a wide range of public services — issuing birth certificates, handling building permits, managing social welfare payments, and maintaining subsurface infrastructure records. Yet despite this diversity, every gemeente operates within a tightly standardised national IT framework — shared base registries, common authentication infrastructure, sector-wide messaging protocols, and a national reference architecture.
The result is one of the most interesting integration challenges in European public IT: a highly standardised policy layer sitting on top of an extremely heterogeneous application landscape, actively being modernised under the Common Ground programme. A mid-sized municipality typically runs between 80 and 150 different IT applications, connected by a mixture of 20-year-old SOAP interfaces, modern ZGW REST APIs, Digikoppeling-certified government channels, and point-to-point integrations nobody quite wants to talk about.
This article maps out the full landscape — the standards, the architecture frameworks, the key design principles — and shows exactly how Azure Integration Services fits in, with four concrete, runnable scenarios.
The Dutch gemeente IT landscape
Every Dutch municipality, regardless of size, operates across four distinct layers of IT systems. Getting these layers clear is the prerequisite for any meaningful integration design.
At the base are the 10 national base registries (basisregistraties) — the authoritative sources of truth for citizens (BRP), addresses (BAG), land (BRK), companies (HR/KvK), and more. These are operated centrally by BZK, Kadaster, and CBS, and all municipalities consume them via standardised APIs.
Above that sits the shared national infrastructure operated by Logius: DigiD and eHerkenning for citizen and business authentication, Digikoppeling for secure inter-government messaging, MijnOverheid Berichtenbox for official digital mail, and PKIoverheid certificates for mutual TLS.
The municipal own systems layer is where diversity lives. A zaaksysteem (case management), DMS, vergunningensysteem (permits), e-formulieren platform, social domain application, and financial system — all procured separately, often from different vendors, running different technology generations simultaneously.
Finally, chain partners (ketenpartners) — UWV, Belastingdienst, DUO, RDW, SVB, Zorgkantoor — all exchange structured data with the gemeente via sector-specific chains (SUWI, GBA, etc.) and Digikoppeling channels.
Reference architectures: NORA, GEMMA, and Common Ground
NORA — the national overarching framework
The Nederlandse Overheid Referentie Architectuur (NORA) is the national reference architecture for the entire Dutch government. It defines ten base principles and forty derived principles that apply to all public organisations under a “comply or explain” model — organisations must either apply the principles or formally justify why they do not. NORA is maintained by ICTU under the mandate of the Ministry of Interior (BZK). Its domain-specific “children” include GEMMA for municipalities, PETRA for provinces, WILMA for water boards, and RORA for national government.
GEMMA — the municipality reference architecture
GEMMA (Gemeentelijke ModelArchitectuur), maintained by VNG Realisatie, is now about 20 years old and has recently been restructured into three main components: the GEMMA Basisarchitectuur (architecture principles, business architecture, information architecture), domain-specific thema-architecturen covering security & privacy, zaakgericht werken, and Common Ground, and supporting products including the GEMMA Standaardenlijst and Softwarecatalogus. GEMMA compliance is a standard requirement in municipal IT procurement through the GIBIT (Gemeentelijke Inkoop bij IT Toolbox) framework.
Common Ground — the modernisation vision
Launched around 2018 by Amsterdam, Rotterdam, Den Haag, Utrecht, and Eindhoven, Common Ground is both a movement and an information architecture. Its central insight: the traditional Dutch municipal IT model — where every application keeps its own copy of citizen data — creates thousands of redundant databases, data quality problems, vendor lock-in, and security risks.
The Common Ground shift in one sentence
Instead of every application keeping a copy of the citizen’s address, every application calls the BRP API at the moment it needs the address — data at source, fetched on demand.
The practical realisation is the ZGW APIs — a suite of modern REST APIs covering case management (Zaken API), documents (Documenten API), catalogs (Catalogi API), and notifications (Notificaties API). These are rapidly replacing the older StUF-ZDS SOAP interface for zaakgericht werken integrations.
The Common Ground 5-layer model
Common Ground’s technical architecture is described using a 5-layer model. This is the architectural lens through which every integration decision in a gemeente should be viewed. Layer 3 — the integration layer — is precisely where Azure Integration Services operates.
Critical design constraint
In a Common Ground-compliant architecture, your Azure integration platform must never store authoritative data. It routes, transforms, orchestrates, and monitors — BRP data stays in the BRP, zaakdata stays in the zaaksysteem. Logic Apps workflows must use variables only for the duration of a single run.
Design principles every solution must satisfy
Dutch government IT operates under a layered compliance framework. Any integration solution for a gemeente must satisfy principles at three levels simultaneously: NORA (national), GEMMA (municipal), and Common Ground (information architecture).
NORA base principles (comply or explain)
| Principle | What it means for integration design |
|---|---|
| BP05 — Eenmalig inwinnen (ask once) | Citizens provide data only once. Pre-fill forms from BRP and BAG via API. Never ask for what you can look up. |
| BP08 — Interoperability first | Use open standards: Digikoppeling, ZGW APIs, OAuth 2.0/OIDC. Avoid proprietary interfaces that cannot be replaced without rebuilding the integration. |
| BP09 — Privacy by design | Every flow touching personal data requires AVG-compliant audit logging, purpose limitation coding, and explicit retention policies in Log Analytics. |
| BP10 — Reliability (betrouwbaar) | Durable messaging, dead-letter handling, and retry policies are compliance requirements — not optional engineering niceties. |
GEMMA-specific principles
| Principle | Practical implication |
|---|---|
| G01 — Zaakgericht werken | All trackable citizen work is structured as zaken. Any integration processing citizen requests must create or update a zaak via ZGW Zaken API. |
| G02 — Use base registries | BRP for citizens, BAG for addresses, HR for companies — always the authoritative source. Shadow copies of base registry data are an architectural anti-pattern. |
| G03 — Open over proprietary | Forum Standaardisatie publishes mandatory and recommended standards lists. New procurement must prefer open standards and formally justify deviations. |
Common Ground information architecture principles
- Data bij de bron — Data stays at its authoritative source. Fetch on demand, never copy.
- Ontkoppeling van processen en data — The process layer must not have direct database connections to data stores. All data access goes via Layer 2 APIs.
- Open APIs als standaard — REST + JSON + OpenAPI specification. Legacy StUF/SOAP is being phased out; new integrations use ZGW APIs.
- Autonomie van componenten — Every component must be replaceable without breaking the platform. Design integrations to API contracts, not to specific implementations.
- Federatief gegevenslandschap — No central data warehouse. Data lives in authoritative sources and is composed at runtime — the natural fit for event-driven architecture.
Mandatory open standards (Forum Standaardisatie)
| Standard | Domain | Integration design implication |
|---|---|---|
| Digikoppeling | Secure inter-government messaging | APIM must route WUS/ebMS traffic with PKIoverheid mutual TLS. Synchronous Bv03 acknowledgements required within strict time windows. |
| StUF (legacy) | XML/SOAP data exchange | Most existing systems still speak StUF. Logic Apps translates StUF to ZGW REST for migration paths. |
| ZGW APIs | Modern case management REST | Primary target for new integrations. All new zaaksysteem connections should use ZGW, not StUF. |
| OAuth 2.0 / OIDC | Authentication & authorisation | DigiD and eHerkenning use OIDC. APIM inbound policies enforce token validation on every API call. |
| NL API Design Rules | REST API design | All APIs exposed via APIM must follow Dutch API Design Rules: versioning, HAL, pagination, JSON. |
| AVG / GDPR | Data privacy | All flows touching BSN or personal data need audit logging, purpose limitation headers, and retention enforcement. |
Where Azure Integration Services fits
Azure Integration Services is not one product — it is a suite of five services that together cover the full integration layer. The mapping onto the GEMMA/Common Ground model is precise and complete.
Four hands-on scenarios
The following scenarios represent real integration challenges we deliver for Dutch municipalities. Each maps to a concrete GEMMA/Common Ground requirement, identifies the applicable standards, and shows the Azure architecture that implements it.
Scenario 1 — BRP address change: event-driven fan-out
A citizen reports a change of address (verhuizing). The change is registered in the BRP. All downstream systems — the zaaksysteem, DMS, social domain system, WOZ system — must be updated. The traditional approach (each system polling the BRP nightly) creates stale data, race conditions, and unnecessary load on the base registry.
BSN never in message payloads — APIM strips the citizen service number before forwarding to Service Bus, replacing it with a correlation ID. Each Logic App then calls the BRP Haal Centraal API directly with its own authorised token.
Independent subscriptions, not competing consumers — each downstream system is a separate Service Bus subscription. A failing zaaksysteem cannot starve the social domain system of updates.
Dead-letter alerting as a zaak — dead-lettered messages trigger a monitoring Logic App that creates a zaak of type INTEGRATIESTORING in the gemeente’s case management system, making failures visible without custom monitoring tooling.
Standards applied
GEMMA G02 (use base registries, no shadow copies) · NORA BP09 (privacy by design, BSN pseudonymisation at gateway) · NORA BP10 (durable messaging, dead-letter handling) · Common Ground: data bij de bron
Scenario 2 — Permit application: StUF-to-ZGW migration bridge
A citizen submits a building permit application via the DSO portal. The gemeente’s vergunningensysteem is a legacy system that only speaks StUF-ZDS SOAP. New systems in the same process chain — the notificatieplatform and the klantportaal — expect ZGW REST. The integration layer must translate between the two protocol worlds while ensuring the zaak is created, tracked, and visible to the citizen throughout.
Always create the ZGW zaak first — before calling the legacy system. If the legacy call fails, you have a zaak in status “intake ontvangen” with a logged failure. The citizen’s submission is never lost.
StUF stuurgegevens generation — the Logic App must construct valid StUF header values (zender, ontvanger, referentienummer, tijdstipBericht) so the legacy system can correlate the message back to the zaak UUID. An Azure Function handles the XML serialisation.
Bv03/Fo03 acknowledgement handling — StUF-ZDS uses a synchronous acknowledgement pattern. The Logic App handles both success (Bv03) and error (Fo03) responses and updates the zaak status accordingly.
Standards applied
GEMMA G01 (zaakgericht werken — zaak created first, always) · StUF standard (mandatory for legacy system compatibility) · ZGW Zaken API + Notificaties API · DSO-LV integration protocol
Scenario 3 — SUWI chain: Digikoppeling ebMS integration
A citizen’s income changes at UWV. The gemeente’s social services team must reassess WMO entitlements. UWV sends a structured notification via SUWI-net using Digikoppeling ebMS 2.0 — the mandatory secure messaging channel for inter-government data exchange in the Netherlands. The gemeente must receive this securely, strip personal data at the gateway, process it durably, and trigger a case review workflow.
Bv03 synchronous within the gateway — Digikoppeling ebMS requires an acknowledgement within a strict time window. APIM returns the Bv03 immediately; the Logic App processes asynchronously via Service Bus.
BSN pseudonymisation at the boundary — once inside the internal platform, BSN is replaced with an internal correlation ID stored in Key Vault. Only the APIM gateway and the BRP lookup function ever see the raw BSN.
Logboek dataverwerkingen — every SUWI message generates an audit event to Log Analytics with the purpose code, timestamp, and processing step, satisfying the Dutch privacy legislation requirement for a verifiable data processing log.
Standards applied
Digikoppeling ebMS 2.0 (mandatory for SUWI chain) · PKIoverheid certificates (mutual TLS) · NORA BP09 (privacy by design, BSN pseudonymisation) · AVG logboek dataverwerkingen · ZGW Zaken API for review zaak creation
Scenario 4 — AI-assisted intake: intelligent zaak routing
A citizen submits a free-text message via the gemeentelijk contactformulier: “I have a problem with my neighbour’s tree overhanging my garden and causing water damage to my roof.” The gemeente needs to classify this as the right zaaktype, route it to the correct team, and create a zaak with the right catalogustype — automatically, at scale, and with full audit trail.
No personal data in the LLM prompt — APIM strips BSN, full name, and exact address before the message reaches Azure OpenAI. The model classifies based on the complaint text and anonymised context only.
Every AI decision gets an audit record — the zaaktype classification, confidence score, model version, and Logic App run ID are logged alongside the zaak UUID. When a citizen disputes the routing, the audit trail shows exactly what the model decided and when.
Semantic caching is economically justified — in a municipality of 100,000 inhabitants, roughly 30% of intake messages are variations of the same 5–10 core complaint types. Semantic caching in APIM achieves 40–60% hit rates on intake classification, reducing AI costs significantly.
Human-in-the-loop for edge cases — when the AI confidence score is below a configurable threshold, the Logic App routes to a Teams approval card where a KCC medewerker confirms the classification before the zaak is created.
Standards applied
GEMMA G01 (zaakgericht werken — ZGW Catalogi API for catalogustype lookup) · NORA BP09 (no PII in LLM, AI decision audit log) · APIM AI Gateway (content safety, semantic caching, token attribution) · Common Ground: zaak at source, not duplicated
What this means in practice
Dutch municipalities are in the middle of a generational IT transformation. Common Ground is moving them from siloed data copies and point-to-point SOAP integrations toward a federated, API-first, event-driven platform. Simultaneously, AI is beginning to enter the process layer — not as a novelty, but as a practical tool for intake routing, document classification, and policy lookup.
Azure Integration Services maps almost precisely onto this architectural moment. Logic Apps for orchestration across the five-layer model, APIM for API governance and AI gateway capabilities, Service Bus for the durable messaging that chain partner integration demands, and Event Grid for the reactive architectures that Common Ground’s “data at source” principle requires.
But the technology is only part of the story. Knowing that a SUWI ebMS message requires a Bv03 acknowledgement within 30 seconds, that a BSN must be pseudonymised at the gateway boundary before entering the internal platform, that a new zaaksysteem connection requires ZGW conformance testing and GIBIT-aligned procurement documentation — this is the domain knowledge that determines whether a project succeeds or stalls.
I have tried to combine deep Azure Integration Services expertise with hands-on knowledge of the Dutch municipal IT standards landscape. If you are a gemeente modernising your integration platform, a software vendor building Common Ground-compliant components, or a systems integrator navigating GEMMA compliance requirements — I would like to help.
