Leerlijnen StUF on Leerlijnen KCA

1.0 Todo voor gemeentelijk ICT-landschap

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor Gemeentelijk ICT-landschap

Kernsystemen en basisregistraties

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

10.1 Eisen en wensen ophalen

Wed, 04 Mar 2026 00:00:00 +0000

← Terug naar Stakeholdermanagement en communicatie

10.1 Eisen en wensen ophalen

Kan overleggen met gebruikers en leveranciers om eisen en wensen op te halen.

11.0 Todo voor API-technologie

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor API-technologie

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

11.1 API-designprincipes

Wed, 04 Mar 2026 00:00:00 +0000

11.1 API-designprincipes

Kent API-designprincipes en best practices.

2.0 Todo voor Gemma Architectuur

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor Gemma Architectuur

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

3.0 Todo voor Informatiemodellering

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor Informatiemodellering

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

4.0 Todo voor Uitwisselformaten

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor Uitwisselformaten

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

5.0 Todo voor XML-technologien

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor XML-technologien

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

6.0 Todo voor StUF-standaard

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor StUF-standaard

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

6.1 Opbouw en werking van StUF

Wed, 04 Mar 2026 00:00:00 +0000

6.1 Opbouw en werking van StUF

Kan de opbouw en werking van de StUF-standaard (Standaard Uitwisseling Formaat) uitleggen.

Wat is StUF?

StUF (Standaard Uitwisseling Formaat) is een Nederlandse standaard voor berichtgebaseerde gegevensuitwisseling tussen informatiesystemen in de overheid. StUF biedt een gestandaardiseerde manier voor systemen om gestructureerd informatie uit te wisselen, onafhankelijk van de onderliggende technologie.

Kernprincipes van StUF:

Standaardisatie: Uniforme manier van gegevensuitwisseling
Platform-onafhankelijk: Werkt met verschillende technologieën
Semantische interoperabiliteit: Eenduidige betekenis van gegevens
Berichtgebaseerd: Asynchroon en synchroon berichtenverkeer

StUF-architectuur

Lagenmodel

StUF is opgebouwd volgens een gelaagde architectuur:

7.0 Todo voor RSGB-informatiemodel

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor RSGB-informatiemodel

Nr	Wie	Wat
01	Johan	Todo-lijst vullen

8.0 Todo voor modelleer-tooling

Wed, 04 Mar 2026 00:00:00 +0000

1.0 Todo-lijst voor modelleer-tooling

Nr	Wie	Wat
01	Johan/Robert	Breng alle te gebruiken tooling in beeld.

8.1 Sparx Enterprise Architect

Wed, 04 Mar 2026 00:00:00 +0000

8.1 Sparx Enterprise Architect

Heeft ervaring met Sparx Enterprise Architect.

9.1 Technische specificaties documenteren

Wed, 04 Mar 2026 00:00:00 +0000

Terug naar leerlijn 9

9.1 Technische specificaties documenteren

Kan technische specificaties rondom StUF-koppelvlakken documenteren.

5.1 XML syntax en structuur

Thu, 12 Mar 2026 00:00:00 +0000

5.1 XML syntax en structuur

Begrijpt de syntax en structuur van XML-documenten.

Het probleem: hoe wissel je gegevens uit?

Stel je voor: twee gemeentelijke systemen moeten gegevens over een inwoner uitwisselen. Het ene systeem (A) slaat gegevens op in een database, het andere (B) in een heel ander formaat. Hoe zorg je ervoor dat beide systemen elkaars gegevens begrijpen?

Je zou de gegevens in platte tekst kunnen sturen, bijvoorbeeld:

Jan de Vries, Kerkstraat 12, 3511AB, Utrecht

Maar dit levert direct problemen op:

1.1 Overzicht van gemeentelijke applicatielandschappen

Wed, 04 Mar 2026 00:00:00 +0000

1.1 Overzicht van gemeentelijke applicatielandschappen

Begrijpt de rol van StUF in het gemeentelijke applicatielandschap.

Een gemiddelde gemeente gebruikt tientallen tot meer dan honderd applicaties die samen het applicatielandschap vormen. Deze applicaties ondersteunen alle gemeentelijke taken — van burgerzaken tot belastingheffing, van vergunningverlening tot het sociaal domein. Hieronder een overzicht van de belangrijkste categorieën en systemen.

Kernsystemen en basisregistraties

Systeem / Registratie	Afkorting	Functie
Basisregistratie Personen	BRP	Persoonsgegevens van alle inwoners (voorheen GBA)
Basisregistratie Adressen en Gebouwen	BAG	Alle adressen en gebouwen in Nederland
Basisregistratie Grootschalige Topografie	BGT	Gedetailleerde kaart van alle objecten in de openbare ruimte
Basisregistratie Kadaster	BRK	Eigendomsgegevens van percelen en appartementsrechten
Basisregistratie Waarde Onroerende Zaken	WOZ	WOZ-waarden van onroerend goed
Handelsregister	HR (NHR)	Gegevens van alle ondernemingen en rechtspersonen

Zaakgericht werken

Systeem	Functie
Zaaksysteem (bijv. Rx.Mission, Decos JOIN)	Registratie en afhandeling van alle “zaken” (aanvragen, meldingen, vergunningen)
Documentmanagementsysteem (DMS)	Opslag en beheer van documenten die bij zaken horen
Archiefbeheer	Duurzame bewaring en vernietiging volgens de Archiefwet

Domeinspecifieke applicaties

Domein	Typische applicaties	Voorbeelden
Burgerzaken	Burgerzakenmodule	Centric/PinkRoccade burgerzaken
Belastingen	Belastingsysteem	Centric Belastingen, Hefpunt
Sociaal domein	Regiesysteem, Wmo/Jeugd	GWS4all, Suite voor Sociaal Domein
Vergunningen (Omgevingswet)	VTH-systeem (Vergunning, Toezicht, Handhaving)	PowerBrowser, Squit XO, Rx.Mission
Openbare ruimte	Beheersysteem openbare ruimte	Obsurv, GBI
Financiën	Financieel systeem	Key2Financiën, Unit4

Integratie- en servicelagen

Omdat al deze systemen met elkaar moeten communiceren, is er een integratielaag nodig. Hier speelt StUF een centrale rol:

10.2 Afstemmen met architecten en adviseurs

Wed, 04 Mar 2026 00:00:00 +0000

← Terug naar Stakeholdermanagement en communicatie

10.2 Afstemmen met architecten en adviseurs

Kan afstemmen met architecten en informatieadviseurs van gemeenten, de VNG en overheden.

11.2 API-types: REST, RPC en GraphQL

Wed, 04 Mar 2026 00:00:00 +0000

11.2 API-types: REST, RPC en GraphQL

Heeft begrip van verschillende API-types: REST, RPC en GraphQL.

2.1 GEMMA Referentie-architectuur

Wed, 04 Mar 2026 00:00:00 +0000

2.1 GEMMA Referentie-architectuur

Begrijpt de GEMMA-referentiearchitectuur en de positie van gegevensuitwisseling daarin.

Wat is GEMMA?

GEMMA (Gemeentelijke Model Architectuur) is de referentiearchitectuur voor Nederlandse gemeenten, ontwikkeld door VNG Realisatie. Het biedt een samenhangend kader voor de inrichting van de gemeentelijke informatievoorziening.

GEMMA helpt gemeenten bij:

Het maken van architectuurkeuzes
Het waarborgen van interoperabiliteit tussen systemen
Het implementeren van standaarden
Het realiseren van een toekomstbestendige ICT-infrastructuur

GEMMA-lagen

De GEMMA-architectuur is opgebouwd uit verschillende lagen:

3.1 Ervaring als informatiemodelleur

Wed, 04 Mar 2026 00:00:00 +0000

3.1 Ervaring als informatiemodelleur

Heeft minimaal 5 jaar ervaring als informatiemodelleur in het opstellen van informatiemodellen.

Waarom 5 jaar ervaring?

Informatiemodellering is een vak dat veel ervaring vereist. In 5 jaar bouw je praktische kennis op van:

Modelleertechnieken

UML: Unified Modeling Language voor objectoriëntatie
ER-modellering: Entity-Relationship diagrammen
Conceptuele modellering: Abstracte werkelijkheidsweergave
Logische modellering: Implementatie-onafhankelijke structuren

Domeinkennis

Bestuurlijke processen: Hoe overheidsorganisaties werken
Juridische kaders: Wet- en regelgeving die gegevens beïnvloedt
ICT-landschap: Hoe systemen samenwerken en gegevens uitwisselen
Standaarden: RSGB, StUF, MIM en andere referentiemodellen

Praktische vaardigheden

Stakeholder management: Afstemmen met verschillende belanghebbenden
Requirements engineering: Wensen vertalen naar modelspecificaties
Kwaliteitsborging: Consistentie en volledigheid waarborgen
Documentatie: Modellen begrijpelijk maken voor verschillende doelgroepen

Ervaringsgebieden

Modelleertypes:

4.1 XML als uitwisselingsformaat

