Voor veel bedrijven is dat geen dramatische uitspraak maar een letterlijke beschrijving. Er staat een backofficepakket in het hart van de organisatie. Alles loopt erdoorheen. En de partij die bepaalt wat ermee kan, zit niet bij jou aan tafel. Dat heet vendor lock-in, en in dit artikel leg ik uit hoe je erin terechtkomt, waarom je leverancier geen haast heeft, en hoe je eruit komt zonder alles opnieuw te bouwen.
Ik heb een groot deel van mijn tijd als developer gewerkt met dat soort systemen. Niet zelfgebouwd, maar gekocht en ingericht. Het soort software waar je niet in hoort te programmeren.
In de praktijk was dat precies wel gebeurd.
Wat is vendor lock-in?
Vendor lock-in betekent dat de kosten of de moeite om over te stappen naar een andere leverancier zo hoog zijn geworden dat je er in de praktijk niet meer uit komt. Niet omdat het contractueel verboden is, maar omdat je data, je processen en je kennis vastzitten in een systeem dat je niet zelf beheert.
Het ontstaat zelden door een bewuste keuze. Het groeit.
Hoe kom je hier terecht?
Zo'n pakket wordt over de jaren opgerekt. Via instellingen, custom velden en macro's groeit het uit tot een soort programma dat niemand ooit als programma heeft ontworpen. Het beheer zit meestal niet bij ontwikkelaars, maar bij een paar mensen die toevallig expert op dat pakket zijn geworden. Officieel geen programmeurs. In de praktijk de enigen die weten waarom het systeem doet wat het doet.
Je moest ergens een vinkje aanzetten, omdat er anders verderop iets gebeurde wat niet de bedoeling was. Waarom die twee met elkaar te maken hadden, kon niemand uitleggen. Je wist het alleen omdat het ooit een keer was misgegaan.
Het duidelijkste signaal zag ik bij aanpassingen. De vraag was zelden "klopt dit" of "is dit wat we willen". De vraag was "is de uitkomst nog hetzelfde als eerst". Dit was het resultaat, en dat moest zo blijven.
Op dat moment ben je het stuur kwijt. Je vraagt niet meer waar je heen wilt, je vraagt of het nog mag van het systeem. En je vraagt het aan een handvol mensen die als enige snappen hoe die laag in elkaar zit. Gaan zij weg, dan nemen ze het stuur mee.
Dit is geen incident. Het gebeurt bij ANVA, Autoline, SAP, Salesforce en Exact. Overal ontstaat dezelfde stille laag van maatwerk waar het hele bedrijf ongemerkt van afhankelijk raakt.
Waarom heeft je softwareleverancier geen haast?
Het ongemakkelijke aan vendor lock-in is dit. Zolang jij vastzit, heeft je leverancier geen enkele reden om beter te worden. Het systeem mag verouderd en traag blijven. Jij gaat toch nergens heen.
Je merkt het pas op het moment dat je iets buiten het systeem om wilt doen. Een koppeling. Een automatisering. Je data ergens anders naartoe brengen. Juist de dingen die je minder afhankelijk maken, staan apart op de rekening. Je betaalt om te mogen vertrekken.
En als je dan mag koppelen, kan het vaak alleen op verouderde manieren. Geen events om op in te haken, alleen een trage export of een slecht gedocumenteerde interface uit een ander tijdperk. Ik heb gewerkt met een systeem waarvan de API zo traag was dat je hem niet live kon gebruiken voor een klantomgeving. De enige werkbare route was een volledige kopie van de data ernaast zetten. Zelfs het terugschrijven bleef traag. Dat systeem was er nooit voor gemaakt om die data naar buiten te laten.
Met vijftig klanten is dat geen probleem. Dan wil je vooral een pakket dat alles regelt en waar je verder niet over hoeft na te denken. Volkomen logisch.
Met vijfhonderdduizend klanten ligt het anders. Dan wil je dat die klanten hun eigen zaken online regelen, en dan heb je systemen nodig die dat aankunnen. Dat lukt niet met een schermpje op een Windows-computer.
Maar dit systeem is toch onze core business?
Dit is de zin waar het gesprek meestal strandt. Het systeem is te belangrijk, te verweven, te veel het hart van de zaak. Dus we kunnen er niet vanaf.
Ik denk dat die redenering precies verkeerd om staat.
Je core business zijn je klanten, je contracten, je prijsafspraken en je historie. Dat is het bedrijf. Het pakket is de kast waar het toevallig in ligt, en de sleutel van die kast ligt bij iemand anders.
Hoe belangrijker dat systeem is, hoe minder acceptabel het wordt dat een externe partij bepaalt in welk tempo je vooruit kunt. Het belang is geen argument om stil te blijven zitten. Het is het argument om er wel iets aan te doen.
En de data in je backoffice is niet de data van je backoffice. Het is jouw data.
Moet je dan alles opnieuw bouwen?
De tweede reden dat bedrijven stil blijven zitten, is dat ze maar twee opties zien. Blijven waar je bent, of alles opnieuw bouwen.
Dat tweede is zelden een goed idee. Opnieuw beginnen betekent alles in n keer vervangen en pas aan het eind zien of het klopt. Dat is geen plan, dat is een gok met je hele bedrijf als inzet.
Fred Brooks beschreef dat risico al in 1975, in The Mythical Man-Month. Hij noemde het het second-system effect: het systeem dat je bouwt om het oude te vervangen, is vaak het gevaarlijkste dat je ooit maakt. Je weet inmiddels wat er allemaal beter kan, dus je propt er alles in waar de eerste keer geen tijd voor was. Het wordt ambitieuzer dan nodig en valt daardoor vaker om dan het systeem dat je wilde vervangen.
Moderniseren hoeft niet hetzelfde te zijn als herbouwen.
De derde optie: een laag om het oude systeem heen
Bijna altijd kun je een moderne laag om het oude systeem heen bouwen. Je maakt je data beschikbaar op een plek waar je er wel vrij mee kunt werken, en daar bouw je het nieuwe op. Het oude systeem blijft voorlopig gewoon draaien als bron. Er is geen moment waarop alles tegelijk om moet, en dus ook geen moment waarop alles tegelijk kan omvallen.
Deze aanpak heeft een naam: het strangler pattern, naar de wurgvijg die om een boom heen groeit en hem uiteindelijk vervangt. Je bouwt eromheen, neemt functionaliteit stuk voor stuk over, en op enig moment doet het oude systeem niets meer.
Wat je daarna doet, hangt af van je situatie. Blijft het leverancierspakket, dan leef je ernaast: het oude doet waar het goed in is, jij haalt je snelheid uit de laag eromheen. Moet het systeem op termijn weg, dan is diezelfde laag je migratiepad. Je neemt het werk er stuk voor stuk uit over, tot er niets meer in gebeurt en je het kunt uitzetten.
Wat kun je deze week doen?
Stel je leverancier n vraag, en accepteer geen antwoord in de trant van "dat kan zeker".
Kunnen we onze volledige klantgegevens en historie eruit halen, in een bruikbaar formaat, zonder jullie hulp? Wat kost dat, en hoe lang duurt het?
Het antwoord is de prijs van je vrijheid. Als niemand die prijs kent, weet je nu al genoeg.
Stel daarna dezelfde vraag intern. Hoeveel van de kennis over hoe dat systeem werkt, zit in de hoofden van twee mensen? Als je op die vraag geen fatsoenlijk antwoord hebt, heb je geen leveranciersprobleem maar iets wat dichter bij huis ligt.
Kijk bij een systeem dus niet alleen naar wat het allemaal kan. Kijk ook naar hoe makkelijk je er weer vanaf komt als het niet meer bij je past. Dat moment komt.
Veelgestelde vragen over vendor lock-in
Wat is een voorbeeld van vendor lock-in?
Een backofficepakket dat over de jaren is opgerekt met custom velden, macro's en instellingen, waarbij niemand meer precies weet waarom bepaalde onderdelen met elkaar samenhangen. Zodra je data eruit wilt halen of ergens aan wilt koppelen, blijkt dat alleen te kunnen via een trage export of een slecht gedocumenteerde interface, en staat het apart op de rekening.
Hoe herken je dat je vastzit aan je softwareleverancier?
Het duidelijkste signaal is de vraag die gesteld wordt bij een aanpassing. Gaat het over "is dit wat we willen", dan zit je goed. Gaat het over "is de uitkomst nog hetzelfde als eerst", dan bewaak je een systeem in plaats van dat het jou dient. Een tweede signaal: als je niet weet wat het kost om je data eruit te halen, ken je de prijs van je vrijheid niet.
Hoe voorkom je vendor lock-in?
Bij de keuze van een systeem kijk je niet alleen naar wat het kan, maar ook naar hoe je er weer vanaf komt. Vraag vooraf wat een volledige export kost, in welk formaat die komt en of relaties en historie behouden blijven. Zorg daarnaast dat de kennis over de inrichting niet bij twee mensen zit.
Moet ik mijn hele systeem vervangen om eruit te komen?
Bijna nooit. Een volledige herbouw is de duurste en meest risicovolle route, omdat je alles in een keer vervangt en pas aan het eind ziet of het klopt. Met een strangler pattern bouw je een laag om het oude systeem heen en neem je functionaliteit stapsgewijs over, terwijl het oude systeem gewoon blijft draaien.
Wat is het strangler pattern?
Een moderniseringsaanpak waarbij je een nieuwe laag om een bestaand systeem heen bouwt en daar stap voor stap functionaliteit naartoe verplaatst. Het oude systeem blijft aanvankelijk de bron van waarheid en wordt pas uitgezet als er niets meer in gebeurt. De naam komt van de wurgvijg, die om een boom heen groeit en hem uiteindelijk vervangt.
Het systeem mag van iemand anders zijn, je bedrijf niet
Vendor lock-in is zelden het gevolg van een slechte keuze. Het is het gevolg van jarenlang oprekken zonder dat iemand bijhield wat de uitweg zou kosten. Dat is te herstellen, maar alleen als je de vraag stelt voordat je hem nodig hebt.
Wil je weten hoe je systeem ervoor staat en wat een stapsgewijze modernisering in jouw situatie zou betekenen? Lees hoe wij software moderniseren of maak kennis met je toekomstige tech-team.