BOMOS aanvullende modules: Stelsels

Logius Handreiking
Werkversie

Deze versie:
https://logius-standaarden.github.io/BOMOS-Stelsels/
Laatst gepubliceerde versie:
https://gitdocumentatie.logius.nl/publicatie/bomos/stelsels/
Laatste werkversie:
https://logius-standaarden.github.io/BOMOS-Stelsels/
Redacteurs:
Gül Işik (Logius)
Edwin Wisse (Logius)
Auteur:
Sander Boer (Logius)
Doe mee:
GitHub Logius-standaarden/BOMOS-Stelsels
Dien een melding in
Revisiehistorie
Pull requests

Dit document is ook beschikbaar in dit niet-normatieve formaat: pdf


Samenvatting

BOMOS (Beheer- en OntwikkelModel voor Open Standaarden) is een hulpmiddel van en voor de standaardisatiewereld. Dit deel bevat een aanvullende module voor stelsels. Stelsels vallen buiten scope van het de basis van BOMOS, het Fundament. BOMOS is immers allereerst voor het beheer van standaarden beedoeld. Maar BOMOS kan wel voor stelsels toegepast kan worden omdat de beheerpraktijken van standaarden en stelsels veel overeenkomsten heeft.

Status van dit document

Dit is een werkversie die op elk moment kan worden gewijzigd, verwijderd of vervangen door andere documenten. Het is geen door het TO goedgekeurde consultatieversie.

Documentbeheer

Datum Versie Auteur Opmerkingen
05/04/2022 3.0 Sander Boer Aanvullende modules in eigen document ondergebracht
15/06/2025 3.0 Sander Boer Relatie tussen afsprakenstelsels en GovTech toegevoegd

Colofon

Logius Servicecentrum: Postbus 96810
2509 JE Den Haag
tel. 0900 555 4555 (10 ct p/m)
email servicecentrum@logius.nl

1. Inleiding

BOMOS stelsels maakt deel uit van de BOMOS documentatie. De BOMOS documentatie is onderverdeeld in een aantal delen (zie BOMOS structuur).

1.1 Structuur BOMOS

BOMOS bestaat uit:

De kern van BOMOS is het "Fundament". Dat bestaat uit een basis beschrijving van het Beheer- en Ontwikkelmodel, en een verdere verdieping op basis van literatuur of praktijkervaringen. Het Beheer- en Ontwikkelmodel is in de basis een activiteitendiagram, daarnaast zijn rollen gedefinieerd die relevant zijn bij het beheer- en ontwikkelproces van standaarden.

Daarnaast biedt BOMOS in deel 2 meer verdieping door het delen van met name best practices uit de standaardisatiewereld.

Deel 1 en Deel 2 samen vormen de basis van BOMOS.

Naast deze basis zijn er uitbreidingen voor BOMOS gemaakt door de community, die het toepassen van BOMOS in concrete situaties, soms met een wat andere context, kunnen helpen. We noemen dit de BOMOS Aanvullende Modules, ook wel een Body of Knowledge genoemd, welke dynamisch zullen zijn in de tijd.

Als we het hebben over BOMOS, dan bedoelen we daarmee de basis zoals in Deel 1 en Deel 2 beschreven. De aanvullende modules zijn wel duidelijk met BOMOS verbonden, maar hebben een eigen governance wat kan resulteren in een eigen naam, eigen doelgroep, eigen beheer, etc. In het beheerproces van BOMOS wordt ook beschreven welke eisen er gesteld worden voordat iets opgenomen wordt als BOMOS aanvullende module.

De eerste twee aanvullende modules zijn: - Linked Data & Ontologieën: het specifieke gebruik van Linked Data voor semantische standaarden. - Invulling van BOMOS voor het beheer van afsprakenstelsel: het gebruik van BOMOS in de specifieke situatie rond stelsels.

De aanvullende modules zijn nauw verbonden met BOMOS en hebben tegelijkertijd een eigen governancestructuur. Zo wordt er binnen de context van het bredere BOMOS-kader duidelijk gemaakt dat de genoemde modules hun eigen governancestructuur hebben. Dit biedt transparantie en verduidelijking aan de betrokken partijen en stakeholders, zodat zij begrijpen dat hoewel er een verbinding bestaat met BOMOS, deze modules afzonderlijk worden beheerd en bestuurd.