Wed, 04 Mar 2026 00:00:00 +0000

4.1 XML als uitwisselingsformaat

Kent XML als uitwisselingsformaat (structuur, syntax, schema’s).

Wat is XML?

XML (eXtensible Markup Language) is een markup-taal ontworpen voor het opslaan en transporteren van gestructureerde data. In de overheidscontext is XML de ruggengraat van vele uitwisselingstandaarden, waaronder StUF (Standaard Uitwisseling Formaat).

Kernprincipes van XML:

Self-describing: Data en structuur in één formaat
Human-readable: Leesbaar voor mensen én machines
Platform-independent: Werkt op alle systemen
Extensible: Flexibel uitbreidbaar voor specific behoeften

XML-structuur en syntax

Basis XML-elementen

<?xml version="1.0" encoding="UTF-8"?>
<BRP:Persoon xmlns:BRP="http://www.stufstandaarden.nl/basisgegevens">
 <BRP:BSN>123456789</BRP:BSN>
 <BRP:Geslachtsnaam>
 <BRP:Voorvoegsel>van der</BRP:Voorvoegsel>
 <BRP:GeslachtsnaamStam>Berg</BRP:GeslachtsnaamStam>
 </BRP:Geslachtsnaam>
 <BRP:Voornamen>Jan Peter</BRP:Voornamen>
 <BRP:Geboortedatum>1985-03-15</BRP:Geboortedatum>
</BRP:Persoon>

Syntax-regels

Case-sensitive: <Persoon> ≠ <persoon>
Well-formed: Elke opening-tag heeft matching closing-tag
Nested structure: Elementen kunnen elementen bevatten
Attribute syntax: <element attribuut="waarde">

Namespaces

<!-- Namespace declaraties -->
<StUF:Bv03Bericht
 xmlns:StUF="http://www.stufstandaarden.nl/koppelvlak/stuf"
 xmlns:BG="http://www.stufstandaarden.nl/onderlaag/bg"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

 <StUF:stuurgegevens>
 <StUF:berichtCode>Lv01</StUF:berichtCode>
 <StUF:zender>
 <StUF:organisatie>0363</StUF:organisatie>
 </StUF:zender>
 </StUF:stuurgegevens>
</StUF:Bv03Bericht>

XML Schema’s (XSD)

XML Schema Definition (XSD) definieert de structuur, elementen en datatypes van XML-documenten.

6.2 Versies van de StUF-standaard

Wed, 04 Mar 2026 00:00:00 +0000

6.2 Versies van de StUF-standaard

Kent de verschillende versies van de StUF-standaard en de onderlinge verschillen.

StUF-versie geschiedenis

De StUF-standaard heeft zich de afgelopen decennia in meerdere versies ontwikkeld, waarbij elke versie nieuwe functionaliteit, verbeteringen en soms ook incompatible wijzigingen introduceert.

StUF-chronologie

timeline
title StUF Version Evolution
2001 : StUF 1.0 : Eerste versie
: XML-basis
2003 : StUF 2.0 : Uitbreiding sectormodellen
: Verbeterde semantiek
2006 : StUF-BG 2.04 : Mature basisregistratie-support
: RSGB 2.0 integratie
2009 : StUF 3.00 : Major architectural change
: Nieuwe stuurgegevens
: Verbeterde tijdlijnen
2011 : StUF-BG 3.00 : RSGB 3.0 support
: Materiële/formele historie
2013 : StUF 3.01 : Stability improvements
: Performance optimizations
2015 : StUF-ZKN 3.40 : Document management
: Zaakgericht werken
2018 : StUF Legacy : Maintenance mode
: API-first approach
2020 : StUF 3.05 : Final major release
: Migration guidance

StUF 1.0 - 2.0 (2001-2005)

Pioniersfase

StUF 1.0 Kenmerken:

7.1 Opbouw en doel van het RSGB

Wed, 04 Mar 2026 00:00:00 +0000

7.1 Opbouw en doel van het RSGB

Kan de opbouw en het doel van het RSGB (Referentiemodel Stelsel van Gemeentelijke Basisgegevens) uitleggen.

8.2 XML-spy

Wed, 04 Mar 2026 00:00:00 +0000

8.2 XML-spy bheersen

Kan XML’s en XSD’d bekijken en bewerken m.b.v. XML-spy.

9.2 Processen en procedures beschrijven

Wed, 04 Mar 2026 00:00:00 +0000

Terug naar leerlijn 9

9.2 Processen en procedures beschrijven

Kan processen en procedures rondom informatiemodellen beschrijven.

Oefening 5-3-4

Mon, 23 Mar 2026 00:00:00 +0000

Oefening 5.3.4: Het creëren en gebruiken van globale types

In deze oefening gaan we het schema “Procesdocumentatie4.xsd”, dat je in de voorgaande oefening hebt bewaard zo aanpassen dat we geen redundant definities meer in het schema hebben staan.

Bewaar gedurende de onderstaande oefeining wedrom zelf regelmatig het bestand.

Opdracht

Ga naar het XML-Schema ‘Procesdocumentatie4.xsd’ dat je in de voorgaande oefening hebt vervaardigd of open het opnieuw in ‘Altova XMLSpy’;
Wijzig zo nodig de editing modus naar “Text”;

Klantgegevens

Oefening 5-3-1

Tue, 17 Mar 2026 00:00:00 +0000

Oefening 5.3.1: Een eenvoudig XML-SChema

We gaan in het onderliggende cursusonderdeel toewerken naar een XML-Schema dat geschikt is voor drie verschillende typen documenten, een orderbon, een betaalbevestiging en een factuur.

Maak daarvoor in een XML-Schema de volgende elementen aan met daarachter tussen haakjes het datatype.

orderbon (string);
betaalbevestiging (boolean);
factuur (integer);
voorletters (string);
postcode (string).
ordernummer (string);

Opdracht

Open in ‘Altova XMLSpy’ een nieuw document via “File - New…” (of met Ctrl-N);
Kies “xsd XML Schema v1.0” en klik op “OK”;
Wijzig zo nodig de editing modus naar “Text”;
Zoals je ziet is er een eerste xs:element aangemaakt met daarbinnen een xs:annotation. Die laatste kan gebruikt worden om de diverse XML-Schema onderdelen van documentatie te voorzien. Binnen deze cursus zullen we er verder geen aandacht aan besteden;
Wijzig het xs:element zoals in de intro van deze oefening bij ‘orderbon’ staat aangegeven en voeg ook de twee andere xs:element elementen toe;
Bewaar het bestand ergens als “Procesdocumentatie1.xml” en meteen ook als “Procesdocumentatie2.xml”;
Ga naar “DTD/Schema - Generate Sample XML/JSON/YAML File…”;
Als alles goed is krijg je nu het menu “Generate sample XML file” met daarin in het veld “Please select root” de zes zojuist door je aangemaakte elementen. Selecteer er 1 en klik op “OK”. Er wordt vervolgens een XML-bestand gegenereerd dat voldoet aan het schema;
Als je wil kan je dit voor alle zes de elementen doen. De gegenereerde bestanden hoeven niet bewaard te worden.

Oefening 5-3-2

Tue, 17 Mar 2026 00:00:00 +0000

Oefening 5.3.2: Beperken van waardetypes

In de voorgaande oefening hebben we de elementen <voorletters>, <postcode> en <ordernummer> gedefinieerd. In deze oefening gaan we het waardedomein daarvan beperken. Het element <voorletters> mag alleen maar bestaan uit een of meer combinaties van een hoofdletter en een punt (.). Het <postcode> element mag alleen waardes bevatten die starten met 4 cijfers direct gevolgd door 2 hoofdletters. En het <ordernummer> element mag niet langer dan 13 lang zijn.

Oefening 5-3-3

Tue, 17 Mar 2026 00:00:00 +0000

Oefening 5.3.3: Definiëren van complexere structuren

In deze oefening gaan de elementen <orderbon>, <factuur> en <betaalbevestiging> flink op de schop. De elementen <voorletters>, <postcode> en <ordernummer> zullen onderdeel gaan uitmaken van de nieuwe structuur. Hieronder zie je het informatiemodel dat als basis dient voor deze nieuwe structuur.

Je ziet dat in deze grafische weergave van het model de objecttypes ‘Factuur’, ‘Orderbon’ en ‘Betaalbevestiging’ anders zijn vormgegeven evenals de relaties die van daaruit naar ‘Order’ lopen. Dit komt omdat we al hebben onderkent dat deze objecttypes geen rol spelen in enige database of berichtuitwisseling. De structuur in de documenten zal zoals je zal zien ook niet helemaal overeenkomen met die in dit informatiemodel.

Oefening 5-2-1

Sat, 14 Mar 2026 00:00:00 +0000

Oefening 5.2.1: StUF Zaken

Je krijgt nu een sneak preview in een StUF bericht. Het is een goed voorbeeld van het toepassen van namespaces en we kijken dus nog niet naar de semantiek achter het bericht.

Benodigde files

