Informatie-uitwisseling in de keten: zorgen dat je elkaars taal verstaat Brian Dommisse
1 Voorwoord In dit artikel van Brian Dommisse wordt ingegaan op “semantische interoperabiliteit”. De intentie om met ketenpartners samen te werken is op zich onvoldoende om tot tastbare resultaten te komen. Men zal zich onder meer moeten verdiepen in de talen die de diverse partners spreken en samen tot de gewenste “vertalingen” moeten komen. Uiteindelijk zijn afspraken op sectorniveau nodig over betekenis, structuur, toepassingsbereik etc. van een gemeenschappelijke taal en organen die volgens vaste methoden, met zoveel mogelijk hergebruik van wat voorhanden is, partners helpen om de afspraken te implementeren. Voor een efficiënt beheer van de gebruikte begrippen is het om vele redenen noodzakelijk om dat dicht bij de bron te beleggen en te zorgen voor automatische doorvertaling naar de projectwoordenboeken die er gebruik van maken. Dit gaat allemaal niet vanzelf, maar als het bouwwerk van semantische interoperabiliteit eenmaal staat levert dat een enorme bijdrage aan goedkope en effectieve dienstverlening.
2 Inleiding “Communicatie is zo dicht mogelijk langs elkaar heen praten” wordt weleens beweerd. Het is lang niet altijd zeker dat wat de een bedoelt door de ander zo wordt opgevat. Dat probleem doet zich voor in de dagelijkse omgang met elkaar, maar speelt evenzeer in de communicatie tussen organisaties. In dit artikel wordt die ketenproblematiek beschreven en vervolgens wordt ingegaan op de manier waarop die momenteel binnen diverse overheden, waaronder justitie en onderwijs, praktisch wordt opgepakt.
3 Spreken we dezelfde taal? 3.1 Elke organisatie heeft eigen begrippen Iedereen die iets wil gaan doen met uitwisseling van gegevens tussen organisaties zal ontdekken dat elke organisatie een eigen taal spreekt, in de zin dat men begrippen anders definieert. Dat is lastig. Als je denkt dat je het over hetzelfde hebt, blijkt de een dat anders te interpreteren dan de ander. De problematiek van de vroegtijdige schoolverlating is een voorbeeld van zo’n begripskwestie. Het heeft iets van doen met iemand die de school voor het eindexamen verlaat, dat is duidelijk. Maar wanneer is dat een probleem? Als hij/zij geen werk heeft? Als hij/zij geen diploma heeft en, zo ja, wat is minimaal vereist? Bij welke leeftijdscategorie hanteren we die term? Hoe meet je die schoolverlating eigenlijk? Het heeft lang geduurd eer de betrokken partijen zoals de onderwijsinspectie, de scholen en de gemeenten het daar (in grote lijnen) over eens waren. En de codes die in de diverse systemen gehanteerd worden lopen nog steeds uiteen. Voor een succesvolle communicatie is het dus noodzakelijk om de betekenis van begrippen expliciet te maken zodat iedere partij dezelfde lezing bij die begrippen heeft. Het mooiste is het natuurlijk als iedereen vervolgens die standaarddefinitie ook in de eigen context gaat gebruiken, maar vaak is dat onmogelijk omdat, bijvoorbeeld, de wettelijke context waarin de ene organisatie werkt afwijkt van de andere en die wetten een verschillende definitie van een begrip hanteren. Er zijn dan “vertaaltabellen” nodig. Als het gaat om twee organisaties en een incidenteel proces dat ze gezamenlijk willen oppakken, dan komt men er met bilaterale, binnen een projectomgeving gemaakte, afspraken doorgaans nog wel uit. Afspraken bijvoorbeeld over de voor de uitwisseling te gebruiken techniek, over de definitie en vertaling van begrippen, over de opbouw (syntax) van de berichten en de manier waarin die in de processen worden gebruikt . De context is te overzien en als het werkt dan werkt het, is vaak de, vanuit het project gezien, pragmatische redenering. Gaat het om meerdere processen binnen een bepaalde context en/of een groter aantal partners, dan loont het de moeite te gaan nadenken over
1
overkoepelende standaarden voor technische protocollen, gegevensdefinities, de opbouw van de inhoud van berichten, etc. Niet alleen wordt daarmee de samenwerking beter ondersteund, maar er kunnen ook investeringen gedaan worden die voor meer dan 1 project renderen.
3.2 De vertaalslag: semantische interoperabiliteit Het op elkaar afstemmen van de definities van begrippen en het overbruggen van verschillen in elkaars gegevenshuishouding is een voorwaarde om te komen tot wat “semantische interoperabiliteit” wordt genoemd. Vanuit de keteninformatisering bezien is semantische interoperabiliteit erg gebaat bij een sector- of ketenoverkoepelend informatiemodel waaraan deelnemende organisaties hun eigen informatiemodellen kunnen relateren en die los staat van een specifiek proces. Op basis van dat model kunnen deelnemers op gecontroleerde wijze bedrijfsdocumenten (“berichten”) opstellen die voor iedereen in de keten begrijpelijk zijn. Daartoe moeten onder meer de eigen gegevenswoordenboeken van de betrokken partijen worden afgestemd met een gemeenschappelijk sectorwoordenboek. 3.2.1 Architectuur van de semantiek Een overkoepelende gegevenshuishouding bestaat in ieder geval uit de volgende twee belangrijke componenten: 1. Gegevenswoordenboek. De verzameling van alle kernbegrippen plus hun definities en andere relevante metadata die de ketenpartners in de betreffende context gemeenschappelijk hebben. Onderdeel hiervan vormen codelijsten en referentietabellen.
2. Referentiemodel. Een informatiemodel voor de betreffende samenwerkingscontext. Het referentiemodel beschrijft de relaties tussen de begrippen. Het onderstaande vereenvoudigde voorbeeld is ontleend uit het onderwijs.
2
Op basis van deze twee componenten kunnen berichten eenvoudiger worden gestandaardiseerd omdat zowel de hiërarchie van de relaties tussen begrippen en daarmee de opbouw van het bericht duidelijk wordt als ook de betekenis en het bereik van die begrippen zelf. Om te komen tot een referentiemodel kunnen verschillende wegen worden bewandeld. Voor de hand ligt om te beginnen met het opstellen van een lijst van kernbegrippen en hun definities, afgeleid uit de uitwisselingen die reeds gespecificeerd zijn en de onderlinge samenhang (relaties) pas later daaraan toevoegen. Deze bottom-up benadering wordt vaak gevolgd bij projecten, waarin gestart wordt met het uitwerken van 1 of 2 specifieke interactieprocessen. Omdat men start met een beperkt aantal interacties is het heel goed mogelijk dat men het geheel nog niet goed kan overzien en daar dus ook geen rekening mee houdt. De top-down benadering: eerst het gehele domein beschouwen, alle daarin onderkende processen en gegevensobjecten in een model opnemen is vanwege de consistentie aan te raden, maar in de praktijk lastig uitvoerbaar. Wanneer heeft men genoeg inzicht en overzicht om tot een volledig model te komen? Wie moeten er allemaal meteen bij betrokken worden? Als men dergelijke volledigheid nastreeft kan er geruime tijd overheen gaan voordat er iets concreets bereikt wordt, met alle gevolgen voor de slaagkans van projecten die er in het heden al iets mee moeten. Of die projecten gaan gewoon hun eigen weg en probeer dat later maar weer te verbinden. De kunst is dus altijd om bottom-up en top-down met elkaar te combineren. Dat betekent dat begonnen wordt met een eerste concept van een overkoepelend model, dat voldoende is om de eerste interacties mee te kunnen beschrijven inclusief de relatie tussen de daarin gehanteerde gegevensobjecten. Bekeken moet worden of bestaande modellen toepasbaar zijn door ze aan te passen en/of uit te breiden. De verdere precisering en uitbreiding van het model kan dan werkenderwijs worden ingevuld. Het gegevenswoordenboek is nauw verweven met het referentiemodel, het referentiemodel is als het ware richtinggevend voor de ontwikkeling van het woordenboek. Daarbij kunnen bestaande gegevenswoordenboeken en –verzamelingen die reeds zijn ontwikkeld fungeren als startpunt c.q.
3
voedingsbron onder het motto: “wat er al is moet je niet zelf meer willen ontwikkelen”. Het woordenboek zal daarna projectmatig uitgebreid en aangepast worden op basis van feedback vanuit experts, van de modellering van onderkende interacties en van praktijktesten. Omdat het streven is om in een generiek gegevenswoordenboek voor de sector geen processpecifieke zaken op te nemen worden vaak project- of processpecifieke woordenboeken afgeleid van het generieke woordenboek. In zo’n proceswoordenboek kan dan een onderscheid worden gemaakt tussen generieke bouwstenen, restricties op die generieke bouwstenen en processpecifieke bouwstenen. 3.2.2 Meerdere woordenboeken Het gegevenswoordenboek maakt het mogelijk verschillen in naamgeving, toepassingsbereik en definities die ketenpartners hanteren voor bepaalde begrippen te “vertalen”.. Omdat de context waarin gegevens en gegevensdefinities worden vastgelegd normaliter een ketenproces is (wat ingericht wordt in een ketenproject), worden er voor dat ketenproces nieuwe gegevens die noodzakelijk zijn in het proces toegevoegd aan het proceswoordenboek. Dat proceswoordenboek is dus een combinatie van uit de kern overgenomen en mogelijk ingeperkte gegevensgroepen, aangevuld met nieuwe, voor het proces relevante, gegevensgroepen. De ketenpartners dienen zorg te dragen dat ze hun gegevensmodellen kunnen “vertalen” (mappen) naar dat ketenmodel.. Maar dat is niet de enige uitdaging. Een keten of sector staat nooit op zichzelf en meer dan eens zijn gegevens die in andere sectoren reeds bekend en beschreven zijn ook onderdeel van de communicatie in een bepaalde keten en figureren dan ook in het kernwoordenboek en de daarvan afgeleide proceswoordenboeken en berichten. Het wiel opnieuw uitvinden is zo’n geval niet praktisch en soms zelfs onwenselijk. De uitdaging is dan om gegevens die ketenoverstijgend zijn vanuit de bron af te leiden en te beheren. Mutaties moeten daarbij ook integraal, over de ketens heen, worden beschouwd in plaats van op het niveau van een enkele keten. Een voorbeeld binnen de overheid van zo’n uitdaging vormen de basisregistraties; bij uitstek een bron van gegevens die keten- c.q. domeinoverstijgend van toepassing zijn.. Overheidsinstanties zijn op den duur verplicht om de semantische kern en de gegevensmodellen van de basisregistraties te overerven Het is dus zaak een reeks van woordenboeken en referentiemodellen die niet in de eigen keten zijn ontwikkeld in relatie tot de eigen woordenboeken te beheren. Bijgaand plaatje, overgenomen uit de 1 EBV Methode , geeft een beeld van de complexiteit.
1
1 EBV methode, White paper, http://justid.nl/ebv/publicaties/
4
Elke onderste laag in het plaatje importeert als het ware begrippen uit de bovenliggende laag. Sommige begrippen “sijpelen” op die manier door naar de proceswoordenboeken (in het plaatje aangeduid met domeinspecifieke woordenboeken) en komen zo ook in de uiteindelijke bedrijfsdocumenten terecht. De kunst is dus om begrippen die men overerft uit een hogere laag niet zelf fysiek te beheren maar alleen de relatie ernaar toe vast te houden. Als de bronhouder van bijvoorbeeld de basisregistratie GBA begrippen wijzigt dan zouden die wijzigingen idealiter vanzelf ook mee moeten komen in de woordenboeken die van de GBA begrippen gebruikmaken en uiteindelijk ook in de ketencommunicatie die op deze woordenboeken is gebaseerd. Dit klinkt in theorie allemaal prachtig en deze aanpak is zonder meer het wenkende perspectief. Maar om zo ver te komen moet wel aan een aantal randvoorwaarden worden voldaan: 1. De ketenpartners moeten het niet alleen eens zijn over de eenduidigheid van de “eigen” ketenbegrippen, maar ook over begrippen die niet uniek tot die keten behoren. 2. Iedere bronhouder beschrijft zijn gegevens volgens dezelfde structuur en dezelfde standaarden. Dat maakt overnemen van die begrippen in een andere sector of keten relatief gemakkelijk.. Pogingen hiertoe zijn te zien in de stelselcatalogus van de eOverheid waarin getracht wordt voor alle basisregistraties een vaste structuur te hanteren. Dat is erg lastig, gezien de diverse achtergronden waartegen de diverse basisregistraties worden ontwikkeld en beheerd. Een stapje verder richting de sectoren en de ketens laat zien dat er voorlopig van dat ideaal nog weinig terecht komt.Dat betekent dat er nog veel vertaald moet worden.. 3. Begrippen die zijn overgenomen uit een andere laag of bron moeten in het beheer binnen een bepaalde keten of sector niet te wijzigen zijn. Anders is namelijk de relatie tussen het begrip zoals dat wordt toegepast in een keten en de eigenlijke bron is binnen de kortste keren
5
verbroken. Toevoegen van informatie die specifiek is voor een keten of een proces is overigens wel mogelijk. 4. Wijzigingen moeten direct bekend worden bij de afnemers en dynamisch beschikbaar komen zodat ze zo automatisch mogelijk verwerkt kunnen worden. De praktijk is nu nog dat er veel “met het handje” moet worden gedaan om wijzigingen die elders zijn gedaan ook weer toe te passen in de eigen context. Een stevige klus die vraagt om specifieke expertise.
4 Een gemeenschappelijke aanpak voor gegevensuitwisseling 4.1 De ketendienstverlener Het ontwikkelen, vaststellen en beheren van ketenstandaarden vormt nog geen garantie voor de daadwerkelijke toepassing van die standaarden in uitvoeringsprojecten. Dat die implementatie niet automatisch gebeurt kan tal van oorzaken hebben: • projectleiders en hun opdrachtgevers zijn simpelweg niet op de hoogte van het bestaan van ketenafspraken (vaak omdat projecten bemand worden door externe partijen die niet altijd op de hoogte zijn van alle afspraken die gelden binnen bepaalde ketens en domeinen), • er is geen of weinig ervaring met de implementatie van afgesproken standaarden, zodat veiligheidshalve een techniek wordt gebruikt die men toevallig al kent, • “ongehoorzaamheid” omdat uitvoerenden van mening zijn dat ze een beter alternatief hebben voor de afgesproken standaarden. In het laatste geval dient er op het niveau van de projectaansturing en mogelijk op het bestuurlijk niveau daarboven het een en ander te gebeuren op het gebied van conformance en governance. Het optreden van de andere genoemde redenen is echter onvermijdelijk, zeker in het begin, als afspraken nog redelijk vers zijn. Maar ook later want kennis in projecten verdwijnt vaak weer na afloop van de klus. Om die reden is er in diverse overheidssectoren, maar ook in diverse private sectoren, besloten om niet alleen standaarden af te spreken en met een “keurig strikje” over te dragen aan elk project dat ermee aan de slag moet, maar ook daadwerkelijk diensten te ontwikkelen en aan te bieden aan projecten bij het implementeren van die standaarden. Die diensten worden vaak door een centrale partij uitgevoerd. Idealiter richt die dienst zich daarbij op de zogenaamde koppelvlakken: de punten waarop de organisaties informatie in de vorm van berichten uitwisselen en dus niet op de interne ICThuishouding van de organisaties zelf. Bij justitie heet deze dienst EBV (Elektronisch BerichtenVerkeer, onderdeel van de Justitiële Informatiedienst), in de werk- en inkomenssector hebben we het BKWI (Bureau Keteninformatisering Werk en Inkomen), bij de administratieve onderwijsprocessen vervult het Schakelpunt OCW, ondergebracht bij DUO, die rol en in de gezondheidssector is Nictiz al jaren actief op dit terrein. De aard en het pakket van de diensten van die organisaties verschilt uiteraard wel (mede door de verschillende ontstaansgeschiedenissen) maar op het gebied van de ondersteuning van de semantische interoperabiliteit in die sectoren zien we grote overeenkomsten.
4.2 Een standaardaanpak Als we weer even inzoomen op het onderdeel semantische interoperabiliteit dan is de tendens dat er rond de afgesproken standaarden een standaardaanpak wordt toegepast om te komen tot “ketenproducten” die voor de uitwisseling noodzakelijk zijn. Hieronder zoomen we in op een dergelijke 2 methode zoals die wordt gehanteerd in diverse justitiële ketens (door de dienst EBV) alsmede ook in het kader van de administratieve processen in het onderwijs (door het Schakelpunt OCW). Met behulp van deze specifieke analyse- en ontwerpmethode wordt allereerst inzicht geboden in de informatie die binnen een bepaald keten- of interactieproces “stroomt” tussen de betrokken partijen waarbij wordt ingezoomd op een of meerdere transacties tussen 2 partijen waarin daadwerkelijk een set van gegevens wordt uitgewisseld (die set dit wordt in de specificatie een bedrijfsdocument genoemd). Los van het bepalen van de scope van het hele interactieproces en de daarin onderkende
2
Zie EBV Methode: White paper, http://www.justid.nl/ebv/publicaties/
6
transacties worden in die eerste stap globaal ook de structuur en betekenis vastgelegd van de elementen die in die uitwisseling een rol moeten spelen. Na het globaal specificeren van de uit te wisselen bedrijfsinformatie wordt automatisch van een kernof ketengegevenswoordenboek die van toepassing is voor een bepaalde keten een (keten)proceswoordenboek afgeleid. Op die wijze wordt hergebruik flink gestimuleerd. Ervaringscijfers leren ons dat voor nieuwe ketenprocessen men soms wel voor meer dan 90% gebruik kan maken van concepten die reeds eerder in het kader van eerder beschreven processen zijn bedacht zonder die nog aan te hoeven te passen c.q. uit te breiden. Het proceswoordenboek is meestal een inperking op het kernwoordenboek. Niet alle begrippen zijn namelijk van toepassing op het specifieke proces en ook niet alle elementen die bij een bepaald begrip zijn opgenomen in het kernwoordenboek zijn relevant. Op basis van de beschikbare gegevens in het proceswoordenboek worden bedrijfsdocumenten samengesteld die in het kader van de onderkende bedrijfstransacties moeten worden uitgewisseld. Als laatste stap wordt de technische specificatie gegenereerd, meestal in de vorm van een XML Schema (XSD). Hiermee wordt het berichtenverkeer in de praktijk volledig elektronisch ingericht. De XSD’s zelf zijn dus gegenereerde eindproducten en worden niet in die vorm beheerd en onderhouden. De bron is altijd het logische gegevensmodel en de daarvan afgeleide bedrijfsdocumentspecificaties. Zo is een dienst als EBV (justitie) al jaren in staat om de gegevenswoordenboeken en de uiteindelijk gegenereerde XSD’s synchroon te laten lopen, waar in andere sectoren een gegevenswoordenboek vaak nog een papieren realiteit is en de XSD’s door programmeurs met het handje in XML-tools worden gemaakt. Omdat met een XSD niet alle afspraken over het gebruik van gegevens kunnen worden vastgelegd en gevalideerd, worden als bijproduct vaak zogeheten codeerinstructies opgeleverd. Hierin staan de specifieke vulling en verwerking van de XSD’s voor een bepaald koppelvlak beschreven alsmede ook de business rules die van toepassing zijn op dit koppelvlak. Het zijn, zo gezegd, de regels voor de programmeurs die aangeven hoe ze moeten omgaan met de inhoud van een bericht zowel qua acceptatie als qua verdere verwerking. Er zijn overigens standaarden beschikbaar (zoals Schematron) waarmee deze regels geformaliseerd kunnen worden zodanig dat ze toegepast kunnen worden voor automatische verwerking.
5 Vertaling naar de theorie Brengt deze verhandeling ons tot nieuwe inzichten waar het gaat om de theorie rond keteninformatisering? Dat is zeer de vraag. Het gaat in dit betoog meer over een praktische uitwerking van een ketensamenwerking waartoe al eerder is besloten. Die uitwerking vergt echter wel een stevige betrokkenheid vanuit het management omdat er concessies moeten worden gedaan en geïnvesteerd moet worden. De ketentheorie maakt waarschijnlijk dat die er alleen zal zijn als de druk om genante fouten (of de herhaling daarvan) te voorkomen groot is. Standaardiseren is vanuit het perspectief van Keteninformatisering gezien niet zozeer de oplossing voor een dominant ketenprobleem, maar om dominante ketenproblemen effectief en snel aan te pakken wordt de toepassing van standaarden ook op het gebied van semantische operabiliteit als steeds urgenter ervaren. “Zo beschouwd kunnen we concluderen dat we met standaardisatie eigenlijk te maken hebben met het oplossen van een metaprobleem, een probleem dat achter dominante ketenproblemen wegkomt en dat een zeer kritische succesfactor vormt voor de oplossing van de, wat 3 ik maar even noem, meer “tastbare” ketenproblemen” .
3
Dommisse, B.P.M.J., Past Standaardisatie in Keteninformatisering?, in: Grijpink, J.H.A.M. e.a., Geboeid door ketens, pag. 191-202, ISBN 10:90-811470-1-3
7