1.2 Leeswijzer

Bent u vanuit een beleidsmakende of besturende rol alleen op hoofdniveau geïnteresseerd, dan biedt het fundament (deel 1) voldoende achtergrond en context. Bent u zelf actief in standaardisatiecommunities dan kunt u naadloos doorgaan met het lezen van deel 2: De verdieping met best practices, waarin meer achtergrond en praktische tips rond standaardisatie zijn opgenomen.

Wilt u BOMOS gaan toepassen dan is het ook raadzaam om de aanvullende modules te gaan bekijken. Hier kunt u voorbeelden en tools vinden die kunnen helpen bij implementaties van open standaarden. Ook vindt u hier varianten op BOMOS. Deze implementatieprofielen maken BOMOS toepasbaar op meer dan (semantische) standaarden alleen.

2. Invulling van BOMOS voor het beheer van afsprakenstelsels

2.1 Wat zijn afsprakenstelsels?

Het is lastig om een eenduidige definitie te geven van wat een afsprakenstelsel precies is. Het is de Nederlandse vertaling van Trust Framework. Andere benamingen voor een afsprakenstelsel is een vertrouwensraamwerk. In Nederland zijn eHerkenning, Medmij, KIK-V, iDIN voorbeelden van een afsprakenstelsel.

Uit literatuuronderzoek (zie understanding trust frameworks) blijkt dat slechts één paper een definitie bevat, afkomstig van het National Institute of Standards and Technology (NIST):"een juridisch afdwingbare set specificaties, regels en overeenkomsten die een meerzijdig systeem regelen, opgezet voor een gemeenschappelijk doel, ontworpen voor specifieke transacties binnen een gemeenschap van deelnemers, en gebonden aan gemeenschappelijke vereisten."

Een afsprakenstelsel is een samenwerkingsstructuur. Het regelt belangrijke zaken rondom vertrouwen en interoperabiliteit en bevat afspraken over het besturen van deze samenwerking. Een van de belangrijke eigenschappen van een afsprakenstelsel is dat het een oplossing is voor het schalingsvraagstuk. Afsprakenstelsels faciliteren positieve netwerkeffecten waarbij de waarde van het netwerk toeneemt naarmate meer partijen deelnemen.

Een afsprakenstelsel biedt voordelen van marktwerking voor de afnemers van diensten - er is concurrentie op innovatie en prijs. Ook biedt het verbeteringen rond beschikbaarheid doordat afnemers kunnen kiezen uit meerdere aanbieders en ook tegelijkertijd die diensten kunnen afneme

2.2 GovTech als katalysator voor samenwerking

GovTech is een op technologie gebaseerde samenwerking tussen actoren uit de openbare én private sector om de digitale transformatie van de overheidssector te ondersteunen.

GovTech ontstaat uit de erkenning dat de overheid niet de capaciteit en ervaring heeft om zelfstandig in te spelen op technologische ontwikkelingen en innovaties. Het vormt de basis voor initiatieven waarbij bedrijfsleven, overheid en maatschappelijk veld elkaar vinden om gezamenlijk maatschappelijke vraagstukken op te lossen met behulp van technologie. Deze samenwerking begint vaak rommelig (denk aan een hackathon) met de focus op technologie. Dat groeit bij succes door naar pilots om aan te tonen dat technologie toepasbaar en nuttig is.

Het cruciale keerpunt ontstaat wanneer een GovTech-initiatief de stap wil zetten van experiment naar een robuuste dienst die productiewaardig en schaalbaar is. Op dit moment worden dezelfde uitdagingen zichtbaar die afsprakenstelsels addresseren: de noodzaak voor duidelijke afspraken over interoperabiliteit, vertrouwen, veiligheid en integriteit. Dit vereist een andere aanpak die meer te maken heeft met politiek dan met techniek.

2.3 Inhoud van een afsprakenstelsel

