Wat is vendor lock-in?
En hoe kunt u dit voorkomen?

Stelt u zich voor dat u de aanbieder bent van een SaaS product. Dit betekent dat uw software letterlijk de backbone van uw onderneming is. U heeft een goede relatie met uw klanten en eindgebruikers en zij voorzien u graag van feedback. Uw software ontwikkelaar is echter niet in staat om deze feedback tijdig te verwerken in uw product. U stelt uw klanten dus teleur en het is duidelijk waar de bottleneck zit. Bij uw software ontwikkelaar. U oriënteert zich, vanzelfsprekend, op een andere partij. Echter, uw software product is op een zeer specifieke manier ontwikkeld op een obscuur framework waar uw huidige ontwikkelaar een groot fan van is. Dit betekent dat een nieuwe ontwikkelaar uw huidige product moet gaan vertalen naar een gangbaar framework en geaccepteerde taal. Dit kan aanzienlijke kosten met zich meebrengen. Een aanzienlijke drempel om van leveranciers te wisselen, het zou mogelijk kunnen zijn dat u een dergelijke investering niet kan opbrengen. U zit vast en bent zeer beperkt in uw vermogen om te innoveren.

Kies voor geaccepteerde frameworks om vendor lock-in te voorkomen.

Letterlijk vertaald is een framework een kader. Binnen dat kader kan gebruik gemaakt worden van voorgeprogrammeerde generieke functionaliteit waar onze developers als het ware specifieke code ‘bovenop bouwen’. Zo werken zaken als authenticatie, login ondersteuning en database connecties ‘out-of-the-box’.

Het kader dat een framework ons biedt heeft ook een positieve, standaardiserende, invloed op het ontwikkelproces. Het framework is opgezet om op een bepaalde manier gebruikt te worden. Het team volgt de standaard en hoeft geen onderlinge afspraken te maken, die zijn er immers al. Iets wat de efficiency en kwaliteit van het teamwork ten goede komt.

Het ene framework is het andere niet. Sommige van deze frameworks zijn klein en wat obscuur terwijl andere groot, breed geaccepteerd en continu ontwikkeld worden. De meeste developers kunnen moeiteloos met een dergelijk framework aan de slag.

Kies voor geaccepteerde talen om vendor lock-in te voorkomen.

Er zijn in de wereld meer dan 250 programmeertalen. Voor een lijstje klikt u hier. Deze zijn natuurlijk lang niet allemaal relevant. Verre van zelfs. Toch hebben relatief veel kleine of zelfs obscure programmeertalen een trouwe schare aanhangers. De keuze voor een minder geaccepteerde programmeertaal kan in sommige gevallen vendor lock-in tot gevolg hebben. Simpelweg omdat de meeste software ontwikkelaar niet bekend zullen zijn met deze programmeertalen. De meeste ervaren software ontwikkeling bedrijven zullen aan de slag kunnen met talen als (bijvoorbeeld) Java, Javascript, PHP, Phyton, C# of Perl. Voor een taal zoals Limbo geldt dit in de meeste gevallen niet.

De keuze voor een niet breed geaccepteerde programmeertaal kan u en uw onderneming in meer of mindere mate afhankelijk maken van de ontwikkelaar die u deze taal adviseert. Het omgekeerde is gelukkig ook waar, als u platform of product gebouwd wordt op basis van een breed erkende programmeertaal dan is wisselen van software ontwikkelaar relatief gemakkelijk.