Een mooi voorbeeld hiervan kwam ik tegen in het artikel "Nobody Needs Reliable Messaging" van Marc de Grauw. Het gaat in op hoe samenwerkende partijen het beste digitale berichten kunnen uitwisselen. Om de verzender van een bericht zekerheid te geven dat zijn bericht bij de ontvanger is aangekomen, zijn er speciale technieken ontwikkeld ("reliable messaging"). Vooral nuttig natuurlijk als het gaat om belangrijke berichten. De Nederlandse overheid maakt er daarom, in de vorm van ebMS en WSRM, dan ook steeds meer gebruik van.
Toch kun je de vraag stellen of je daarmee altijd bereikt wat je wil bereiken. Want meestal wil je niet zozeer weten of je bericht goed is aangekomen, maar vooral of het wel goed is verwerkt. Dat je bestelling bij Bol.com is aangekomen is mooi maar niet waar het om gaat. Wat je echt wil weten is of ze je bestelling goed hebben verwerkt, en of bekend is wanneer je product zal worden geleverd.
Voor een goede samenwerking spreek je daarom als afnemer met je leverancier af wat er aan informatie terug moet worden geleverd. Soms is een retourbericht met "true" of "false" al genoeg. Soms wil je graag een hele set aan gegevens ontvangen. In ieder geval altijd meer dan alleen een melding dat je bericht is ontvangen. Maar als je toch inhoudelijke informatie gaat uitwisselen, kun je de vraag stellen waarom je nog met "reliable messaging" zou werken. Want dat je bericht is aangekomen snap je immers ook wel als je een inhoudelijk retourbericht ontvangt. In veel situaties geldt dan ook dat het eigenlijk overbodig is. Of, erger nog, dat het onnodig complexiteit oplevert. En dat is wel het laatste waar je bij een samenwerking behoefte aan hebt.
In genoemd artikel wordt beschreven dat er binnen HL7 (een wereldwijde berichtstandaard voor de zorgwereld) om die reden voor is gekozen om geen gebruik te gaan maken van reliable messaging, Iets dat op het eerste gehoor vreemd klinkt omdat het daarbij natuurlijk gaat om berichten waarbij een betrouwbare uitwisseling essentieel is.
Mijn eigen ervaringen met berichtuitwisseling binnen de Eenvoudige MidOffice (EMO), die vanaf 2007 binnen gemeente Nijmegen wordt gebruikt, stroken hiermee. Het bedachte xml-berichtformaat is bewust zo eenvoudig mogelijk gehouden. Met dat simpele formaat, en zonder reliable messaging, worden er nu al ruim 6 jaar probleemloos duizenden en duizenden berichten uitgewisseld.
Een ander voorbeeld waarin EMO qua taakverdeling afwijkt van een aantal andere zaaksystemen is de manier waarop er identificerende "zaakidentificatiecodes" worden toegekend. Vaak wordt gekozen voor een centrale uitgifte door het gemeentelijk zaaksysteem. Bij EMO is gekozen voor het concept waarbij dit ook door gekoppelde applicaties kan worden gedaan. Ze krijgen daarvoor dan een eigen unieke aanduiding, en kunnen daar vervolgens zelf (binnen de eigen context unieke) codes aan vastknopen. Eenvoudig en handig bij het, in de gemeentewereld vaak gezien als problematisch, koppelen van applicaties.
Bij een samenwerking bepalen wie wat het beste kan doen blijkt dus niet altijd zo makkelijk te zijn als het lijkt. Reden waarom er goed over nadenken zich in praktijk dubbel en dwars kan terugverdienen. Zeker in situaties waarin complexe oplossingen de norm zijn geworden.