"Goede afspraken maken goede vrienden". De kern van een afsprakenstelsel ligt in het organiseren van vertrouwen en interoperabiliteit tussen meerdere partijen om gezamenlijk een doel te realiseren dat te complex of te groot is om individueel aan te pakken.

Een afsprakenstelsel vormt een gestructureerde samenwerkingsovereenkomst die barrières wegneemt en schaalbare samenwerking mogelijk maakt.

Elinor Ostrom beschrijft in het boek Governing the Commons de voorwaarden voor succesvolle samenwerking rond schaarse gemeenschappelijke voorzieningen zoals het beheer van waterputten. Deze principes zijn te herkennen in de samenwerking van succesvolle afsprakenstelsels. Deze zijn (vrij vertaald): - Er zijn duidelijke grenzen op gebied van homogene functionaliteit/middelen en een homogene gebruikersgroep. - Overeenstemming en balans in baten en lasten voor alle betrokkenen. - Iedereen kan bijdragen aan verbeteringen. - Controle (door transparantie) op alle betrokkenen. - Graduele sancties op overtreden afspraken zijn aanwezig en worden uitgevoerd. - Verschillen van inzicht kunnen snel en effectief opgelost worden. - Stelsel (deelnemers) heeft mandaat om zichzelf te organiseren. - Gebruik stelsels van stelsels om de individuele stelsels eenvoudig te houden.

Deze principes staan aan de basis van de afspraken en regels over de onderstaande aspecten die terugkomen als onderdelen binnen een afsprakenstelsel: - Informatie over rechten en plichten van deelnemende partijen: zoals definities, aansprakelijkheid, organen, besturing en taakverdeling. - Financiën: het beheren van een afsprakenstelsel en het organiseren van besturing kost geld: wat zijn de afspraken over wie wat betaalt? - Operatie: wie lost incidenten op? Wordt er gewerkt onder een label of merk? Denk aan communicatie, merkbeheer en afspraken over de operationele processen. - Normenkaders: aan welke eisen moeten de diensten/producten van leveranciers voldoen? - Architectuur en techniek: denk hierbij aan technische standaarden, use-cases en interface beschrijvingen.

Dit componentendiagram is ontwikkeld door en op basis van het onderzoek van L. van der Peet en geeft inzicht in de decompositie van relevante componenten van een afsprakenstelsel.

componenten diagram trust framework
Figuur 1 Componenten diagram afsprakenstelsels

2.4 Hoe is BOMOS als best practice inzetbaar voor het beheer van afsprakenstelsels?

Afsprakenstelsels zonder standaarden bestaan niet.... Standaarden staan aan de basis van het mogelijk maken van interoperabiliteit en samenwerking. Een afsprakenselsel kan je daarom zien als een bundeling van standaarden met daarbij een belangrijke toevoeging: bij een stelsel zijn er ook afspraken gemaakt over het operationaliseren van samenwerking om een product of dienst aan te bieden. Voor een groot deel komt het beheer van een afsprakenstelsel en van een standaard met elkaar overeen en dat maakt BOMOS prima toepasbaar voor deze bredere scope. De BOMOS activiteiten zijn binnen stelsels ook goed herkenbaar en toe te passen met hier en daar een uitzondering of afwijking. Net zoals bij het beheer van een standaard zijn er bij stelsels activiteiten gericht op het organiseren van de besturing, de doorontwikkeling, het beheren van centrale voorzieningen, het helpen bij aansluiten en promotie van gebruik.

Logius heeft samen met de ICTU is een instrument gemaakt om een BOMOS assessment uit te voeren gericht op afsprakenstelsels. Dit assessment is op meerdere manieren in te zetten. Bij het inrichten van een stelsel kan de lezer in vogelvlucht verkennen welke onderdelen belangrijk zijn om als eerste in te richten. Bij een bestaand afsprakenstelsel is het assessment waardevol om met betrokkenen na te gaan welke onderdelen extra aandacht nodig hebben. Deze tool is online beschikbaar, zie BOMOS assessment.