Download ZakLk01.zip en plaats de inhoud (ZakLk01.xml) op een locatie waar jij er makkelijk bij kunt.
Download Zkn0310-schema.zip en plaats de inhoud (een aantal XML-Schema bestanden) op een locatie waar jij er makkelijk bij kunt.

Opdracht

Oefening 5-1-1

Fri, 13 Mar 2026 00:00:00 +0000

Oefening 5.1.1: Visitekaartje

Teneinde de input voor visitekaartjes automatisch te kunnen verwerken, heeft de verantwoordelijke afdeling van een groot IT-bedrijf een web-pagina gebouwd. Daarin worden de gegevens ingebracht die op een visitekaartje geplaatst kunnen worden. Deze gegevens worden in XML-formaat naar het bedrijf gestuurd, dat uiteindelijk de visitekaartjes produceert. Het XML-schema waarin dit XML-formaat is vastgelegd ga je nu gebruiken om een XML-bestand te creëren.

Benodigde files

Download Visitekaartje.zip en plaats de inhoud (Visitekaartje.xsd) op een locatie waar jij er makkelijk bij kunt.

Opdracht

Oefening 5-1-2

Fri, 13 Mar 2026 00:00:00 +0000

Oefening 5.1.2: Luxe visitekaartje

Het bedrijf heeft besloten voor specifieke functies ook privé informatie op een visitekaartje toe te staan. Het gaat om het adres, het e-Mailadres, het telefoonnummer en het mobielenummer. Het XML-schema is daartoe aangepast.

Benodigde files

Download Visitekaartje-luxe.zip en plaats de inhoud (Visitekaartje-luxe.xsd) op een locatie waar jij er makkelijk bij kunt.

Opdracht

Open ‘Altova XMLSpy 2024 Enterprise XML Editor’.;
Creëer een nieuw XML-document via “File – New” en kies de optie “xml Extensible Markup language 1.0”;
Als je nu op OK klikt krijgt je het “Choose Schema or DTD” menu te zien. Selecteer de optie “Assign Schema/DTD file”;
Klik vervolgens achter het invoerveld op het map icoontje voor “Browse file” en selecteer het bestand “Visitekaartje-luxe.xsd” waar je dat eerder hebt opgeslagen;
Klik op “Open” en vervolgens op “OK”;
XMLSPY heeft nu wederom een XML-bestand voor je aangemaakt met dezelfde minimaal benodigde set elementen als eerder en deze geopend in “Text view”. Voorzie de elementen weer van inhoud.
Valideer indien gewenst weer.;
Creëer een extra adres, e-Mailadres, telefoonnummer en mobielnummer;
Definieer op deze elementen het in het XML-Schema gespecificeerde attribuut. Ga daarvoor in de starttag achter de naam staan en voor een spatie in. Je krijgt dan te zien welke attributen je toe kunt voegen. Voorzie deze ook van een waarde die is toegestaan. Negeer het attribuut ‘xsi:type’;
Bewaar het bestand ergens als “Visitekaartje-luxe.xml”.

10.3 Werkgroepen en communities

Wed, 04 Mar 2026 00:00:00 +0000

← Terug naar Stakeholdermanagement en communicatie

10.3 Werkgroepen en communities

Kan participeren in landelijke werkgroepen, communities en expertisegroepen.

11.3 SOAP/XML vs. REST/JSON

Wed, 04 Mar 2026 00:00:00 +0000

11.3 SOAP/XML vs. REST/JSON

Kent het verschil tussen SOAP/XML-gebaseerde koppelvlakken en REST/JSON-gebaseerde koppelvlakken.

2.2 Relatie StUF, RSGB en GEMMA-standaarden

Wed, 04 Mar 2026 00:00:00 +0000

2.2 Relatie StUF, RSGB en GEMMA-standaarden

Kent de relatie tussen StUF, RSGB en andere GEMMA-standaarden.

De GEMMA-standaardenfamilie

Binnen GEMMA vormen verschillende standaarden een samenhangend ecosysteem:

StUF (Standaard Uitwisseling Formaat)

Functie: Uitwisselingsstandaard voor berichten tussen systemen
Technologie: XML-gebaseerd berichtenprotocol
Gebruik: Zorgt voor gestandaardiseerde communicatie tussen applicaties

RSGB (Referentie Semantisch Gegevensmodel Basisregistraties)

Functie: Semantisch model voor basisregistratiegegevens
Scope: Definieert objecttypen, attributen en relaties
Gebruik: Basis voor informatiemodellen in gemeentelijke systemen

Onderlinge relaties

Hoe ze samenwerken:

RSGB definieert wat de gegevens betekenen
StUF definieert hoe gegevens uitgewisseld worden
Applicaties implementeren beide standaarden

Andere GEMMA-standaarden

RGBZ (Referentie Gegevensmodel Burgerzaken)

Specifiek voor zaakgericht werken
Gebruikt StUF voor uitwisseling
Bouwt voort op RSGB-principes

iWlz (informatiemodel Wet langdurige zorg)

Domeinspecifiek voor WMO/Wlz
Volgt GEMMA-architectuurprincipes
Gebruikt StUF-patronen voor berichten

Evolutie naar API’s

De GEMMA-standaarden evolueren:

3.2 Metamodel Informatie Modellering (MIM)

Wed, 04 Mar 2026 00:00:00 +0000

3.2 Metamodel Informatie Modellering (MIM)

Kent en begrijpt het Metamodel Informatie Modellering (MIM).

Wat is MIM?

Het Metamodel Informatie Modellering (MIM) is de Nederlandse standaard voor het maken van informatiemodellen. Het biedt een gemeenschappelijke taal en methodologie voor:

Semantische interoperabiliteit: Eenduidige begrippenkaders
Modelconsistentie: Uniforme modelleringsregels
Uitwisselbaarheid: Models die verschillende tools kunnen interpreteren

MIM-architectuur

Beschouwingsniveaus

MIM kent vier beschouwingsniveaus:

Niveau	Naam	Focus	Doelgroep
1	Model van begrippen	Betekenis en definities	Business, beleidsmakers
2	Conceptueel model	Informatiekundige structuur	Informatieanalist
3	Logisch model	Implementatie-onafhankelijke gegevensstructuur	Gegevensarchitect
4	Fysiek model	Technische implementatie	Database-ontwerper

Kernconcepten

Basisobjecten:

4.2 JSON als uitwisselingsformaat

Wed, 04 Mar 2026 00:00:00 +0000

4.2 JSON als uitwisselingsformaat

Kent JSON als modern uitwisselingsformaat (syntax, schema’s, voordelen ten opzichte van XML).

Wat is JSON?

JSON (JavaScript Object Notation) is een lichtgewicht, text-based data-uitwisselingsformaat. Hoewel oorspronkelijk ontworpen voor JavaScript, is JSON nu de de-facto standaard geworden voor moderne web-APIs en wordt steeds vaker ingezet in overheidscontext als alternatief voor XML.

Kerneigenschappen:

Compact: Minder overhead dan XML
Human-readable: Eenvoudig te lezen en schrijven
Native JavaScript: Perfect voor web-applicaties
Language-agnostic: Support in alle moderne programmeertalen

JSON-syntax en structuur

Basis JSON-datatypes

{
 "string_waarde": "tekst",
 "number_waarde": 42,
 "decimal_waarde": 3.14159,
 "boolean_waarde": true,
 "null_waarde": null,
 "array_waarde": [1, 2, 3, "vier"],
 "object_waarde": {
 "nested_key": "nested_value"
 }
}

Persoon-voorbeeld (vergelijkbaar met XML)

{
 "persoon": {
 "bsn": "123456789",
 "geslachtsnaam": {
 "voorvoegsel": "van der",
 "geslachtsnaamStam": "Berg"
 },
 "voornamen": "Jan Peter",
 "geboortedatum": "1985-03-15",
 "adres": {
 "straatnaam": "Hoofdstraat",
 "huisnummer": 42,
 "huisnummertoevoeging": "A",
 "postcode": "1234AB",
 "woonplaatsnaam": "Amsterdam"
 },
 "contactgegevens": [
 {
 "soort": "email",
 "waarde": "jan.vandenberg@example.com"
 },
 {
 "soort": "telefoon",
 "waarde": "06-12345678"
 }
 ]
 }
}

JSON vs XML-vergelijking

XML-versie:

6.3 Koppelvlakspecificaties

Wed, 04 Mar 2026 00:00:00 +0000

6.3 Koppelvlakspecificaties

Kan StUF-koppelvlakspecificaties opstellen, lezen en beheren.

Wat zijn koppelvlakspecificaties?

Een koppelvlakspecificatie is een document dat precies beschrijft hoe twee systemen met elkaar kunnen communiceren via StUF-berichten. Het definieert de berichten, scenario’s, en business-regels die nodig zijn voor succesvolle gegevensuitwisseling.

Componenten van een koppelvlakspecificatie:

Functionele specificatie: Wat wordt uitgewisseld en waarom
Technische specificatie: Hoe wordt het uitgewisseld
Berichtcatalogus: Welke berichten zijn beschikbaar
Scenario’s: Workflows en use cases
Schema’s: XML-schema definities
Implementatie-voorbeelden: Concrete berichten

