Dit document beschrijft het Beheermodel van BOMOS.
Status van dit document
Dit is de definitieve versie van dit document. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.
1. Inleiding
1.1 Leeswijzer
Dit document beschrijft hoe Logius, afdeling Standaarden
(Uitvoeringsorganisatie), BOMOS beheert en hoe de bijbehorende
governance is ingericht.
1.2 BOMOS versie 2 naar versie 3
BOMOS staat voor 'Beheer en Ontwikkelmodel Open Standaarden. De
methodiek is ontstaan uit een samenwerking met verschillende partijen
met expertise m.b.t. het open beheren van standaarden. In 2006 heeft de
Werkgroep CMO (Community Model Open Standaarden), een werkgroep
bestaande uit TNO, Bureau Forum Standaardisatie en Logius aan dit
onderwerp gewerkt, dit vormde het startpunt voor de ontwikkeling van
BOMOS versie 1 en 2. De methodiek is sindsdien ondergebracht bij Logius
en is toe aan een nieuwe versie. Daarnaast is er behoefte aan tooling
(op basis van BOMOS) ter ondersteuning van het beheren van stelsels en
standaarden. Logius beheerd stelsels en standaarden met behulp van
BOMOS maar de methodiek zelf wordt momenteel niet actief beheerd. Om de
methodiek conform BOMOS actief te beheren en door te ontwikkelen zijn we
recent gestart met een werkgroep en het schrijven van dit
beheerdocument.
1.3 Nut
Het nut en de werking van de standaard zijn reeds goed beschreven in
BOMOS versie 2.
Met BOMOS worden standaardisatiecommunities ondersteund en geïnspireerd
bij het structureel vormgeven van het beheer en verdere ontwikkelingen
van standaarden.
1.3.1 Werking
Het doel is en blijft een duurzame standaard die een bijdrage levert in
interoperabiliteit. Duurzaam kan alleen als het ontwikkel- en
beheerproces op een kwalitatief hoogstaand niveau is ingericht. Dit
document levert een bijdrage om de ontwikkeling en beheer van de
standaard op een hoger plan te krijgen en daarmee duurzame standaarden
en Stelsels te realiseren. Uiteraard is een duurzame standaard een open
standaard die duurzaam beheerd wordt.
1.3.2 Status
De actuele versie van BOMOS 2.0 is op te vinden op xxx door xxx
vastgesteld.
Concept versie BOMOS 3.0 moet nog worden vastgesteld.
Logius richt de beheerorganisatie in conform het Beheer en
OntwikkelModel voor Open Standaarden (BOMOS). Ook dit beheer document is
op basis van BOMOS ingericht.
De rol van beheerder en adviseur wordt steeds belangrijker in de
digitale samenleving. Aan de hand van de ervaring van verschillende
beheerpartijen, willen we het beheer van de afdeling stelsels en
standaarden nog effectiever kunnen inrichten en daarmee het
draagvlak en de adoptie van de standaarden verhogen. Nog een
belangrijke redenen is om interoperabiliteit na te streven om zo
effectiviteit en efficiency in het samenwerken te realiseren met
bijvoorbeeld beheerorganisatie, toeleveranciers en klanten in de
keten. Drie concrete zaken voor de doorontwikkeling van BOMOS: Een
nieuwe versie uitbrengen van BOMOS met nieuwe inzichten en een
bredere scope dan de huidige versie (de methode wordt in de nieuwe
versie bijvoorbeeld ook toegepast op stelsels)
We willen BOMOS de basis maken van ons standaardenbeheer.
Bijvoorbeeld de beheerplannen en governance van standaarden
beschrijven volgens BOMOS, alsmede offertes voor eventuele nieuwe
standaarden om zo meer uniformiteit aan te brengen in het beheer van
de standaarden van onze afdeling. Dit verhoogd de kwaliteit van onze
processen en documenten en maakt dat we als team sneller en
flexibeler kunnen reageren op verzoeken om nieuwe standaarden in
beheer te nemen.
We willen onze kennis delen met andere organisaties, die ook
standaarden of stelsels beheren, en met hen kennis uitwisselen. Dit
is gunstig bij het blijven actualiseren van de BOMOS.
2.2 Governance
BOMOS is het Beheer- en OntwikkelModel voor Open Standaarden. Het is een
instrument dat helpt bij de inrichting van het beheer van open
standaarden. Dit maakt BOMOS als het ware een standaard voor het beheren
van standaarden. BOMOS bestaat uit een bundeling van best practices en
voorbeelden van goed standaardenbeheer. Het is ontwikkeld door de
BOMOS-community en voor iedereen vrij te gebruiken.
Bij het beheer van een open standaard hoort een open governance en een
open procedure voor belanghebbenden om te kunnen participeren in het
beheer. Logius, afdeling Standaarden neemt hierin de rol van
onafhankelijke, duurzame beheerpartij en facilitator.
Logius gaat uit van de governance van de Generieke Digitale Infrastructuur (GDI).
De GDI geeft richting aan het Meerjarenprogramma Infrastructuur Digitale Overheid (MIDO).
Voor MIDO is een governance opgesteld waarin de stakeholders van Logius richting geven aan de ontwikkelingen bij Logius.
Standaardenbeheer sluit aan op deze governance. Bij het beheer van BOMOS worden verschillende gremia onderscheiden die
gezamenlijkinvulling geven aan de governance op de standaard:
Uitvoeringsorganisatie (Uitvoering Groep - UG) Operationeel
Het is een Operationeel Overleg met periodieke bijeenkomsten (2 x per
maand) waarbij de vragen en doorontwikkel wensen m.b.t. BOMOS worden
doorgenomen, geprioriteerd en worden uitgewerkt. Daarnaast wordt door de
leden de releaseplanning en de roadmap opgesteld en voorgelegd aan het
AG.
Adviesorgaan en Klankbordgroep BOMOS (Advies Groep - AG) Tactisch
Het is een Technisch Overleg met periodieke bijeenkomsten (1 x per
kwartaal) waarbij de vragen en doorontwikkel wensen m.b.t. BOMOS worden
doorgenomen, geprioriteerd, uitgewerkt en vastgelegd. Dit gremium is
verantwoordelijk voor het vaststellen van het van beheermodel van de standaard, de externe publicaties, de doorontwikkel-roadmap en het
vaststellen van releases van de standaard, en dient als het voorportaal van het strategisch/besluitvormende gremium.
Directie Digitale Samenleving (Bestuur groep - BG) Strategisch
Dit is het hoogst ambtelijke gremium dat besluit over major releases van
de standaard. Major releases die grotere financiele impact hebben gaan via de BG.
Het BG is momenteel nog niet actief m.b.t. BOMOS waardoor de UG bij wijzigingen aan de
standaard, de nieuwe versie eerst voorlegt aan het AG voor het borgen van een
zo breed mogelijke afstemming met verschillende belanghebbenden.
N.B. De definitieve invulling van de strategische laag
wordt in 2023 duidelijk.
Dit is het meest operationele gremium waarin iedere
belangstellende/belanghebbende vragen kan stellen, advies kan geven en
suggesties kan doen voor de doorontwikkeling van BOMOS. Deelname
aan de Community is vrij voor eenieder die een belang heeft bij de
standaard (overheid, wetenschap en markt ). Dergelijke vragen en
suggesties worden door Logius verzameld en voorgelegd aan het UG en AO.
2.2.1 Governancestructuur en organisatiestructuur
BOMOS sluit aan op de MIDO governance op strategisch niveau. Voor de governance van BOMOS zelf zijn meer governance lagen nodig, met name voor tactisch en operationeel niveau. BOMOS beheer omvat de volgende gremia:
Figuur 4
images/image5.png "BOMOS Organisatiestructuur")
Bestuur groep:
OBDO/MIDO (programmeringstafel Infrastructuur)
Logius afdeling Standaarden
Logius afdeling Portfolio
Bureau Forum Standaardisatie
Deelnemers Adviesorgaan/klankboordgroep:
Kadaster
Geonovum
Directie Digitale Samenleving
KOOP
TNO
Bureau Forum Standaardisatie
Informatie Huis Water
RIONED
Logius afdeling Stelsels
Logius afdeling Standaarden
Uitvoeringsgroep:
Logius afdeling Standaarden
Logius afdeling Stelsels
De BOMOS Community:
Is geen vast gremium, dit kunnen verschillende
beheersorganisaties zijn die deel willen nemen aan de BOMOS Community.
Alle beheer organisaties mogen hierin mee participeren.
2.2.2 Besluitvorming
Het huishoudelijk regelement en de besluitvormingsprocessen van de governance
zijn beschreven. In deze beschrijving is duidelijk welk gremium over
welke onderwerpen gaat. Voor iedereen moet helder zijn op welke manier,
binnen welk tijdskader en door wie beslissingen worden genomen. Dit
geldt zowel voor de meer strategische besluiten als voor de operationele
afstemming. Voor elk onderdeel van de governance moet worden beschreven
hoe de besluitvorming is ingericht. Daarbij is alleen meerderheid of
consensus besluitvorming toegestaan. Waarbij aangegeven kan worden of er
meerdere stemmingsronden mogelijk zijn.
Het Logius adviesorgaan bestaat uit vertegenwoordigers van publieke
organisaties, bestaande uit twee standaardisatie specialisten en een
aantal adviseurs. De leden werken in verschillende beheerorganisaties
zoals hierboven omschreven. Het adviesorgaan adviseert het bestuur over de inhoud en prioriteiten voor
het basisprogramma en het beheer van BOMOS. Voor het basisprogramma en het beheer van BOMOS, treedt het adviesorgaan BOMOS AG op
als stuurgroep. Het Adviesorgaan AG beoordeelt en beslist over wijzigingsvoorstellen en stelt een nieuwe (versie) van
BOMOS vast die bij Logius is in beheer is. Het adviesorgaan is ook
aanspreekpunt voor klachten over het beheer van BOMOS door Logius. In de werkgroepen wordt inhoudelijk en praktijkgerichte kennis uitgewisseld,
de samenwerking met andere standaardisatieorganisaties is een belangrijk onderdeel voor de doorontwikkeling en beheer van BOMOS.
2.2.3 Sturing strategisch
Er is transparante besturing op strategisch niveau aanwezig die past bij
de ambities van de standaard.
Het operationeel beheer van BOMOS wordt uitgevoerd door de
beheerorganisatie Logius. Er is een BOMOS community verdeeld in drie
lagen met bijbehorende beraden waarin afvaardigingen van deelnemers en
dienstverleners van de beheerorganisaties zitting hebben:
Strategisch niveau - OBDO/MIDO (programmeringstafel Infrastructuur), Het bureau Forum Standaardisatie en het Adviesorgaan BOMOS.
Het Adviesorgaan BOMOS heeft ook een formele rol op strategisch niveau
en is aanwezig om het bestuur kennis inhoudelijk te ondersteunen.
Tactisch niveau - Porfoliomanager Logius (programmeringstafel Infrastructuur), Het Bureau
Forum Standaardisatie en het Adviesorgaan. Het Adviesorgaan BOMOS
heeft ook een formele rol op strategisch niveau en is aanwezig om
het bestuur kennis inhoudelijk te ondersteunen.
Operationeel niveau- Adviesorgaan BOMOS, Uitvoeringsorganisatie
Afdeling Standaarden, Adviesorgaan/klankbord BOMOS en BOMOS
Community welke bestaan uit deelnemers van de beheersorganisaties.
2.2.4 Stakeholders-betrokkenheid
Het is duidelijk hoe stakeholders betrokken worden en hoe ze mee kunnen
participeren en wat hun rol daarbij is. Relevante typen stakeholders
moeten een plek kunnen krijgen ergens in de gekozen structuur van het
stelsel, en niet principieel worden buitengesloten. Dat wil niet zeggen
dat elk type stakeholder per definitie dezelfde rechten en plichten
heeft. Zorg daarnaast ervoor dat binnen die groepen vooral organisaties
aangesloten zijn die zich committeren aan de doelstellingen van de
standaard.
Betrokkenheid van de Community bij de verdere ontwikkeling van de
standaard is voor het gebruik en de draagvlak ervan van groot belang.
Voor de standaard geldt dat geen onderscheid wordt gemaakt tussen
publieke en private organisaties en bijvoorbeeld kennisinstellingen. Zij
vormen samen de community. Aan de inspraak in het wijzigingsproces zijn
voor hen geen kosten verbonden. Logius informeert en betrekt de
community via de website en de verschillende nieuwsbrieven. Uit de
community worden de werkgroepen gevormd op het moment dat dit benodigd
is. De vergaderdata en verslagen van deze werkgroepen zijn beschikbaar
voor een ieder via
BOMOS Fundament
en BOMOS Verdieping.
Inschrijven voor bijeenkomsten is mogelijk via xxxxx (via toekomstige
weblink)
2.2.5 Belangenorganisaties-betrokkenheid
Betrokkenheid van belangenorganisaties is van cruciaal belang vanwege het feit dat ze vaak
optimaal hun achterban kunnen bereiken en vertegenwoordigen. Alle relevante belangenorganisaties
moeten dan ook betrokken zijn, en waar mogelijk moeten partnerschappen worden gesloten op het gebied van communicatie
De afdeling Standaarden van Logius werkt samen met andere
beheerorganisaties, dit kunnen verschillende type beheerorganisaties
zijn, hierin wordt geen onderscheid gemaakt. Een brede samenwerking en
kennisgebied is in het belang van de standaard maar ook in het belang
van de beheerorganisatie zelf. Daarom zorgt de Uitvoeringsorganisatie
(afdeling Standaarden) en het Adviesorgaan BOMOS ervoor dat
belanghebbende beheerorganisaties worden betrokken bij verschillende
activiteiten en overlegvormen. De activiteiten of overleggen kunnen
workshops zijn, werkgroep overleggen voor wijzigingen of
klankboardgroepen voor het uitwisselen van kennis.
2.2.6 Opdracht werkgroepen
Zowel de opdracht van de werkgroep als de wijze waarop over de
resultaten en uitdagingen gerapporteerd wordt zijn beschreven.
Nieuwe ideeën of wijzigingsverzoeken komen binnen bij de
Uitvoeringsorganisatie (afdeling Standaarden) van Logius via
BOMOS Fundament
en BOMOS Verdieping,
of via contacten in het netwerk van de medewerkers van de afdeling
Standaarden of Stelsels. Zodra een nieuw initiatief zich aandient, in de
vorm van een opdracht, zorgt de afdeling Standaarden ervoor dat het
adviesorgaan hiervan op de hoogte wordt gesteld en er een werkgroep
wordt opgezet.
2.3 Structureel financieel model
Jaarlijks wordt bepaald welk deel van de basisfinanciering besteed wordt
aan het standaardisatiewerk en daarmee het beheer van de standaarden.
Het beheer van BOMOS standaard wordt gefinancieerd door het ministerie van BZK
in het kader van de financiering van Logius dienstverlening.
Deelname aan de community kent geen drempels of restricties. De leden
van de community werken in verschillende beheerorganisaties en kunnen
alle informatie m.b.t. de standaard en het beheer daarvan inzien via de
website en issues of RFC's melden. Het Logius adviesorgaan behandeld
deze issues of RFC's. In de community en werkgroepen wordt inhoudelijk
en praktijkgerichte kennis uitgewisseld, de samenwerking met andere
standaardisatieorganisaties is een belangrijk onderdeel voor de
doorontwikkeling en beheer van BOMOS.
3.2 Architectuur
De belangrijkste toepassing van BOMOS is als hulpmiddel voor de verdere
ontwikkeling van beheerorganisaties. De standaard is een op zichzelf
staande open standaard en geen onderdeel van een bovenliggende standaard
of stelsel. Er is dus geen afhankelijkheid met andere beheerorganisaties
van stelsels of standaarden. De samenwerking met andere
standaardisatieorganisaties is wel een belangrijk onderdeel voor de
doorontwikkeling en beheer van BOMOS.
3.3 Jaarplan/Ontwikkelagenda
Afgeleid van de doelstellingen is voor de standaard een ontwikkelagenda
opgesteld waarmee invulling wordt gegeven aan de geformuleerde visie.
Uit het overzicht hieronder kun je opmaken welke ontwikkeling op welk
moment in de tijd gerealiseerd gaat worden.
Gremium
Accent
Rol participant
Ondersteuning door beheerder (Logius)
BOMOS Community (omvang onbeperkt Operationeel 2x Per jaar)
Inhoud – delen
Samen met alle leden van de community: 1. Volgen van ontwikkelingen. 2. Leveren van input voor de doorontwikkeling van de standaard.
1. Informatie m.b.t. specificaties en beheer open delen met community. 2. Deelnemen aan BOMOS klankbordgroep 3. Organiseren bijeenkomsten.
BOMOS Klankbordgroep (Tactisch 4x per jaar)
Inhoud – afstemmen –adviseren en beluit
Samen met andere experts van de beheer organisatie: 1. Inhoudelijk ontwikkelen van standaard onderdelen en bijbehorende documentatie. 2. Voorbereiden van de release-planning. 3. Prioriteiten stellen voor de ontwikkeling, roadmap van nieuwe releases van de standaarden. 4. Goedkeuring van aanpassingen op de standaard. 5. Vaststellen externe publicaties over het standaardenbeleid en releases. 6. Vaststellen beheermodel van de standaard.
1. Informatie m.b.t. specificaties en beheer open delen met community. 2. Analyseren, ontwerpen en uitwerken van specificaties. 3. Volgen en beïnvloeden van standaarden of modules 4. Organiseren bijeenkomsten. 5. Beschikbaar stellen specificaties en publicaties
Directie Digitale Samenleving (Strategisch besluitvormend, 2x per jaar)
Bestuurlijk besluit
Samen met andere bestuurders: 1. Vaststellen budget van BOMOS. 2. Vaststellen beheermodel van de standaard.
1.Begeleiding van de Adviesraad
3.4 Pilots
Een pilot is onderdeel van de adoptiestrategie om de verschillende
stakeholders te overtuigen van de meerwaarde van de standaard. Dit doen
we doormiddel van het aanbieden van een assessment. Hiervoor is tooling
ingericht en beschikbaar gesteld op de Logius website. Met deze tool kun
je d.m.v. het invullen van een vragenlijst inzicht krijgen in de mate
van volwassenheid van het beheer van een standard of stelsel. De
resultaten kunnen positief bijdragen aan het draagvlak van een standaard
of stelsel en tevens bijdragen aan verbetering van de kwaliteit.
3.5 Adoptiestrategie
Het gebruik van BOMOS is niet vanzelfsprekend. De toepassing en het
beheer ervan in praktijk brengen is ons uiteindelijke doel. De community
en werkgroepen zijn hierbij van wezenlijk belang. Voor de adoptie en
erkenning van de standaard door het werkveld, heeft Logius, de standaard
ook aangeboden ter publicatie aan de beheersorganisatie en aan het Forum
Standaardisatie. Zij adviseren ook in het gebruik van de standaarden. In
samenwerking met de beheerorganisaties welke deelnemen aan de
werkgroepen en aan de community streven wij naar adoptie en erkenning.
3.6 Rechtenbeleid
De Standaard zelf en dit beheermodel vallen onder de Creative Commons
licentie (Creative Commons Attribution 4.0 License) Dit houdt in dat het
is toegestaan om deze documenten te gebruiken, verder te verspreiden en
aan te passen. Dit werk en de specificaties van de standaard worden
royaltee-free ter beschikking gesteld. Organisaties en personen die
bijdragen aan de standaard dienen dit onder dezelfde voorwaarden te doen
als bij het originele werk. Door bij te dragen aan de standaard
verklaren zij hiermee in te stemmen.
3.7 Kwaliteitsbeleid en benchmarking
Het beheer van de standaard wordt volledig open ingevuld. Dit borgt dat
zoveel mogelijk belangstellenden en belanghebbenden betrokken zijn bij
wijzigingen en besluitvorming.
Uitbreidingen en aanpassingen in de standaard komen tot stand door
participatie van de verschillende belanghebbenden. Belanghebbenden
kunnen op vier manieren participeren: als lid van de BOMOS Community
en/of de Advies Groep en/of als lid van de Bestuur groep.
4.2 Wensen en Eisen
RFC's kunnen binnen komen via verschillende kanalen rechtstreeks bij
Logius, tijdens overleggen, via de website of mail.
Vanuit verschillende overleggen:
BOMOS Community - Operationeel
Uitvoeringsorganisatie (Uitvoering Groep - UG) Operationeel
Adviesorgaan BOMOS (Advies Groep - AG) Tactisch
Directie Digitale Samenleving (Bestuur groep - BG) Strategisch
RFC's worden als issue's in de repository van het kennisplatform BOMOS
op Github:BOMOS Fundament
of BOMOS Verdieping
geregistreerd als deze vanuit de BOMOS Community of Adviesorgaan
binnenkomen. Komt het rechtstreeks vanuit Logius zelf binnen dan worden
deze in Confluence of Jira geregistreerd. Om te voorkomen dat er
verschillende lijsten met issues en verzoeken ontstaan, is afgesproken
dat ieder issue en verzoek als eerste wordt beoordeeld door een lid van
de Uitvoeringsorganisatie en BOMOS adviesorgaan zorgt voor het overzicht
van de stromen met RFC's.
Dit houdt concreet in dat RFC's die rechtstreeks bij Logius afdeling
standaarden worden neergelegd, door een lid van de
Uitvoeringsorganisatie en het BOMOS adviesorgaan wordt opgepakt en
doorgespeeld aan de BOMOS werkgroep zodat daar de eerste
beoordeling kan plaatsvinden.
4.3 Uitvoering en ontwikkeling (Wijzigingsproces)
De procedure van RCF naar daadwerkelijke wijziging ziet er als volgt
uit:
Issues die in behandeling worden genomen worden als RFC gelabeld
RFC's worden besproken en uitgewerkt door de Uitvoeringsorganisatie
Logius afdeling Standaarden (Uitvoering Groep - UG)
RFC's worden vastgesteld in het Adviesorgaan BOMOS (Advies Groep -
AG) Tactisch
RFC worden na vaststelling door de Directie Digitale Samenleving
(Bestuur groep - BG) Strategisch geconsulteerd en na vaststelling
volgt publicatie van de nieuwe versie van standaard
4.4 Status van de standaard
Logius, afdeling standaarden onderscheidt twee statussen die BOMOS kan
hebben:
Afkorting
Status van de standaard
Beschrijving van de status
IO
In Ontwikkeling
Een nieuwe release van de standaard is "In Ontwikkeling" wanneer er met medeweten en medewerking van participanten (BOMOS Community en klankbordgroep) aan gewerkt wordt en wanneer dit onderdeel of deze release nog niet voor de buitenwereld is gepubliceerd.
IG
In Gebruik
Als een nieuwe release van de standaard gereed is, en is bestendigd door de Directie Digitale Samenleving, stelt de BOMOS klankbordgroep de status 'In Gebruik' vast. Hierna wordt de nieuwe release gepubliceerd zodat alle gebruikers hiervan kunnen profiteren.
4.5 Documentatie
Alle documenten m.b.t. de standaard en het beheer van de standaard
worden openbaar en zonder drempels voor gebruik, gepubliceerd op
logius.nl, Github en Confluence pagina's. Logius publiceert tenminste
de volgende documenten:
Dit Beheer-beheermodel
De vergaderstukken van het Technisch overleg en overige besluitvormende gremia.
De specificaties van de standaard
De voorlopige specificaties van de nieuwe versie van de standaard.
Logius biedt momenteel geen opleiding aan, maar borgt dat de informatie
m.b.t. de standaard altijd, zonder drempels, toegankelijk is via de
Logius website of via Github, zie hiervoor 4.5 Documentatie. Bovendien
kunnen geïnteresseerden via verschillende kanalen contact opnemen met
Logius in geval van vragen of opmerkingen. Zie hiervoor 5.2 Helpdesk.
Aanvullend organiseert Logius afdeling Stelsels een e-learning waarin
handreikingen worden gegeven over het verschil tussen standaarden en
stelsels en hoe het beheer op basis van BOMOS ingericht kan worden.
Verder worden er regelmatig overleggen gepland en streven naar een
jaarlijkse seminar m.b.t. BOMOS.
5.2 Helpdesk
Logius biedt ondersteuning en advies via verschillende kanalen:
Per post: Logius, Postbus 96810; 2509 JE Den Haag, (t.a.v. Standaarden).
5.3 Validatie & Certificatie
Met BOMOS worden standaardisatiecommunities ondersteund en geïnspireerd
bij het structureel vormgeven van het beheer en verdere ontwikkelingen
van standaarden. BOMOS is niet verplicht en is ook geen
conformiteitsbeoordeling.
Logius is promotor van de standaard. Zowel intern voor de toepassing van
de standaard in Logius voorzieningen als extern, door andere partijen te
informeren en adviseren over de mogelijkheden van de standaard. BOMOS
wordt via verschillende kanalen gepromoot. Ten eerste via de Logius
website en het Kennisplatform BOMOS. Naast communicatie op de website en
op het kennisplatform, organiseert Logius als uitvoeringsorganisatie
vrij toegankelijke bijeenkomsten voor de community, werkgroep en
adviesorgaan. Daarnaast promoot ook Forum Standaardisatie actief het
gebruik van BOMOS.
6.2 Publicatie
Als een nieuwe versie van BOMOS de status "In Gebruik" heeft, worden
verschillende zaken gepubliceerd. Logius publiceert altijd de volledige
specificatie van de standaard op een deel van de Logius website.
Aanvullend publiceert Logius alle genoemde documentatie.
6.3 Klachtenafhandeling
Klachten over de opzet of de uitvoering van het beheerproces kunnen
ingediend worden bij Logius. Dit kan in principe via alle beschikbare
kanalen, zie kanalen bij Helpdesk. De indiener van de klacht krijgt
zo spoedig mogelijk en altijd terugkoppeling over de voortgang van en
beslissing over zijn klacht. Het adviesorgaan BOMOS is aanspreekpunt
voor klachten over het beheer van BOMOS door Logius.
7. Bijlage: Gebruik ReSpec
Voor publicatie van de standaarden die bij Logius en beheer zijn wordt
gebruik gemaakt van ReSpec. ReSpec is een applicatie om technische
documentatie te maken die publiceerbaar is op het internet en gemakkelijk
kan worden geïndexeerd door zoekmachines om de documentatie vindbaar
te maken. Het is ontwikkeld ten behoeve van de documentatie van W3C
standaarden. Door gebruik te maken van ReSpec publiceren we documentatie
overeenkomstig een (de facto) W3C standaard.
ReSpec is een Javascript applicatie. Input voor ReSpec bestaat uit
teksten in HTML of Markdown, zie [RFC7763].
ReSpec combineert een serie input files tot één documentatiedocument
in HTML met een duidelijke inhoudsopgave en kruisverwijzingen naar de
verschillende secties en figuren.
ReSpec is ontwikkeld door een werkgroep van W3C en wordt actief
doorontwikkeld.
7.1 Logius profiel
Logius heeft een eigen profiel gemaakt op ReSpec om Logius
organisatiespecifieke zaken, zoals layout, te ondersteunen.
Wijzigingen in de W3C versie worden regelmatig doorgevoerd
in de Logius versie.
De Logius ReSpec versie is zo algemeen mogelijk gemaakt zodat
deze door andere overheden in Nederland eenvoudig toegepast kan
worden. In de Logius versie gebruiken we zoveel mogelijk input
in Markdown formaat.
7.2 Literatuurverwijzingen
ReSpec maakt gebruik van de online Specref
database van Literatuurverwijzingen. Deze database bevat referenties
naar, onder andere, referenties voor de W3C documentatie.
Voor Nederlandse documenten die niet in Specref staan maken we gebruik
van een standaard literatuurlijst die voor alle documenten gebruikt
kan worden en die apart beheerd wordt. Het beheer is onder meer nodig
om links naar online documentatie bij te houden.
GitHub biedt functionaliteit om documenten te publiceren vanuit een
repository. Logius gebruikt deze functionaliteit om het met
ReSpec gegenereerde document te publiceren
als HTML-document en een PDF-document. Deze documenten worden automatisch
gekopieerd naar een publicatiewebsite onder beheer van Logius.
8.2 Wijzigingsvoorstellen
Het proces zoals beschreven onder
operationeel beheer, wensen en eisen
wordt voor de Logius standaarden geïmplementeerd door gebruik te maken
van GitHub issues. Een issue kan binnen GitHub ingediend worden
door iedere (GitHub)gebruiker en wordt bij ontwikkeling van code
gebruikt om functionele wensen of gevonden bugs in te dienen zodat
deze door ontwikkelaars opgepakt kunnen worden. Een issue kan
online besproken worden en uiteindelijk gesloten worden wanneer
deze verwerkt is.
8.2.1 Branches
Binnen het standaardenbeheer bij Logius maken we gebruik van verschillende
branches. De main branch bevat de laatste formeel geaccepteerde versie
van een document. De develop branch bevat een werkversie met daarin alle
wijzigingen die in een volgende geaccepteerde versie opgenomen moeten
worden.
Aanpassingen in de documentatie die voor een specifiek wijzigingsvoorstel
gemaakt worden worden in een eigen branch verwerkt. Deze branch wordt gesplitst vanaf de develop branch en wordt nadat het wijzigingsverzoek aangenomen
is teruggebracht naar de develop branch. Voorbeeld: een wijzigingsverzoek
voor het aanpassen van de architectuurbeschrijving zal in een branche nieuwe architectuur worden verwerkt. Deze wordt gesplitst vanaf, en
teruggebracht naar, de develop branch. Door wijzigingen in een eigenaarbranch op te nemen zijn alle wijzigingen op de documentatie inzichtelijk per wijzigingsvoorstel.
De develop branch wordt dus niet gebruikt om wijzigingen op het document
te maken maar dient als verzamelbranch voor de verschillende wijzigingen
die in een volgende release moeten komen.
8.2.2 Labels
Om GitHub issues te classificeren en te agenderen voor het juiste overleg
maken we gebruik van een aantal standaard labels. We labelen binnenkomende
issues als
Type Alle soorten issues kunnen binnenkomen. Met Type sorteren we
de issues in vragen, correcties en wijzigingen.
Correctie
Documentatie
Vraag
Wijziging
Scope Vooral relevant voor wijzigingsvoorstellen. Hiermee wordt
aangegeven of het een kleine of grote wijziging betreft. Dit heeft
betrekking op de impact van een wijziging en daarmee op de
versienummering.
Klein
Groot
Overleg Het label Overleg heeft alleen betrekking op wijzigingsvoorstellen.
Wanneer deze labels gebruikt worden wordt het voorstel geagendeerd voor het betreffende overleg.
TO-DK
TO-Auth
Gegevensuitwisseling
Toegang
Interactie
Infrastructuur
Status
In onderzoek
In bewerking
Uitwerking door derden
In review
Klaar voor review
Gereed
Afgewezen
8.3 Patches
TODO: beschrijving patching operationeel
8.4 Automatisering en scripts
GitHub ondersteunt automatisering van taken door scripts. Standaard
is de publicatie via github pages. Binnen de Logius standaarden maken
we gebruik van scripts om documenten te publiceren, links te checken en om een paar eenvoudige
tests op digitoegankelijkheidseisen uit te voeren.
9. Bijlage: versie-nummering Logius standaarden
Deze bijlage beschrijft de versioneringsmethodiek ofwel de standaard manier om om te gaan met versienummers van de standaard. De versioneringsmethodiek is gelijk voor alle 'gepubliceerde standaarden' die onder beheer zijn van Logius (afdeling standaarden) en is gebaseerd op Semver. Semver staat voor Semantisch Versioneren en we gebruiken versie 2.0.0 van de standaard zoals gepubliceerd op specificatie van Semantisch Versioneren (SEMVER).
Dat wil zeggen we kennen een bepaalde betekenis toe aan Major,Minor en Patch wijzigingen voor de standaarden zodanig dat de versienummers informatief zijn voor het type wijziging. Aandachtpunt hierbij is dat semantische versionering voor standaarden anders werkt dan semantische versionering voor software. De versienummers voor standaarden drukken uit of een (implementatie) van een oude versie van de standaard voldoet aan de regels van de nieuwe standaard (en dus compliant is aan de nieuwe versie) of niet.
Het voordeel van deze manier van versioneren is dat het versienummer signaleert of een implementatie van een bepaalde versie van de standaard voldoet aan een andere (nieuwe) versie van de standaard of dat er sprake is van nieuwe / gewijzigde regels waar aktie op moet worden ondernomen om compliant te zijn aan deze versie.
De beschreven methodiek is van toepassing op de standaarden die Logius in beheer heeft. In de tekst worden Digikoppeling standaarden als voorbeeld aangehaald maar semantische versienummering is ook op de andere standaarden van toepassing.
9.1 Versioneringsmethodiek
Per document wordt met [documentnaam] X.Y.Z de versie aangegeven.
Met X.Y.Z wordt gerefereerd aan major (X) en minor (Y) releases en (Z) patches,
dit wordt hieronder toegelicht.
MAJOR wordt verhoogd als de nieuwe versie van de standaard zodanig wijzigt dat uitwerkingen (implementaties) volgens de vorige versie van de standaard niet meer voldoen aan de normen/eisen van de nieuwe versie van de standaard.
MINOR wordt verhoogd bij wijzigingen waarbij uitwerkingen (implementaties) volgens de vorige versie van de standaard ook voldoen aan de normen/eisen van de nieuwe versie van de standaard.
PATCH wordt verhoogd bij correcties.
9.1.1 Patch Releases
In een patchrelease worden wijzigingen doorgevoerd die de technische
specificatie niet raken. Dit kunnen tekstuele wijzigingen zijn of
inhoudelijke indelingen van de documenten. De wijzigingen worden
vastgelegd in release notes. Een patch releases wordt door de beheerder
op eigen initiatief of op aanwijzingen van gebruikers doorgevoerd en gepubliceerd.
Een patchrelease wordt aan het Technisch Overleg ter kennisgeving medegedeeld.
Een nieuwe patchrelease vervangt een eerdere versie in zijn geheel.
9.1.2 Minor releases
Een minor release geeft aan dat de nieuwe versie van de standaard zodanig is gewijzigd dat een implementatie van de voorgaande versie van de standaard voldoet aan de regels van de nieuwe versie. In een minor release kunnen wijzigingen doorgevoerd worden die de technische
specificatie van een koppelvlak raken. Dat kunnen fouten zijn in de specificatie
zijn of bv het verlichten van een restrictie. In de SEMVER aanpak voor software zijn
minor releases technisch backwards compatible. Voor de uitwisselingsstandaarden zoals
Digikoppeling is backwards compatibility lastiger te bepalen omdat uiteindelijk
twee partijen met elkaar moeten meebewegen.
Minor Releases kunnen dus mogelijk technisch backwards incompatible zijn.
Voor Minor Releases wordt een uitgebreid vaststellingsprocedure gevolgd
(conform het beheermodel van de standaard) en er kan in overleg met de deelnemers
van het Technisch Overleg tot een migratiepad worden besloten. Dit migratiepad
wordt in de release meegenomen.
9.1.3 Major Releases
Een major release geeft aan dat de nieuwe versie van de standaard zodanig is gewijzigd dat een implementatie van de voorgaande versie van de standaard niet voldoet aan de regels van de nieuwe versie.
Bijvoorbeeld de overgang naar nieuwe externe
(meestal internationale) standaarden binnen een bestaand profiel. Als hierbij het
functionele toepassingsgebied van de standaard, waarvoor het pas-toe-of-leg-uit
regime geldt, verandert, dan wordt eerst de uitgebreide vaststellingsprocedure
gevolgd en vervolgens de procedure van het Forum Standaardisatie.
9.2 Toelichting en voorbeeld regels
Een versie van een standaard (versie 1.2.0) is compatible met een eerdere versie van een standaard (versie 1.1.0) als uitwerkingen/ implementaties volgens de eerdere versie 1.1.0 ook volledig voldoen aan de normen en eisen van versie 1.2.0 .
Wijzigingen in de standaard kunnen impact hebben op de technische werking van implementaties en/of op afspraken die de technische werking van implementaties niet raken bijvoorbeeld organisatorische of proces afspraken;
Voor standaarden is relevant of een realisatie volgens de oude versie van een standaard wel of niet voldoet aan de nieuwe versie van de standaard;
Globale regels voor het bepalen van de impact op de versionering:
Toevoegen = Major
Wijzigingen = Major of Minor (afhankelijk van de verwachte impact van de wijziging)
Verwijderen = Minor
Correctie = Patch
Voor standaarden waarbij wijzigingen op onderdelen kan verschillen tussen
major en minor kan een impactmatrix opgesteld worden waarmee impact op de
onderdelen gespecificeerd kan worden.
9.3 Versie overgangen
Wanneer een nieuwe major versie uitkomt zal de oude versie conform de afgestemde migratiepad een einddatum van geldigheid krijgen. In de overgangsperiode kunnen dus meerdere versies gepubliceerd zijn en de status geldig hebben.
Om te kunnen werken aan publicatie-, werk- en voorstelversies van documenten worden Git branches gebruikt.