Inmiddels is er praktijkervaring opgedaan met het uitvoeren van deze specifieke BOMOS assessment voor stelsels. BOMOS helpt bij het creëren van een gezamenlijke “taal” en helpt om elkaars rollen en de beleving daarbij beter te begrijpen en dat maakt constructieve discussies mogelijk.

De uitkomst van een assessment helpt om inzicht te geven en het gesprek te voeren over de verbetermogelijkheden rond beheer. Doe je een assessment samen met de stakeholders dan biedt dit gelijk het draagvlak om die veranderingen in gang te zetten. Het BOMOS fundament is goed toepasbaar voor het inrichten van beheer van nieuwe afsprakenstelsels. BOMOS helpt dan om een programma of opdrachtgever een beeld te schetsen welke activiteiten ingeregeld moeten gaan worden en waarom. Dit beeld helpt bij het prioriteren en inplannen van het inregelen van beheeractiviteiten en het maken van de inschatting van de hiervoor benodigde middelen.

2.5 BOMOS toegepast op afsprakenstelsels

BOMOS model
Figuur 2 BOMOS activiteiten

2.5.1 Strategie

2.5.1.1 Governance

Het hebben van een gestructureerde afstemming tussen de verschillende betrokken partijen (‘de stakeholders’) binnen een stelsel is essentieel. Deze afstemming verloopt via de governance van een stelsel. Hiervoor is een beschrijving nodig van de organisatiestructuur, gremia voor besluitvorming en rollen. De organisatiestructuur maakt duidelijk welke gremia bestaan in het kader van de besluitvorming en welk type beslissingen in welk gremium wordt genomen. Ook maakt de structuur duidelijk hoe taken, relaties en communicatie tussen de groepen geborgd is. Daarbij is een onderscheid tussen een sturend orgaan en uitvoering essentieel. Afspraken hoe er besluiten worden genomen, hoe men kan deelnemen in besluitvormende gremia en over de scope van sturing kunnen onderdeel maken van het afsprakenstelsel zelf maar kunnen ook daarbuiten liggen in de vorm van een instellingsbesluit of convenant. De rol van toezichthouder is een extra rol ten opzichte van de rollen binnen standaarden: wat is er georganiseerd om te toetsen of de afspraken daadwerkelijk worden nagekomen en wat zijn de procedures en middelen om in te grijpen indien dit niet het geval is. Het is van belang deze taak onafhankelijk te beleggen om te voorkomen dat de slager zijn eigen vlees keurt. Daarnaast is deze rol belast met de taak om in geval van niet naleving passende maatregelen te nemen.

2.5.1.2 Visie

Het doel van wat een afsprakenstelsel beoogt moet helder en duidelijk zijn. In de kern is de missie van een stelsel het “willen oplossen” van een probleem wat te complex en te groot is om zelfstandig te doen en waarbij de hulp van andere organisaties nodig is. Deze organisaties bundelen de krachten om deze oplossing te realiseren en om hierover afspraken over te maken. Dit uit zich in een positieve businesscase. Deze missie en visie komt terug in de communicatie uitingen van een stelsel en verbindt de partijen die actief binnen een stelsel actief zijn.

2.5.1.3 Financiën

Voor de partijen die een actieve rol willen vervullen binnen een stelsel moet het financieel aantrekkelijk zijn en daar moet een positieve businesscase tegen over staan om een stelsel toekomst te geven. Dat geldt voor private, publiek-private en publieke stelsels. Deze businesscase is ook nodig om te verantwoorden dat een beheerorganisatie moet worden ingericht en voor een langere periode kan worden gefinancierd. De financiering voor de beheerorganisatie kan worden bekostigd door de stakeholders, leden van een stelsel of centraal vanuit de eigenaar. Roadmapping (extra activiteit) Het maken en hebben van een meerjarige roadmap bevat de strategische keuzes en hoe daar in stappen naar toe wordt gewerkt. Het helpt bij de adoptie omdat de stakeholders weten wanneer bepaalde functionaliteit wordt opgeleverd en daarmee aantrekkelijk wordt om gebruik te gaan maken van de stelselproducten of een rol te vervullen binnen het stelsel. Het maken en hebben van een gezamenlijk doel in de vorm van een roadmap zorgt ook voor draagvlak. Het bevat de concrete stappen om de visie te realiseren.

