Op 17 maart 2011 had ik samen met collega's mijn eerste SETU-overleg. Op dat moment ben ik twee maanden werkzaam bij TNO, net afgestudeerd en een groentje als het gaat over data-delen. Aangenomen als junior adviseur IT-governance, was mijn betrokkenheid bij het SETU-project bedoeld als een klein uitstapje waar ik mijn adviesvaardigheden kon ontwikkelen. Nietsvermoedend dat het onderwerp data-delen en data-standaarden de rode draad en mijn expertise zouden worden in de ruim 10 jaar die volgden.
Berichtstandaardisatie
In een periode van 6 maanden ontwikkelden we voor SETU, samen met uitzenders, softwareleveranciers én jobboards een gestandaardiseerd berichtmodel voor het uitwisselen van vacatures. SETU kende op dat moment al standaarden voor een Order, Timecard en Factuur. Aan ons, het TNO-team, de taak om het proces te faciliteren en met onze kennis en expertise te komen tot een werkbare en gedragen specificatie van een vacature.
De pressure cooker methode
Dit standaardisatie proces moet sneller kunnen. We ontwikkelden de pressure cooker methode om in één week tijd te komen tot een 1.0 versie van de benodigde standaard die zo'n 90% van de functionaliteiten moet bevatten. Deze methode pasten we voor het eerst toe voor de ontwikkeling van de STOSAG-standaard, een set van technische én berichtstandaarden voor de afvalinzamelingsbranche.
De totale doorlooptijd van de pressure cooker methode betreft zo'n 3 maanden:
- In de eerste maand verzamelen we zoveel mogelijk input, voorbeelden en aanvullende documentatie zodat het projectteam zich kan inwerken in het domein. Mijn ervaring is dat het veel inlevingsvermogen vergt om in zo'n korte tijd de benodigde domeinkennis eigen te maken. Elke sector heeft zijn eigen taal en werkelijkheid die voor ons als buitenstaander soms vreemd overkomt.
- In de tweede maand bereiden we de pressure cooker week voor. We versturen de uitnodigingen, regelen de locatie en faciliteiten en maken een "draaiboek" voor de week. Welke (deel)onderwerpen behandelen we eerst? Welke werkvorm kiezen we? Hoe leggen we de resultaten vast?
- De derde maand begint met de intensieve pressure cooker week zelf. Zo'n 10 tot 15 domein experts, van verschillende bedrijven met verschillende rollen hebben hun agenda leeggeveegd om samen te werken aan de standaard. Doel: we gaan pas naar huis als het af is.
In 2014 begeleide ik samen een collega de pressure cooker waarin we de TLN Papierloos Transport standaarden opzetten. De scope bestond uit een elektronische transportopdracht, vrachtbrief én factuur. De vrachtbriefspecificatie is in de jaren daarna doorontwikkeld en vormde de basis voor de digitale vrachtbrief van Beurtvaartadres.
Niet opnieuw het wiel uitvinden
Maar nadat de berichtstandaard gespecificeerd is, is deze nog niet geïmplementeerd in de IT-systemen van betrokken organisaties. Ook hier vroegen we ons af of dit sneller en eenvoudiger zou kunnen. De gedachte: we willen zoveel mogelijk aansluiten op reeds bestaande standaarden om hergebruik van implementaties te bevorderen.
Zo ontwikkelden we de meeste specificaties als een profiel op een (internationale) bestaande standaard. Een profiel is een inperking of invulling voor de toepassing in een specifieke situatie. Bijvoorbeeld: de SETU Timecard is een profiel op de internationale HR-XML standaard voor de Nederlandse uitzendbranche; de Elektronische Begeleidingsbrief Afval (EBA) is een profiel op de UBL Waybill voor afvaltransport; en ook de in 2019 gepubliceerde Europese norm voor e-factureren is een profiel op de UBL Invoice en de UN/CEFACT Invoice.
Een profiel biedt o.a. de mogelijkheid om aan nationale wet- en regelgeving te voldoen en sectorspecifieke eisen en functionaliteiten te ondersteunen. Zo is voor de EBA het afvalstroomnummer een verplicht veld omdat deze informatie vanwege wetgeving gespecificeerd moet worden op de vrachtbrief.
Keerzijde van generieke standaarden
Er zit echter ook een keerzijde aan het maken van genoemde profielen op bestaande (internationale) berichtstandaarden. De standaarden (zoals bijvoorbeeld UBL) bestaan soms uit wel honderden, veelal optionele velden in complexe structuren. Terwijl voor een specifieke toepassing bijvoorbeeld slechts 10 datavelden nodig zijn. Daarnaast bieden deze standaarden wel mogelijkheden voor toepassingsspecifieke uitbreidingen, ook wel extensies genoemd, echter leidt dit vaak niet tot elegante en begrijpbare berichtenmodellen. Daarbij komt dat de doorontwikkeling van deze internationale standaarden veelal veel te lang duurt; al gauw enkele jaren. Een gevolg van de generieke opzet, het willen ondersteunen van te veel verschillende (bedrijfs)processen en de internationale consensus die vereist is voor besluitvorming.
Software ontwikkelaars klagen dan ook regelmatig over te complexe structuren, verouderde protocollen en traagheid in het doorvoeren van wijzigingsverzoeken. Terechte kritiek, maar wel de consequentie van de keuze tot hergebruik. Het geoogde hergebruik in software implementaties bleef echter vaak uit. In de praktijk blijven bedrijven hun eigen interne data structuur hanteren en wordt elke berichtstandaard als losstandaande mapping op het interne datamodel geimplementeerd.
De complexiteit gecombineerd met het uitblijven van de herbruikbbaarheid van implementatiess, heeft mij doen realiseren dat het adopteren van internationale berichtstandaarden een dood spoor is voor veel toepassingen. Mijn advies is dan ook: doe dit niet (meer).
...maar hoe dan wel?
Geen generieke berichtenstandaarden dus. Maar hoe dan wel?
In de afgelopen jaren hebben we ervaring opgedaan met ontology driven API design. In de kern komt dit erop neer om gebruikmakend van bestaande domeinmodellen (ontologieën) berichtspecificatie samen te stellen die voorzien in de informatiebehoefte van een specifieke use-case. Voor elke use-case wordt dus een apart berichtmodel gespecificeerd in plaats van elke use-case te mappen als profiel op een generiek berichtmodel. Hiermee wordt het mogelijk om een zo klein en strict mogelijke specificatie op te stellen die voorziet in de informatiebehoefte; niet meer, niet minder. De semantisch interoperabiliteit blijft gewaarborgd omdat de berichtmodellen worden samengesteld uit beschikbare relaties en attributen uit het domeinmodel. De berichtmodellen kunnen worden gebruik in de request- en response body van API specificaties.
Om deze aanpak met tooling te ondersteunen hebben we een wizard ontwikkeld als geintegreerd onderdeel van Semantic Treehouse. Daarover later meer in een volgend artikel.
Enkele voorbeelden van use-case specifieke data-uitwisselingsstandaarden die gebasseerd zijn op een onderliggend datamodel:
- Het Open Trip Model (OTM) voor data delen in de logistieke keten;
- De DICO standaard voor bouw en techniek sector;
- De VERA standaard voor de woningcorporatie sector;
- De SETU planning APIs (WIP) die ontwikkeld worden op basis van HR Open en SETU datamodellen.
Lessen geleerd
Simpelgezegd komt dat neer op:
- Verkies eenvoud boven hergebruik;
- Verkies snelheid boven compleetheid;
- Definieer een generiek data model (ontologie) waaruit berichtmodellen samengesteld worden;
- Definieer één berichtmodel per specifieke toepassing/use-case/API endpoint;
- Definieer zoveel mogelijk verplichte velden i.p.v. bijna alles optioneel;
- Maak hergebruik van bestaande, in de praktijk gebruikte, ontologieën.