Is SaaS gevoelig voor ‘vendor lock-in’?

Is SaaS gevoelig voor ‘vendor lock-in’?

Elke organisatie zou er over moeten nadenken; hoe gemakkelijk kan ik van softwareleverancier wisselen, zonder dat ik heel veel werk voor niks gedaan heb en/of dat werk (deels) opnieuw zou moeten doen?

Veel organisaties weten niet of zij te maken hebben met vendor lock-in en wat de gevolgen hier van kunnen zijn. Ontbreekt hen de kennis, of interesseert hen slechts de prijs?

Met deze blog wil ik je attent maken op de risico’s van vendor lock-in bij SaaS applicaties in het algemeen en beeldbanken in het bijzonder. Ook weet je na het lezen van deze blog en hoe je een vendor lock-in kunt onderkennen én (een volgende keer) kunt voorkomen!

Wat is Vendor lock-in?

Volgens Wikipedia:
“Vendor lock-in maakt een klant afhankelijk van een leverancier voor producten en diensten, omdat hij niet in staat is om van leverancier te veranderen zonder substantiële omschakelingskosten of ongemak.”

Tot zover de definitie.

Wikipedia gaat echter nog een stap verder door M.H. Paapst te quoten (Barrières en doorwerking, Dissertatie Rijksuniversiteit Groningen p. 21-22):

“Om te kunnen spreken van vendor lock-in dient er bovendien sprake te zijn van een superieur of beter alternatief waar de klant naar zou willen overstappen. Zou er geen superieur of beter alternatief zijn dan is de gekozen oplossing optimaal en zal de klant de afhankelijkheid van de leverancier niet beschouwen als een lock-in.”

Deze toevoeging is wat mij betreft een behoorlijk gekleurde mening; ook al zou je het niet erg vinden dat je geen kant op kunt en is er geen superieur alternatief, dan nog betreft het een vendor lock-in. Wanneer je substantiële omschakelingskosten of ongemak ervaart als je eventueel zou overwegen om over te stappen. Een product kan goedkoper of eenvoudiger in het gebruik zijn zonder direct superieur te zijn aan je huidige product. Als je vooraf al wéét dat je vast zit aan je leverancier, kan het ook zijn dat dát je de moed ontneemt om naar een alternatief te gaan kijken. Over vendor lock-in gesproken!

Waarom zou je vendor lock-in erg moeten vinden?

Ik ken genoeg organisaties die er geen enkel probleem mee hebben dat ze met handen en voeten gebonden zijn aan hun leverancier. De grootste groep wéét echter niet dat zij met handen en voeten aan hun leverancier gebonden zijn!

Natuurlijk hoeft het voor nu geen probleem te zijn; het werkt zoals het moet, de leverancier is een toffe peer die niet moeilijk doet over een uurtje hier of daar en je bent nog niet een alternatief tegengekomen die ook maar in de buurt komt van wat zijn product kan.

Regeren is vooruitzien… OK, dat is een dooddoener, maar wel een hele legitieme in deze. Wellicht wil je groeien of juist inkrimpen of heel wat anders? Het kan ook zijn dat het product niet ontwikkeld wordt en dat jij er steeds verder vanaf komt te staan omdat jij wel op de markt anticipeert…

Besef daarbij, dat voor veel bedrijven vendor lock-in een verdienmodel is. De reguliere kosten zijn soms zelfs lager dan de concurrentie, maar als je zakelijk afscheid van elkaar neemt, betaal je vaak het verschil ruimschoots bij. Ik ken gevallen dat er zelfs dubbel afgerekend moest worden, omdat de data uit het oude systeem niet bruikbaar was in het nieuwe systeem.

Er zijn genoeg organisaties die wel wíllen wel overstappen, maar ze kunnen het zich simpelweg niet veroorloven.

Alleen op grote schaal?

Vendor lock-in ben ik al op vele niveau’s tegengekomen. Meestal zijn het grote software pakketten of specialistische software. Onlangs kwam ik er bij een klant achter dat vendor lock-in zelfs zijn intrede heeft gedaan in WordPress thema’s!