Structuur van een koppelvlakspecificatie

graph TB
A[Koppelvlakspecificatie] --> B[Functionele Specificatie]
A --> C[Technische Specificatie]
A --> D[Berichtcatalogus]
A --> E[XML Schema's]
A --> F[Voorbeeldberichten]
B --> B1[Use Cases]
B --> B2[Business Rules]
B --> B3[Autorisaties]
C --> C1[Protocol-binding]
C --> C2[Error Handling]
C --> C3[Security]
D --> D1[Request Messages]
D --> D2[Response Messages]
D --> D3[Notification Messages]
E --> E1[Message Schemas]
E --> E2[Data Type Definitions]
E --> E3[Validation Rules]
F --> F1[Successful Scenarios]
F --> F2[Error Scenarios]
F --> F3[Edge Cases]

StUF-BG Koppelvlakspecificatie

Basisgegevens koppelvlak

StUF-BG specificatie componenten:

7.2 Versies van het RSGB

Wed, 04 Mar 2026 00:00:00 +0000

7.2 Versies van het RSGB

Kent de verschillende versies van het RSGB en de onderlinge verschillen.

8.3 Imvertor

Wed, 04 Mar 2026 00:00:00 +0000

8.3 Imvertor gebruiken om informatiemodellen te controleren

Kan imvertor hanteren om te zorgen dat de informatiemodellen voldoen aan de MIM-voorwaarden.

9.3 Specificaties publiceren

Wed, 04 Mar 2026 00:00:00 +0000

Terug naar leerlijn 9

9.3 Specificaties publiceren

Kan specificaties publiceren voor gebruik door gemeenten en leveranciers.

5.2 XML-namespaces

Thu, 12 Mar 2026 00:00:00 +0000

5.2 XML-namespaces

Begrijpt het doel van XML-namespaces en kan de techniek daarachter toepassen in de context van meerdere standaarden.

Probleem

In de voorgaande paragraaf gaven we al aan dat XML voorziet in een techniek waarmee computers, maar ook mensen, ondubbelzinnig kunnen begrijpen wat elk gegeven betekent. Maar wat als je nu gegevens wil vastleggen of uitwisselen over verschillende entiteiten die weliswaar een andere betekenis hebben maar wel dezelfde naam gebruiken. Denk bijvoorbeeld aan een ‘Bank’, dit kan een meubel zijn maar ook een financiële instelling. In de onderstaande tabel geven we nog een aantal voorbeelden:

1.2 Stelsel van Basisregistraties

Wed, 04 Mar 2026 00:00:00 +0000

1.2 Stelsel van Basisregistraties

1.2.1 Wat is het stelsel van basisregistraties

Het stelsel van basisregistraties is het geheel van afspraken en voorzieningen gericht op het doelmatige en efficiënte beheer van een beperkt aantal gegevens, die nodig zijn voor de uitvoering van de taken van de overheid. Die gegevens zijn vastgelegd in gegevensverzamelingen met een wettelijke basis — de basisregistraties — inclusief hun onderlinge samenhang en de gemeenschappelijke voorzieningen voor verzameling, verspreiding en gebruik. (Bron: digitaleoverheid.nl)

1.3 Informatiestromen binnen gemeenten

Wed, 04 Mar 2026 00:00:00 +0000

1.3 Informatiestromen binnen gemeenten

Begrijpt de informatiestromen binnen gemeenten en tussen gemeenten en keten-/netwerkpartners.

10.4 Nieuwe ideeën uitdragen

Wed, 04 Mar 2026 00:00:00 +0000

← Terug naar Stakeholdermanagement en communicatie

10.4 Nieuwe ideeën uitdragen

Kan nieuwe ideeën en concepten ontwikkelen, uitdragen en verdedigen.

11.4 Transitie StUF naar API's

Wed, 04 Mar 2026 00:00:00 +0000

11.4 Transitie StUF naar API’s

Kan adviseren over transitievraagstukken rondom bestaande StUF-koppelvlakspecificaties richting API’s.

2.3 Bijdragen aan GEMMA

Wed, 04 Mar 2026 00:00:00 +0000

2.3 Bijdragen aan GEMMA

Kan bijdragen aan de ontwikkeling en het gebruik van GEMMA-architectuur en standaarden.

Hoe kun je bijdragen aan GEMMA?

Als informatieanalist of gegevensarchitect bij VNG Realisatie kun je op verschillende manieren bijdragen aan de doorontwikkeling van GEMMA:

1. Standaardontwikkeling

Meewerken aan nieuwe standaarden:

Deelname aan werkgroepen en expertgroepen
Input leveren vanuit praktijkervaring
Reviewen van conceptversies
Testen van standaarden in pilotprojecten

Focus gebieden:

Uitbreiding van informatiemodellen
Ontwikkeling van API-standaarden
Harmonisatie tussen domeinen

2. Implementatieondersteuning

Gemeenten helpen bij toepassing:

3.3 Conceptueel modelleren (MIM niveau 2)

Wed, 04 Mar 2026 00:00:00 +0000

3.3 Conceptueel modelleren (MIM niveau 2)

Kan werken op MIM-beschouwingsniveau 2 (conceptueel modelleren).

Wat is conceptueel modelleren?

Conceptueel modelleren op MIM niveau 2 richt zich op het vastleggen van de informatiekundige structuur, onafhankelijk van technische implementatie. Het vertaalt businessbehoeften naar een formeel informatiemodel.

Doelen van conceptueel modelleren:

Communicatie: Gemeenschappelijke taal tussen business en IT
Analyse: Begrijpen van informatiestromen en -behoeften
Ontwerp: Basis voor verdere uitwerking naar logische en fysieke modellen
Validatie: Toetsen van volledigheid en consistentie

MIM niveau 2 kenmerken

Focus op betekenis

Wat moet worden geregistreerd (niet hoe)
Waarom is informatie relevant
Welke samenhangen bestaan tussen gegevens

Abstractieniveau

Implementatie-onafhankelijk
Business-georiënteerd
Platform-neutraal

Conceptuele modelleerelementen

Objecttypen

Objecttypen representeren verzamelingen van objecten uit de werkelijkheid:

4.3 SOAP-protocol

Wed, 04 Mar 2026 00:00:00 +0000

4.3 SOAP-protocol

Kent het SOAP-protocol voor webservices (structuur, WSDL, security, foutafhandeling).

Wat is SOAP?

SOAP (Simple Object Access Protocol, later hernoemd naar Service Oriented Architecture Protocol) is een messaging-protocol voor het uitwisselen van gestructureerde informatie in web services. SOAP is een W3C-standaard die zwaar wordt gebruikt in enterprise- en overheidsomgevingen voor betrouwbare, veilige communicatie tussen systemen.

Kerneigenschappen:

Protocol-agnostic: Werkt over HTTP, HTTPS, SMTP, TCP
Platform-independent: Kan tussen verschillende systemen communiceren
Extensible: Uitbreidbaar met headers en security-features
Standardized: Strikte W3C-specificatie met tooling-support

SOAP-berichtstructuur

Basis SOAP-envelope

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:tns="http://example.org/persoon-service">

 <!-- Optionele headers -->
 <soap:Header>
 <tns:Authentication>
 <tns:Username>gemeente_amsterdam</tns:Username>
 <tns:Token>abc123-xyz789</tns:Token>
 </tns:Authentication>
 </soap:Header>

 <!-- Verplichte body -->
 <soap:Body>
 <tns:GetPersoonRequest>
 <tns:BSN>123456789</tns:BSN>
 </tns:GetPersoonRequest>
 </soap:Body>
</soap:Envelope>

SOAP-response

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:tns="http://example.org/persoon-service">

 <soap:Body>
 <tns:GetPersoonResponse>
 <tns:Persoon>
 <tns:BSN>123456789</tns:BSN>
 <tns:Voornaam>Jan</tns:Voornaam>
 <tns:Achternaam>Berg</tns:Achternaam>
 <tns:Geboortedatum>1985-03-15</tns:Geboortedatum>
 <tns:Adres>
 <tns:Straat>Hoofdstraat 42</tns:Straat>
 <tns:Postcode>1234AB</tns:Postcode>
 <tns:Plaats>Amsterdam</tns:Plaats>
 </tns:Adres>
 </tns:Persoon>
 </tns:GetPersoonResponse>
 </soap:Body>
</soap:Envelope>

SOAP Fault (foutafhandeling)

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
 <soap:Fault>
 <soap:Code>
 <soap:Value>soap:Client</soap:Value>
 <soap:Subcode>
 <soap:Value>tns:InvalidBSN</soap:Value>
 </soap:Subcode>
 </soap:Code>
 <soap:Reason>
 <soap:Text xml:lang="nl">
 BSN '12345678X' is geen geldig Burgerservicenummer
 </soap:Text>
 </soap:Reason>
 <soap:Detail>
 <tns:ValidationError>
 <tns:Field>BSN</tns:Field>
 <tns:Message>BSN moet uit precies 9 cijfers bestaan</tns:Message>
 <tns:Code>BSN_INVALID_FORMAT</tns:Code>
 </tns:ValidationError>
 </soap:Detail>
 </soap:Fault>
 </soap:Body>
</soap:Envelope>

WSDL (Web Service Description Language)

WSDL beschrijft de interface van een SOAP web service - welke operaties beschikbaar zijn, hoe berichten gestructureerd zijn, en hoe de service te bereiken is.

6.4 StUF-berichten ontwerpen

Wed, 04 Mar 2026 00:00:00 +0000

6.4 StUF-berichten ontwerpen

Kan StUF-berichten ontwerpen waarmee gegevens uitgewisseld worden.

Berichtontwerp-principes

Het ontwerpen van effectieve StUF-berichten vereist aandacht voor zowel functionele als technische aspecten. Een goed ontworpen bericht faciliteert betrouwbare gegevensuitwisseling en ondersteunt business-processen optimaal.

Ontwerpoverwegingen

Functionele aspecten:

Doel: Wat wil je bereiken met het bericht?
Context: In welk business-proces wordt het gebruikt?
Stakeholders: Wie zijn zender en ontvanger?
Gegevens: Welke informatie moet worden uitgewisseld?
Timing: Wanneer wordt het bericht verstuurd?

Technische aspecten:

7.3 Relatie RSGB en StUF

Wed, 04 Mar 2026 00:00:00 +0000

7.3 Relatie RSGB en StUF

Begrijpt de relatie tussen het RSGB en StUF-koppelvlakspecificaties.

9.4 Impactanalyses en adviezen vastleggen

Wed, 04 Mar 2026 00:00:00 +0000

Terug naar leerlijn 9

9.4 Impactanalyses en adviezen vastleggen

Kan impactanalyses en adviezen schriftelijk vastleggen.

10.5 Gegevensarchitectuur overbrengen

Wed, 04 Mar 2026 00:00:00 +0000

← Terug naar Stakeholdermanagement en communicatie

10.5 Gegevensarchitectuur overbrengen

Kan gegevensarchitectuur overbrengen aan anderen op alle niveaus.

11.5 Balans oud en nieuw

Wed, 04 Mar 2026 00:00:00 +0000

11.5 Balans oud en nieuw

Kan balanceren tussen beheer van bestaande (“oude”) techniek en innovatieve nieuwe ontwikkelingen.

3.4 Logisch modelleren (MIM niveau 3)

Wed, 04 Mar 2026 00:00:00 +0000

3.4 Logisch modelleren (MIM niveau 3)

Kan werken op MIM-beschouwingsniveau 3 (logisch modelleren).

Wat is logisch modelleren?

Logisch modelleren op MIM niveau 3 vertaalt het conceptuele model naar een implementatie-onafhankelijke gegevensstructuur. Het voegt technische details toe zonder vast te leggen op een specifiek platform.

Verschil met conceptueel niveau:

Conceptueel (niveau 2): WAT moet worden vastgelegd
Logisch (niveau 3): HOE kan het worden gestructureerd

Logische modelkenmerken

Uitgebreidere specificatie

Datatypes: Concrete gegevenstypes (tekst, nummer, datum)
Lengtebeperkingen: Maximale aantal karakters of cijfers
Formaat-specifaties: Reguliere expressies, waardenlijsten
Constraintregels: Bedrijfsregels en validatielogica

Technische verfijning

Kardinaliteiten: Exacte minimale en maximale aantallen
Identificatie: Primaire sleutels en unieke attributen
Referentie-integriteit: Verwijzingen tussen objecttypen
Indexering: Performance-overwegingen voor toegang

Logische modelleerelementen

Verfijnde attributen

Gespecificeerde relaties

Gegevensgroepen

Transformatieregels vanuit conceptueel model

Objecttypen → Entiteiten

Elk objecttype wordt een logische entiteit
Abstracte objecttypen kunnen worden weggelaten
Specialisaties kunnen samengevoegd worden

Attributen → Velden

Conceptuele attributen krijgen concrete datatypes
Afleidbare attributen kunnen weggelaten worden
Identificerende attributen worden primaire sleutels

Relaties → Koppelingen

Associaties worden foreign key relaties
Many-to-many relaties krijgen tussentabellen
Composities worden geneste structuren

Logische modelleringspatronen

Identificatiepatronen

Temporele patronen

Referentiedatapatronen

Constraintspecificatie

Domeinregels

CHECK (Geboorte_datum <= CURRENT_DATE)
CHECK (Lengte_x > 0 AND Lengte_x < 1000)
CHECK (Email LIKE '%@%.%')

Referentiële integriteit

Bedrijfsregels

Kwaliteitsbewaking

Normalisatie

1NF: Geen herhalende groepen
2NF: Geen partiële afhankelijkheid van samengestelde sleutels
3NF: Geen transitieve afhankelijkheden

Denormalisatie overwegingen

Performance: Strategische redundantie voor snelheid
Usability: Vereenvoudiging voor eindgebruikers
Integration: Aansluiting bij bestaande systemen

Validatietechnieken

Automatische controles

MIM-conformiteit: Tooling voor modelvalidatie
Consistentie-checks: Kruisverwijzingen en constraints
Volledigheid-analyse: Coverage van functionele requirements

Review-processen

Technical review: Architecten en database-specialisten
Domain review: Functionele experts en data-eigenaren
Implementation review: Ontwikkelaars en system integrators

Documentatie-eisen

Technische specificatie

Datatype-definities: Precieze formaten en beperkingen
Constraint-catalogus: Alle bedrijfs- en technische regels
Indexering-strategie: Performance-optimalisatie

Implementatie-guidance

Mapping naar platforms: Hoe het model te implementeren in verschillende databases
Migratie-strategie: Hoe bestaande data over te zetten
Test-scenario’s: Hoe het model te valideren

Tools voor logisch modelleren

Database-ontwerp tools

ER/Studio: Enterprise data modellering
PowerDesigner: Comprehensive modellering platform
Oracle SQL Developer Data Modeler: Oracle-specifiek
MySQL Workbench: MySQL-gericht

Validatie-tools

Schema-validatoren: Automatische MIM-controle
Data-profiling tools: Analyse van bestaande datasets
Constraint-checkers: Validatie van bedrijfsregels

Uitdagingen logisch modelleren

Platform-onafhankelijkheid behouden

Vermijd: Database-specifieke datatypes
Gebruik: Standaard MIM-datatypes
Focus: Op logische structuur, niet implementatie

Performance vs Puurheid

Balans: Tussen gegevenskwaliteit en systeemprestaties
Documenteer: Afwijkingen van standaardpatronen
Rechtvaardigen: Technische beslissingen expliciet

Legacy-integratie

Analyseer: Bestaande datastructuren
Map: Oude naar nieuwe modellen
Migreer: Geleidelijk en gecontroleerd

Logisch modelleren vereist zowel conceptueel inzicht als technische kennis. Het is de brug tussen businessbehoeften en technische implementatie, waarbij kwaliteit en implementeerbaarheid in balans moeten blijven.

4.4 HTTP-protocol voor REST-API's

Wed, 04 Mar 2026 00:00:00 +0000

4.4 HTTP-protocol voor REST-API’s

Beheerst HTTP als protocol voor REST-API’s (methods, status codes, headers, caching).

HTTP-basics voor API’s

HTTP (Hypertext Transfer Protocol) vormt de basis van moderne web-API’s. In REST-architectuur wordt HTTP gebruikt zoals het bedoeld is: als een complete application-layer protocol voor resource-manipulatie.

HTTP Request-structuur

POST /api/personen HTTP/1.1
Host: api.gemeente.nl
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: Gemeente-App/2.1.0
Content-Length: 156

{
 "bsn": "123456789",
 "voornaam": "Jan",
 "achternaam": "Berg",
 "geboortedatum": "1985-03-15"
}

HTTP Response-structuur

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/personen/pers_abc123
ETag: "v1.2.3"
Cache-Control: private, max-age=3600
Content-Length: 234

{
 "id": "pers_abc123",
 "bsn": "123456789",
 "voornaam": "Jan",
 "achternaam": "Berg",
 "geboortedatum": "1985-03-15",
 "created_at": "2024-03-05T14:30:00Z",
 "updated_at": "2024-03-05T14:30:00Z",
 "_links": {
 "self": "/api/personen/pers_abc123",
 "adres": "/api/personen/pers_abc123/adres"
 }
}

HTTP Methods voor CRUD-operaties

GET - Resource opvragen

# Single resource
GET /api/personen/123456789 HTTP/1.1
Host: api.gemeente.nl
Accept: application/json

# Collection met filters
GET /api/personen?achternaam=Berg&geboortejaar=1985 HTTP/1.1
Host: api.gemeente.nl
Accept: application/json

# Response
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=300

{
 "data": [
 {
 "id": "pers_123",
 "voornaam": "Jan",
 "achternaam": "Berg"
 }
 ],
 "pagination": {
 "total": 1,
 "page": 1,
 "per_page": 25
 }
}

POST - Resource aanmaken

POST /api/personen HTTP/1.1
Host: api.gemeente.nl
Content-Type: application/json
Content-Length: 95

{
 "bsn": "987654321",
 "voornaam": "Maria",
 "achternaam": "Jansen"
}

# Success Response
HTTP/1.1 201 Created
Location: /api/personen/pers_xyz789
Content-Type: application/json

{
 "id": "pers_xyz789",
 "bsn": "987654321",
 "voornaam": "Maria",
 "achternaam": "Jansen",
 "created_at": "2024-03-05T14:30:00Z"
}

# Error Response
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
 "type": "https://api.gemeente.nl/problems/validation-error",
 "title": "Validation Failed",
 "status": 400,
 "detail": "Het verstrekte BSN is al in gebruik",
 "instance": "/api/personen",
 "invalid_params": [
 {
 "name": "bsn",
 "reason": "BSN moet uniek zijn"
 }
 ]
}

