Luc Scheidel: Stop de dataduplicatie

Stop de dataduplicatie


Moet de logistieke keten in een blockchain? Gaan we met API’s telkens terug naar de bron? Of is het beter als we gewoon de good old Cargo-IMP ‘message technology’ blijven gebruiken? Daar is veel discussie over. Maar naarmate ik ouder word, en dus meer ervaring opstapel, ben ik meer geneigd om kennis uit het verleden toe te passen op nieuwe ontwikkelingen.

Toen

Even graven in het geheugen. Toen de computer zijn intrede deed, begon ook het massaal aanleggen van bestanden. Ted Codd ontwikkelde in de jaren zeventig van de vorige eeuw een manier om daar zo slim mogelijk mee om te gaan. Als IBM-ingenieur wilde hij opslagruimte beperken, want dat was duur. Tegelijkertijd wilde hij inconsistenties en fouten voorkomen.

Hoe zijn methode werkte? Een voorbeeld: als de naam van een klant in verschillende bestanden verwerkt wordt, dan is de kans groot dat er schrijffouten ontstaan. En als die klant zijn naam wijzigt, moet je dat op veel plekken aanpassen. Codd stelde voor om data te ‘normaliseren’. Oftewel: de naam van een klant staat in het klantenbestand. En alle andere bestanden verwijzen daarnaar. Zo hoef je er maar op één plek voor te zorgen dat de data klopt. En een aanpassing is simpel door te voeren. IBM deed trouwens aanvankelijk niets met dit idee. Larry Ellison ging ermee aan de haal en richtte Oracle op.

Nu

In de huidige logistieke keten doen we het anders. De verzender vertelt via zijn ERP-systeem welk product hij verstuurt. Die informatie wordt gekopieerd en doorgegeven in de keten via Cargo-IMP. En vaak worden die data gaandeweg aangepast. Maar er zijn ook veelbelovende nieuwe technologieën om data te delen.

Met een Application Programming Interface (API) krijg je bijvoorbeeld gecontroleerd toegang tot andere data-sets. Een Uniform Resource Identifier (URI) wijst je naar de plek waar data te halen is. En er zijn encryptietechnieken die ervoor zorgen dat alleen de bron en de ontvanger de inhoud van de data kennen. IATA is al bezig om de dataformaten in ONE Record te definiëren. En iShare, dat ontwikkeld is door de Nederlandse Topsector Logistiek, zorgt ervoor dat data eigenaar bepaalt in welke handen het komt.

Wat kunnen we ermee? Volgens Codd is het beter om telkens terug te gaan naar de bron. Met deze moderne technologieën kan dat steeds beter. Maar Codd maakte ook een uitzondering als dat opvragen van de data te lang duurt. Als de performance in gevaar kwam, was het toegestaan om kopieën te maken. Vertalen we dat naar onze logistieke keten, dan zijn de port community systemen (PCS) de manier om dat gecontroleerd te doen. Met een kopie in de Information Exchange van Cargonaut is de kwaliteit geborgd.

Blockchain werkt net even anders. Daar krijgen alle deelnemers in de keten een kopie van de data. Voor wijzigingen in die data is een proces afgesproken: er moet ‘onderhandeld’ worden. Geen ‘normalisatie’ dus. Moeten we Blockchain dan maar meteen bij het oud vuil zetten? Dat is ook niet nodig. Blockchain is geen oplossing voor gewone zendingsinformatie. Maar er zijn toepassingen denkbaar met veel minder data waarbij alle partijen willen meekijken of de data echt klopt. Dan lonen de extra opslagruimte van een blockchain en het dure onderhandelingsmechanisme wel.

En de toekomst?

Wat mij betreft combineren we de normalisatieprincipes van Codd met de technologie die we voorhanden hebben en nemen zo snel mogelijk afscheid van Cargo-IMP. En dus ook van het kopiëren van berichten. We regelen toegang tot de databron via API’s en we gebruiken URI’s om ons de weg te wijzen. Alleen als de performance in gevaar komt, maken we onderweg slimme kopieën via onze Information Exchange en andere PCSen. En voor toegang tot een beperkte set vertrouwelijke data gebruiken we een blockchain. Ik denk dat Codd vanuit zijn graf daar wel een ‘thumbs-up’ voor zou geven.

Auteur: Luc Scheidel