Er zijn thema’s die de content van pagina’s en berichten in een eigen tabel wegschrijven die standaard niet uitgelezen wordt als je een ander thema kiest. Hierdoor lijkt het dus alsof je content verdwenen is. Het bedrijfje uit India kan je tegen een tarief helpen met het omzetten naar een ander thema, maar adviseert om een thema van hen te gebruiken om het probleem te voorkomen.

Nu gaat dit voorbeeld om tientjeswerk en is met een beetje (SQL-)handigheid de data zelf uit de database te halen, maar het wachten is op het thema die de content gecodeerd wegschrijft.

De overheid en grote bedrijven zijn meer bedacht op vendor lock-in en nemen de overdracht van content meestal op in hun contracten, maar ook daar komt het nog te vaak voor dat men met handen en voeten gebonden zit aan een leverancier. Door dergelijke constructies ben je als organisatie aanvankelijk wel goedkoper uit (niet zelden is er ook sprake van koppelverkoop), maar kun je niet eenvoudig overstappen naar een andere leverancier mocht je ontdekken dat de geboden oplossing wellicht niet zo goed aansluit bij jouw behoefte en werkwijze.

Natuurlijk kun je altijd overstappen, maar daar heb je de medewerking van de leverancier voor nodig en, dat kun je al raden, die laat zich daar dan vorstelijk voor betalen. Bovendien is het meestal zeer specifiek gemaakt en is het niet zo maar over te nemen in een ander systeem, waardoor de kans aanwezig is, dat je met onbruikbare content zit. Wat zo goedkoop leek, blijkt nu dus mega duur te worden en dus blijven de meeste organisaties maar zitten waar ze zitten…

Hoe voorkom je het?

Nog een dooddoener dan maar? Voorkomen is beter dan genezen.

Je kunt in je contracten opnemen, dat de content altijd kosteloos uit het systeem gehaald kan worden in een door de opdrachtgever aan te geven formaat in het geval er over gestapt wordt naar een andere leverancier. Hiermee ben je al een heel eind.

Een andere mogelijkheid is, om te eisen dat de programmatuur de content behandeld volgens industriestandaarden.

Wat is nu eigenlijk je eigendom?

De content die je uit naam van je bedrijf in een systeem hebt gezet is en blijf altijd het eigendom van je bedrijf, tenzij daar andere afspraken over gemaakt zijn (contract!). In beeldbanken bestaat content niet alleen uit de documenten, foto’s, etc. maar ook nadrukkelijk de metadata die je aan deze bestanden gekoppeld hebt. Het is dus van groot belang om vast te leggen dat je alle vormen van content in een algemeen bruikbaar formaat teruggeleverd krijgt van de leverancier na beëindiging van het contract. En dus ook de metadata voorzien van een koppeling naar het bestand waaraan de metadata gekoppeld is, indien noodzakelijk.

Natuurlijk kun je nog discussiëren over wat een “algemeen bruikbaar formaat” is, maar het aansluiten bij industriestandaarden is een gangbare eis. Een leverancier zou hier geen geld voor mogen vragen.
Het wordt een ander verhaal als je de leverancier vraagt een transitie te doen naar je nieuwe leverancier. Dit kan een complex traject zijn wat niet zonder meer kosteloos uitgevoerd kan worden.

Wat zijn industrie standaarden voor een Beeldbank?

Voor beeldbanken zijn er een aantal industriestandaarden aan te wijzen. Voor bestanden is het meestal niet zo moeilijk; het formaat wat je hebt geüpload is ook het formaat waarin je het terug zou moeten krijgen. Voor metadata ligt het een stuk minder eenvoudig. Voor zowel de organisatie als voor de leverancier is dit het goud van het product en er is dus een groot belang om dit goed te beschrijven.

Niet elke leverancier van beeldbanken werkt op dezelfde manier, waardoor er dus verschillen ontstaan in het terugleveren. De opslag van metadata valt in 3 varianten uiteen;

• sidecar-bestand

• database

• in de file zelf

Wat de voor- en nadelen zijn van deze verschillende werkwijzen komt wellicht in een latere blog aan de orde, maar voor het terugleveren van elk van deze 3 zijn de nodige aandachtsgebieden.

Sidecar-bestand

