Vendor lock-in voorkomen: hoe open moet jouw data eigenlijk zijn?

Wie werkt aan informatiemanagement, komt al snel uit bij dezelfde ambitie: voorkomen van vendor lock-in. Het is bijna een modewoord aan het worden. Maar hoe zit het eigenlijk echt?

Van de energiesector tot de maritieme sector: organisaties investeren in Knowledge Graphs, Object Type Libraries (OTL’s) en datastandaarden om informatie beter te structureren en systemen met elkaar te laten samenwerken.

Toch is vendor lock-in minder zwart wit dan vaak wordt gedacht. Het gaat niet alleen om de vraag of data wel of niet toegankelijk is. De relevante vraag is: kun je informatie inclusief betekenis, relaties en rechten gecontroleerd meenemen naar een andere omgeving? Laten we hier verder in duiken. Aan het einde van de tekst sluiten we af met een FAQ.

Wanneer ontstaat vendor lock-in in de praktijk?

Vendor lock-in ontstaat wanneer data, processen en een datamodel zo sterk aan één applicatie zijn verbonden dat overstappen ingewikkeld wordt. Op papier is de informatie vaak eigendom van de organisatie. De uitdaging begint zodra die informatie moet worden geëxporteerd.

Een export bestaat dan bijvoorbeeld uit losse tabellen, technische bestanden of velden zonder onderlinge samenhang. Juist deze samenhang maakt informatie bruikbaar: welke informatie staat erin en hoe is deze aan elkaar gerelateerd. De gegevens zijn beschikbaar, maar de gebruiker kan er niets mee als de definitie en de structuur niet meegeleverd wordt.

Dan ontstaat een gouden kooi. De “eigen” data lijkt beschikbaar, maar zonder het oorspronkelijke systeem is de waarde beperkt.

Is volledig open data altijd de beste oplossing?

Uit angst voor gesloten systemen kiezen organisaties soms voor de andere uiterste positie: volledige openheid. Dat kan uitstekend werken bij openbare registers, datasets die breed hergebruikt mogen worden of voor datasets binnen organisaties waarvoor geen (uitgebreide) autorisatie structuur noodzakelijk is.

Binnen complexe organisaties, projecten en infranetwerken ligt dat anders. Daar spelen vertrouwelijkheid, contractuele afspraken, security, privacy en eigenaarschap een belangrijke rol. In deze situaties is het zelfs onwenselijk dat iedereen alle data vrij kan bevragen en bewerken.

Open data zonder duidelijke autorisatie kan juist zorgen voor minder overzicht, minder veiligheid en minder controle over de bron. Daarbij is ook het eerdergenoemde punt over openheid van definitie en structuur net zo belangrijk. Zonder dat is de data nog steeds gesloten.

Bestaat er software die vendor lock-in voorkomt en tegelijkertijd werkbaar blijft?

Je zoekt software die data kan uitwisselen zonder samenhang, betekenis of grip op de informatie te verliezen. Een exportknop alleen volstaat niet.

Veel leveranciers beloven vrijheid van vendor lock-in. Uiteindelijk leveren zij tabellen die teams opnieuw moeten koppelen en vertalen. De afhankelijkheid van het systeem verandert dan in een kostbaar herstelproces. Bovendien is de kans aanwezig dat door deze translatie er sprake is van dataverlies, als de beschikbare data niet in de gewenste structuur overgezet kan worden.

De betekenis van data mag niet veranderen als het de software verlaat. Technisch moet een oplossing daarom drie zaken bieden:

• Open API’s en technisch goed leesbare formaten zoals JSON-LD voor koppeling, export en hergebruik.
• Behoud van semantiek, inclusief relaties, context, metadata en validatieregels.
• Fijnmazige governance met rollen, projectrechten, filters en een audittrail.

Er bestaat zeker software die dit mogelijk maakt, zoals Datastorms. Maar hoe sluit Datastorms aan op deze drie voorwaarden?

Hoe combineert Datastorms openheid met regie?

Datastorms kiest bewust voor zoveel mogelijk openheid, met governance als uitgangspunt. Data kan laagdrempelig worden ontsloten via toegankelijke API’s en standaardformaten zoals JSON. We groeien naar Linked Data toe. Totdat we het summum hebben bereikt, leveren we naast de JSON ook de datamodel-informatie. Zo blijft koppelen met andere systemen mogelijk en verdwijnt het datamodel niet in een black box.

Tegelijkertijd bepalen gebruikersrollen, contextfilters en projectrechten wie informatie mag bekijken, aanpassen of exporteren. Data is beschikbaar voor de juiste persoon, binnen de juiste context en op het juiste moment.

Dat noemen wij Governance by Design.

Waarom is semantiek belangrijk bij data-uitwisseling?

Een traditionele export lijkt vaak op een stapel losse bladzijden. De woorden zijn aanwezig, maar het verhaal ontbreekt. Zonder betekenisvolle relaties tussen objecten, documenten, eisen en processen moet de ontvangende partij zelf opnieuw uitzoeken hoe alles samenhangt.

Datastorms houdt die semantiek zo dicht mogelijk bij de data. Dankzij de graphstructuur blijft zichtbaar welke informatie met elkaar verbonden is. De combinatie van deze graphstructuur van de database en het platform Datastorms an sich kunnen daarom ingezet worden als slimme datahub om gegevens uit Applicatie A te vertalen naar de gemeenschappelijke taal van een organisatie en gestructureerd af te leveren in Applicatie B.

Wat betekent vrijheid van data echt?

Vendor lock-in voorkomen betekent dus niet dat iedereen altijd overal bij moet kunnen. Het betekent dat een organisatie zelf de regie houdt over haar informatie, zonder afhankelijk te worden van één gesloten systeem.

Data is pas echt van jou wanneer je ook de definitie en structuren ervan weet, je kunt bepalen hoe je het gebruikt, deelt, overdraagt en beschermt. En wanneer je weet wie de sleutel krijgt.

Hierbij de sleutel tot het voorkomen van vendor lock-in: Datastorms