2.5.2 Tactiek

2.5.2.1 Community

Het begrip community is binnen afsprakenstelsel wat minder ingeburgerd maar er zijn wel organisatievormen die op tactisch niveau acteren maar meer in de vorm van een expertgroep of werkgroep. Deze groepen zijn betrokken bij inhoudelijke veranderingen in een afsprakenstelsel en het opstellen van advies over o.a. innovaties en architectuur. De governance van een stelsel geeft opdracht voor het inrichten van een expert– of werkgroep met een daarbij duidelijke opdracht. De samenstelling binnen een werkgroep is afhankelijk van de opdracht. Er zijn werkgroepen die alleen bestaan uit een afvaardiging vanuit de leveranciers maar ook uit een samenstelling met gebruikers en andere stakeholders.

2.5.2.2 Adoptie en Erkenning

Om in het overheidsdomein actief te zijn helpt het om een formele status te hebben van het stelsel, lees een verplichting of een advies om van de stelselproducten gebruik te maken. En een andere belangrijke factor is het ontwikkelen van een kritische massa rondom het gebruik. Het is vaak een kip – ei probleem waarbij partijen wachten wie de eerste stappen zet zelf mee gaan doen als bijvoorbeeld grote uitvoeringsorganisaties de overstap maken. Om dit goed te organiseren is een strategie noodzakelijk met daarbij de steun vanuit de stakeholders. Hierdoor groeit ook de kans dat leveranciers een positieve businesscase kunnen maken en nieuwe deelnemers instappen. De governance is verantwoordelijk voor adoptie.

2.5.2.3 Architectuur

Er zijn verschillende manieren of viewpoints (zie Archimate) om naar de architectuur te kijken: vanuit strategie, business, de applicaties en onderliggende componenten. Deze variatie aan zienswijze heeft vaak te maken met de verschillende rollen die partijen hebben binnen een stelsel. Idealiter zijn die allemaal beschreven, maar de praktijk kan dat per stelsel verschillen hoe dat is uitgewerkt. Het hebben van deze modellen helpt om makkelijker met elkaar te communiceren en de impact en kansen van veranderingen goed in te schatten. Het verlaagt ook de drempel voor nieuwe partijen die deel uit willen maken van een stelsel. Binnen een stelsel speelt interoperabiliteit een belangrijke rol en dat zie je terugkomen in de aandacht voor de architectuur van de technische koppelvlakken tussen de verschillende partijen. Onder architectuur vallen ook de keuzes welke (technische) standaarden binnen een stelsel gebruikt moeten worden door de deelnemers. Het hebben en samen bepalen van architectuurprincipes voor een stelsel (zie NORA) is een waardevol kader om wijzigingsvoorstellen te toetsen.

2.5.2.4 Stelselrisico analyse (extra activiteit)

Het afsprakenstelsel vormt de basis om veilig en betrouwbare gegevensuitwisseling mogelijk te maken tussen verschillende partijen. Daarvoor is het ook van belang om als governance een goed beeld te hebben hoe het gesteld is met dreigingen en risico’s op het stelsel zelf. Wat kan er misgaan, wat kan ik doen om dit te voorkomen en in het geval dat de dreiging realiteit wordt: wat zijn dan de stappen en wie betrek ik hierbij?

2.5.3 Operationeel

2.5.3.1 Wensen & Eisen

Net zoals standaarden ontwikkelt een afsprakenstelsel zich ook door om te voldoen aan de wensen en eisen van gebruikers. Een andere belangrijke kracht voor wijzigingen die structureel bijdragen aan de businesscase, wet- en regelgeving en maatregelen om aan (toekomstige) dreigingen rond veiligheid en betrouwbaarheid te voldoen. Om dit in goed banen te leiden bevat een afsprakenstelsel regels hoe wijzigingen geïnitieerd worden, beschrijving van de besluitvorming en hoe die wijzigingen in het afsprakenstelsel terecht komen en uiteindelijk geïmplementeerd worden door de betrokken partijen. Een belangrijk aspect bij het doorvoeren en implementeren van wijzigingen in een stelsel is het borgen van continuïteit: idealiter voorkom je scenario’s waarbij wijzigingen via een big bang scenario worden uitgerold maar kan dit in een eigen tempo. Dit is te organiseren door een vorm van backward compatibility te faciliteren.

