Vendor lock-in bij SaaS-oplossingen wordt de laatste tijd nogal eens als risico van SaaS geschetst. Terecht, want lock-in is altijd een probleem; bij een pakket, bij SaaS en ook bij zelfgebouwde oplossingen. Maar het is te vermijden.
Vendoer lock-in kan worden tegengegaan als de volgende vier regels worden toegepast:
1. Kies alleen SaaS-oplossingen waarbij je ondubbelzinnig eigenaar van de data bent en blijft.
2. Zorg voor een model (bijvoorbeeld een objectmodel) waarin de business beschreven is en projecteer dat op het model van de leverancier. Dit is nodig voor conversies, voor koppelingen en voor de exit-strategie.
3. Kies alleen SaaS-oplossingen met goede interfaces. Niet alleen user-interfaces, maar ook API's voor dataverkeer en integratie.
4. Gebruik die API's vervolgens zo min mogelijk. De kracht van SaaS zit vooral in de lage kosten en investeringen. Gooi dat voordeel niet weg door niet echt noodzakelijke integratie zelf te bouwen, want daarmee lock je jezelf in.
En eigenlijk is er nog een vijfde regel: doe geen water bij de wijn, ook niet als dat op korte termijn voordelen biedt.
Als je dit doet, dan is lock-in een beheersbaar risico. En de Pavlov-reactie van ict'ers om dan maar zelf iets te gaan bouwen, maakt het erger. Misschien wordt de vendor lock-in iets minder, maar de maatwerk lock-in wordt des te groter.
Goed stuk, klopt als een bus.
SaaS is namelijk gewoon software en vrijwel alle software heeft een vorm van lock-in. Als het niet qua vendor is, dan is het wel qua mogelijkheden. Soms is er niks mis met de vendor maar heb je inmiddels iets nodig dat 10x zo veel kan.
Deze adviezen impliceren wel dat je uitgaat van SaaS toepassingen waarbij de data nog bruikbaar is als het ge?xporteerd wordt. Voor dingen als administratieve software, simpele CRM en eenvoudige database-applicaties is dat wel zo, maar bij ingewikkelder software waar je heel veel kanten mee uit kan en waar je veel zelf kan inrichten, wordt dat steeds lastiger. (maar dus ook steeds belangrijker).
Additionele adviezen?
Als je vendor lock-in wilt vermijden moet je eigenlijk bij aanschaf kijken of een exit een serieuze optie is. Anders kun je maar beter de gok nemen dat het wel goed zal komen tegen die tijd.
Als je een goede exit wilt checken:
Test de exporteermogelijkheden voordat je het koopt. Test met real-world data, 1 testrecordje exporteren werkt altijd wel.
Bekijk de data die eruit komt en bekijk de documentatie die je erbij krijgt. Eventueel met hulp van een deskundige. Soms komt er data uit het systeem die zo krankzinig ingewikkeld is dat je weer een half computersysteem moet ontwikkelen om het elders in te lezen. Dat wil je voor zijn.
Laat de deskundige checken of er ID-velden meekomen in de export, want die bepalen of de data die je uit je database krijgt, elders weer in elkaar kunt zetten. We krijgen als ontvangende partij vaak te maken met data waarin alle inhoud wel staat, maar de ID velden ontbreken of incompleet zijn, waardoor je er soms toch niks mee kan.
Soms komt bij een export niet alle data mee. Berucht zijn externe bestanden, afbeeldingen en andere binaire data. Ook vaak een probleem: lange velden worden soms afgekapt na een aantal tekens.
Berucht zijn systemen waarbij de gebruiksmogelijkheden wel ge?pgraded zijn, maar de export-tools nog een versie of wat achterlopen. Export van data is vaak een ondergeschoven kindje bij developers en heeft altijd minder aandacht dan de voorkant van de applicatie. Dus als je dan exporteert heb je toch weer onvolledige data waar je niks mee kan.
Ook berucht: soms kun je met een systeem elk stukje data maar 1x exporteren en dan niet meer. Dan moet de leverancier moet in de database gaan rommelen en dan kan het weer 1x. Vraag of dat hier zo is.
Als de data als XML te exporteren is, is dat een groot pluspunt, maar ook hier weer: check de exports. Want veel systemen die zeggen dat ze XML exporteren, exporteren onbruikbare data-rommel die niet zonder handmatig schoonmaken op een ander systeem in te lezen is.
Een grote database met jaren aan verzamelde data kan zo’n enorme hoeveelheid data produceren dat je tegen praktische bezwaren aanloopt: te groot om te downloaden via internet, past niet op een DVD, het ontvangende systeem loopt uit z’n geheugen en crasht of wordt extreem langzaam. Stel hier vragen over bij de leverancier.
Kijk vooral uit met leveranciers die zeggen: “we geven je wel een mysql exportje, dan kan je het overal weer inlezen”. Dat betekent dat ze niks geregeld hebben en ga je van alle hier genoemde gevaren stevig last krijgen en alle rariteiten van de applicatie zelf mag gaan ontdekken.
Als je van applicatie gaat wisselen is namelijk niks zo onbruikbaar als de originele database. Meestal heb je helemaal niks aan de database zonder de applicatie, want elke database bevat rariteiten, evolutie en ingewikkelde regels. Welk merk database men gebruikt doet dus niet ter zake. Een goede exportmogelijkheid moet je hebben.
De allergrootste vraag is dan toch wel: ik weet dit allemaal wel, omdat ik er veel mee te maken krijg. Als je zelf niet deskundig bent op dat gebied, hoe vind je die deskundige die er wel verstand van heeft? Dat is pas echt een lastige vraag.