ch02_Tactiek.md

Tactiek

In deze sectie worden onderwerpen verdiept die gerelateerd zijn aan tactische onderwerpen uit het Beheer- en Ontwikkelmodel.

De open invulling van een standaard (Activiteit Community)

Openheid is een belangrijk aspect van een duurzame standaard. Maar wat betekent dat voor de beheerorganisatie? Dat kunnen we nader beschouwen door naar een definitie of model van een open standaard te kijken. Echter door de jaren heen is er veel discussie geweest rond de definitie van openheid. Veelal richt de discussie zich op de beschikbaarheid (gratis of nominale bedrag voor aanschaf), gebruiksrechten (het wel/niet toestaan van Intellectual Property Rights (IPR)/Royalty Free en standaardisatieproces (wel/niet gratis participatie). Het model van Krechmer geeft een neutraal en brede blik op openheid, vandaar dat we het in BOMOS hanteren.

Krechmer's open standaarden model: '10 requirements'

Ken Krechmer heeft een model ontwikkeld waarmee de openheid concreet gemaakt wordt en waarmee hij standaardisatieorganisaties kan vergelijken. In het model maakt hij onderscheid tussen de verschillende openheidaspecten (requirements) en de verschillende gezichtspunten op standaarden. Als gezichtspunten/rollen hanteert hij de ontwikkelaar van de standaard, de implementator van de standaard in een product, en de gebruiker van de standaard (product waarin de standaard is verwerkt). Niet elk openheidsaspect is voor elke rol even interessant, zoals het model ook laat zien:

	Eisen	Ontwikkelaar	Implementator	Gebruiker
1	Open meeting	X
2	Consensus	X
3	Due process	X
4	One world	X	X	X
5	Open IPR	X	X	X
6	Open change	X	X	X
7	Open documents		X	X
8	Open interface		X	X
9	Open access		X	X
10	Ongoing support			X

Deze 10 criteria voor open standaarden betekenen het volgende voor de beheerorganisatie:

1. Open Meeting betekent dat iedereen mag meedoen in het standaardisatie proces. Geen stakeholders uitsluiten. Ook het mogelijk maken om tegen lage kosten op een per-meeting basis deel te nemen is belangrijk. Dit maakt het ook voor studenten of voor MKB bedrijven mogelijk om aan te sluiten. Meetings moeten duidelijk aangekondigd worden en er moeten zo min mogelijk barrières zijn voor stakeholders om deel te nemen. Een ontwikkelen beheerorganisatie moet zuinig zijn op stakeholders die willen participeren. In veel gevallen is het niet eenvoudig om voldoende stakeholders op de been te krijgen die actief willen participeren. Dus in plaats van drempels is stimulering meer op zijn plaats. De valkuil is om meetings alleen open te stellen voor slechts een bepaalde groep van (betalende) stakeholders.

2. Consensus gaat over de besluitvorming binnen de organisatie. Is er een (groep van) organisatie(s) die dominant zijn? In principe zou iedere participant gelijke rechten moeten hebben en kunnen meebeslissen. De valkuil is om een dominante groep (bijv. het bestuur/partijen die financieel fors bijdragen) te hebben die volledige controle heeft.

3. Due Process gaat over de processen hoe stemrondes zijn georganiseerd en de processen voor verzoeken tot heroverweging (appel) van beslissingen. Er moeten procedures zijn voor klachten, en die procedures moeten inzichtelijk zijn. Hetzelfde geldt voor de procedures voor besluitvorming, en in het bijzonder het proces om mogelijke patstellingen te doorbreken. Valkuil is om dit niet georganiseerd te hebben.

4. One World betekent dat idealiter voor hetzelfde doel er één standaard op de wereld wordt gebruikt, ook ter voorkoming van handelsbarrières. Dit wil uiteraard niet zeggen dat het voor een specifiek doel of context niet mogelijk zou zijn om een nieuwe standaard neer te zetten. Maar het betekent ook dat er geen regionale of nationale standaard gecreeërd dient te worden als een wereldwijde standaard voldoet. In algemene termen betekent One World ook dat de standaardisatieorganisatie niet verkokert, met oogkleppen op, een standaard ontwikkelt zonder wetenschap van andere standaarden/initiatieven. De valkuil is om als standaardisatieorganisatie oogkleppen op te hebben, en alleen bezig te zijn met eigen standaarden terwijl er goede standaarden beschikbaar zijn, eventueel als halffabricaat. Open betekent hier open in relatie met andere standaardisatieorganisaties om geen overlappende maar aansluitende zaken te ontwikkelen. Een andere valkuil is een te beperkte scope te kiezen voor de te ontwikkelen of beheren standaard; bijvoorbeeld nationaal in plaats van wereldwijd.

5. Open IPR (intellectuele eigendomsrechten) is het aspect waar de meeste discussie over is geweest, waarbij met name 'royalty free' en 'onherroepelijk' de kernwoorden uit de definitie van open zijn. Standaardisatieorganisaties en leveranciers hebben lang getracht om 'RAND' (Reasonable and Non-Discriminatory) op te nemen in de definitie van openheid. Deze standaardisatieorganisaties voldoen dan ook vaak op dit punt niet aan de definitie van open, wat betekent dat vele standaarden die in de perceptie open zijn, volgens de definitie niet open zijn op dit punt. De definitie van open standaard laat aan duidelijkheid niks te wensen over, en voorkomt discussie over RAND, bijvoorbeeld wat is reasonable? Dat leidt tot veel discussie. Royalty free en onherroepelijk beschikbaar zou de standaard moeten zijn. De valkuil is om dit niet geregeld te hebben, wat bij veel semantische standaardisatieorganisaties het geval is. De intenties zijn goed (open), maar door het niet expliciet te regelen kan dat tot problemen leiden in de toekomst. Ook is vaak niks geregeld over de rechten van de bijdrage die 'vrijwilligers' vanuit externe partijen leveren in werkgroepen van de standaard. Dit is een potentieel gevaar voor de duurzaamheid van de standaard.

6. Open Change: Als een leverancier alleen gedwongen wordt om de standaard open beschikbaar te stellen, maar zelf op elk moment wijzigingen kan doorvoeren, zullen de voordelen van standaarden nooit bereikt worden en behoudt de ene leverancier zijn macht. Een open manier van wijzigingen in de standaard doorvoeren is van groot belang, maar krijgt tot op heden weinig aandacht. Standaardisatieorganisaties die niet voldoen aan open meeting, consensus en due process kunnen per definitie niet voldoen aan open change. Een open invulling kan geschieden door het beschrijven van wijzigingsprocessen waarbij geen partij een bijzondere status heeft in de besluitvorming. De valkuil is om het proces van wijzigingen niet open in te richten, helemaal omdat er vaak geen aandacht voor is.

7. Open Documents betekent dat alle documenten open beschikbaar zijn. Dat betekent dat niet alleen de standaarden zelf maar ook work in progress beschikbaar moet zijn, notulen van meetings, e.d. Daarmee kunnen gebruikers van de standaard de complete achtergrond doorgronden. De valkuil is om alleen de standaarden zelf open beschikbaar te stellen.

8. Open Interface is vooral relevant voor technische standaarden, en heeft betrekking op het ruimte laten voor leveranciers voor gesloten uitbreidingen, en daarnaast ook de ruimte bieden voor backward en forward compatibiliteit. Valkuil: het niet adresseren van backward compabiliteit en de ruimte bieden voor tijdelijke uitbreidingen (forward compatibiliteit).

9. Open Access: Eindgebruikers vertrouwen er vaak op dat hun leverancier(s) de standaarden correct hebben geïmplementeerd. Om 'Open Access' te bereiken moet het mogelijk te zijn om de implementatie van de standaard te testen (conformiteit); dat kan door middel van conformiteittesten (testprotocollen) tot aan officiële certificatie. Een andere mogelijkheid zijn zogenoemde plugfesten waarbij de interoperabiliteit tussen verschillende implementaties van een standaard inzichtelijk wordt gemaakt. De valkuil is om hier van uitstel naar afstel te gaan. De standaarden moeten een bepaalde mate van volwassenheid hebben wil dit zinvol zijn. Daarom wordt het vaak uitgesteld. En van uitstel volgt afstel. Een open invulling betekent ook het inzichtelijk (open) maken van het gebruiken van de standaard in implementaties, bijvoorbeeld door het publiceren van implementatieoverzichten.

10. Ongoing Support is het leveren van ondersteuning op de standaard gedurende de levenscyclus. De valkuil is het stoppen met het leveren van ondersteuning als de interesse van leveranciers afneemt. Een open invulling betekent op zijn minst dat de levenscyclus van een standaard beschreven is waarmee gebruikers garantie krijgen over de ondersteuning op de standaard. Idealiter dient de ondersteuning pas af te lopen als er geen interesse meer is in de standaard bij de eindgebruiker.

Veel van de huidige discussies over openheid gaan over slechts twee aspecten van openheid te weten, 'One World' en vooral 'Open IPR', terwijl de andere aspecten daardoor onderbelicht raken. Alle punten helpen bij het inrichten van maximaal open standaardisatieorganisatie. Tot op heden is er geen organisatie bekend die op alle punten volledig open is. Volledig open op al deze punten is een utopie, maar deze punten zijn wel aandachtspunten, en kunnen het denkproces helpen om standaardisatie meer open te krijgen. Overigens is het goed te weten dat de formele standaardisatieorganisaties in veel gevallen niet (of slechts ten dele) voldoen aan de aspecten 6-10.

Concrete tips voor openheid

Op basis van het voorgaande zijn er een aantal concrete tips op te stellen: Maak besluitvorming open door:

• Publiceren van de notulen van verschillende gremia.
• Consensus besluitvorming.
• Geen partijen uitsluiten bij bijeenkomsten.
• Een website met daarop alle documenten (ook drafts) kosteloos beschikbaar.
• Een duidelijke wijzigingsprocedure.
• Het testbaar maken van de standaard door middel van testprocedures, validatie, certificatie en/of plugfests.
• Regel structurele financiering.
• Veel aandacht besteden aan de relatie met andere standaarden in de omgeving.
• De rechten expliciet hebben vastgelegd; de intellectuele eigendomsrechten op de standaarden, copyrights op documenten, de bijdrage van personen in werkgroepen en in de totstandkoming van de standaarden. Versiebeheer vastleggen: hoe om te gaan met backward en forward compatabiliteit, en daarnaast de ondersteuning vastleggen op basis van de levenscyclus van een standaard.
• Het vastleggen in een document van de ontwikkelen beheeraspecten.

Het toetsbaar maken van het model

Het model van Krechmer is een ideaal startpunt maar kan aangevuld worden om meer praktische handvatten te bieden. Daartoe hebben we de criteria verder uitgewerkt in variabelen per criteria. Deze variabelen zijn beter te relateren aan de praktijksituatie. Tot slot kunnen er scores toegekend worden per variabelen; dat maakt openheid tussen standaarden ook vergelijkbaar. Theoretisch gezien zou er dan bijvoorbeeld een minimale score kunnen worden gedefinieerd willen we spreken over een open standaard. Echter dat doet geen recht aan het feit dat bepaalde variabelen belangrijker zijn dan andere variabelen.

Het model op de volgende pagina is een invulling van de 10 criteria van Krechmer en is een hulpmiddel om de beheer-activiteiten op een open manier in te vullen.

	Principe	Criteria		Variable	Toelichting	Score
1	Open meeting	Iedereen kan partiperen in het standaardisatieproces	1	Toegangsprijs	Is er een toegangsprijs voor standaardisatiebijeenkomsten? Is dat betaalbaar voor de verschillende deelnemers? Gratis (2 punten), Betaalbaar, laag of gediversifieerd tarief (1 punt) of kostbaar (0 punten)	0/1/2
			2	Bereikbare vergaderlocaties	Vergaderlocaties worden zodanig gekozen dat reiskosten voor iedereen geminimaliseerd zijn	0/1/2
			3	Open voor iedereen	Elke organisatie of persoon kan in principe participeren in de ontwikkeling van de standaard	0/1/2
			4	Open kalender	Is de vergaderagenda online beschikbaar en actueel? Ruim van tevoren?	0/1/2
2	Consensus	De basis van een standaard is consensus	1	Open proces	Het proces van standaardisatie is openbaar zodat er voor iedereen duidelijk is hoe zaken besloten zijn	0/1/2
			2	Procedure bij geen consensus	Er is een procedure voor het geval geen consensus bereikt kan worden	0/1/2
			3	Gelijke stem	Alle stakeholders hebben in de besluitvorming een even grote stem. Dit voorkomt de aanwezigheid van dominante stakeholders.	0/1/2
			4	Externe review	De resultaten van de standaardisatie-bijeenkomsten worden gepubliceerd waardoor externe organisaties en personen de mogelijkheid hebben om resultaten te reviewen. Dit ook om kwaliteit te verhogen.	0/1/2
3	Eerlijk standaardisatieproces	Vastgelegde procedures om gedurende het standaardisatieproces consensus te garanderen	1	Open agenda	Voor elke stakeholder is het mogelijk om agendapunten aan te leveren	0/1/2
			2	Procesmanagement	Is er sprake van een reglement waarin de procedures en protocollen van het standaardisatieproces zijn vastgelegd (manier van stemmen, beroepsmogelijkheden etc.)	0/1/2
			3	Onafhankelijke voorzitter	Worden de standaardisatiebijeenkomsten door een onafhankelijk persoon voorgezeten zodat de belangen van alle stakeholders de juiste aandacht krijgen?	0/1/2
			4	Mogelijkheid tot beroep	Wanneer men ontevreden is over de besluitvorming in een standaardisatiebijeenkomst is er de mogelijkheid om een klacht in te dienen bij een hoger orgaan? Dit orgaan bekijkt de situatie en heeft de bevoegdheid om in te grijpen	0/1/2
4	Open IPR	Intellectuele eigendomsrechten m.b.t. standaard zijn zo open mogelijk	1	Rechten gepubliceerd	De manier waarop juridische zaken rondom de standaard zijn geregeld dient openbaar te zijn	0/1/2
			2	Juridische belemmeringen	Hoe minder juridische belemmeringenvoor het gebruik van de standaard, hoe opener de standaard is	0/1/2
			3	Wederzijdse licenties	Op aanpassingen van de standaard rusten automatisch dezelfde licenties als op het origineel, zodat aangepaste standaarden niet voorzien kunnen worden van allerlei juridische belemmeringen	0/1/2
5	One world	De standaard kan voor hetzelfde doel wereldwijd gebruikt worden	1	Harmonisatie	In hoeverre sluit de standaard aan op gerelateerde standaarden?	0/1/2
			2	Lokatie onafhankelijkheid	In hoeverre bevat de standaard elementen die uniek zijn voor een specifieke geografische lokatie? Een open standaard dient zo min mogelijk van dit soort elementen te bevatten zodat de toepasbaarheid groter wordt	0/1/2
6	Open documenten	Documenten m.b.t. de standaard zijn openbaar	1	Open concepten	De concept-documenten met betrekking tot de standaard zijn openbaar	0/1/2
			2	Open specificaties	De specificaties van de standaard zijn openbaar.	0/1/2
			3	Open notulen	De notulen van bijeenkomsten zijn openbaar.	0/1/2
			4	Open procedures	De procedures (zoals Concensus en Eerlijk standaardisatieproces) zijn openbaar.	0/1/2
			5	Open distributie	Het distribueren van de hierboven beschreven documenten staat iedereen vrij.	0/1/2
7	Open interface	Compatibiliteit en conformiteit leiden tot interoperabiliteit.	1	Compatibiliteit	Verschillende versies van de standaard zijn – voor zover mogelijk - compatibel met elkaar, d.w.z. verschillende versies zijn op basaal niveau interoperabel.	0/1/2
			2	Implementaties conform specificatie	De standaard beschrijft expliciet wat conformiteit aan de standaard betekent en aan welke criteria voldaan moeten worden. Zodat transparant kan worden welke implementaties conform de standaard zijn. Betekent twee implementaties conform de standaard ook interoperabiliteit?	0/1/2
8	Open access	Er zijn methodes om conformiteit te testen en te certificeren.	1	Validatie testen	Er kan getest worden of een standaard daadwerkelijk op een juiste manier is geïmplementeerd. Een laagdrempelige testmogelijkheid.	0/1/2
			2	Conformiteit valideren	Een toets kan plaats vinden op conformiteit, waarbij validatie een onderdeel vormt. Het resultaat wordt vastgelegd in een document.	0/1/2
			3	Conformiteit certificatie	Een toets die plaats vindt op basis van conformiditeitsregels, waarbij het resultaat openbaar gepubliceerd wordt en kan leiden tot een certificaat.	0/1/2
			4	Disability support	De standaard houdt rekening met mensen die een handicap hebben, en voldoet aan richtlijnen hiervoor.	0/1/2
9	On-going support	De standaard wordt ondersteund totdat er geen gebruikers meer zijn	1	Ondersteuning gedurende de hele levenscyclus van de standaard.	Gedurende de levenscyclus van de standaard (van begin tot eind) is er ondersteuning voor gebruikers vanuit de standaardisatieorganisatie. Met name ook aan het einde van de cyclus wanneer er wellicht nog maar een klein aantal gebruikers is en de neiging om geen ondersteuning te bieden groot is.	0/1/2
10	Open change	Wijzigingen in de standaard op basis van openheid	1	Uitbrengen nieuwe versie	Wie bepaalt wanneer aan een nieuwe versie van een standaard gewerkt gaat worden, en wanneer deze uitgebracht gaat worden? Ook hiervoor geldt consensus	0/1/2
			2	Inbrengen wijzigingsverzoeken	Wie kunnen er wijzigingsverzoeken indienen, en worden die eerlijk (op basis van een vastgestelde procedure) behandeld? Hiervoor zouden geen partijen uitgesloten moeten worden.	0/1/2

Het Forum Standaardisatie toetst standaarden op onder meer openheid voor opname op de pas-toe of leg-uit lijst. In deze bredere toets zijn de criteria van Krechmer ook verwerkt. Het model hier gepresenteerd is een verdieping, bedoeld als handreiking om openheid vorm te geven en kan niet gebruikt worden in het formele proces van opname voor de lijst van pas-toe of leg-uit. Meer informatie over de toetsingscriteria is te vinden via de website van het Forum Standaardisatie.

Open invulling met Open Source Software

Onderdeel van het activiteitendiagram is moduleontwikkeling, dit wil zeggen dat de organisatie software kan (laten) ontwikkelen waarin de standaard geïmplementeerd is. Gevaarlijk is om dit als standaardisatieorganisatie zelf 'commercieel' te doen aangezien de standaardisatieorganisatie een concurrent wordt van andere leveranciers in de markt. De ondersteuning van de standaard door andere leveranciers zal dan snel afnemen. Door het ontwikkelen op basis van open source wordt dit deels ondervangen. De open source module waarin de standaard is verwerkt komt dan vrij beschikbaar waardoor de commerciële leveranciers dit verder kunnen oppakken, en op termijn kan de standaardisatieorganisatie haar handen er vanaf trekken. Het is dan ook voornamelijk een middel (stimulans) om de markt in beweging te krijgen.

Verder is Open Source Software een prima alternatief voor gesloten source software. Het voornaamste verschil is het business model. Voor de adoptie van een standaard is het belangrijk dat de standaard geïmplementeerd wordt in alle software, ongeacht het business model. Het is in enige mate gevaarlijk, vanuit adoptie oogpunt, om een bepaald type leverancier een voorkeursbehandeling te geven aangezien daarmee weerstand gecreëerd wordt bij andere leveranciers.

Open Source Software dient zeker niet verward te worden met open standaarden. Dit zijn wezenlijk andere concepten, waarbij vanuit het oogpunt van interoperabiliteit alleen open standaarden essentieel zijn.

Samenhang met andere standaarden (Activiteit Architectuur)

Zoals eerder geschetst is interoperabiliteit het doel en zijn standaarden het middel. Dit deel gaat in op deze relatie tussen verschillende standaarden.

De gelaagdheid van standaarden

Om interoperabiliteit (uitwisselbaarheid) te bewerkstelligen tussen organisaties of systemen is een complexe set van standaarden nodig. Dit maakt de materie uitermate lastig want het gaat niet meer om het kiezen of beheren van één standaard, maar het gaat om een set van standaarden die op sommige gebieden sterk aan elkaar gerelateerd zijn. Een onderscheid is daarbij te maken in standaarden voor technische zaken en standaarden voor de semantiek van informatie-uitwisseling. Het interoperabiliteitsraamwerk (op basis van Jian, H., & Zhao, H. (2003). A Conceptual Model for Comparative Analysis of Standardization of Vertical Industry Languages.) laat dit zien; tussen haakjes staan engiszins verouderde voorbeelden van standaarden waarmee dit kan worden ingevuld.

Voor technische interoperabiliteit moeten er keuzes gemaakt worden, waarbij vaak gekozen wordt voor een technische filosofie waarbij een familie van standaarden hoort; Echt veel keuzes zijn er eigenlijk niet. Bijvoorbeeld als communicatiemechanisme is het Internet met als standaarden TCP/IP, HTTP, etc. voor de hand liggend. Op het gebied van messaging (transport) mechanisme is er misschien meer keuze, maar Web Services als familie hier lange tijd voor de hand liggend, en inmiddels zijn REST APIs defacto standaard geworden. De keuze voor Web services brengt een keuze voor de individuele standaarden (zoals SOAP, WSDL, etc.) met zich mee. Overigens is de keuze voor deze technische standaarden alleen niet voldoende. Om interoperabiliteit te bereiken zijn doorgaans nog profielen nodig bovenop deze standaarden waarin beschreven staat hoe de opties in de standaarden ingevuld moeten worden. Ook al is dit niet domeinspecifiek wordt dit nu vaak per domein ingevuld, vooral om gebruikers een complete interoperabiliteitsoplossing te kunnen bieden in combinatie met de semantische standaarden.

Bij het Standaardisatie Platform E-facturatie (STPE) zie je de gelaagdheid van standaarden goed terug. Daar heeft men te maken met de EN 16931: een Europese standaard dat een semantisch model voor de kernfactuur beschrijft (Common Semantics). Dit model is uitgedrukt in twee Horizontal Languages: UBL en UN/CEFACT Cross Industry Invoice (CII). Beide van deze talen bouwen op XML als Common Syntax. De EN 16931 doet geen uitspraken over hoe de Technical Interoperability ingericht dienen te worden.

Op het semantisch vlak eindigt de gelaagdheid niet met de Europese kernfactuur. In Nederland heeft men een nationaal profiel op de EN 16931 gespecificeerd om het gebruik van de norm in Nederland te bevordereren: de NL-CIUS (Core Invoice Usage Specifcation). Er zijn zelfs brancheverenigingen die de NLCIUS weer verder specificeren. Zo is de SETU Invoice een laag bovenop de NLCIUS met een aantal inperkingen en instructies om het gebruik van de factuurnorm in het uitzenddomein te bevorderen.

Tot slot is de keuze voor de technische standaard JSON tegenwoordig voor de hand liggend. In het verleden was XML, en daarvoor EDI de aangewezen technologie. Deze wordt nog veel gebruikt in bestaande situaties, maar niet meer in nieuwe situaties.

De technische standaarden zijn randvoorwaardelijk, maar de echte uitdaging ligt bij de semantische standaarden waarin de betekenis van de informatie-uitwisseling centraal staat. Verticale semantische standaarden zijn gericht op een specifieke sector, terwijl horizontale sector overstijgend zijn. In de praktijk zijn verticale standaarden noodzakelijk om goed aan te sluiten bij de context van de organisatie. Verticale standaarden kunnen een nadere invulling zijn van horizontale standaarden, zie hiervoor de volgende paragraaf.

Om het nog complexer te maken zijn er standaarden die gebruikt worden om standaarden te maken, denk bijvoorbeeld aan de standaard UML, als taal om diagrammen te tekenen die bijvoorbeeld het proces en data-model van een standaard bevatten.

Life cycle van gelaagde standaarden

Uit het toepassen van gelaagde familie van standaarden volgt een noodzaak om actief te sturen op het toepassen van actueele standaarden. Dit kan uitdagingen opleveren. Wanneer een onderliggende standaard overgaat naar een nieuwe versie kan het nodig zijn de bovenliggende standaard aan te passen op de onderliggende standaard.

Zo is het van belang de een onderliggende standaard in actief beheer beheer is. Alleen wanneer de gebruikte standaard beheerd wordt kunnen wijzigingsverzoeken in behandeling genomen worden en kunnen eventueele fouten in die standaard gecorrigeerd worden. Wanneer een gelaagde standaard gebruikt maakt van een onderliggende standaard die niet meer in beheer is zijn de mogelijkheiden om de standaard bij te werken beperkt.

Het is dus raadzaam om in het beheer van een (gelaagde) standaard de ontwikkelingen in de onderliggende standaard(en) actief te volgen om over te kunnen gaan naar een nieuwe versie.

De relatie met internationale standaarden

Semantische standaarden kennen een ongekende complexiteit in vergelijking met andere standaarden en worden anders ontwikkeld en beheerd. Het merendeel van de IT-standaarden wordt al buiten de officiële standaardisatieorganisaties (zoals ISO en NEN) ontwikkeld, namelijk in zogenoemde industrieconsortia zoals W3C en OASIS. Wanneer we naar semantische standaarden kijken, gaat het echter nog een stap verder aangezien die grotendeels door een eigen organisatie ontwikkeld worden.

Voor het beheer van de Noordzee zijn internationaal uitwisselbare gegevens over zeewater noodzakelijk. De Aquo-standaard was alleen geschikt voor het Nederlands continentaal plat. Dat is maar een stukje van de Noordzee. Maar om (beleids-) vraagstukken over de hele Noordzee aan te pakken, moet Nederlandse beheerders data uitwisselen met bijvoorbeeld Engelse databeheerders. Daarvoor is een internationale standaard nodig. In de 1e fase zijn is het Informatiehuis Water met een consortium van relevante partijen een woordenboek aan het samenstellen. Dat is een tabel met enerzijds de Nederlandse Aquo-term en anderzijds de Engelse SeaDataNet/EMODnet-term.

De praktijk laat zien dat alleen een onderscheid tussen horizontale en verticale standaarden te beperkt is. Internationale verticale standaarden hebben vaak nog een specifieke invulling nodig om bijvoorbeeld in de context van een land (zoals Nederland) perfect te kunnen aansluiten bij de bedrijfsprocessen in die context. Dit is noodzakelijk om interoperabiliteit te kunnen behalen. Op nationaal niveau ontstaan dan standaarden, ook wel afspraken of toepassingsprofielen genoemd, die een verdere invulling bevatten van een internationale standaard. Daarnaast worden er ook regelmatig specifieke codelijstjes voor de nationale context toegevoegd. Dit leidt tot de volgende classificatie:

• Internationale horizontale standaard
• Internationale verticale standaard
• Nationale standaard/toepassingsprofiel/afspraak/taxonomie
• Nationale vocabulaires, codelijstjes, etc.

Ook in de organisaties is dit terug te zien: HL7 is de internationale standaard, en daarnaast is er HL7 Nederland. Bij het internationale HR Open Standards is het SETU dat Nederlandse HR Open Standards profielen maakt.

Alle vormen, of het nu een internationale horizontale standaard is of een nationaal codelijstje, moeten allemaal ontwikkeld en beheerd worden! Overigens wil het niet zeggen dat alle vier de classificaties voor een bepaald toepassingsdomein moeten voorkomen. In de praktijk kan elke willekeurige combinatie voorkomen, afhankelijk van de situatie.

IM Metingen is een standaard die door de bodembeheerders en waterbeheerders gezamenlijk is opgesteld om gegevensuitwisseling over de verschillende vakgebieden heen mogelijk te maken. Maar er is bij het ontwerp al rekening gehouden met internationale gegevensuitwisseling. IM Metingen is gebaseerd op de internationale standaard OpenGIS® Observations and Measurements (O&M). Observations and Measurements is een standaard voor het beschrijven van observaties en metingen. Deze observaties en metingen zijn weer gekoppeld aan een locatie. Met O&M is het mogelijk om observaties en metingen in een internationaal model te modelleren en uit te wisselen.

Tijdens de adoptiefase is nog wel eens een gehoorde opmerking dat men alleen de internationale standaard wil adopteren in plaats van de nationale. De argumentatie is meestal dat men wereldwijd zaken doet, of dat de internationale standaard breder aansluit of breder bekend is. In de praktijk zal dit echter leiden tot beperkte interoperabiliteit aangezien de internationale standaard minder goed zal aansluiten en veelal ook te veel vrijheidsgraden kent. Omdat interoperabiliteit het doel is van standaarden is het geen verstandige keus. Men zou zich moeten richten op de nationale standaard die zorg draagt voor aansluiting bij internationale standaarden en zorg draagt voor optimale toepassing in de Nederlandse context.

Ook in de beheerfase van een standaard is het nuttig aandacht te houden voor internationale standaarden. Wanneer tijdens de adoptiefase geen passende internationale standaard beschikbaar is kan een nationale standaard de enige optie zijn. Maar dat kan veranderen. Een voorbeeld is de Digikoppeling standaard. Digikoppeling omvat een koppelvlakspecificatie met hetzelfde doel en toepassing als het Europese eDelivery wat later vastgesteld is. In het kader van standaardenbeheer zou ervoor gekozen moeten worden de nationale standaard uit te faseren ten gunste van een meer recente internationale standaard. Ook hier zal een nationaal profiel op de internationale standaard nuttig zijn. Voor de beheerorganisatie resulteert dit in een andere rol. De beheerorganisatie vertegenwoordigt de Nederlandse stakeholders indien nodig in het beheer van de internationale standaard.

Belangrijk aandachtspunt bij internationale standaarden is dat in een situatie van bijvoorbeeld een internationale verticale standaard in combinatie met een nationaal toepassingsprofiel, dat voor beide een andere naam wordt gehanteerd om verwarring in de praktijk voorkomen.

Voorbeelden van gelaagdheid van standaarden

Tot slot, ook binnen de standaarden zelf kan weer gelaagdheid ontstaan, op verschillende manieren. Tussen verticalen sector modellen en horizontale standaarden, en daarnaast worden ook andere (bv. technische) standaarden vaak samen toegevoegd om een totaal oplossing te bieden voor interoperabiliteit.

XBRL is een voorbeeld van een internationale verticale standaard (in de financiële sector) waarvoor nationale taxonomieën zijn opgesteld, bijvoorbeeld de US GAAP of in Nederland door het SBR programma.

In het kader van e-factureren heeft de Nederlandse overheid gekozen voor een internationale horizontale standaard (UBL), en heeft men vervolgens zelf een factuurmodel ontwikkeld om de vrijheidsgraden te beperken. Dus ook hier is er sprake van een nationaal toepassingsprofiel om uiteindelijk interoperabiliteit te kunnen bereiken.

Om alle informatiemodellen in Nederland nog beter op elkaar aan te laten sluiten is een metamodel ontwikkeld voor informatiemodellering (MIM). Hierin komt de modelleringskennis van onder meer Geonovum, Kadaster en VNG Realisatie samen. Met deze standaard wordt interoperabiliteit tussen andere standaarden bevordert.

Sector overstijgende interoperabiliteit: Verzuiling

Door de sector-specifieke aanpak van de semantische standaarden ontstaat de angst voor verzuiling van sectoren. Interoperabiliteit over sectoren heen wordt niet opgelost, en wordt zelfs mogelijk steeds lastiger. Het potentiële probleem is alom bekend, en oplossingen worden daarvoor bedacht maar tot op heden stranden deze in zeer lage adoptie en gebrek aan draagvlak en ondersteuning. Dat kan twee oorzaken hebben;

1. Het probleem van sector overstijgende interoperabiliteit wordt nog niet als nijpend beschouwd aangezien binnen de sector nog grotere uitdagingen liggen.

2. De voorgestelde technische oplossingen zijn vaak uitermate complex. Bijvoorbeeld een technisch fraaie oplossing is de UN/CEFACT Core Components standaard. Deze standaard is meer dan tien jaar oud, maar is uiteindelijk nooit breed geadopteerd.

De kern van de oplossing zit hem waarschijnlijk niet in de techniek, maar in de beheerorganisaties actief in de verschillende domeinen. Deze zullen minder verkokerd moeten optreden en meer moeten samenwerken met de collega beheer-organisaties in aanverwante sectoren. Daar is de laatste jaren dan ook al verbetering in opgetreden. Mede ook op basis van het 'open' gedachtegoed, want in een one world (zie sectie over openheid) zijn er geen concurrerende standaarden en sluiten standaarden perfect op elkaar aan.

De relatie met formele standaarden

De vorige paragrafen maken helder dat semantische standaarden in de meeste gevallen een gelaagdheid kennen en daarmee voortbouwen of gebruik maken van andere standaarden. Interessant daarbij is een probleem dat generiek is voor het ontwikkelen van standaarden, maar in de pressure cooker nadrukkelijk naar voren komt: de omgang met formele (o.a. ISO, CEN, NEN) standaarden. Uitgangspunt is namelijk dat er zoveel mogelijk hergebruik plaatsvindt van bestaande standaarden en dat niet het wiel opnieuw uitgevonden wordt.

Bij formele standaarden zijn er een aantal pijnpunten:

Het niet kunnen inzien van de formele standaarden: Een aantal keren werd in de pressure cooker sessie melding gemaakt dat een bestaande formele standaard mogelijk al een (deel)oplossing bevat. Echter niemand weet het zeker want niemand heeft de standaard ingezien omdat er kosten aan verbonden zijn. Ook al kunnen de kosten beperkt zijn, de drempel is te hoog. Nu moest door de begeleider na afloop van de dag de standaard maar aangeschaft worden, om er soms na drie minuten achter te komen dat de standaard niet bruikbaar was. Dit staat snelle voortgang (in de pressure cooker) in de weg. In de praktijk blijkt (bijv. bij Geonovum en SETU) dat zelfs een 'gratis registratie' al als een te hoge drempel wordt ervaren.

De kosten tijdens het ontwikkelen van standaarden: De kosten voor aanschaf van een formele standaard (specificatiedocument) zijn gemiddeld grofweg 100 euro per standaard. Relatief een klein bedrag bij de ontwikkeling van een nieuwe standaard, soms hooguit zonde als direct na aanschaf blijkt dat die niet relevant is. Maar een groter probleem is het aantal; bijna nooit is het één standaard die aangeschaft moet worden. In het geval van de pressure cooker voor de afvalsector ging het naast de aanschaf van een DIN standaard, ook om de aanschaf van NEN-, en ISO-standaarden, waarbij een ISO standaard uit vier delen bestaat die los aangeschaft dienen te worden. Dan nemen de kosten, maar ook de frustratie over het gedoe verder toe. Dit gedoe heeft vaak ook met inkoop-proces binnen een organisatie te maken. Al snel ontstaat een laat maar, zal toch wel niet nuttig zijn gevoel.

Dit probleem kan ondervangen worden door de werkgroep/pressure cooker onder te brengen bij het NEN, aangezien NEN werkgroepen onbeperkt inzage hebben in de standaarden. Echter aan het onderbrengen van de werkgroep bij NEN zijn ook kosten verbonden.

Hergebruik: De waarde van de formele standaarden is groot. Ook in de pressure cooker voor de afvalsector werd genoeg waardevols in de bestaande formele standaarden gevonden, waardoor zeker niet het wiel opnieuw uitgevonden hoefde te worden. Alleen dan wordt het onduidelijk hoe de formele standaarden hergebruik toestaan. Er bestaan twee opties:

• Verwijzen naar de formele standaard, maar dat leidt tot kosten voor implementaties (zie onder).
• Een stuk uit de formele standaard overnemen.

Dit laatste is met name nuttig als de formele standaard veel breder (of voor een ander domein) van toepassing is maar dat de keuzes ook prima van toepassing zijn op 'onze' standaard. Wel leidt het tot vraagstukken rondom de openheid van het eindresultaat. Het NEN hanteert als vuistregel dat 10% overgenomen mag worden na overleg met het NEN. Dit laatste is ook noodzakelijk zodat NEN kan controleren of er geen patenten worden geschonden die op de formele standaarden kunnen rusten.

De kosten voor de implementaties: Als verwezen wordt naar een bestaande formele standaard, dan zal elke leverancier die de standaard wil implementeren deze formele standaard moeten aanschaffen. De eigen standaard kan dan wel open en gratis beschikbaar zijn, maar door de verwijzing creëren we toch een adoptiedrempel, en mogelijk risico dat de standaard verkeerd geïmplementeerd wordt omdat men tijdens de implementatie besluit de formele standaard niet aan te schaffen. Dus worden alle implementatie-partijen opgezadeld met kosten en wordt zo toch een adoptie en interoperabiliteits-drempel gecreëerd, wat niet de bedoeling was.

Strategieën voor omgang met lokalisatie profielen

Als we in een nationale, sectorspecifieke context, een internationale standaard willen gebruiken, dan creëren we een belangrijke afhankelijkheid. De invulling van de relatie tussen de nationale en internationale standaard kan op verschillende manieren worden ingevuld, afhankelijk van de context en de gekozen strategie. Idealiter wordt gewoon de internationale standaard volledig geadopteerd, maar in de praktijk weten we dat een internationale standaard bijna nooit een op een overgenomen kan worden; soms zijn veranderingen beperkt: slechts wat extra zaken die voor de specifieke nationale context toegevoegd moeten worden om interoperabiliteit te kunnen bereiken.

De volgende situaties kunnen zich voordoen:

• De specifieke context vergt uitbreidingen/aanpassingen aan de standaard.
• Er zitten vele overbodige zaken in de standaard die zorgen voor extra complexiteit die niet nodig is voor de specifieke context.
• Er worden fouten gevonden in de internationale standaard.
• Er missen zaken in de standaard die niet specifiek zijn voor de context.
• Er is behoefte aan een nieuwe standaard.

Algemeen gesproken kunnen dan de volgende activiteiten ondernomen worden:

• Aanpassen in de internationale standaard (en brengen de aanpassingen niet terug naar de internationale standaard) (Adaptations)
• Toegestane uitbreidingen aan de standaard invullen (Extensions)
• Zaken uit de standaard halen (Ommissions)
• Passen de standaard tijdelijk aan (we brengen de gewenste aanpassingen in bij de internationale standaard, maar hebben nu een oplossing nodig die tijdelijk is, totdat de internationale standaard is aangepast) (Temporary Adaptations)

De strategieën:

Strategie	Kenmerken
Local Re-Use	We hergebruiken de internationale standaard, maar passen het aan naar de behoeftes en creeren een nieuwe standaard
Local Profiling	Een profiel (dat niet voldoet aan de internationale standaard) bovenop de internationale standaard, waarin alle aanpassingen verwerkt zijn.
Compliant & Temporary Local Profiling	Een profiel waarin in principe alleen toegestane uitbreidingen in worden opgenomen, maar daarnaast tijdelijke oplossingen bevat van zaken die internationaal zijn ingebracht, maar die een tijdelijke oplossing rechtvaardigen. Deze tijdelijke oplossingen voldoen niet aan de internationale standaard.
Compliant Profiling	Alleen uitbreidingen in een profiel die voldoet aan internationale standaarden.
Comply	100% overname van internationale standaard zonder aanpassingen of uitbreidingen.

Met name om interoperabiliteit internationaal mogelijk te maken is het verstandig om zoveel mogelijk in lijn te blijven met de internationale standaarden en een strategie te kiezen aan de rechterkant van het figuur, waar mogelijk compliant profiling. Echter dat vergt afstemming met de internationale standaard, waaraan kosten verbonden zijn, ondermeer door het bezoeken van de internationale standaardisatie bijeenkomsten. Een noodzakelijkheid om interoperabiliteit in internationale context na te streven.

De Linked Data standaarden voor semantisch modelleren

Linked Data heeft een lange weg doorgemaakt, maar is inmiddels de defacto standaard voor semantisch modelleren. De standaarden en technologieën die hieronder vallen, zoals RDF, SPARQL en OWL, worden steeds meer in de praktijk geadopteerd. Dat begon in de academische wereld maar heeft zich de afgelopen jaren uitgebreid naar de publieke sector en het bedrijfsleven.

Linked Data brengt veranderingen in de semantische standaardisatiediscipline die BOMOS omschrijft. Het gaat niet enkel om het gebruik van nieuwe technologieën en hulpmiddelen. Linked Data betekent een andere benadering tot semantische interoperabiliteit: de nadruk verschuift van het standaardiseren van berichten (of 'transacties') naar het standaardiseren van de onderliggende domeinbeschrijving; de taal. Met vocabulaires en ontologieen wordt de taal in een domein gestandaardiseerd, maar ook relaties tussen domein-ontologieën kunnen gelegd worden, waardoor Linked Data de grenzen van sectoren weet te doorbreken en een middel voor domein-overstijgende interoperabiliteit is geworden. Daarnaast voldoen de Linked Data standaarden aan de open standaarden criteria, en een aantal zijn dan ook opgenomen op de pas-toe of leg-uit lijst van de Nederlandse Overheid.

Bij Floricode zien we door de jaren heen verschuivingen in aandacht op basis van architectuurkeuzes. Zo is de aandacht van traditionele berichten(uitwisseling) standaardisatie verschoven richting masterdata voor sierteelt.

Eenzelfde ontwikkeling zien we ook in de uitzendbranche. Van oudsher biedt de SETU gestandaardiseerde berichtspecificaties voor veelgebruikte en generieke integratievraagstukken, zoals de Plaatsing, het Urenbriefje en de Factuur. Om digitale integratie-uitdagingen op een moderne, flexibele en kostenefficiënte manier op te blijven lossen, richt de SETU zich steeds meer op het bieden van een gemeenschappelijke taal (ontologie). Deze SETU-taal is opgebouwd uit concepten en relaties met bijbehorende terminologie en definities. Deze concepten en relaties worden als bouwblokken gebruikt op bericht- en API specificaties op te stellen in verschillende formaten. 

Stimuleren van het gebruik van standaarden (Activiteit Adoptie & Erkenning)

Veel standaardisatieorganisaties zoeken naar mogelijkheden om het gebruik van hun standaard te stimuleren. Dit kan op verschillende manier gedaan worden. Een strategie daarvoor wordt een adoptiestrategie genoemd.

Succesfactoren voor adoptie van een standaard

Uit werkgroepen van het Forum Standaardisatie komt een aantal kritieke succesfactoren naar voren die bij de adoptie van verschillende standaarden een rol hebben gespeeld:

1. De standaard moet volwassen zijn; anders durft niemand te investeren.
2. Geduld: Adoptie van een standaard vergt tijd, soms meerdere jaren.
3. De voordelen moeten voor iedereen helder zijn, voor het bedrijfsproces, maatschappelijk en financieel; er is draagvlak.
4. Er moet een betrokken probleemeigenaar zijn, juist ook omdat adoptie vele jaren duurt; echt commitment is onontbeerlijk.
5. Er is een kritieke massa van gebruikers nodig.
6. Een leidende partij of een leidend proces kan adoptie sterk stimuleren.
7. Er moet een actieve community zijn die betrokken is bij ontwikkeling en gebruik van de standaard.
8. Er is geld nodig voor ondersteuning, opleiding, beloning etc.
9. Gebruik een goede mix van adoptiemiddelen.

Kiezen van de juiste middelen

Het is niet gemakkelijk om de juiste strategie te kiezen voor het bevorderen van de adoptie van een standaard. Soms is een dergelijke strategie niet nodig en wordt de standaard volledig 'gedragen' door partijen in het veld. Vaak hangt een standaard echter samen met een bredere ontwikkeling. Denk bijvoorbeeld aan een standaard voor digitalisering van een keten. De invoering van de standaard hangt dan samen met de vraag of een organisatie aan de slag gaat met die digitalisering.

De middelen voor adoptie kunnen onderverdeeld worden in drie groepen:

• Financieel: de 'peen' het stimuleren van de adoptie door het faciliteren van het gebruik van de standaard. Voorbeelden van middelen zijn het geven van subsidie of het bieden van implementatie-instrumenten die de kosten van een implementatie verminderen.
• Communicatief: de 'preek' het geven van voorlichting over de voordelen die de standaard biedt voor organisaties. Bijvoorbeeld door het schrijven van artikelen of het organiseren van seminars.
• Juridisch: de 'zweep' het verplichten van het gebruik van een standaard. Bijvoorbeeld door de standaard op te nemen op de lijst met open standaarden voor 'pas toe of leg uit' van het Forum Standaardisatie.

Meestal is er niet één altijd passende strategie. De keuze zal afhangen van de bestaande en gewenste situatie en van tal van omgevingsfactoren. Adoptiemiddelen kunnen bijvoorbeeld verschillen in of afhangen van:

• de keuze voor de primair aan te spreken doelgroepen: alle gebruikers specifieke gebruikers, softwareleveranciers
• de middelen die worden ingezet: verleiding, contracten, wetgeving, commerciële dwang
• de aanpak: klein beginnen, of direct groot; eerste kleine groep, of direct de hele doelgroep; eerst een klein deel van de standaard en later meer
• de bestaande situatie in de doelgroep: Is gegevensverkeer daar al gemeengoed? Worden daar al oudere of andere standaarden gebruikt?
• de dominante voordelen die de standaard met zich mee moet brengen of het dominante probleem waarvoor zij een oplossing is: Waar vallen de grootste baten van de standaard? Waar de kosten? Wie voelt het meest de huidige beperkingen?
• intrinsieke aspecten van de standaard: Hoe complex is deze? Wat is zijn werkingsgebied? Welke kennis is nodig voor de toepassing ervan?

Voorbeelden van adoptiemiddelen:

• Informeren/adviseren.
  • Informatie-event organiseren.
  • Voorlichtingsdagen.
  • Presentatie op een congres.
  • Artikelen in magazines.
  • Advies over gebruik van de standaard.
• Betrekken en beïnvloeden.
  • Collectieve business case opstellen en verspreiden.
  • Documenteren cases.
  • Publiceren overzicht met gebruikers.
  • Open standaardisatieproces.
  • Oprichten klankbordgroep.
  • Community building.
  • Oprichten samenwerkingsplatform.
  • Afstemmen softwareleveranciers van gebruikers.
• Samenwerken en faciliteren.
  • Testbed voor implementatie van de standaard.
  • Uitvoeren van gezamenlijke pilots.
  • Plugfest organiseren.
  • Partnerschappen realiseren.
  • Validators.
  • Business case tool.
  • Referentie implementaties.
• Ontlasten en subsidiëren.
  • Subsidie voor invoering.
  • Financiering implementatie bij software leveranciers.
  • Opstellen van een specifiek plan van aanpak.
  • Het invoeren van een eigen implementatie die als 'broker' fungeert.
  • Certificering.
  • Gratis implementatie ondersteuning.
• Onderhandelen en contracteren.
  • Bestuurlijke verankering bij gebruikers.
  • Opstellen convenant.
  • Contract opstellen tussen sturende actor en ketenpartijen.
• Opdragen en verplichten.
  • Opleggen via de lijst met open standaarden voor 'pas toe of leg uit'.
  • Wettelijke dwang.

Stappenplan

We beschrijven vijf stappen om de juiste keuzes te kunnen maken voor adoptie in een bepaalde sector organisaties:

Stap 1: Geschiktheid

Er moet een goede 'match' zijn tussen de standaard en de vragen in de betreffende sector:

• Hoe groot is het interoperabiliteitsprobleem?
• Hoe complex is de aard van hun interacties?
• Sluit de standaard daar goed bij aan?

Adoptie kan alleen succesvol zijn indien er een voldoende match is.

Stap 2: Individuele business case

Vervolgens is het van belang te onderzoeken hoe de doelgroep er precies uit ziet:

• Welke partijen zijn betrokken?
• Hoe valt de business case bij hen uit?
• Hoeveel ruimte zit er in die business case voor verandering?
• Is er bijvoorbeeld een partij die een 'first mover' voordeel heeft?

Dit geeft een goed beeld van de business case per (soort) organisatie in het netwerk. Een sterkere individuele business case leidt tot een hogere individuele adoptiekans.

Stap 3: Collectieve analyse

Naast de individuele business case moet er ook gekeken worden naar de collectieve business case. Welk voordeel biedt de standaard voor het netwerk van organisaties als geheel?

Een sterke collectieve business case leidt tot een hogere collectieve adoptiekans.

Stap 4: Middelen keuze en planning

Vervolgens moet gekeken worden naar de middelen die passend zijn bij de individuele en collectieve adoptiekans.

Een hoge individuele adoptiekans leidt doorgaans tot een communicatief middel. Immers: de kans is hoe dan ook al groot dat een organisatie besluit tot adoptie van de standaard.

Een gemiddelde individuele adoptiekans leidt doorgaans tot een financieel middel. Er is een duwtje in de rug nodig om over te gaan tot adoptie van de standaard. Een lage individuele adoptiekans leidt doorgaans tot een juridisch middel. Zonder dwang zal een organisatie waarschijnlijk niet overgaan tot adoptie van de standaard.

Plugfest

Een zogenoemd 'plugfest' of 'plugtest' (ook wel 'connectathon' genoemd) is een adoptiemiddel op het gebied van samenwerken & faciliteren. De kern van een plugfest is om leveranciers die de standaard geïmplementeerd hebben bij elkaar te laten komen, en interoperabiliteit tussen de leveranciers/systemen ter plekke gaan testen aan de hand van scenario's.

Tijdens een plugfest wordt in een bijeenkomst de implementatie van een standaard getoetst door te onderzoeken of de door de standaard beoogde informatie-uitwisseling tot stand komt. Om dit te toetsen kunnen scenario's gebruikt worden. In deze scenario's worden stappen doorlopen die tijdens normaal dagelijks gebruik van de standaard ook worden doorlopen. De scenario's richten zich op de uitwisseling van informatie tussen applicaties.

Indien een scenario niet succesvol wordt doorlopen dan kan worden onderzocht waar dit aan ligt. Dit hoeft overigens niet altijd aan de implementatie van de standaard te liggen, maar kan ook andere oorzaken hebben die de interoperabiliteit in de weg staan. Indien mogelijk wordt het euvel ter plaatse verholpen waarna het scenario nogmaals doorlopen kan worden.

Vanuit een standaardisatie-organisatie bekeken kan het organiseren van een plugfest een positieve bijdrage leveren aan:

interoperabiliteit: plugfests bieden leveranciers die de standaard hebben geïmplementeerd de mogelijkheid de implementatie van die standaard te toetsen tegen andere implementaties van andere leveranciers. Eventuele fouten kunnen direct of in later stadium gecorrigeerd worden en onderdelen van de standaard die nog onvoldoende helder gespecificeerd blijken, komen op deze manier boven tafel.

transparantie: leveranciers weten na afloop van een plugfest met welke collegae zij kunnen samenwerken op basis van de standaard. Indien er publiek aanwezig is bij het plugfest dan krijgt dit een beeld van de wijze waarop verschillende leveranciers met de standaard omgaan en welke applicaties van leveranciers goed samenwerken.

adoptie: leveranciers kunnen zich onderscheiden door te participeren aan een plugfest. Door publiek uit te nodigen kan de standaard ook onder aandacht van eindgebruikers gebracht worden.

Een voorbeeld: plugfesten in de onderwijspraktijk

In het onderwijsveld is een plugfest georganiseerd rondom de digitale leermaterialen standaarden. Het plugfest werd door zowel leveranciers als door eindgebruikers goed bezocht. Voorafgaand aan het plugfest is nauw contact met participerende leveranciers onderhouden en is hen gevraagd alvast leermaterialen aan te leveren. Deze materialen zijn door Kennisnet vooraf getoetst en op basis van de resultaten kregen leveranciers een tweede mogelijkheid een verbeterd pakket met leermateriaal aan te leveren. De scores van de tweede toets zijn tijdens het evenement bekend gemaakt. Tijdens het plugfest zijn leveranciers in staat gesteld te laten zien hoe goed zij leermaterialen die in de standaard zijn opgeslagen kunnen gebruiken in hun software. Tegelijkertijd was er de mogelijkheid voor gebruikers om te kijken of hun eigen materiaal in verschillende applicaties van verschillende leveranciers werkte. Bijna alle leveranciers die de eerste keer meededen hebben ook de tweede keer geparticipeerd. Er zijn zelfs leveranciers bijgekomen. De winnaars van het plugfest namen de uitslag op in promotie-uitingen van hun bedrijf.

Leerpunten, aandachtspunten, do's and dont's

Kies: Een plugfest gericht op interoperabiliteit is een compleet ander plugfest dan die gericht op adoptie/transparantie. Een plugfest gericht op interoperabiliteit kan bijvoorbeeld besloten zijn, gericht op ondersteuning richting leveranciers, en passend in de vroege levensfase van een standaard. Een plugfest gericht op adoptie is zeer open, met publiciteit, gericht op transparantie en passend in een volwassen levensfase van een standaard. Een keuze is dan ook noodzakelijk.

Bepaal duidelijk wat en hoe getoetst wordt. Mogelijkerwijs is dit niet de gehele standaard, maar slecht onderdelen ervan. Communiceer de toetsingscriteria en het toetsingsproces.
Betrek leveranciers vroegtijdig; zij zijn de kern van een plugfest.
Creër winst voor leveranciers. Combineer bijvoorbeeld het plugfest met de mogelijkheid om hun producten te demonstreren aan eindgebruikers. Zorg eventueel voor aandacht in de media voor de standaard en voor de leveranciers.
Alle deelnemers zijn winnaars! Dit moet ook gecommuniceerd worden. Immers de deelnemers stellen zich kwetsbaar op en werken mee aan transparantie. Dat kan niet gezegd worden over de niet-deelnemers.
Geef leveranciers de kans zich goed voor te bereiden. Werk eventueel mee aan toetsingen van implementaties voorafgaand aan het plugfest via bijvoorbeeld andere validatietechnieken.
Zorg voor voldoende expertise tijdens het plugfest die kan helpen bij de implementatie van de standaard. Dit kunnen medewerkers van de standaardisatie-organisatie zijn, maar ook eventuele externe experts.
Het werken met een panel wordt ontraden, aangezien dit subjectieve scores oplevert en veel tijd kost in de voorbereiding.

Factoren voor adoptie

Een andere manier om te kijken naar de adoptie van een standaard is door te analyseren welke factoren bijdragen aan het adoptieproces. Bij ieder van deze factoren zijn er instrumenten die de adoptie kunnen verbeteren:

Relatieve voordelen dragen bij aan de adoptie van een standaard. Een organisatie heeft voordeel bij het gebruik van een standaard. Deze voordelen kunnen zichtbaarder gemaakt worden door:

• Voordelen te communiceren.
• Business cases te tonen.
• Best practices te ontwikkelen.

Hoge adoptie kosten hebben een negatieve invloed. Getracht kan worden deze kosten te verminderen. Bijvoorbeeld door:

• Subsidie te verlenen.
• Implementaties makkelijker te maken, bijvoorbeeld door hulpmiddelen beschikbaar te stellen.

Institutionele effecten hebben betrekking op afspraken vanuit de wet of in een sector, die een meer of minder verplichtend karakter hebben voor het gebruik van de standaard. Instrumenten zijn ondermeer:

• Contractuele afspraken maken met gebruikers.
• Opnemen in wettelijke afspraken of via de lijst voor 'pas toe of leg uit'.
• Andere juridische verplichtingen.

Een belangrijk, vaak vergeten factor is community ideologie. Een sterke community rondom een standaard kan bijdragen aan de adoptie. Door de community te versterken en zo mogelijke 'evangelisten' te zoeken kan de adoptie versterkt worden.

Een toenemend gebruik versterkt zichzelf vanwege netwerkeffecten. Dit kan daarom ook onderdeel uitmaken van de adoptiestrategie. Bijvoorbeeld door een grote organisatie te strikken die gebruik gaat maken van de standaard, door het organiseren van partnerships, gratis implementaties of het organiseren van een plugfest.

Adoptie binnen gebruikersorganisaties

Een standaardisatie-organisatie heeft doorgaans vooral een netwerkperspectief op de adoptie van hun open standaarden. Een ander perspectief is dat van een individuele organisatie. Deze individuele organisatie moet keuzes maken op het gebied van de te gebruiken standaarden. Sturingsmiddelen voor een organisatie om gericht te sturen op de adoptie van open standaarden zijn onder andere:

Compliance management: waarin een organisatie definieert hoe het met verplichte standaarden omgaat.
Het IT-beleid: waarin een organisatie de grote lijnen op het gebied ICT en open standaarden definieert. Architectuur management: de modellen en principes (waaronder de toe te passen standaarden) waaruit het ICT-landschap is opgebouwd.
Portfolio management: de kwaliteitscriteria van projecten, de inzet van middelen voor ICT-innovatie en vernieuwingsprojecten. Dit is bijvoorbeeld van belang voor het toekennen van middelen aan een migratie naar een bepaalde (nieuwe) open standaard.
Inkoop en leveranciersmanagement: de eisen die aan leveranciers worden gesteld.

Voor een standaardisatie-organisatie zijn dit aangrijpingspunten om de adoptie binnen een specifieke partij te stimuleren. Daar zit ook de samenhang met de adoptiemiddelen die een standaardisatie-organisatie kan inzetten. Bijvoorbeeld:

1. Door juridische middelen (pas toe of leg uit, opname in de wet) wordt een organisatie gedwongen om binnen het compliance managementproces te bepalen hoe een bepaalde standaard wordt ingebed.
2. Door voorbeelden te geven of referentiemodellen te bieden kan gestimuleerd worden dat een organisatie een standaard opneemt in de doelarchitectuur.
3. Via financiële middelen kan de migratie naar een standaard meer prioriteit krijgen in het portfolio management proces.
4. Tenslotte kan door bijvoorbeeld het bieden van modelbestekken de adoptie worden versneld op het gebied inkoop.

Kwaliteitsbeleid en benchmarking

Kwaliteit van standaarden

Veel organisaties streven naar interoperabiliteit, waarbij semantische standaarden een middel zijn om dit doel te behalen. De afgelopen jaren zijn dan ook vele semantische standaarden geïntroduceerd. Er is echter weinig bekend over de kwaliteit van semantische standaarden. Dat is opmerkelijk, want de kwaliteit van die standaarden is ongetwijfeld van invloed op de mate waarin het doel van interoperabiliteit behaald kan worden.

In tegenstelling tot andere disciplines, zoals software-engineering, is er weinig literatuur en kennis beschikbaar over wat een kwalitatief goede standaard is die een effectieve bijdrage levert aan interoperabiliteit. Dit definieert ook ons kwaliteitsbegrip: fitness for use! (definitie van kwaliteitsgoeroe Juran). Het overheidsbeleid richt zich voornamelijk op de openheid van een standaard, wat slechts één kwaliteitsaspect is. Een kwalitatief hoogwaardige standaard is ongetwijfeld een open standaard, maar het omgekeerde is niet noodzakelijkerwijs waar: een open standaard hoeft niet per definitie een kwalitatief hoogwaardige standaard te zijn. Overigens wordt in de toetsing van standaarden voor de 'pas-toe-of leg-uit lijst' van de Nederlandse overheid een sterke nadruk gelegd op de openheid, maar onderkent ook dat er meer kwaliteitsaspecten (bruikbaarheid, potentieel en impact) zijn die ook meegenomen worden in de toetsing voor opname op de lijst.

Semantische standaarden worden meestal door eigen organisaties ontwikkeld, en niet binnen grote standaardisatieorganisaties. Dit kan impact hebben op de kwaliteit; op zijn minst zal de kwaliteit daardoor sterk verschillen per semantische standaard.

Floricode heeft dit kwaliteitsinstrument toegepast om 1 van hun standaarden in de praktijk naar een hoger kwalitatief niveau te brengen. Het leverde een uitgebreide analyse op, waarvan 4 pagina’s aan verbetersuggesties. Sommige daarvan zijn strategischer van aard (bv. het transformeren van Floricode (voor deze standaard) van een loket voor technische oplossingen naar een bureau voor informatieoplossingen, gedreven door partijen in de sierteeltketen). Tot aan hele praktische en concrete verbeteringen, bijvoorbeeld voor de testomgeving (Maak checks in de test omgeving heel specifiek, geef duidelijk aan welke tests worden uitgevoerd en hoe de resultaten van het test center moeten worden geïnterpreteerd.) Al met al een waardevolle exercitie.

Wat vinden de standaardisatieorganisaties zelf van de kwaliteit?

Een onderzoek onder 37 beheerorganisaties van standaarden (waaronder internationale standaarden zoals XBRL, HR-XML, ACORD en HL7 en nationale standaarden zoals SETU, StUF en Aquo) laat zien dat meer dan 90 procent van de ondervraagde opstellers van standaarden vindt dat de kwaliteit van hun standaard verbeterd kan worden (zie onderstaande figuren). Daarnaast vindt ook een zeer ruime meerderheid dat een verbetering in kwaliteit van hun standaarden zal bijdragen aan betere interoperabiliteit.

Wat moet er dan gebeuren?

Ook laat het onderzoek zien dat de kwaliteit van een standaard essentieel is om het uiteindelijke doel van interoperabiliteit te behalen (meer dan 90 procent van de respondenten is die mening toegedaan). Minder overtuigend maar nog steeds zeer nadrukkelijk is de relatie tussen het kwaliteitsniveau en de kans op succesvolle adoptie van een standaard. Er is dus ruimte voor kwaliteitsverbeteringen die kunnen leiden tot betere interoperabiliteit en betere adoptie van de standaarden. Het is echter lastig de kwaliteit te verbeteren als de kwaliteit niet bekend is. De respondenten (meer dan 80 procent) willen een instrument gebruiken om de kwaliteit van hun standaarden te bepalen. Maar dan moet dit wel beschikbaar zijn.

Overigens laten de uitkomsten ook zien dat standaardisatieontwikkelaars zeker geneigd zijn om hoge kwaliteit na te streven en open te staan voor een kritische blik op hun werk door toepassing van een kwaliteitsinstrument. Een eventueel gebrek aan kwaliteit van een standaard heeft meerdere oorzaken, maar uit te sluiten valt de motivatie van de standaardisatieontwikkelaars. Eerder onderzoek heeft aangetoond dat juist bij semantische standaarden de ontwikkelaars intrinsiek gemotiveerd zijn; dat wil zeggen dat ze hun werk als hun hobby beschouwen.

Een grotere waarschijnlijkheid is de relatie tussen het budget en de kwaliteit van standaarden. Standaarden worden vaak met een miniem budget ontwikkeld wat ongetwijfeld consequenties heeft voor de kwaliteit, bijvoorbeeld doordat het budget op is de standaard wordt opgeleverd terwijl eigenlijk nog een ronde van review en verwerking een betere standaard zou opleveren.

Een andere mogelijke reden is het gebrek aan standaardisatie-expertise, aangezien het nog te weinig als 'vak' wordt gezien. Ook het polderen bij het standaardiseren met werkgroepen draagt niet positief bij. Regelmatig worden te veel opties in standaarden opgenomen om alle deelnemers in werkgroepen tegemoet te komen. Het resultaat is een te complexe standaard die in de praktijk slecht implementeerbaar is en leidt tot niet interoperabele implementaties die allemaal wel voldoen aan de standaard.

Het kwaliteitsinstrument

Hoe ziet zo’n instrument waarmee we de kwaliteit van een standaard inzichtelijk kunnen maken eruit? Een kwaliteitsinstrument voor standaarden is een complex onderwerp; dan moeten we ook weten; wat is een kwalitatief goede standaard? Welke kwaliteitsaspecten zijn van invloed, en hoe zijn die te meten? Maar ook over het onderwerp zelf: wat is een semantische standaard? Uit welke componenten bestaat een semantische standaard? Want daar zal de kwaliteitsthermometer in gestoken moeten worden. Het is noodzakelijk te weten hoe de kwaliteitsthermometer eruit kan zien, maar ook waar we hem in kunnen steken.

Het kwaliteitsmodel dat we in BOMOS aanreiken, is gebaseerd op het promotieonderzoek van Erwin Folmer. Het is specifiek gericht op semantische standaarden, maar leunt sterk op kwaliteits-onderzoek en standaarden op het gebied van software ontwikkeling; een domein waar veel kwaliteitsonderzoek heeft plaatsgevonden. Het kwaliteitsmodel is gevalideerd met experts en in verschillende situaties gebruikt.

Het kwaliteitsmodel zoals hier gepresenteerd is niet het volledige kwaliteitsmodel. Het volledige kwaliteitsmodel gaat nog een laag dieper met kwaliteitsconcepten, en geeft ook suggesties voor het uitvoeren van metingen, tot aan een procesmodel voor het gebruik van dit kwaliteitsmodel zodat het inzetbaar als instrument is. Het volledige kwaliteitsmodel (en instrument) is onderdeel van het proefschrift [[[folmer2012]]].

Het kwaliteitmodel

Het kwaliteitsmodel maakt een belangrijk onderscheid tussen productkwaliteit, proceskwaliteit en kwaliteit in gebruik. Productkwaliteit gaat over de producten/deliverables van het standaardisatieproces, en kan dan ook gemeten worden in de inhoud van die producten, met name het standaard specificatie document, maar bijvoorbeeld ook technische afgeleiden. Het is de intrinsieke kwaliteit van de standaard. Proceskwaliteit gaat allereerst over de totstandkoming van de standaard, en vervolgens over het beheerproces. Proceskwaliteit meet je in de beheerorganisatie van de standaard (veelal SDO (Standard Development Organization) of SSO (Standard Setting Organization) genoemd. Tot slot is het belangrijk te weten of de standard wel in de praktijk een implementeerbare en werkbare oplossing is, dat is onderdeel van kwaliteit in gebruik.

Deze driedelige structuur maakt de inzet van het model flexibel. Het is niet nodig het gehele model in te zetten, maar op basis van de vraag kan het relevante deel in het model gekozen worden. De volgende typische vragen zijn te beantwoorden met het respectievelijk genoemde deel van het kwaliteitsmodel:

1. Wat is de intrinsieke kwaliteit van de standaard? – Onderdeel A.
2. Wat is de implementeerbaarheid van de standaard? – Onderdeel A en B.
3. Wat is de duurzaamheid (toekomstvastheid) van de standaard? – Onderdeel B en A (deels).
4. Zou ik de standaard moeten selecteren? – Onderdeel C (voornamelijk).
5. Is de standaard een goede oplossing voor het interoperabiliteitsprobleem? – Alle onderdelen.

A. Productkwaliteit

Als we specifieker naar productkwaliteit gaan kijken, dan kunnen we in meer detail de volgende vragen mee beantwoorden:

1. Is de afgedekte functionaliteit van de standaard toepasselijk? – Heeft het de capaciteit om het interoperabiliteitsprobleem op te lossen?
2. Is de standaard stabiel? – Kan het geïmplementeerd en gebruikt worden zonder barrières?
3. Is de standaard duurzaam? – Is de standaard klaar voor de toekomst?

In onderstaande tabel zijn de eerste twee (van drie) decompositie lagen van productkwaliteit opgenomen, inclusief definities en toelichting. Het geeft al veel handvaten om de kwaliteit van een standaard mee onder de loep te nemen.

Measurable Concept	Definition	Remarks
A. Product Quality	The total attributes of a standard that determine its ability to satisfy stated and implied needs when used under specified conditions.	This includes both internal and external quality in ISO terms.
A1. Functionality	The capability of the standard to provide functions which meet stated and implied needs when the standard is used under specified conditions.	The specification fulfills the functional needs of the intended job.
A1.1 Completeness	The extent to which a standard is of sufficient breadth, depth, and scope for the task at hand.	This includes other terms like relevancy and suitability, and is the functional view on the content of the specification. The task at hand is aimed at solving an interoperability problem.
A1.2 Accuracy	The capability of the standard to provide true data with the needed degree of precision.	The level of needed specificity and precision in both semantic meaning and technical syntax. (This does not cover, but relates to, the quality of the content: consistency (A1.3))
A1.3 Consistency	The extent of consistency in using the same values (vocabulary control) and elements to convey similar concepts and meaning in a standard.	The degree of coherence and freedom of contradiction within the standard (ISO 25012). The quality of the content of the different models.
A1.4 Compliancy	The capability of the standard to adhere to other standards, conventions or regulations in laws, but also to define what compliancy implies for this standard.	The compliancy when other standards are implemented, and how the conformance to this standard can be assured.
A2. Usability	The capability of the standard has to be understood, learnt, used and attractive to the user, when used under specified conditions.	Also contains terms like implementability and readability, and is needed so as to estimate the efforts required for implementation.
A2.1 Understandability	The capability of the standard to enable the user to understand the standard for usage for particular tasks and conditions of use.	To enable it to be read and interpreted by users.
A2.2. Testability	The capability of the standard to be validated.	Intended to avoid faulty implementations.
A2.3 Openness	The implementation of open characteristics within the standard.	Includes "open specification".
A2.4 Complexity	The complexity of the technical solution proposed by the standard.	The complexity of the technical representation of the standard.
A3. Durability	The capability of the standard to have a long lasting life cycle; Connecting to current situations and future proofs.	Includes concepts like changeability and flexibility.
A3.1 Adaptability	The capability of the standard to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the considered standard.	Includes customizability.
A3.2 Maintainability	The capability of the standard to be modified in an efficient manner.	Modifications may include corrections, improvements or adaptation to changes in the environment, requirements or functional specifications. This also covers re-usability, replaceability and co-existence.
A3.3 Advancedness	The state of the art notion of the standard, in relation to current practice and future innovation.	Advancedness in relation to the outside environment in stakeholder organizations. Currentness: Fits the timeframe.

B. Proceskwaliteit

De meer gedetailleerde vragen die gerelateerd zijn aan proceskwaliteit zijn:

1. Is het Ontwikkel en Beheerproces professioneel georganiseerd?
2. Hoe wordt de standaard aangeboden aan de buitenwereld?
3. Hoe passend is de organisatie structuur bij de standaard?

In de volgende tabel zijn de eerste twee (van drie) decompositie lagen van proceskwaliteit opgenomen, inclusief definities en toelichting.

Measurable Concept	Definition	Remarks/Synonyms/Direction for measures
B. Process Quality	The quality of the sequence of interdependent and linked procedures that resulted in the standard.	Organizational quality.
B1. Development & Maintenance	The professionalism of how the standard development and the maintenance are organized.	This concept is based on BOMOS. [[[folmer2011]]]
B1.1 D&M Process	The capability of the D&M process to suit a standardization environment.	The D&M should guide developers in achieving quality.
B1.2 Versioning	The capability of the standard to have versioning in place that combines stability and the possibility to make changes.	Explicit version management is required to raise the appropriate expectations.
B2. Communication	The totality of communication activities related to the standard.	The presentation of the standard to the outside world.
B2.1 Support	The availability of knowledgeable support.	Support aimed at helping stakeholders with (the choice of) implementing the standard.
B2.2 Adoption Strategy	The availability of a promotion strategy to strive for successful adoption in practice.	Adoption will not go automatically but needs to be striven for.
B3. Organization	The capability of the organizational structure to effectively set standards.	Perhaps there is a network of organizations involved.
B3.1 Governance	The organization of decision making within the governance.	Relates to the openness of the standard.
B3.2 Fitness	The suitability of the development organization for the job.	The capability of the organization to support the standard appropriately.
B3.3 Financial	The capabilities to be financially neutral and stable for years to come.	Relates to the openness of the standard, and the adoption potential.

C. Kwaliteit in gebruik

Het specificatie document van de standaard kan een top kwaliteit hebben (productkwaliteit), de standaardisatie organisatie professioneel ingericht (proceskwaliteit), en toch kan de standaard in de praktijk niet het gewenste resultaat opleveren. Dat is wat het onderdeel kwaliteit in gebruik inzichtelijk wil maken.

Kwaliteit in gebruik wordt gemeten in de omgeving/context van de standaard: wordt het gebruikt, of heeft het die potentie, door de stakeholders. De twee meest prominente vragen:

1. Is de standaard geaccepteerd as oplossing in de praktijk?
2. Leidt het gebruik van de standaard ook tot interoperabiliteit in de praktijk?

Ook hier zijn in onderstaande tabel de eerste twee (van drie) decompositie lagen van kwaliteit in gebruik opgenomen, inclusief definities en toelichting.

Measurable Concept	Definition	Remarks/Synonyms
C. Quality in Practice	The extent to which a standard can be used by specified users to meet their needs to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. (ISO 14598)	Quality in use.
C1. Acceptance	The adoption of the standard within the domain.	Adoption/acceptance in practice.
C1.1 Solution Providers	The extent to which solutions providers have adopted the standard.	Solution providers provide products and service that are used by the end users. The adoption by solution providers is a multiplier for adoption.
C1.2 End Users	The extent to which the end users have adopted the standard.	The actual use of the standard.
C1.3 Recognition	The extent to which the standards receive external recognition.	The credibility.
C2. Interoperability	The ability of two or more systems or components to exchange information and to use the information that has been exchanged. (Legner & Lebreton, 2007)	The capability of the standard to achieve meaningful communication between systems.
C2.1 Maturity	The capability of the standard to be a stable and proven solution.	A mature standard will positively influence interoperability.
C2.2 Correctness	Extent to which an implementation of a standard satisfies its specifications and fulfills the user's mission objectives. (McCall et al., 1977)	Also called "Free of Error".
C2.3 Cost & Benefits	The extent to which the benefits cover the costs of standardization.	Although not necessary for all stakeholders, the total use of the standard should have a positive business case.

Het kwaliteitsinstrument gebruiken

De relatie tussen interoperabiliteit en standaarden is die van doel-middel. Zonder het kwaliteitsaspect in ogenschouw te nemen worden standaarden te veel gezien als heilige graal. De standaard wordt het doel, in plaats van een middel om op een effectieve en efficiënte manier interoperabiliteit te bereiken. Een aandachtsverschuiving naar de kwaliteit van standaarden voorkomt dat standaarden een doel op zich worden en zal de relatie tussen standaarden en interoperabiliteit versterken.

Dit kwaliteitsmodel, in onderstaand figuur samengevat kan daarvoor een bruikbaar hulpmiddel zijn. Bij toepassing is het sterk aan te raden om het complete instrument te bestuderen [[[folmer2012]]], en zelfs te overwegen om een maatwerk instrument te maken door slechts een selectie uit het kwaliteitsmodel mee te nemen.

Het kwaliteitsmodel is een startpunt om te gebruiken om de kwaliteit van een standaard te bekijken. Maar het moet wel kosteneffectief worden ingezet. In veel gevallen is het gewenst dat een kwaliteitsmeting in enkele uren uitgevoerd kan worden. In dat geval zijn de kosten vrij beperkt, en zullen de opbrengsten de kosten al snel overtreffen.

Inzet van het kwaliteitsmodel kan ook heel geschikt zijn als zelf-evaluatie door de standaardisatie-ontwikkelaar die de eigen standaard goed kent en het model als denkkader kan gebruiken om de eigen standaard mee te analyseren. Immers het kwaliteitsmodel is niet bedoeld om goed/fout aan te geven, maar puur bedoelt om mogelijke verbeteringen te identificeren.

Wat zou het gebruik van het kwaliteitsinstrument voor standaarden kunnen opleveren. Kort samengevat:

• een model om naar de standaard te kijken: een frisse blik / inzicht in wat van invloed is op de kwaliteit van een standaard.
• ideeën voor verbetering van de standaard.
• ideeën voor aanpassingen in het standaardisatieproces.

Het helpt de standaardisatieontwikkelaar om met een frisse blik naar de standaard te kijken en daarbij een gevoel te krijgen hoe de kwaliteit te beïnvloeden is. Gedurende het gebruik zal de standaardisatieontwikkelaar ideeën ontwikkelen hoe de standaard te verbeteren is of mogelijkheden zien om het standaardisatieproces te veranderen om een hogere kwaliteit te bereiken.

In de complete vorm is het kwaliteitsinstrument een meetinstrument (zoals een thermometer) voor standaarden, dat wil zeggen een compleet gereedschap inclusief 'tool' en 'gebruikshandleiding'. Maar ook alleen het kwaliteitsmodel, met een stevig fundament, kan als 'bril' worden gebruikt om standaarden in de praktijk mee te toetsen.

Kwaliteit van implementaties

De kwaliteit van de standaard kan nog zo goed zijn, als de kwaliteit van de implementaties achterblijft wordt er ook geen interoperabiliteit bereikt. Deze sectie gaat in op mogelijke vormen certificering, compliancy testing, validatie, en andere vormen van toetsen van het toepassen van de standaard, met daarbij eventueel een beloning. Certificering hanteren we als containerbegrip voor alle vormen hiervan.

Nadat de standaard is ontwikkeld en in enige mate is geadopteerd in de markt komt nagenoeg altijd de certificeringsvraag wel boven drijven. Soms zijn het leveranciers, als early adopters van de standaard die zich graag in de markt door middel van een stempel positief willen onderscheiden (oftewel: ze willen graag return op hun investment als early adopter). En soms blijken in de praktijk implementaties niet interoperabel te zijn wat de vraag van certificering om interoperabiliteit te garanderen oproept. Deze verschillen laten al zien dat certificering verschillend ingezet kan worden om simpelweg verschillende vragen in te vullen.

Doel van certificeren

Vanuit een standaardisatie-organisatie bekeken kan certificering een positieve bijdrage leveren aan:

Interoperabiliteit en transparantie. Indien het correct gebruiken van de standaard gemarkeerd wordt met een certificaat zal het voor organisaties eenvoudiger zijn om samenwerkingspartners te vinden met wie men interoperabel is.

Adoptie bevorderen. Early adopters de kans geven zich er positief mee te onderscheiden. Voor leveranciers kan het noodzaak worden om een certificaat te verkrijgen omdat ze anders buiten de markt vallen. Certificaat kan dan bijvoorbeeld gevraagd worden in aanbestedingen.

Financieën. Certificering kan ingezet worden als potentiële bron van inkomsten om het beheer van standaarden te financieren. Uitgangspunt hierbij is gebruikers van de standaard betalen voor de ontwikkeling hiervan.

Dit zijn verschillende doelstellingen die niet altijd verenigbaar zijn: bijvoorbeeld de uitvoering van een interoperabiliteitscertificaat zal grondiger uitgevoerd moeten worden dan een adoptie-certificaat. Dat betekent dat de kosten voor uitvoering hoger zullen liggen waardoor er minder 'winst' gemaakt kan worden op het certificaat, en daardoor een kleinere bijdrage voor de financiën van een standaardisatie-organisatie zal opleveren, en eerder kosten-neutraal zal zijn.

Samenvattend kan certificering ingezet worden als:

• Interoperabiliteits-instrument
• Adoptie-instrument
• Financieel instrument

Wie of wat kan worden gecertificeerd?

Bij een certificeringtraject is er altijd iets of iemand dat gecertificeerd wordt. Dit kan een natuurlijk persoon, een organisatie, een implementatie-proces, een product of zelfs een project zijn. Er moet echter wel een keus gemaakt worden, het is niet mogelijk om hetzelfde certificaat uit te reiken aan (bijvoorbeeld) zowel een persoon als een pakket.

Organisatie: Een organisatie kan gecertificeerd worden indien de organisatie zich bijvoorbeeld gecommitteerd heeft aan bepaalde afspraken, zoals de implementatie van de standaard voor een bepaalde datum, of een hoeveelheid van implementaties. Daarnaast kan een organisatie certificaat ook als kapstok certificaat dienen. Bijvoorbeeld een organisatiecertificaat wordt uitgedeeld als er een minimale hoeveelheid aan implementaties van de standaard in projecten, producten, personen of processen heeft plaatsgevonden.

Natuurlijke personen: Een persoon kan gecertificeerd worden op basis van zijn kennis en expertise, bijvoorbeeld door het volgen en succesvol afronden van een opleiding, of door het (aantoonbaar) uitvoeren van een hoeveelheid aan projecten met de standaard.

Projecten: Semantische standaarden worden vaak ingezet in de uitwisseling van informatie. Een project tussen twee (of meer organisaties), waarin eventueel ook producten worden ingezet, kan dan gecertificeerd worden.

Producten: Voor veel standaarden is het cruciaal dat de standaard is geïmplementeerd in producten en diensten die aangeboden worden op de markt. Door aanschaf van een gecertificeerd product kan een organisatie eenvoudig gebruik maken van de standaard.

Implementatieproces: Als het proces (de aanpak) gecertificeerd is dan geeft dat vertrouwen in het resultaat van dat proces. In het geval bij standaardisatie zou een projectaanpak voor gebruik van de standaard in projecten kunnen certificeren, wat vertrouwen geeft dat het projectresultaat een succesvolle implementatie van de standaard bevat.

Opleidingsmateriaal: Als de opleiding, of het opleidingsmateriaal, is gecertificeerd dan geeft dat vertrouwen in de kennis die wordt verkregen om op basis daarvan een project te kunnen uitvoeren.

Bij het toekennen van het certificaat hoort meestal het gebruik maken van een logo dat door de beheerorganisatie wordt uitgegeven. Openheid en het voorkomen van intellectueel eigendomsrecht betekent niet dat er geen beschermd logo gebruikt mag worden. Uiteraard staat dat openheid niet in de weg.

Waarop kan worden gecertificeerd?

Er bestaat een spanningsveld tussen het aantal soorten certificaten dat uitgereikt wordt en omvang van gestelde eisen per certificaat. Enerzijds is het wenselijk om het aantal soorten certificaten beperkt te houden, dit om te voorkomen dat een organisatie vele certificeringtrajecten moet doorlopen (bovendien daalt de 'waarde' van een certificaat bij een toenemend aantal soorten). Anderzijds is het niet wenselijk dat een organisatie alle onderdelen van de te ontwikkelen standaarden moet kunnen ondersteunen om gecertificeerd te kunnen worden. Een algemeen certificaat kan weinig zeggend zijn, terwijl bij twintig specifieke certificaten niemand er meer iets van begrijpt.

In de meeste situaties bestaat een semantische standaard uit een familie van standaarden. Een afweging die gemaakt moet worden is op welk niveau de certificering wordt ingevoerd: voor de gehele set of voor een deel functionaliteit (vaak: de standaard). Daarbij moet ook bedacht worden dat ieder versienummer van een standaard dan een certificaat krijgt: het aantal explodeert al snel.

Een grote hoeveelheid aan certificaten is niet verstandig als adoptie het doelstelling is voor certificering aangezien de herkenbaarheid en waarde van het certificaat dan afneemt. Daarnaast moet er ook een stimulans zijn om bijvoorbeeld een nieuwe versie te implementeren, bijvoorbeeld door de uitgifte van een nieuw certificaat. Een deel van de oplossing om bijvoorbeeld de hoeveelheid certificaten een halt toe te roepen, is een bepaalde geldigheidsduur van het certificaat. Bijvoorbeeld in plaats van SETU timecard v1.2 certificaat uit te geven, zou SETU timecard 2020 certificaat (waarin is aangegeven dat SETU timecard v.1.2 de versie van de standaard is) een alternatief kunnen zijn dat zijn waarde verliest in 2021 of 2022. Hiermee wordt de versieproblematiek ondervangen.

Overigens is er een gevaar van doorschieten: bijvoorbeeld als er nieuwe versies van een standaard uitgebracht moeten worden om de financiën van de beheerorganisatie op orde te brengen.

Wie geeft het certificaat uit en wie doet de toetsing?

Voor het uitgeven van het certificaat zijn er logische kandidaten: de standaardisatie-beheer organisatie, de branche-organisatie, formele standaardisatieorganisaties (NEN), onafhankelijke kennisinstellingen (zoals bv. TNO), certificeringsinstellingen (bv. DNV) of andere belangenbehartigers. Er is een belangrijk onderscheid tussen de toetser en de uitgever. Beide rollen kan bij dezelfde partij zijn belegd, maar kan ook opgedeeld worden tussen verschillende partijen wat een onafhankelijkheid en betrouwbaarheid waarborgt. Dat laatste verdient de aanbeveling want de betrouwbaarheid van een certificaat is van groot belang. De uitgever heeft eindverantwoordelijkheid en geeft de certificaten uit, en stelt het toetsingskader op. De uitvoering van de toets (op basis van het toetsingskader) kan dan door een andere en zelfs meerdere partijen worden uitgevoerd. Het stelt wel eisen aan het toetsingskader, immers onafhankelijk van de toetser zou het resultaat van de toets gelijk moeten zijn.

In veel gevallen zou de uitgever en opsteller van het toetsingskader de standaard beheerorganisatie kunnen zijn al dan niet in samenwerking met de branche-organisatie. De uitvoering kan dan belegd worden bij een onafhankelijke kennisinstelling, certificeringsorganisatie, of bij meerdere consultancybureaus. Als de toetsing licht van aard is, dan is de splitsing minder logisch.

Scheiding tussen uitgever en toetser draagt bij aan de onafhankelijkheid van de toetsing en indien fixed-price afspraken gemaakt kunnen worden over de kosten van een toetsing wordt tevens het (financieel) risico voor de standaardisatie-organisatie beperkt. Keuzes kunnen nog gemaakt worden wie het aanspreekpunt is, waar de aanvraag tot certificeren wordt ingediend, gebruik van certificaat/logo en ondermeer een klachtenprocedure.

Het pakket van eisen is de publieke versie van het toetsingskader, en geeft aan de certificatieaanvrager aan waarin de implementatie moet voldoen. Het toetsingskader is niet publiek beschikbaar en geeft aan hoe de meting/ beoordeling plaatsvindt.

Daarnaast moet er een beroepsprocedure zijn met een partij als aanspreekpunt indien er een meningsverschil is over de al dan niet toekenning van een certificaat.

Waarop wordt getoetst?

Conformance aan een standaard is niet triviaal. Veel semantische standaarden zijn uitgedrukt in XML Schema. Om uitspraken over conformance te doen is het niet voldoende om te controleren of de XML instantie technisch valideert ten opzichte van het XML Schema. Dit laatste is technisch prima uit te voeren (ook al moeten er wel meerdere XML schema validators gebruikt worden voor goede resultaten), maar zegt niks over de vraag of de juiste informatie ook op de juiste plek is ingevuld. Immers als Amsterdam de waarde is van het element 'Achternaam' en 'Jansen' de waarde van het element 'Woonplaats', dan zal dit technisch prima valideren (tenzij woonplaats een waarde moet bevatten uit een lijst), maar toch voldoet het hoogstwaarschijnlijk niet aan de standaard. Deze semantische validatie is lastig uit te voeren. Voorgaand voorbeeld was misschien helder, maar stel dat het zou gaan om de elementen 'geboorteplaats' en 'woonplaats', dan is correct gebruik niet te controleren zonder bewijsstukken of iets dergelijks. Nu JSON dominant als uitwisselingsformaat defacto standaard is geworden kan validatie plaatsvinden door middel van SHACL validatieregels.

De kwaliteit van gemeentelijke data op het gebied van stedelijk water en de daarvoor benodigde infrastructuur is een belangrijk aandachtpunt in het vakgebied. Bronhouders kunnen de basiskwaliteit van een rioleringsbestand controleren ten opzichte van in het Gegevenswoordenboek Stedelijk Water vastgelegde conformiteitsklassen (elke toepassing heeft eigen eisen). De generieke applicatie Nulmeting is vrij beschikbaar op de GWSW-server. Aangezien rioleringsgegevens conform de GWSW-standaard in RDF (linked data) uitgedrukt zijn, vindt de kwaliteitsmeting plaats met behulp van SHACL (Shapes Constraint Language).

Daarnaast is verschil in harde (onbetwistbare en betekenisvol op het gebied van interoperabiliteit) toetsing en zachte toetsing (betwistbaar of betekenisloos op het gebied van interoperabiliteit.) Bijvoorbeeld een zachte toetsing is de belofte van een organisatie om de standaard te implementeren door ondertekening van een convenant: dit is niet betwistbaar (convenant is wel/ niet ondertekend), maar betekent op dit moment niet veel op het gebied van interoperabiliteit. Het moge duidelijk zijn dat zachte toetsing relatief eenvoudig is en harde toetsing complexer.

De exacte invulling van de toetsingsprocedure (het toetsingskader) en de aspecten waarop getoetst zal worden (pakket van eisen) moet ingevuld worden en is situatieafhankelijk. We stellen wel een aantal uitgangspunten voor:

• De toets moet zo objectief ('hard') mogelijk zodat bij certificeringtrajecten eenduidig aangetoond kan worden waarom een partij wel of juist niet gecertificeerd wordt. Dit voorkomt onnodige discussies en risico's. Bovendien kan alleen getoetst worden op zaken die ook vastgelegd zijn in de standaard (of het pakket van eisen).
• Naast de structuur van berichten (syntax) is het wenselijk om de inhoud van berichten te controleren. Dit kan deels door gebruik te maken van in de standaard vastgelegde 'business rules'. Ook is het in sommige gevallen wenselijk om de samenhang tussen berichten te toetsen.

Personen zijn bijvoorbeeld eenvoudiger toetsbaar op basis van een examen. Organisaties zijn eenvoudig toetsbaar op intenties en beloftes. Het proces is ook relatief eenvoudig toetsbaar, maar bij projecten, producten en organisaties (anders dan op intenties) wordt het complex.

Andere variaties zijn er op het gebied dat voor een organisatie-certificaat bijvoorbeeld de organisatie alleen de standaard mag gebruiken (en geen alternatieven), of in een aantal (percentage) gevallen de standaard inzet, of minimaal één geval (dan is men 'in staat').

Sommige certificaten vereisen dat er een aantal instanties (voorbeelden) worden ingeleverd die vervolgens worden gevalideerd. Uiteraard moet er dan nagedacht worden over wat een goede hoeveelheid voorbeelden is, en daarnaast moet men zich wel realiseren dat men de bron van de voorbeelden niet kan garanderen: bijvoorbeeld misschien komen ze wel niet uit het te certificeren systeem, maar zijn ze met de hand aangemaakt.

Hulpmiddel voor keuzes rond certificaten

In deze sectie is tot nu laten zien dat certificering complex is, en er meerdere keuzes gemaakt kunnen worden.

De figuur laat vrij eenvoudig zien dat doelstellingen rond adoptie en financiën in enige mate te combineren zijn, maar dat met name een interoperabiliteit doelstelling een andere invulling van certificering nodig maakt in vergelijking met de andere doelstellingen.

Andere vormen van certificering

Een voor- maar ook nadeel van certificering is de impact die het heeft op de markt. Dit houdt in dat rekening gehouden moet worden met juridische zaken (bijvoorbeeld een leverancier die de beheerorganisatie gaat aanklagen omdat het ook een certificaat wil), maar ook dat beheerorganisatie zijn onafhankelijkheid en daardoor draagvlak verliest. Of als opmaat, of om geen risico's te nemen wordt er vaak gebruik gemaakt van een alternatief. Naast certificering is er validatie. In feite is certificering het geven van een stempel na succesvolle validatie. Echter als het certificeringdoel wegvalt kunnen er lagere eisen gesteld worden aan validatie. Ondanks het wegvallen van het 'stempel' kan validatie toch deels voor dezelfde doelstellingen gebruikt worden:

Interoperabiliteit: In principe kan dezelfde test voor certificatie ook als validatie worden uitgevoerd, maar dan zonder stempel.
Financiën: Ook voor een service gericht op validatie kan geld gevraagd worden. Echter dat zal nooit veel meer zijn dan de daadwerkelijke kosten van validatie, waarmee het geen cash cow zal worden.
Adoptie: Het beschikbaar hebben van een helpdesk waarin validatie vragen gesteld kunnen worden helpt de adoptie. Echter certificering zal een veel groter effect hebben op de adoptie.

Vooral de interoperabiliteit doelstelling is prima te realiseren met validatie, en wordt door veel beheerorganisaties al ingezet. Tooling is hiervoor laagdrempelig beschikbaar.

Met een plugfest wordt interoperabiliteit in de keten getoond door te laten zien dat de samenwerking tussen meerdere systemen werkt die aan elkaar geplugd zijn. Een plugfest met adoptie doelstelling is een openbare demonstratie van interoperabiliteit door meerdere leveranciers, en is ook een vorm van publieke validatie waarbij de resultaten een vorm van certificering zijn; immers de winnaar zal de winst gaan uitdragen in commerciële uitingen. Zowel certificering als plugfest hebben als doel transparantie richting de markt, om de markt in beweging te brengen. Maar een plugfest kan ook gebruikt worden voor een interoperabiliteit doelstelling, daarmee krijgt het plugfest een besloten karakter en worden de resultaten niet gepubliceerd. Voor meer informatie over plugfests zie sectie Plugfest.

Validatie kijkt ook naar individuele systemen maar dan zonder doel van transparantie van de markt maar als doel ondersteuning richting organisaties en projecten. Tot slot kunnen er pilot projects gestart worden om interoperabiliteit in de keten te testen.

Validatie

De meeste beheerorganisaties bieden hulpmiddelen voor het valideren van het gebruik van standaarden, zoals:

• Geonovum:
  Validatie services van Geonovum

• Kennisnet:
  Edustandaard Testvoorziening

• SETU:
  SETU Support tool
  (alleen toegankelijk voor deelnemers in SETU).

Overigens is de techniek die validatie van semantische standaarden mogelijk maakt zeer generiek.

Overigens zou het dus goed mogelijk zijn om validatie te gebruiken voor de interoperabiliteit doelstelling, en daarnaast op een andere manier certificatie in te richten voor adoptie of financiële doelstellingen. De volgende tabel laat zien waar de verschillende concepten voor gebruikt kunnen worden.

Middel	Wanneer geschikt	Risico/Inspanning/Opbrengst
Certificeren	De markt moet gaan bewegen.	Risico: Hoog
	Ervaring is opgedaan met validatie.	Inspanning: Hoog
	Partijen zijn die compliancy claimen, maar het mogelijkerwijs niet zijn.	Opbrengst: Continu
Plugfest (adoptie-doelstelling)	Als adoptie redelijk gaat, maar nog een paar partijen achterblijven.	Risico: Middel
	Bij een relatief nieuwe standaard.	Inspanning: Middel
		Opbrengst: Eenmalig
Validatie-service / Helpdesk	De markt continu wil ondersteunen.	Risico: Laag
	De kwaliteit van de implementaties wilt gaan verhogen.	Inspanning: Middel
		Opbrengst: Continu
Plugfest (interoperabiliteit-doelstelling)	De markt wil ondersteunen.	Risico: Laag
	Een beeld krijgen of de standaard in de praktijk voldoet en hoe die gebruikt wordt.	Inspanning: Middel
		Opbrengst: Eenmalig
Pilot ondersteuning	Eerste oefeningen met de standaard.	Risico: Laag
	Nog mogelijkheden zijn om de standaard aan te passen.	Inspanning: Laag
	Belangrijk project, als voorloper voor andere projecten.	Opbrengst: Eenmalig

De praktijk

Terwijl validatie zeer gebruikelijk is geldt dit zeker niet voor certificatie. Over het algemeen wordt dit als 'gevaarlijk' gezien, en zou alleen toegepast moeten worden als het zeer zorgvuldig is ingericht. Het betekent immers nogal wat: een leverancier die het certificaat niet krijgt kan daarmee nadelige gevolgen ondervinden in de markt. De leverancier kan overgaan tot rechtszaken om het certificaat te bemachtigen. Dat leidt tot kosten voor de beheerorganisatie en negatieve publiciteit. Daarnaast is de standaardisatieorganisatie in veel gevallen afhankelijk van de kennis van leveranciers in de werkgroepen voor de totstandkoming van de standaard. Mogelijkerwijs staakt de leverancier ook de medewerking aan de werkgroep. De standaardisatieorganisatie kan zijn neutraliteit verliezen, wat schadelijk is voor adoptie en verdere ontwikkeling van de standaard.

Daardoor zijn er meerdere semantische standaardisatieorganisaties die certificering overwogen hebben, maar tot op heden wordt certificering weinig toegepast.

Een ondersteunende service die bijdraagt aan het correct implementeren van een berichtenstandaard, data service of andere vorm van data API is bieden van een validatieomgeving voor eindgebruikers en software ontwikkelaars. Een dergelijke validator biedt de mogelijkheid om per versie van een berichtstandaard een automatische validatie te configureren. Voor een XML-implementatie gaat dat om een check op de XML-syntax, een check op het XML-schema (XSD) en controle van de set van validatieregels uitgedrukt in schematron. Software ontwikkelaars kunnen grotendeels zelf uit de voeten met het gebruik van de validator en op technisch vlak hoeft de standaarden-organisatie alleen nog vragen te beantwoorden in probleemgevallen of bij onduidelijkheden. Dat is van meerwaarde voor de gebruiker én scheelt de beheerorganisatie tijd. Ook fungeert een geautomatiseerde validatie als scheidsrechter wanneer partijen verschil van mening hebben over interpretatie van de standaard.

Dat validatie in dienst kan staan voor certificatie laat Ketenstandaard zien. Deze stichting in de bouw- en installatiebranche beheert standaarden voor alle fasen van het bouwproces. Zij maken daarbij gebruik van Semantic Treehouse, de op BOMOS gebaseerde beheeromgeving ontwikkeld door TNO. Ketenstandaard biedt via deze omgeving een validatietool aan haar gebruikers waarmee zij kunnen laten zien dat hun berichten aan de standaard voldoen. In dat geval wordt het bedrijf waar die gebruiker actief is opgenomen in een certificatenoverzicht op datakwaliteit.nu, en kan de gebruiker een certificaat-label downloaden om te plaatsen op de bedrijfswebsite. Zo kunnen leveranciers en klanten van elkaar zien met wie er op een gestandaardiseerde manier data is te delen.