Veel grote bedrijven hebben te maken met programmeerinsluiting. Hierbij is de gebruikte programmeertaal of -omgeving dermate verouderd dat verandering van het softwaresysteem relatief hoge kosten met zich meebrengt. Deze problematiek vormt in de meeste gevallen een al dan niet sluimerend bedrijfskritisch risico. Paul Jansen beschrijft voor welk type oplossing bedrijven – afhankelijk van hun specifieke situatie – het best kunnen kiezen.
Naarmate softwaresystemen groter worden, nemen de kosten van het onderhoud meer dan lineair toe. Als een systeem een bepaalde kritische massa heeft bereikt, is het zelfs niet meer mogelijk om zonder veel kapitaalvernietiging over te stappen op een andere softwaretechnologie. Dit laatste probleem heet ook wel insluiting (‘lock-in’), een term die afkomstig is uit economische theorieën.
Een speciale vorm van insluiting is insluiting veroorzaakt door het gebruik van verouderde programmeertalen en -omgevingen. Volgens onze definitie treedt programmeertaalinsluiting op wanneer een softwaresysteem voldoet aan de volgende drie criteria: Het systeem omvat meer dan 250.000 zelfgeschreven regels code; De functionaliteit die het systeem biedt zal nog zeker vijf jaar nodig zijn; Het systeem is gebouwd met behulp van softwaretechnologie die niet (meer) mainstream is.
Hierbij worden anno 2001 als definitie van mainstream de volgende programmeertalen en -omgevingen gebruikt: Java, C, C++, HTML, Visual Basic, Perl, Delphi/Pascal, SQL, Java Script, Cobol, PHP, Fortran en Python. Zie http://www.tiobe.com/tpci.htm voor een actueel overzicht.
Vrijwel alle grotere Nederlandse bedrijven hebben een of meerdere systemen die voldoen aan deze drie criteria.
Problemen met programmeertaalinsluiting ontstaan vaak vanuit de onderkant van een organisatie. Omdat software-engineers werken in een ‘verouderde’ omgeving zijn ze niet in staat om dezelfde productiviteit te halen als met een nieuwe technologie. In tegenstelling tot nieuwe technologie missen ze bijvoorbeeld relevante herbruikbare bibliotheekfuncties of bijvoorbeeld geavanceerde tools om programma’s te debuggen.
Voor engineers is het uit carrièreoverwegingen bovendien niet interessant om op hun cv te pronken met programmeerervaring in exotische programmeertalen als Lisp, Forth of Rexx. Dit leidt uiteindelijk tot uitstroom van personeel naar werkgevers die nieuwe ontwikkelingsprojecten hebben gestart in bijvoorbeeld Java, C/C++ of Delphi.
Meestal komt het management pas in actie wanneer de uitstroom een tijd aan de gang is of wanneer er een onmisbaar persoon dreigt op te stappen. De meest cruciale medewerkers worden gebonden door middel van betere arbeidsvoorwaarden, en het leed lijkt weer geleden. Als vervolgens iemand die een sleutelpositie bekleedt toch vertrekt, langdurig ziek wordt of met pensioen gaat, kan er een serieus bedrijfsprobleem ontstaan. Het is heel lastig om dan nog vanuit zo’n situatie voldoende gekwalificeerd personeel te rekruteren of in te huren, omdat de programmeergemeenschap van de gebruikte technologie klein is. Programmeertaalinsluiting is dus een soort tijdbom, waarvan niet duidelijk is wanneer die zal ontploffen.
Oplossingsstrategieën
De eerste stap op weg naar een oplossing voor insluiting in een programmeertaal is tijdige onderkenning van het probleem door het management. Hoe langer het management wacht, des te moeilijker het wordt om de organisatie op tijd te mobiliseren.
Vervolgens zijn er vier oplossingsstrategieën mogelijk: vervanging door standaardoplossingen, encapsulatie, taalconversie of nieuwbouw. In de meeste gevallen wordt gekozen voor een combinatie van bovenstaande oplossingsrichtingen. Welke combinatie het geschiktst is, hangt sterk af van de specifieke situatie, waarbij de huidige toestand van het systeem en de beschikbaarheid van zowel budget als personeel een belangrijke rol spelen.
Vervanging door standaardoplossingen
Een overweging die zeker gemaakt dient te worden indien programmeertaalinsluiting optreedt, is of er commerciële softwarepakketten bestaan die het overgrote deel van de functionaliteit van het oude systeem kunnen afdekken. Op deze manier wordt een eventuele programmeertaalinsluiting verlegd naar derden. Immers, de toeleverancier is er dan verantwoordelijk voor dat het softwarepakket technologisch gezien niet in een geïsoleerde positie raakt. Gerenommeerde softwareleveranciers zullen er echter voor waken dat ze in een dergelijke positie komen.
Een goed voorbeeld van vervanging van eigen softwaresystemen door externe standaardoplossingen is de grootschalige introductie van erp-systemen op de Nederlandse markt in de jaren negentig ter vervanging van bedrijfsspecifieke logistieke systemen.
Het grote voordeel van het gebruik van standaardoplossingen is dat bedrijven kunnen meeliften op nieuwe functionaliteit die wordt geboden door de leverancier. De investering in dergelijke nieuwe functionaliteit wordt gedeeld met andere klanten van zo’n standaardpakket, hetgeen staat tegenover het zelf bekostigen van elke uitbreiding. Daarentegen is de zeggenschap wat er precies dient te worden toegevoegd, sterk verzwakt.
Bij de afweging of een softwaresysteem kan worden vervangen door een commercieel standaardpakket, is het belangrijk om geen volledige afdekking van de oorspronkelijke functionaliteit na te streven. Gezien de unieke oorsprong van het oude systeem is dit vaak nagenoeg onmogelijk. Dit kan dan dienen als (onterecht) excuus om de overstap naar een standaardpakket niet te maken.
Veel standaardpakketten bieden de mogelijkheid om aangepast of geconfigureerd te worden al naargelang de specifieke behoeften. Het is zaak om de benodigde aanpassingen tot een minimum te beperken, omdat anders mogelijkerwijs alsnog een programmeertaal-insluitingsprobleem wordt gecreëerd. Denk aan een bedrijf dat nog een sterk verouderde versie van een commercieel pakket gebruikt zonder over te (kunnen) stappen op een nieuwere versie.
Encapsulatie
Onder encapsulatie wordt verstaan: het inpakken van een bestaand systeem in kleine componenten met elk een eigen interface. Met behulp van protocollen (zoals Corba en COM) is het dan mogelijk om de oude softwarecomponenten te laten communiceren met nieuwe software die ontwikkeld is met behulp van moderne technologie.
Encapsulatie is veruit de goedkoopste en snelste oplossing indien programmeertaal-insluiting optreedt. Er is echter één essentiële voorwaarde aan verbonden: het systeem moet voldoende modulair zijn opgebouwd. Wanneer dit namelijk niet het geval is, en het software-systeem in kwestie één onlosmakelijke monoliet blijkt te zijn, is het ondoenlijk om – gezien de grootte van het systeem – zinvolle componenten te onderscheiden.
Omdat systemen die met programmeertaalinsluiting te kampen hebben vaak al een lange geschiedenis achter de rug hebben, is de oorspronkelijke architectuur meestal niet meer te achterhalen. Ook is het mogelijk dat er nooit een duidelijke architectuur geweest. Het afsplitsen van componenten van voldoende granulariteit, en daarmee encapsulatie als mogelijke oplossing, is daarom vaak een utopie.
Encapsulatie heeft geen toegevoegde waarde indien de oude software die in componenten wordt geïsoleerd, onderhevig is aan intensieve functionele veranderingen. Deze veranderingen dienen dan namelijk in de oude software en dus met behulp van oude technologie te worden gerealiseerd. Er is dan geen noemenswaardige verandering opgetreden in vergelijking met de oorspronkelijke situatie.
Taalconversie
Taalconversie is het met behoud van functionaliteit vertalen of verbeteren van een bestaand systeem. Dit is een relatief goedkope oplossing die zowel de kennis als de stabiliteit van het oude systeem bewaart. Taalconversie kan op verschillende manieren worden gerealiseerd: handmatig, automatisch en semi-automatisch. Hoe groter het softwaresysteem, des te interessanter wordt het om zoveel mogelijk geautomatiseerd te converteren.
Taalconversie, en dan met name geautomatiseerde taalconversie, is een complexe activiteit die niet moet worden onderschat. Naast het behoud van functionaliteit is het noodzakelijk dat ook de onderhoudbaarheid van het systeem wordt gewaarborgd. Indien bron- en doeltaal te veel van elkaar verschillen, zal dit niet kunnen worden gegarandeerd. Zo zal een conversie van een systeem in de procedurele programmeertaal Fortran naar de objectgeoriënteerde taal Java waarschijnlijk resulteren in een Fortran-systeem in een Java-jasje.
Om taalconversie succesvol te kunnen toepassen dient een heel scala van voorwaarden van toepassing te zijn. Enkele belangrijke eigenschappen in dat opzicht zijn: de grootte van het systeem (Hoeveel regels code omvat het? Zijn al deze regels geprogrammeerd in dezelfde programmeertaal?), de externe afhankelijkheden van het systeem (Worden er externe bibliotheken gebruikt? Vinden er veel verschillende soorten systeemafhankelijke aanroepen plaats?) en de professionaliteit van de organisatie (Is er een project organisatie? Bestaan er (automatische) test scenario’s?). Een uitgebreid overzicht van deze voorwaarden en bijbehorende risico’s zijn te vinden op http://www.tiobe.com/migration_standard.htm.
De laatste jaren is taalconversie meer in de schijnwerpers komen te staan. Een belangrijke aanleiding is de bestrijding van het ‘jaar-2000’-probleem geweest waarbij bestaande academische ideeën op het gebied van softwareanalyse en transformatietechnologie zijn toegepast in de industrie. Sinds die tijd bestaan er tal van kleine gespecialiseerde Nederlandse bedrijven die zich hebben toegelegd op automatische re-engineering en taalconversie.
Nieuwbouw
De oplossingsstrategieën die tot nu toe de revue zijn gepasseerd, laten de functionaliteit van een systeem min of meer in tact. Alhoewel standaardpakketten en standaardbibliotheken (na taalconversie of encapsulatie) de mogelijkheid scheppen om nieuwe functionaliteit eenvoudig in te zetten, zijn de perspectieven voor nieuwbouw wat dit punt betreft onbegrensd. Eindelijk kan men afrekenen met relicten uit het verleden en kunnen ideeën, die al heel lang gekoesterd werden, gerealiseerd worden.
Het grote gevaar dat in deze oplossing schuilt is dat men – door het gevoel te hebben bevrijd te kunnen worden van het juk van het verleden – verblind kan raken voor de kosten en doorlooptijd die nieuwbouw met zich meebrengen. Uitgaande van een optimistische productiviteit van 50 geteste regels nieuwe code per mensdag (gerenommeerde instituten gaan uit van maximaal 10 regels), betekent dit dat de nieuwbouw van een systeem van 250.000 regels code ongeveer 20 mensjaren zal kosten.
Hier komt nog eens bij dat een bestaand software systeem meestal in de loop der jaren is uitgegroeid tot een functioneel stabiel systeem. Nadat nieuwbouw is gerealiseerd, zal er eerst behoorlijk wat tijd van eindgebruikers overheen moeten gaan voordat de stabiliteit van het oude systeem kan worden benaderd. Om deze redenen is nieuwbouw vaak een goede oplossing in combinatie met een van de andere genoemde oplossingen.
Kiezen van oplossingsstrategie
De hiervoor genoemde oplossingsstrategieën zijn gepresenteerd in oplopende volgorde van de investeringskosten die ermee zijn gemoeid. In de tabel hieronder is af te lezen wat deze oplossingen gemiddeld kosten voor een redelijk modulair software systeem van ongeveer 250.000 regels code. Het betreft hier een zeer ruwe indicatie: de werkelijke kosten kunnen aanzienlijk afwijken afhankelijk van de specifieke situatie.
| Oplossingsstrategie | Kosten in euro’s |
| Standaardoplossing | Zeer variabel |
| Encapsulatie | 80.000 |
| Taalconversie | 300.00 |
| Nieuwbouw | 2.500.000 |
De variatie in kosten van vervanging door een standaardoplossing is dermate hoog dat het geven van een gemiddelde geen zin heeft. Het kan zijn dat er een gratis product bestaat dat de bestaande functionaliteit kan vervangen, maar het kan ook betekenen dat er een zeer prijzig product moet worden aangeschaft inclusief dure consultancy om aanpassingen te verrichten.
De meest logische weg om te komen tot een oplossing voor een programmeertaalinsluitingsprobleem is te starten bij de goedkoopste oplossing: vervanging door een standaardoplossing. Indien vervanging door een standaardpakket niet mogelijk blijkt of een dure aangelegenheid dreigt te zullen worden, wordt aangeraden om encapsulatie in overweging te nemen. Deze oplossing is namelijk relatief goedkoop en heeft het kleinste risicoprofiel.
Pas als zowel vervanging door een standaardoplossing als encapsulatie niet mogelijk zijn, zou taalconversie als serieus alternatief moeten worden geëvalueerd. De reden hiervoor is dat taalconversie alleen onder relatief speciale omstandigheden tot succes kan leiden. Nieuwbouw, tot slot, moet altijd als laatste redmiddel worden beschouwd. Het is duur en kent het grootste risicoprofiel.
Praktijkvoorbeeld
Logistix Partners is een erp-software-leverancier voor het midden- en kleinbedrijf.
Hun product, Logistix geheten, is een systeem dat bestaat uit iets meer dan 1 miljoen regels Microsoft Dos Basic code. Het erp-product voldoet qua functionaliteit uitstekend aan de huidige markteisen (de klantentevredenheid is hoog) en zal dus nog jaren verkocht kunnen worden. Nieuwe, externe ontwikkelingen op het gebied van softwaretechnologie kunnen echter niet of heel moeizaam worden bijgehouden omdat de huidige Dos Basic gemeenschap te klein is om voor voldoende ondersteuning in de vorm van tools en bibliotheken of zelfs taaluitbreidingen te zorgen. Nu Logistix Partners graag naar een grafische omgeving wil en zelfs naar asp, steekt de programmeertaal-insluitingsproblematiek de kop op.
De eerste oplossing, vervanging door een standaardoplossing, kan alleen betrekking hebben op delen van het Logistix-systeem die niet tot de commercieel gezien unieke karakteristieken van het Logistix-product behoren. Vervanging van het Logistix-systeem in zijn geheel door een ander standaard erp-pakket behoort uiteraard niet tot de mogelijkheden omdat Logistix een product is dat verkocht wordt door Logistix Partners. Een onderdeel dat wel in aanmerking komt voor vervanging door een standaardoplossing is een in eigen beheer ontwikkelde, op files gebaseerde database. Database-anomalieën die in het verleden nog wel eens voor hoge onderhoudskosten zorgden, zijn dan te minimaliseren. Overige kandidaten voor vervanging zijn niet gevonden.
De verschillende onderdelen van het Logistix-systeem zijn sterk met elkaar verbonden. Dit heeft alles te maken met het feit dat de eerste commerciële versies van Dos Basic die zijn gebruikt, geen deugdelijke ondersteuning boden om programma’s modulair op te zetten. Als gevolg hiervan is encapsulatie voor het Logistix-systeem niet mogelijk.
Randvoorwaarden
De volgende oplossingsstrategie, automatische taalconversie van het Logistix-systeem, blijkt goed mogelijk. Er wordt namelijk voldaan aan bijna alle randvoorwaarden die hiervoor gelden. Enkele essentiële voorwaarden zijn:
- Alle kennis over het systeem is nog aanwezig binnen het bedrijf;
- Alle betrokken medewerkers staan volledig achter de verandering;
- Het systeem is een ‘stand-alone’ applicatie (geen externe interfaces);
- Meer dan 99,5 procent van de code is geschreven in Dos Basic;
- Slechts een klein gedeelte van de Dos Basic taal wordt gebruikt.
- Delphi is een mainstream programmeeromgeving;
- Er is kennis op Delphi-gebied aanwezig binnen het bedrijf;
- Delphi heeft uitgebreide grafische user interface faciliteiten;
- Er bestaan relatief veel externe ondersteuningsmogelijkheden (in de vorm van diensten, maar ook producten) om Delphi-applicaties om te vormen tot asp.
Door een slimme afbeelding van Basic-files op Delphi-units is de modulariteit van het Logistix-systeem sterk toegenomen. Om Logistix tot asp te kunnen verheffen is echter nog verdere modularisering vereist; het grafisch gebruikersinterface moet losgekoppeld zijn van de rest van de software. Dit zal gebeuren door een geplande combinatie van handmatige re-engineering en geautomatiseerde programmatransformaties.
Paul Jansen Managing Director Tiobe