PUT - Resource volledig vervangen

PUT /api/personen/pers_123 HTTP/1.1
Host: api.gemeente.nl
Content-Type: application/json
If-Match: "v1.2.3"

{
 "bsn": "123456789",
 "voornaam": "Johannes",
 "achternaam": "van den Berg",
 "geboortedatum": "1985-03-15"
}

# Success Response
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "v1.2.4"

{
 "id": "pers_123",
 "bsn": "123456789",
 "voornaam": "Johannes",
 "achternaam": "van den Berg",
 "geboortedatum": "1985-03-15",
 "updated_at": "2024-03-05T14:35:00Z"
}

# Conflict Response (optimistic locking)
HTTP/1.1 412 Precondition Failed
Content-Type: application/problem+json

{
 "type": "https://api.gemeente.nl/problems/stale-data",
 "title": "Resource Modified",
 "status": 412,
 "detail": "De resource is gewijzigd door een andere gebruiker"
}

PATCH - Gedeeltelijke resource-update

PATCH /api/personen/pers_123 HTTP/1.1
Host: api.gemeente.nl
Content-Type: application/json-patch+json
If-Match: "v1.2.4"

[
 {
 "op": "replace",
 "path": "/voornaam",
 "value": "Jan"
 },
 {
 "op": "add",
 "path": "/emailadres",
 "value": "jan.vandenberg@example.com"
 }
]

