Gemeenten zijn verplicht om informatie uit te wisselen conform de standaard Digikoppeling. Het zou veel inspanningen besparen als een centrale ondersteuning de implementaties in goede banen zou leiden; in dit kader wordt gewerkt aan een nieuwe standaard, onder de naam ‘Digikoppeling adapter intern’. De vraag is echter of gemeenten gediend zijn met de inhoud van deze nieuwe standaard.
Nadat ik een poosje heb geworsteld met de vraag hoe ik mijn opmerkingen bij ‘Digikoppeling adapter intern‘ het beste zou kunnen overbrengen, op een manier die begrijpelijk is voor beslissers, kwam ik tot de conclusie dat dit niet gaat lukken. In plaats daarvan moet de opzet van de ‘moeder-standaard’ zelf, Digikoppeling, ter discussie worden gesteld.
De site van Forum Standaardisatie zegt dit over Digikoppeling:
Geautomatiseerde gegevensuitwisseling tussen informatiesystemen voor sector overstijgend berichtenverkeer, op basis van drie koppelvlakstandaarden:
▪ DK ebMS standaard voor meldingen tussen informatiesystemen
▪ DK WUS standaard voor de bevraging van informatiesystemen
▪ DK GB standaard voor de uitwisseling van grote berichten
Samengevat, schrijft Digikoppeling ons voor dat ‘bevragingen’ moeten worden gerealiseerd met berichten conform de webservices standaarden en ‘meldingen’ met het berichtenprotocol ebMS. De toepassingsregels zien er overtuigend uit en de toepassingsgebieden van koppelvlakstandaarden lijken helder te zijn afgebakend.
Uitgangspunt
Het probleem is echter dat men de daadwerkelijke interoperabiliteitsbehoefte van de overheid niet als uitgangspunt heeft genomen. Er is geredeneerd vanuit de techniek, en wel op detailniveau. Een achterhaalde technische stelling dat een zogenaamd ‘betrouwbaar’ berichtentransport gebruikt moet worden voor het verzenden van ‘meldingen’ staat centraal in Digikoppeling. Daardoor loopt deze standaard uit de pas met de gangbare praktijk. Het is gebruikelijk dat bij de geautomatiseerde interacties tussen bedrijven de keuze wordt gemaakt tussen:
– Klassieke b2b (asynchrone) uitwisselingen van berichten (edi en verder),
– Service gerichte interacties door middel van webservices,
– Restful, queuing … (deze laat ik hier gemakshalve verder buiten beschouwing).
Dat is ingegeven door de manier waarop interacties tussen informatiesystemen worden gemodelleerd: óf op basis van berichtenuitwisseling óf op basis van services, óf …
Het vraagstuk interoperabiliteit wordt ook wereldwijd op die manier opgelost: er zijn aparte technologieën en standaarden voor b2b-berichten (AS2, ebMS …) en voor webservices (WS-*, WSDL). En dat is wezenlijk anders van wat de standaard Digikoppeling ons voorschrijft: ‘meldingen – ebMS; bevragingen – WUS’ …
De standaard Digikoppeling wijkt dus af van de ict-trends. De meest voelbare implicatie daarvan is dat het gebruik van webservices wordt achtergesteld door de regel ‘meldingen – ebMS’. Dat leidt tot onnodig hogere kosten omdat de b2b (ebMS) koppelingen duurder en moeilijker te beheren zijn. Dit terwijl wereldwijd ontelbaar veel ‘meldingen’ dagelijks met behulp van webservices probleemloos worden uitgewisseld.
Het tweede probleem is dat Digikoppeling verschillende technologieën onbedoeld vermengt. Dat leidt tot meer maatwerk; daarbij gaat het hier om onnodig, puur technisch maatwerk dat geen relatie heeft met de overheidsproblematiek. Een voorbeeld daarvan is de inspanning om de marginale standaard WS-Reliablemessaging als alternatief voor ebMS in Digikoppeling te incorporeren. Dit is moeilijk en onlogisch. Daarnaast is de overheid niet geëquipeerd om techniek zelf te ontwikkelen en op bit-niveau te blijven aansturen.
Technologietrends
Nederlandse overheidsorganisaties hebben geen bijzondere, overkoepelende standaarden nodig. Wat nodig is, is meer rekening houden met de technologietrends; men moet de wereldwijde ontwikkelingen onderkennen en binnen dat kader keuzes maken. Voor Digikoppeling betekent dit dat we berichtenuitwisselingen niet in dezelfde standaard kunnen opnemen met webservices. En uiteraard, nooit en te nimmer centraal en vooraf een oplossingsrichting afdwingen, expliciet noch impliciet. Het is aan projecten om per koppeling te kiezen: óf service gericht óf b2b-messaging.
Tot slot: we moeten ons afvragen of formele standaardisatie soms niet een te zwaar instrument is, dat het bereiken van het beoogde doel, namelijk interoperabiliteit, juist in de weg staat? Een informele handreiking, maar dan onderbouwd met concrete, werkende voorbeelden (met broncode en al) en toegespitst op de daadwerkelijke behoefte van de overheid kan veel effectiever zijn dan een formele standaard. Dus, voor wat betreft ‘Digikoppeling adapter intern’: we hebben deze aanvullende standaard niet nodig. Maak in plaats daarvan een werkend prototype; laat bijvoorbeeld zien hoe, met behulp van queuing, berichten kunnen worden uitgewisseld tussen een applicatie en een b2b-broker, ook in de cloud. Of, nog beter, bestel de voorbeeldprogrammatuur bij de gemeentelijke leveranciers van b2b-brokers…
Borjan Čače, zelfstandig ict adviseur/ict architect
Verfrissend prikkelende kijk op nut en wijze van standaardisatie. Een tweetal opmerkingen:
– “Nederlandse overheidsorganisaties hebben geen bijzondere, overkoepelende standaarden nodig” lijkt me wat te kort door de bocht omdat je op andere gebieden dan waar het hier gaat wel degelijk standaarden kunt gebruiken om efficiënt uit te kunnen wisselen lijkt me.
– “Wat nodig is, is meer rekening houden met de technologietrends; men moet de wereldwijde ontwikkelingen onderkennen en binnen dat kader keuzes maken.” Mee eens, maar dan zou ik in de opsomming bij ‘Uitgangspunten’ juist “Restful, queuing, …” niet buiten beschouwing laten, maar ook hier de aandacht geven die ze gelet op de technologietrends nu verdienen.
Door Ad kwam dit artikel op mijn netvlies. Zinvol artikel al heb ik nogal wat links en zoekopdrachten moeten uitvoeren om de materie helder te krijgen (en dat is nog niet geheel gelukt). Als er een paar principes zijn van waarden die ik door de tijd heb opgedaan, dat is mijn ervaring dat:
– Totale scheiding tussen de gebruikers interface en de werking aan de achterkant *zonder* achterdeurtjes
– Dicht bij de kern blijven. Als jouw overheidsbedrijf / dienst iets doet en daarvoor een werkende gegevens verzameling heeft (werkend systeem) dan zouden alle externe diensten dezelfde deze gegevens op eenzelfde manier kunnen consumeren
– Geen brokers. Eindpunten direct op elkaar aansluiten, authenticatie en ID’s zouden wel via één systeem en methode gefaciliteerd moeten worden (maar dus geen “man in the middle” systeem)
– RESTful is de de facto standaard, SOAP is dat niet
– Voorkom afhankelijkheden (de aanjager van legacy)
@Henri:
nav ‘Geen brokers. Eindpunten direct op elkaar aansluiten / geen “man in the middle” systeem’. Ik zie de vele voordelen van een ‘smart endpoints dumb pipes’ aanpak, maar de omgeving waarin je werkt bepaalt voor een belangrijk deel de mate waarin dit uitgangspunt toepasbaar is. Gemeenten kennen veel verschillende diensten en producten. Voor de applicaties die ze daarbij gebruiken zijn ze (enkele uitzonderingen daargelaten) afhankelijk van wat de markt biedt. Integratie is dan voorspelbaar een ‘uitdaging’. Eentje waarbij broker-voorzieningen wel degelijk een nuttige rol kunnen spelen. Waarbij je advies natuurlijk van toepassing is op het voorkomen van de situatie dat alle slimmigheid die applicaties missen in een broker worden gestopt (waarmee ze zelf tot het volgende probleem worden gepromoveerd).
– nav ‘RESTful is de de facto standaard, SOAP is dat niet’ Los van wat je onder ‘de facto’ verstaat (als in je sector veel SOAP wordt gebruikt is het daar ook een de facto standaard…) is het de vraag of het daarom altijd de voorkeur moet krijgen (net zo min als dat dit geldt voor een vastgestelde standaard zoals SOAP). Vergelijkbaar als wat Borjan doet bij zijn pleidooi om per project / koppeling te kiezen voor service gericht of b2b-messaging, ben ik een voorstander van de aanpak om per situatie te bezien welke standaard(en) het beste bruikbaar zijn. Wat er toe leidt dat je meer dan 1 standaard (EDI, SOAP, RESTfull, XML, Json, …) zult moeten kunnen ondersteunen, want ‘die ene altijd de beste’ zal er volgens mij nooit komen.
Ad, Henri,
Bedankt voor jullie inbreng!
Nog ter verduidelijking van mijn standpunt over de Nederlandse standaardisatie in ons domein. Voor wat betreft de techniek, ik ben van mening dat standaarden beperkt moeten zijn tot uitsluitend keuzes uit het palet van internationale standaarden. En dan alleen als er op een bepaald toepassingsgebied concurrerende standaarden bestaan of een andere aanscherping/inperking nodig is. Bijvoorbeeld, voor B2B messaging zijn er meer berichtenprotocollen beschikbaar, o.a. ebMS en AS2. Dus, omwille van interoperabiliteit is het verstandig om hiervan slechts één te gebruiken. Hierbij wil ik benadrukken dat het kiezen over het algemeen geen eenvoudige opgave is. Om een goed afgewogen keuze te kunnen maken moet men de trends nauw volgen, toepassingsgebied kennen, Gartner lezen …
Wat naar mijn mening altijd onvermijdelijk mis gaat, is het zelf voor de overheid specifieke technische oplossingen bedenken en die dan d.m.v. standaardisatie verplicht stellen. Voordat je het weet, ga je helemaal anders werken dan de rest van de wereld …
Samengevat: eerst technologiegebieden conform de wereldwijde trends afbakenen en dan per gebeid en op basis van concrete behoeftes bekijken of er gezamenlijke keuzes gemaakt moeten/kunnen worden.
Aan de functionele kant is er wel een specifieke Nederlandse uitwerking nodig. Het heeft bijvoorbeeld duidelijke voordelen om landelijke gegevensdefinities centraal vast te stellen. Ook de gezamenlijke vertalingen naar XSD zijn nodig, evenals functionele interface definities van vaak gebruikte services.
Verder, over RESTful en webservices gebaseerd op WSDL/SOAP: de toepassingsdomeinen van deze twee soorten oplossingen zijn goeddeels disjunct. REST is bedacht voor hypermedia en voor interacties tussen browser scripts en personal devices enerzijds en server-applicaties anderzijds. WSDL/SOAP webservices daarentegen zijn bedacht voor interacties tussen server-applicaties onderling. Beide zijn op dit moment doorontwikkeld en op eigen toepassingsdomein dominant. Uiteraard zijn er grijze gebieden waar nagedacht moet worden over welke oplossingsrichting beter past, maar dat verstoort het grote beeld niet.