Dit is een los bestandje welke vaak dezelfde naam heeft als het bestand waarover het gaat, maar met een andere extensie. Soms bevat het ook een preview van het bestand en dan is de extensie meestal THM (thumbnail). Andere veel voorkomende extensies zijn: XMP, IPT, IPTC, XML, MIE, en INFO.

Vaak zijn sidecar bestanden gewone tekstbestanden, maar ik ben ook al wel vaker tegengekomen dat deze bestandjes gecodeerd zijn weggeschreven en dan moet je toch al weer snel denken aan vendor lock-in…

Het inlezen en eventueel decoderen kan een tijdrovende klus zijn, want het gaat meestal om erg veel bestanden.

Database

Wanneer metadata in een database zit, kan dit vaak eenvoudig geëxporteerd worden naar een ander databaseformaat of zelfs een tekstbestand of Excel. Dit werkt meestal vrij eenvoudig en kost ook niet veel tijd. Het exporteren van duizenden regels uit een tabel kost vaak slechts een paar uur.

In de file zelf

Dit is de meest eenvoudige oplossing van allemaal en heeft daarom ook de voorkeur.

Vrijwel alle bestanden ondersteunen het schrijven van metadata in de file zelf volgens de codering van IPTC/XMP. Het grote voordeel van het opslaan van metadata in de file is, dat je bij het ontvangen van de bestanden, ook gelijk alle metadata in de bestanden hebt zitten. Je hoeft dus niks meer te koppelen of uit te zoeken.

In de praktijk

Zoveel leveranciers, zoveel wijzen voor het opslaan van metadata. Nogal wat goedkope systemen maken het je niet makkelijk om foto’s inclusief de metadata te extraheren.

Metadata staat dan in een database en wordt dan vaak via een omweg in een complex eigen formaat weggeschreven,wat niet standaard te gebruiken is door een ander systeem.
Het omzetten, herstructureren en importeren van dit formaat in een nieuwe beeldbank gaat als snel in de vele honderden, zo niet duizenden euro’s lopen. Veel organisaties zien dit niet zitten en stappen maar niet over.

Beeldbanken die aansluiten bij de industrie standaarden IPTC/XMP hebben een voorsprong. Niet alleen wordt de metadata herkent door andere programma’s (zoals Adobe Photoshop), je bent ook verlost van conversies en dure uren!

Je kan dus direct na het overhevelen van de content naar de nieuwe leverancier onmiddellijk verder waar jij gebleven was zonder grote export en import kosten! En nog belangrijker… Géén vendor lock-in!

Moet je er altijd uit ontsnappen?

Zoals ik al schreef, hoeft vendor lock-in geen probleem te zijn als je tevreden bent met de situatie.
Wel adviseer ik altijd dat je moet informeren naar de kosten en voorwaarden van het terugleveren. Uiteraard ruim vóórdat je er werkelijk mee bezig gaat. Leveranciers die vendor lock-in als verdienmodel hebben, kunnen het ruíken wanneer je haast hebt of ze wéten het omdat je contract afloopt… In die situatie zul je altijd de hoofdprijs betalen.

Je hoeft dus niet per sé te ontsnappen uit een vendor lock-in, maar zorg er voor dat je wéét of je in een vendor lock-in zit en wat het je kost om er uit te komen.

Conclusie

Op zich is SaaS niet gevoeliger voor vendor lock-in dan niet-SaaS oplossingen, maar doordat het gehele systeem buiten de deur draait kan het wel als gevoeliger aanvoelen. Belangrijk is voor je een contract afsluit, vragen te stellen over het terugleveren van content en de bijkomende kosten. Laat dit ook vastleggen!

Zit je toch gevangen in een vendor lock-in, dan zijn er vaak nog wel mogelijkheden om hier (onder-)uit te komen. Wat je vooraf moet vaststellen zijn de volgende zaken;

• hoe bedrijfskritisch is de informatie

• hoeveel tijd heb je tot het einde van het contract

• wat doe je met de nieuwe content in de tussentijd

• kun je er nog samen met de leverancier uitkomen

• wat is je budget om je content veilig te stellen

• welke rol kan je nieuwe leverancier spelen

Weet je het niet zeker of je makkelijk kunt overstappen? Vraag het je leverancier en laat desnoods een onafhankelijke derde er naar kijken. DAMsupport is je hierbij graag van dienst.