2.5.3.2 Documentatie

Het afsprakenstelsel is vrij beschikbaar en toegankelijk. Hiermee voorkom je dat de buitenwereld met wantrouwen kijkt naar wat er binnen een afsprakenstelsel gebeurt omdat het dan meer lijkt op een kartel. Idealiter zijn de stukken die gebruikt zijn ook publiek toegankelijk. Transparantie helpt bij het realiseren van draagvlak.

2.5.3.3 Operationeel handboek (extra activiteit)

Een afsprakenstelsel bevat voor een belangrijk deel afspraken hoe met elkaar wordt samengewerkt. Dit gaat over onderwerpen hoe je zoals bij wensen & eisen over het wijzigproces maar ook hoe je kan toetreden, hoe verstoringen en incidenten worden gemeld en verholpen, over de service windows van de betrokken partijen en over de rapportage-eisen richting elkaar en de governance.

2.5.4 Implementatieondersteuning

De mate hoe een afsprakenstelsel hier invulling aan geeft is afhankelijk van de taakverdeling tussen de deelnemers binnen een stelsel en de stelselbeheerorganisatie. Het is daarbij logisch dat de partij die een contract afsluit met een leverancier daar ook aanklopt voor ondersteuning bij de implementatie (aansluiten) en het gebruik. Binnen het stelsel zelf heeft de beheerorganisatie een taak om een rol te spelen bij vraagstukken rond de interpretatie van de stelsel specificaties en bijvoorbeeld bij het aansluiten op het netwerk.

2.5.4.1 Validatie & certificatie

Er zijn stelsels die validatie-tooling beschikbaar stellen waarmee deelnemers hun implementatie mee kunnen testen. Het is van groot belang dat de leveranciers betrokken zijn met de realisatie en toetsing van dergelijke tooling om te voorkomen dat pas in een laat stadium (tijdens de realisatie) onvolkomenheden en onduidelijkheden in specificaties boven tafel komen. Rond inspectie en certificatie: dit is normaliter een taak van de partij die de rol van toezichthouder vervult. De toezichthouder kijkt of het afgesproken normenkader goed is geïmplementeerd bij de leverancier. Er zijn afspraken wanneer de leverancier zelf actief de toezichthouder informeert om een toetsing uit te voeren. Denk hierbij aan wijzigingen op processen die raakvlak hebben met het normenkader.

2.5.5 Communicatie

2.5.5.1 Promotie

De voordelen van de product of dienst van een afsprakenstelsel moeten bij zoveel mogelijk publiek bekend worden gemaakt. Het hebben van een gemeenschappelijk merk of label helpt daarbij en zorgt voor de herkenbaarheid van de dienst. Het afsprakenstelsel bevat regels hoe generieke uitingen worden opgesteld, merkbeheer, wat de beheerorganisatie doet en wat de speelruimte van de leveranciers is. De leveranciers zijn verantwoordelijk voor hun eigen marketing en acties om de eigen markt te vergroten maar zijn daarbij gebonden aan het afsprakenstelsel. De beheerorganisatie heeft een rol om de voordelen van het stelsel uit te dragen maar niet van de individuele diensten of producten van de leveranciers die onder dit stelsel vallen.

2.5.5.2 Publicatie

Hieronder valt het hebben van een site die informatie bevat over het afsprakenstelsel, inzet van sociale media en het delen van informatie met specifieke gebruikersgroepen.

2.5.5.3 Klachtenafhandeling

De gebruikers kunnen de behoefte hebben om naast het indienen van de klacht bij de eigen leverancier ook bij een onafhankelijke partij die klacht te melden. Een klachtencommissie kan het geval dat beide partijen er niet uitkomen een bindende uitspraak

3. Lijst met figuren

Logius Handreiking - Werkversie