Interoperabiliteit is de mogelijkheid van verschillende autonome, heterogene systemen, apparaten of andere eenheden om met elkaar te communiceren en samen te werken. Dit is nog niet in elk bedrijf of project een bekend begrip, maar wel iets dat steeds belangrijker wordt in een wereld waar de hoeveelheid data die wij produceren en consumeren consequent groeit. Denk aan big data, internet of things, etc.

De output van de een is de input voor de ander

In tegenstelling tot hoe het soms voelt, zijn de meeste producten waar in projectverband aan wordt gewerkt slechts een klein deel van een groter geheel. Dit betekent dat wat wordt ontwikkeld voor een enkel product grote impact kan hebben op een systeem. En dat wat wordt ontwikkeld voor een enkel systeem weer grote impact kan hebben op een grotere keten die uit meerdere systemen bestaat. Hoe langer er geïsoleerd wordt ontwikkeld en getest zonder bewustwording van de ‘lijntjes’ rondom een product of systeem, hoe groter de kans dat producten of systemen niet met elkaar overweg kunnen.

Waarom is het zo belangrijk om je input- en output data in een vroeg stadium te valideren?

Binnen een keten kennen we data producers en data consumers. Dat wil zeggen: systemen genereren data en/of lezen data in. Vergelijk het eens met een boodschappenlijstje. Als iemand jou een boodschappenlijstje geeft (data generatie) en jij kunt niet goed lezen wat er staat (data inlezen), dan kan dit ertoe leiden dat jij compleet verkeerde boodschappen koopt. Als je vervolgens bij deze persoon terugkomt met de verkeerde boodschappen (data generatie), kan hij hier niet mee maken wat hij wil. Als je nou bij het ontvangen van het boodschappenlijstje had gevraagd wat er stond, of had afgestemd hoe het lijstje zou moeten worden aangeleverd (bv. alles in blokletters), dan had deze miscommunicatie kunnen worden voorkomen. En zoals iedere tester weet: hoe vroeger het stadium waarin een bug wordt gevonden, hoe goedkoper het is om hem op te lossen.

Mogelijke valkuilen

Een van de valkuilen, met name in grotere organisaties, is de zogenoemde ‘eilandjescultuur’. Dit wil zeggen dat mensen die aan een enkel systeem werken niet verder willen of kunnen kijken dan dit systeem. Dit heeft tot gevolg dat ze niet op de hoogte zijn van wat zich hierbuiten afspeelt. Wanneer zich een probleem met de data voordoet gaan de hakken in het zand: iedereen heeft de code opgeleverd aan de hand van specificaties voor hun systeem en niemand is dus verantwoordelijk voor het probleem. Er wordt vaak over en weer met de vinger gewezen en in de praktijk gaat er een (te) lange tijd overheen voordat iemand het voortouw neemt en het probleem oplost.

Een andere valkuil is het gebrek aan communicatie over specificaties. Specificaties worden niet altijd eenduidig opgeschreven voor ieder systeem, of kunnen op meer dan één manier worden geïnterpreteerd. Als er geen overleg is tussen verschillende ketenpartijen over hoe data moet worden aangeleverd, dan is het mogelijk dat een ontvangende partij hier andere verwachtingen bij heeft dan een leverende partij. Het is uiteindelijk veel kostbaarder om dit in een later stadium op te lossen, dan om het vooraf goed af te stemmen.

Een derde valkuil is synchronisatie. Op verschillende systemen draaien verschillende softwareversies. Het kan daarom voorkomen dat de nieuwe software op systeem A moet worden getest tegen een oudere versie van de software op systeem B, om bijvoorbeeld een klantscenario na te bootsen of de compatibiliteit te verifiëren. Dit betekent dat er coördinatie nodig is tussen verschillende ketenpartijen om dit in gang te zetten, maar ook om het belang van deze test door te laten dringen. De praktijk wijst echter uit dat het belang van een dergelijke test niet altijd wordt gedeeld door alle partijen, wat ertoe leidt dat niet alle partijen hun systemen of data op orde brengen. Er staan immers taken met een hogere prioriteit (bv. eigen sprintdoel) op de backlog. De ketentest kan hierdoor maar deels worden uitgevoerd en dit brengt risico’s met zich mee wanneer de release live gaat.

Advies

Mijn advies luidt: communiceer op tijd! Een project of systeem dat onderdeel is van een keten moet kennisnemen van de data die het produceert en consumeert.

Wat is de data flow? Wie produceert wat wij consumeren, en wie consumeert wat wij produceren? Is er een overzicht van deze leveranciers? Zijn de processen en specificaties over de gehele keten eenduidig gedefinieerd?

En niet te vergeten: welke afspraken maken we over dataverantwoordelijkheid?

“Assumptions are the mother of all fuckups” is een bekende quote voor testers.
Ik zeg: “Communication is the mother of all solutions”!