View profile

Over legacy software

Jos van Essen
Jos van Essen
De vorige nieuwsbrief kondigde ik het al aan: de meest succesvolle software is software die de tand des tijds weet te doorstaan. En decennia later nog steeds draait. Maar het is ook één die zorgt voor enorme hoofdbrekens in organisaties.
Een tijdje geleden moest mijn zoontje een nieuwe bril. Toen we er eentje bij de opticien hadden uitgezocht nam de dienstdoende opticien ons mee naar een computer en starte een programma op dat verdacht veel leek op Norton Commander. Voor de mensen die daar niet zo'n beeld bij hebben, hier een plaatje:

Norton Commander, een voorloper van de Windows Verkenner in DOS, omstreeks 1995
Norton Commander, een voorloper van de Windows Verkenner in DOS, omstreeks 1995
In dat DOS achtige programma moest ze ons als klant aanmaken, de oogmetingen vanuit het ziekenhuis invoeren en de bestelling plaatsen. Het zag er allemaal vreselijk omslachtig en foutgevoelig uit maar de medewerker wist wat ze deed. Ze vertelde dat er wel meer klanten waren die opmerkingen hadden over dat programma.
De winkelketen waar we de bril kochten was een grote bekende en landelijke naam. Toen ik buiten stond, met geprinte bon in een nogal oud lettertype, begreep ik niet waarom zo'n grote keten toch nog zulke oude software gebruikt om zulke belangrijke zaken te doen: immers: als je met dat programma de verkeerde glazen besteld dan heeft een klant daar direct enorme last van (het ging overigens goed).
Legacy software is echt overal. Bijvoorbeeld op deze camping van een eigenaar die een AtariST uit 1985 gebruikt om z'n boekingen mee te beheren. Nu is dat allemaal heel grappig en onschuldig, maar ook ‘serieuze’ organisaties als banken, verzekeraars, pensioenfondsen en de overheid draaien nog volop op oude software in programmeertalen die niemand meer kent en op frameworks die allang geen onderhoud meer krijgen.
En dat niet alleen: sommige van die software wordt op cruciale plekken ingezet. Als de computer van de man van de camping het begeeft dan zijn alle boekingen weg. Als een systeem omvalt dat je niet meer kunt beheren of onderhouden dan ontstaan er bij banken, verzekeraars en overheden nog veel grotere problemen.
Echter: dat is het geheim: de software die al zo lang draait is vaak uiterst goed in het doen van z'n taak. Gebruikers weten alle rare ‘quirks’ die er in zitten. De medewerker die de bril bestelde wist dat als je niet eerst zocht op het bestellingsnummer dat je dan de bestelling niet kon koppelen aan de klant. Gewoon een onhandig bugje dat iedereen kent. Iemand heeft een work-around. Prima.
Een ander belangrijk aspect van legacy is dat er soms in te grote snelheid is gebouwd aan nieuwe functionaliteit, maar niet meer genoeg tijd is gegaan naar onderhoud. Hoe groter en uitgebreider de software hoe lastiger het wordt om deze te onderhouden. Achterstallig onderhoud leidt tot nog meer achterstallig onderhoud en stapelt zich verder op. Systemen kunnen niet meer updaten omdat ze daarmee omvallen. Security patches kunnen niet - of matig - worden doorgevoerd omdat ze de applicatie verstoren. Daarbij nemen de kosten van onderhoud vaak ook verder toe: er zijn steeds minder ontwikkelaars, en de paar ontwikkelaars die er nog wel zijn worden steeds unieker, en dus duurder.
Daarbij hebben veel partijen zogenaamde vendor-lock-ins gemaakt: het systeem is niet (goed) in staat om informatie over te dragen of uit het draaiende systeem te halen.
Zo is het heel goed mogelijk dat de opticien al heel vaak heeft gekeken of de bestaande klanten niet konden worden overgezet, maar bleek waarschijnlijk te ingewikkeld.
Evenzogoed kan het zijn dat super-gespecialiseerde software zoals die van de opticien niet zomaar ergens beschikbaar is. Dan moet je als organisatie zelf iets bouwen. Of iets op maat laten bouwen. Dat kan (heel) duur zijn. Niet in de laatste plaats omdat je niet alleen betaald voor het nieuwe systeem, maar ook alle winkels en verkopers opnieuw moet trainen om in de nieuwe situatie te werken.
Voor ‘moderne’ Software as a Service (SaaS) kun je evenzogoed in een vendor-lock-in raken: je start met werken in Asana, en komt er na 1,5 jaar achter dat dit je niet bevalt. Migreren naar een andere project-management tool is lastig. Of je moet helemaal opnieuw beginnen maar dat kan pijnlijk zijn. In die zin zit je ook vast aan Asana.
Nog modernere software maakt gebruik van API’s waarmee je kunt koppelen en stellen je in staat om software op je eigen manier te gebruiken. Sentry is hier een voorbeeld van maar dit kan ook met Gitlab. Je hebt hiermee meer controle over de manier waarop data in- en uit een systeem gaat.
Zelfs een simpele export-functie van een applicatie kan al genoeg zijn om die applicatie ook te verlaten als je ontevreden bent of iets beters hebt gevonden. Ondat dit vanuit de SaaS zakelijk natuurlijk geen prettige gedachte is bouwen veel SaaS toepassingen niet teveel exporteer- of migratiefuncties. Of deze bestaan wel, maar zitten verstopt in de duurste pakketten. Op die manier blijf je klant, hopen ze.
Did you enjoy this issue? Yes No
Jos van Essen
Jos van Essen

JSON, API's, webtokens, CI deployments, JavaScript, Tag Manager: we horen allemaal regelmatig termen voorbij komen waarvan we niet 100% zeker weten of we het ook daadwerkelijk begrijpt. Deze nieuwsbrief laat een licht schijnen op deze materie: tech voor op het web uitgelegd

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.