# Alternative: JSON Merge Patch
PATCH /api/personen/pers_123 HTTP/1.1
Content-Type: application/merge-patch+json

{
 "voornaam": "Jan",
 "emailadres": "jan.vandenberg@example.com"
}

DELETE - Resource verwijderen

DELETE /api/personen/pers_123 HTTP/1.1
Host: api.gemeente.nl
If-Match: "v1.2.4"

# Success Response (no content)
HTTP/1.1 204 No Content

# Success Response (with info)
HTTP/1.1 200 OK
Content-Type: application/json

{
 "message": "Persoon succesvol verwijderd",
 "deleted_at": "2024-03-05T14:40:00Z"
}

# Conflict Response
HTTP/1.1 409 Conflict
Content-Type: application/problem+json

{
 "type": "https://api.gemeente.nl/problems/cannot-delete",
 "title": "Cannot Delete Resource",
 "detail": "Persoon kan niet worden verwijderd vanwege actieve zaken"
}

HTTP Status Codes

Success Codes (2xx)

200 OK # Successful GET, PUT, PATCH
201 Created # Successful POST (resource created)
202 Accepted # Request accepted (async processing)
204 No Content # Successful DELETE or PUT (no response body)
206 Partial Content # Partial GET (range requests)

Client Error Codes (4xx)

400 Bad Request # Malformed request
401 Unauthorized # Authentication required
403 Forbidden # Authorization failed
404 Not Found # Resource doesn't exist
405 Method Not Allowed # HTTP method not supported
406 Not Acceptable # Unsupported Accept header
409 Conflict # Resource conflict (e.g., duplicate)
410 Gone # Resource permanently deleted
412 Precondition Failed # If-Match, If-None-Match failed
413 Payload Too Large # Request body too large
415 Unsupported Media Type # Unsupported Content-Type
422 Unprocessable Entity # Semantic validation failed
429 Too Many Requests # Rate limiting

Server Error Codes (5xx)

500 Internal Server Error # Generic server error
501 Not Implemented # Feature not implemented
502 Bad Gateway # Upstream service error
503 Service Unavailable # Temporary service outage
504 Gateway Timeout # Upstream service timeout

HTTP Headers voor API’s

Request Headers

Authentication/Authorization:

5.3 XML-Schema's (XSD)

Wed, 04 Mar 2026 00:00:00 +0000

5.3 XML-Schema’s (XSD)

Kan XML-Schema’s (XSD’s) lezen, begrijpen en opstellen.

Het probleem: XML is te vrij

In sectie 5.1 heb je geleerd hoe je met XML gegevens structureert. Maar XML zelf legt alleen syntaxregels op — welgevormdheid. Het zegt niets over welke elementen en attributen zijn toegestaan, in welke volgorde ze mogen voorkomen of welke waarden geldig zijn.

Stel: twee gemeentelijke systemen wisselen persoonsgegevens uit via XML. Systeem A stuurt:

6.5 Bedrijfsregels en validaties

Wed, 04 Mar 2026 00:00:00 +0000

6.5 Bedrijfsregels en validaties

Kan bedrijfsregels en validaties definiëren die bij StUF-berichten horen.

Bedrijfsregels in StUF-context

Bedrijfsregels zijn voorschriften die bepalen hoe gegevens in StUF-berichten moeten worden gevalideerd, verwerkt en geïnterpreteerd. Ze borgen de kwaliteit en consistentie van gegevensuitwisseling tussen overheidsapplicaties.

Types bedrijfsregels

1. Structurele validaties

XML-schema conformiteit
Verplichte velden controle
Datatype-validaties
Lengte-beperkingen

2. Semantische validaties

BSN-elfproef
Datum-consistentie
Referentiële integriteit
Domain-specific rules

3. Autorisatie-regels

Toegangsrechten per organisatie
Gegevens-classificatie
Privacy-beperkingen
Audit-requirements

4. Business-logica regels

7.4 Impactanalyse op RSGB-elementen

Wed, 04 Mar 2026 00:00:00 +0000

7.4 Impactanalyse op RSGB-elementen

Kan bepalen welke RSGB-elementen geraakt worden bij wijzigingen in het logisch ontwerp (bijv. BRP).

10.6 Kennis delen

Wed, 04 Mar 2026 00:00:00 +0000

← Terug naar Stakeholdermanagement en communicatie

10.6 Kennis delen

Kan via presentaties, kennissessies en interviews kennis delen.

11.6 Visie op de toekomst

Wed, 04 Mar 2026 00:00:00 +0000

11.6 Visie op de toekomst

Heeft een visie op de toekomst van de gemeentelijke informatievoorziening.

3.5 Informatiemodellen analyseren en wijzigen

Wed, 04 Mar 2026 00:00:00 +0000

3.5 Informatiemodellen analyseren en wijzigen

Kan bestaande informatiemodellen analyseren en wijzigingsvoorstellen doen.

Analyse van bestaande modellen

De analyse van informatiemodellen vereist een systematische aanpak om kwaliteit, actualiteit en geschiktheid voor het doel te beoordelen.

Analysedimensies

1. Structurele kwaliteit

Volledigheid: Zijn alle benodigde objecttypen, attributen en relaties aanwezig?
Consistentie: Zijn er conflicterende definities of dubbelingen?
Coherentie: Hangen de modelelementen logisch samen?

2. Semantische kwaliteit

Begrippenduidelijkheid: Zijn definities eenduidig en begrijpelijk?
Domeindepping: Is de werkelijkheidsrepresentatie accuraat?
Terminologie: Is naamgeving consistent en herkenbaar?

3. Technische kwaliteit

4.5 Formaat- en protocolkeuzes

Wed, 04 Mar 2026 00:00:00 +0000

4.5 Formaat- en protocolkeuzes

Kan afgewogen keuzes maken tussen verschillende uitwisselingsformaten en protocollen op basis van context en requirements.

Decision Framework voor Format- en Protocolkeuze

Het kiezen van het juiste uitwisselingsformaat en protocol is een strategische beslissing die lange-termijn impact heeft op maintainability, performance en interoperabiliteit. Voor overheidsorganisaties zijn er specifieke overwegingen die deze keuze beïnvloeden.

Evaluatie-criteria

Technical Criteria:

Performance: Message-size, parsing-speed, bandwidth-usage
Complexity: Development-effort, debugging-ease, tooling
Interoperability: Cross-platform support, legacy-compatibility
Security: Built-in security features, vulnerability-resistance
Scalability: High-volume handling, caching-support

Business Criteria:

5.4 XML-schemavalidatie

Wed, 04 Mar 2026 00:00:00 +0000

Terug naar leerlijn 5

5.4 XML-schemavalidatie

Begrijpt XML-schemavalidatie en kan documenten valideren tegen schema’s.

