Wat is een vendor lock-in?
Om te beginnen is het belangrijk om een goede beschrijving te geven van vendor lock-in. Vendor lock-in betekent dat klanten in meerdere of mindere mate afhankelijk zijn en blijven van een bepaalde leverancier. Bijvoorbeeld, klanten kunnen niet eenvoudig van het ene product naar het andere overstappen. Daarnaast kan het wijzigen of toevoegen van functionaliteit niet langer mogelijk zijn, of slechts beperkt. Dit is iets waar je altijd de leverancier voor nodig zult hebben om aan te pakken.
Bij elke technologie is er altijd een zekere mate van vendor lock-in. Zelfs open-source software kent een bepaalde vorm van lock-in. Vaak zijn er geen licentiekosten en is er soms niet eens een leverancier, maar er is wel sprake van een technologische lock-in. Je gebruikt het product omdat het iets specifieks kan doen. Bij elke overgang verlies je deze mogelijkheden, of moet je ze op een iets andere manier opnieuw implementeren. Hierdoor heb je altijd transitiekosten.
Wat het meest van belang is, is dat een leverancier de vendor lock-in zoveel mogelijk beperkt en klanten/gebruikers de mogelijkheid biedt om over te stappen naar een andere leverancier of product. Dit betekent dat je kennis en ook de data buiten het product moet (kunnen) opslaan. De zakelijke logica die binnen een applicatie wordt gebruikt, moet zo transparant mogelijk blijven.
Het is goed om te beseffen dat het principe van lock-in niet alleen van toepassing is op productleveranciers. Een vorm van lock-in kan ook optreden bij diensten wanneer er zeer specifieke kennis bij betrokken is.
Afhankelijk maken, dat is iets wat niemand zou moeten willen.
Zoals gezegd, kent vendor lock-in verschillende perspectieven. Ten eerste, vanuit het perspectief van kennis en hoe deze in een product is ingebed, waardoor het niet langer duidelijk is hoe het product werkt. Ten tweede, vanuit een technologisch perspectief, waarbij afhankelijkheid van een bepaalde technologie het lastig kan maken om over te stappen naar een andere technologie. Tot slot, vanuit het perspectief van afhankelijkheid van een leverancier om aanpassingen te doen.
Als je dit vergelijkt met een USoft-implementatie, zul je zien dat de lock-in zoveel mogelijk wordt beperkt. Een USoft-implementatie heeft hiervoor een aantal belangrijke kenmerken:
- Regels en logica worden op een gestructureerde en nette manier geïmplementeerd, zodat je altijd zowel de definitie als de implementatie kunt terugvinden. De kennis wordt daardoor ook buiten de applicatie opgeslagen, wat kennis lock-in voorkomt.
- Alle gegevens blijven beschikbaar, zelfs buiten het gebruik van USoft. Dit verkleint het risico op technologie lock-in aanzienlijk.
- USoft is een low-code platform. Developers kunnen zelf aan de applicaties werken, wat de afhankelijkheid van USoft-consultants ook minimaliseert.
De logica die binnen de USoft-applicatie wordt uitgevoerd, wordt weerspiegeld in USoft Studio. Voor elk project worden bedrijfsregels en afspraken gedefinieerd en beheerd in USoft Studio. Bedrijfsregels worden in natuurlijke taal gedefinieerd en verduidelijkt met diagrammen. Op basis hiervan is de logica van de applicatie altijd traceerbaar en kan deze worden gerepliceerd in een andere applicatie. Als de softwarelicentie wordt beëindigd, kan er ook een export uit USoft Studio worden gemaakt, waardoor alle informatie voor de organisatie behouden blijft. Concluderend moet er overgangskosten worden gemaakt, maar is er geen lock-in.
Bovendien worden de gegevens die in alle USoft-applicaties worden gegenereerd en/of verwerkt, altijd opgeslagen buiten het USoft-platform in een externe database. Dit omvat alle informatie over de applicatie (metadata), zoals regels en processen. Deze database is altijd leesbaar met externe tools en bevat geen verrassingen. Daarnaast is het volledig inzichtelijk op basis van industriestandaarden zoals SQL en XML. Het datamodel, zoals gedefinieerd in USoft, is 1 op 1 te vinden in de database. Dit maakt het gemakkelijk bruikbaar voor andere applicaties.
Tot slot is het businessmodel van USoft niet gericht op het afhankelijk maken van klanten van de consultancy die door USoft of partners wordt geboden. Het low-code platform van USoft stelt klanten, die eigen businessanalisten en ontwikkelaars hebben, in staat om hen op te leiden in het gebruik van het platform. Op basis hiervan kan de gehele applicatie worden onderhouden en aangepast wanneer nodig.
Langdurige samenwerking is een goede zaak.
Een beetje lock-in is nu ook niet per se slecht. Langdurige samenwerking zorgt ervoor dat er steeds meer wederzijds begrip en gedeelde kennis wordt opgebouwd. Dit stelt USoft in staat om betere oplossingen voor klanten te bedenken en te bouwen. Daarnaast kan ons platform in samenwerking met de klant verder worden ontwikkeld om in lijn te blijven met de behoeften van de klant. De klant verwerft steeds meer kennis van USoft. Na verloop van tijd zal de samenwerking steeds beter worden.
Technische achtergrond
Functies die in USoft zijn gebouwd als bedrijfsregels zullen niet meer werken als USoft uitvalt. De rules engine die de bedrijfsregels uitvoert en beheert, is een integraal onderdeel van het USoft-platform. Dus, als het platform inactief wordt, gaat de functie van de engine verloren. Dit betekent dat de applicatie die de logica uitvoert, opnieuw moet worden gebouwd of vernieuwd. Maar net als bij de datastructuur worden de bedrijfsregels ook op een optimaal leesbare en testbare manier in de database opgeslagen. Niet alleen kan de bedrijfslogica correct worden opnieuw opgebouwd met andere software, maar het is ook mogelijk om te testen of de bedrijfsregels “nog werken”. Aangezien de bedrijfsregels zijn opgebouwd op basis van standaard SQL, kunnen ze worden gebruikt om de nieuwe software te creëren. Omdat alles gebaseerd is op open standaarden, gaat er geen kennis verloren wanneer het gebruik van USoft wordt stopgezet.
Tot slot zijn sommige functies in een USoft-applicatie buiten de rules engine gebouwd, bijvoorbeeld in de CSS- en JavaScript-lagen van webpagina’s. Er geldt een beperkte lock-in voor deze functionaliteit: het is technologie die niet specifiek is voor USoft en alleen op de punten hoeft te worden aangepast waar deze direct communiceert met de rules engine en de onderliggende data.