Welgevormdheid: de basisregels

Een XML-document dat aan alle syntaxregels voldoet, heet welgevormd (Engels: well-formed). Een document dat niet welgevormd is, wordt door elke XML-verwerker geweigerd — er is geen “beetje goed”.

Regel 1: Precies één root-element

<!-- Fout: -->
<voornaam>Jan</voornaam>
<achternaam>de Vries</achternaam>

<!-- Goed: -->
<persoon>
 <voornaam>Jan</voornaam>
 <achternaam>de Vries</achternaam>
</persoon>

Regel 2: Elke openingstag heeft een sluitingstag

6.6 Specificaties verduidelijken

Wed, 04 Mar 2026 00:00:00 +0000

6.6 Specificaties verduidelijken

Kan bij vragen of meningsverschillen over de toepassing van StUF specificaties en schema’s verduidelijken ten behoeve van eenduidige implementatie.

Rol van StUF-expert

Als StUF-expert word je regelmatig geconfronteerd met interpretatievragen over specificaties. Deze vragen ontstaan doordat:

Specificaties soms ambigue geformuleerd zijn
Implementaties verschillende interpretaties toestaan
Business-context invloed heeft op technische keuzes
Legacy-systemen afwijkende gedragingen vertonen

Veelvoorkomende vraagcategorieën

1. Schema-interpretaties

Verplichte vs optionele velden
Datatype-beperkingen
Cardinaliteit-regels
Namespace-gebruik

2. Bericht-semantiek

7.5 RSGB onderhouden en doorontwikkelen

Wed, 04 Mar 2026 00:00:00 +0000

7.5 RSGB onderhouden en doorontwikkelen

Kan het RSGB onderhouden en doorontwikkelen.

1.4 Relevante ontwikkelingen

Wed, 04 Mar 2026 00:00:00 +0000

1.4 Relevante ontwikkelingen

1.4.1 Common Ground

Visie Common Ground

Common Ground is de visie die beschrijft hoe gemeenten hun informatievoorziening willen inrichten. Het gaat uit van een gedeelde basis die overheidsbreed moet worden gevormd, en kan daarom pas volledig worden gerealiseerd als de hele digitale overheid en iedereen die daarbij betrokken is, meedoet. De transitie naar een moderne informatievoorziening vereist niet alleen een meerjarige transitie-aanpak, maar dus ook betrokkenheid en inzet van vele partijen.Fungeert als schakel tussen business en techniek bij het realiseren van koppelingen.

10.7 Stakeholders ondersteunen

Wed, 04 Mar 2026 00:00:00 +0000

← Terug naar Stakeholdermanagement en communicatie

10.7 Stakeholders ondersteunen

Kan stakeholders (gemeenten, marktpartijen, interne collega’s) ondersteunen bij vragen over gegevensuitwisseling.

3.6 Nieuwe informatiemodellen structureren

Wed, 04 Mar 2026 00:00:00 +0000

3.6 Nieuwe informatiemodellen structureren

Kan nieuwe informatiemodellen structureren op basis van opgehaalde eisen en wensen.

Van requirements naar informatiemodel

Het structureren van nieuwe informatiemodellen begint met een grondige analyse van eisen en wensen. Dit vereist een systematische aanpak om van functionele requirements naar een formeel informatiemodel te komen.

Requirements-analyse proces

1. Stakeholder-identificatie

2. Requirements-verzameling

5.5 SOAP-protocol

Wed, 04 Mar 2026 00:00:00 +0000

5.5 SOAP-protocol

Begrijpt SOAP als protocol voor gegevensuitwisseling op basis van XML.

6.7 Impactanalyses uitvoeren

Wed, 04 Mar 2026 00:00:00 +0000

6.7 Impactanalyses uitvoeren

Kan de technische en organisatorische impact van wijzigingen in StUF-standaarden analyseren, zowel voor eigen organisatie als voor ketenpartners.

Impact-analyse framework

De impact van StUF-wijzigingen strekt zich uit over meerdere dimensies:

mindmap
root((StUF Impact))
Technisch
Applicaties
Legacy systemen
Modern applicaties
Interfaces
Middleware
Infrastructure
Networks
Security
Performance
Monitoring
Data
Schema changes
Migratie
Validatie
Archivering
Organisatorisch
Processen
Business workflows
Administratief
Juridisch
Compliance
Resources
Developers
Testing
Training
Budget
Stakeholders
Interne teams
Leveranciers
Ketenpartners
Eindgebruikers
Financieel
Ontwikkeling
Software aanpassingen
New tooling
Testing
Documentatie
Operationeel
Support
Maintenance
Training
Downtime
Strategisch
Architecture debt
Innovation capacity
Risk mitigation
Compliance costs

Technische impact-analyse

1. Applicatie-niveau impact

Schema-wijzigingen analyseren:

3.7 Informatiemodelleervisie uitdragen

Wed, 04 Mar 2026 00:00:00 +0000

3.7 Informatiemodelleervisie uitdragen

Kan de informatiemodelleervisie uitdragen via presentaties, kennissessies en schriftelijke bijdragen.

Waarom visie uitdragen belangrijk is

Het uitdragen van informatiemodelleervisie gaat verder dan het technisch beheersen van modelleringsvaardigheden. Het omvat het inspireren, overtuigen en mobiliseren van organisaties om informatiemodellering strategisch in te zetten.

Strategische waarde

Bewustwording: Organisaties helpen begrijpen van de waarde van goede informatiemodellen
Adoption: Stimuleren van breed gebruik van modelleringsmethodieken
Standardisatie:促进 uniformiteit en interoperabiliteit
Innovation: Inspireren tot nieuwe toepassingen van informatiemodellering

Kernboodschappen van informatiemodelleervisie

1. Informatiemodellering als strategische discipline

Boodschap: “Informatiemodellering is niet alleen een technische activiteit, maar een strategische discipline die organisaties helpt hun informatiehuishouding op orde te brengen en toekomstbestendig te maken.”

5.6 XML vs. JSON

Wed, 04 Mar 2026 00:00:00 +0000

5.6 XML vs. JSON

Kent het verschil tussen XML en JSON als uitwisselingsformaten.

6.8 Implementatie-scenario's opstellen

Wed, 04 Mar 2026 00:00:00 +0000

6.8 Implementatie-scenario’s opstellen

Kan verschillende implementatie-strategieën voor StUF-migraties ontwikkelen, afgestemd op organisatie-eisen, technische constraints en risicotolerantie.

Implementatie-strategieën overzicht

De keuze van implementatie-strategie bepaalt het succes van StUF-migraties. Elke strategie heeft eigen voor- en nadelen:

graph TD
A[StUF Implementation Strategies] --> B[Big Bang]
A --> C[Phased Migration]
A --> D[Parallel Implementation]
A --> E[Pilot-First]
B --> B1[One-time cutover]
B --> B2[High risk, fast result]
B --> B3[Intensive weekend]
B --> B4[All-or-nothing approach]
C --> C1[Gradual rollout]
C --> C2[System-by-system migration]
C --> C3[Lower risk per step]
C --> C4[Longer total timeline]
D --> D1[Run both versions]
D --> D2[Gradual traffic migration]
D --> D3[Safe rollback option]
D --> D4[Higher operational complexity]
E --> E1[Start with low-risk area]
E --> E2[Learn and improve]
E --> E3[Scale successful approach]
E --> E4[Slowest to complete]

Scenario 1: Big Bang Implementation

Geschikt voor:

Kleine organisaties (1-3 kern-systemen)
Hoge samenhang tussen systemen
Beperkte legacy-complexity
Sterke project-management capaciteit
Korte maintenance-windows beschikbaar

Implementatie-planning

Timeline: 6 weken intensieven

3.8 Rol van informatiemodellen

Wed, 04 Mar 2026 00:00:00 +0000

3.8 Rol van informatiemodellen

Heeft een mening over de rol en bruikbaarheid van informatiemodellen in software-ontwikkeling en gegevensuitwisseling.

Informatiemodellen in softwareontwikkeling

Informatiemodellen spelen een centrale rol in moderne softwareontwikkeling, van requirement-analyse tot onderhoud en uitbreiding van systemen.

Model-Driven Development

Voordelen van model-eerst benadering:

Design clarity: Expliciete vastlegging van data-structuren voorkomt misverstanden
Code generation: Automatische generatie van database-schemas, API’s, en data-access code
Consistency: Uniformiteit tussen verschillende systemen-onderdelen
Documentation: Model fungeert als living documentation

Praktijkvoorbeeld:

5.7 JSON Schema's

Wed, 04 Mar 2026 00:00:00 +0000

5.7 JSON Schema’s

Heeft kennis van JSON Schema’s (aanvullend naast XSD).

6.9 Verbetertrajecten initiëren

Wed, 04 Mar 2026 00:00:00 +0000

6.9 Verbetertrajecten initiëren

Kan continue-verbeteringsinitiatieven voor StUF-implementaties opzetten, monitoren en sturen om de kwaliteit en efficiëntie van gegevensuitwisseling structureel te verhogen.

Continue verbetering-framework

StUF-verbetertrajecten vereisen systematische aanpak die technische optimalisatie combineert met proces-verbetering:

mindmap
root((StUF Verbetering))
Technische Optimalisatie
Performance
Message processing
Network efficiency
Database queries
Memory usage
Kwaliteit
Data validation
Error handling
Monitoring
Testing coverage
Modernisatie
Architecture patterns
Cloud-native
API-first design
Automation
Proces Verbetering
Workflows
Development processes
Testing procedures
Deployment automation
Incident handling
Mensen
Training programs
Knowledge sharing
Skill development
Team structuur
Governance
Standards compliance
Change management
Risk management
Performance monitoring
Innovatie
Nieuwe Technologieën
Cloud services
Containers
Microservices
Event-driven architecture
Best Practices
Industry standards
Community learnings
Research insights
Benchmarking
Toekomstoriëntatie
Standards roadmaps
Technology trends
Business evolution
Strategic alignment

Verbetering-identificatie systematiek

1. Performance-monitoring dashboard

class StufPerformanceAnalyzer:

 def __init__(self):
 self.metrics_collector = MetricsCollector()
 self.trend_analyzer = TrendAnalyzer()
 self.bottleneck_detector = BottleneckDetector()

 def generate_improvement_opportunities(self) -> List[ImprovementOpportunity]:
 """Identificeer verbeter-mogelijkheden op basis van metrics"""

 opportunities = []

 # 1. Performance-bottlenecks
 performance_issues = self._analyze_performance_bottlenecks()
 opportunities.extend(performance_issues)

 # 2. Error-pattern analysis 
 error_patterns = self._analyze_error_patterns()
 opportunities.extend(error_patterns)

 # 3. Capacity-planning issues
 capacity_issues = self._analyze_capacity_trends()
 opportunities.extend(capacity_issues)

 # 4. Integration-efficiency
 integration_issues = self._analyze_integration_efficiency()
 opportunities.extend(integration_issues)

 # Prioriteer op basis van impact en effort
 prioritized_opportunities = self._prioritize_opportunities(opportunities)

 return prioritized_opportunities

 def _analyze_performance_bottlenecks(self) -> List[ImprovementOpportunity]:
 """Detecteer performance-bottlenecks in StUF-processing"""

 opportunities = []

 # Message parsing performance
 parsing_metrics = self.metrics_collector.get_parsing_performance()
 if parsing_metrics['avg_parse_time'] > 500: # > 500ms gemiddeld
 opportunities.append(ImprovementOpportunity(
 type='performance',
 area='message_parsing',
 description=f'Message parsing trager dan acceptabel: {parsing_metrics["avg_parse_time"]}ms gemiddeld',
 current_value=parsing_metrics['avg_parse_time'],
 target_value=250, # Target: 250ms
 impact='HIGH',
 effort='MEDIUM',
 solutions=[
 'XML parsing optimalisatie',
 'Streaming parser implementatie',
 'Message caching strategie',
 'Parser performance profiling'
 ]
 ))

 # Database query performance
 db_metrics = self.metrics_collector.get_database_performance()
 slow_queries = [q for q in db_metrics['queries'] if q['avg_duration'] > 1000]
 if slow_queries:
 opportunities.append(ImprovementOpportunity(
 type='performance',
 area='database_queries',
 description=f'{len(slow_queries)} database queries zijn langzaam (>1s)',
 current_value=len(slow_queries),
 target_value=0,
 impact='HIGH',
 effort='MEDIUM',
 solutions=[
 'Query optimalisatie',
 'Index toevoeging/aanpassing',
 'Database partitioning',
 'Query result caching'
 ]
 ))

 # Memory usage patterns
 memory_metrics = self.metrics_collector.get_memory_usage()
 if memory_metrics['memory_growth_trend'] > 0.1: # >10% growth per week
 opportunities.append(ImprovementOpportunity(
 type='performance',
 area='memory_usage',
 description=f'Memory gebruik groeit {memory_metrics["memory_growth_trend"]*100:.1f}% per week',
 current_value=memory_metrics['memory_growth_trend'],
 target_value=0.02, # Target: <2% growth per week
 impact='MEDIUM',
 effort='HIGH',
 solutions=[
 'Memory leak detection',
 'Garbage collection tuning',
 'Object pooling implementatie',
 'Message size optimalisatie'
 ]
 ))

 return opportunities

 def _analyze_error_patterns(self) -> List[ImprovementOpportunity]:
 """Analyseer error-patronen voor verbetering-mogelijkheden"""

 opportunities = []

 # Frequent error types
 error_analysis = self.metrics_collector.get_error_analysis()

 for error_type, stats in error_analysis['frequent_errors'].items():
 if stats['frequency'] > 10 and stats['trend'] == 'INCREASING': # >10/day en stijgend
 opportunities.append(ImprovementOpportunity(
 type='quality',
 area='error_reduction',
 description=f'Frequent error type: {error_type} ({stats["frequency"]}/day, stijgend)',
 current_value=stats['frequency'],
 target_value=max(1, stats['frequency'] * 0.2), # 80% reductie
 impact='MEDIUM',
 effort='MEDIUM',
 solutions=[
 f'Root cause analysis voor {error_type}',
 'Input validation verbetering',
 'Error handling robustheid',
 'Producer system verbetering'
 ]
 ))

 return opportunities

@dataclass
class ImprovementOpportunity:
 type: str # 'performance', 'quality', 'maintainability', 'scalability'
 area: str
 description: str
 current_value: float
 target_value: float
 impact: str # 'LOW', 'MEDIUM', 'HIGH'
 effort: str # 'LOW', 'MEDIUM', 'HIGH'
 solutions: List[str]

 @property
 def priority_score(self) -> float:
 """Bereken prioriteit-score (impact/effort)"""
 impact_values = {'LOW': 1, 'MEDIUM': 2, 'HIGH': 3}
 effort_values = {'LOW': 1, 'MEDIUM': 2, 'HIGH': 3}

 return impact_values[self.impact] / effort_values[self.effort]

2. Stakeholder-feedback systematiek

feedback_collection_framework:
 stakeholder_groups:
 developers:
 collection_method: "Monthly technical surveys"
 key_questions:
 - "Welke StUF-development aspecten kosten meeste tijd?"
 - "Welke tools/libraries missen in huidige stack?"
 - "Waar ervaar je meeste frustratie in StUF-werk?"
 - "Welke verbetering zou grootste impact hebben?"
 feedback_channels: ["survey", "retrospectives", "1-on-1s"]

 operations:
 collection_method: "Bi-weekly operational reviews"
 key_questions:
 - "Welke incidents komen meest voor?"
 - "Waar is monitoring/alerting ontoereikend?"
 - "Welke maintenance-taken zijn meest tijdrovend?"
 - "Welke automation-mogelijkheden zie je?"
 feedback_channels: ["incident-reviews", "operations-meetings", "issue-tracking"]

 business_users:
 collection_method: "Quarterly user experience sessions"
 key_questions:
 - "Welke data-uitwisseling processen lopen niet soepel?"
 - "Waar ervaar je vertragingen in informatieverwerkking?"
 - "Welke functionaliteit ontbreekt voor jouw werk?"
 - "Welke verbetering zou jouw dagelijkse werk helpen?"
 feedback_channels: ["workshops", "user-interviews", "support-tickets"]

Verbetering-projecten opzetten

1. Project-portfolio management

graph TD
A[Improvement Opportunities] --> B[Impact-Effort Analysis]
B --> C[Project Portfolio Formation]
C --> D[Quick Wins<br/>High Impact, Low Effort]
C --> E[Major Projects<br/>High Impact, High Effort]
C --> F[Fill-ins<br/>Low Impact, Low Effort]
C --> G[Questionable<br/>Low Impact, High Effort]
D --> H[Immediate Implementation<br/>Sprint-based work]
E --> I[Dedicated Project Teams<br/>Quarter-based planning]
F --> J[Background Tasks<br/>Slack time utilization]
G --> K[Defer/Reject<br/>Resource focus]
H --> L[Monthly Review Cycle]
I --> L
J --> L
L --> M[Portfolio Adjustment]
M --> N[Continuous Improvement]

Portfolio-planning template:

3.9 Adviseren aan MIM-community

Wed, 04 Mar 2026 00:00:00 +0000

3.9 Adviseren aan MIM-community

Kan adviseren aan de MIM-community rondom verbeteringen en uitbreidingen van het MIM.

De MIM-community

Het Metamodel Informatie Modellering (MIM) wordt beheerd door een actieve community van overheidsorganisaties, leveranciers, en kennisorganisaties. Deze community werkt samen aan de doorontwikkeling van De Nederlandse standaard voor informatiemodellering.

Community-structuur

Formele governance:

Geonovum: Officiële beheerder van de MIM-standaard
Technical Committee: Besluitvorming over standaardwijzigingen
Werkgroepen: Domein-specifieke expertteams
Adviesraden: strategische sturing vanuit verschillende sectoren

Informele netwerken: