Alle bedrijven hebben ermee te maken: oude software. Deze software voldoet niet meer aan de huidige tijd, maar aanpassingen zijn duur en ontwikkelaars zijn moeilijk te krijgen doordat de software is gemaakt in verouderde programmeertalen.
De eerste keuze bij een dergelijk dilemma is herschrijven of migreren. Herschrijven begint eigenlijk opnieuw en komt daarmee overeen met nieuwbouw. Natuurlijk kan er eerst gekeken worden of er geen cots-oplossing (commercial off-the-shelf) verkrijgbaar is. Herschrijven geeft de mogelijkheid om de functionaliteit en de wensen van de business nog eens goed in kaart te brengen. Migreren is het omzetten van het systeem naar een nieuwe techniek, maar met dezelfde functionaliteit als het oude systeem. Migreren heeft als voordeel dat het oude systeem geldt als referentie. Er zijn veel meer aspecten, die de keuze bepalen, maar daar wil ik me nu niet op richten. Stel dat er wordt gekozen voor migreren.
De keuze voor migratie is vaak omstreden omdat er wordt uitgegaan van het behouden van dezelfde functionaliteit, maar alleen de techniek wordt omgezet naar een nieuwere. Door de business wordt het daarom vaak als lastig gezien in plaats van nuttig. De business ziet doorgaans alleen de ‘freeze' van de functionaliteit voor een bepaalde periode. Migreren is daarom vooral nuttig als het sneller gaat dan herschrijven. Dit legt extra druk op het tijdsplan.
Uitdagingen
Andere uitdagingen zijn dat er een hogere kwaliteit wordt verwacht dan in een nieuwbouw traject, immers de business wil niet de hele applicatie doortesten, want die hebben ze al geaccepteerd. Dit hoort de it-afdeling of leverancier maar te regelen. De bestaande organisatie kan een migratie er meestal niet ‘even' bij doen. De mensen zijn vaak ook met andere systemen bezig en kunnen niet volledig vrijgemaakt worden. Er zullen waarschijnlijk extra mensen of een andere partij ingeschakeld moeten worden.
Die nieuwe mensen hebben dan weer een nieuwe uitdaging. Er is vaak sprake van weinig of ontbrekende kennis en documentatie van de werking van het systeem. Voor de mensen die dagelijks met het systeem werken is het wel bekend, maar voor een nieuwe partij is het lastig te begrijpen.
Aanpak
Hanteer tijdens het migreren het principe van 1-op-1 overgaan. Dit houdt in dat niet alleen de functionaliteit gelijk blijft, maar ook de technische structuur. Een voorbeeld met betrekking tot de technische structuur: Als er een klasse met tien functies is gemaakt in VB6, dan wordt die vertaald naar een klasse met dezelfde tien functies in C#. Dit heeft natuurlijk als nadeel dat de voordelen van C# op dat moment nog niet gebruikt gaan worden, maar als voordeel dat het snel over te zetten is.
Het gevaar bij een migratietraject is dat het teveel een herschrijfproject wordt. In een migratietraject hoort 80 procent rechttoe rechtaan omgezet te kunnen worden. Gebruik hier dan ook een tool voor. De overige 20 procent is handwerk. Voor een herschrijfproject is dit anders en richt je de organisatie juist in op het handwerk, zoals het in kaart brengen van wensen. Als in een migratietraject meer dan 20 procent handwerk verricht moet worden dan merk je dat het project er niet op is ingericht en gaat het onnodig lang duren. De gevaren ontstaan als er toch aanpassingen in de technische structuur aangebracht moeten worden of nieuwe wensen meegenomen moeten worden.
Juist door het 1-op-1 principe biedt een migratieproject unieke kansen. Zo kun je in deze situatie werken met filmpjes in plaats van documenten voor het vastleggen van de werking. Gewoon iemand door het huidige systeem laten klikken en dat opnemen is al voldoende om in detail vast te leggen hoe het systeem werkt. Bij herschrijven moet het dan toch net iets anders en bij nieuwbouw is er nog geen systeem. De ontwikkelaars hebben zo een beeld van de voorkant en de achterkant en kunnen zo het systeem migreren zonder al teveel functionele kennis te hebben.
Nog niet klaar
Natuurlijk is al genoemd dat het 1-op-1 overgaan een aantal nadelen met zich meebrengt. Zo is de technische structuur vaak niet optimaal voor de nieuwe techniek en komen bijvoorbeeld codeerconventies niet overeen. Na het migratietraject en in productiename is er dan ook veel behoefte aan refactoring en vereenvoudiging. Dit gebeurt dan gelukkig wel met nieuwe techniek en nieuwe tools.
Modernisering van een IT-omgeving is een complexe aangelegenheid. Er zijn diverse aanleidingen: dreigend out-of-support door een leverancier, gewenste of noodzakelijke koppelingen die niet meer in de oude architectuur gerealiseerd kunnen worden, gebrek aan kennis en kunde zoals je al noemt, productiviteitsproblemen of een tekort aan technische mogelijkheden om te voldoen aan de hedendaagse vraag uit de business.
De stelling om gewoon 1-op-1 over te gaan vind ik daarom tekort door de bocht. Op basis van wensen, aanleiding, uitgangspunten, technische en organisatorische(on)mogelijkheden, en een groter, toekomstvast plaatje, moet je komen tot een aanpak. 1-op-1 is zeker een optie, maar een herbezinning op functionaliteit is natuurlijk evident.
Niet teveel hooi op de vork nemen en eenvoud is belangrijk bij migraties, maar dat wil niet zeggen dat het eenvoudig is. Goed bedenken waar van vandaan komt, waar je naartoe wilt en dan bepalen wat dan de beste weg is, rekening houdend met de situatie is het advies dat ik zou willen geven.
1 op 1 over, klinkt in het Engels als: compatible with all previeus errors. Dat geeft in feitelijk aan dat dat de (migratie)weg moet zijn
In de vernieuwing van communicatie-infrastructuren is dat de slechts denkbare optie. Na 8 tot 10 jaar is het zelfs niet haalbaar meer…….
Een bedrijf dat helemaal gespecialiseerd in de aanpassing van of aan oude software is Software Onderhoud Nederland (www.softwareonderhoud.nl). Aanpassing kan vaak een goedkoop alternatief zijn, zeker om dure omschakeling in tijden van economische recessie op een goede manier nog even uit te stellen.
@Andre, ik heb bewust niet de keuze tussen nieuwbouw, gedeeltelijk herbouw, inkopen enzovoort niet centraal gezet in het artikel. Migratie is inderdaad altijd lastig. Ik wilde juist inzoomen op dat 1-op-1 overgaan ook een paar unieke voordelen met zich meebrengt.
@Maarten, het artikel is inderdaad gericht op softwareontwikkeling en niet op communicatie-infrastructuren.
@Maarten:
Weer zo’n typische reactie die wellicht grappig is, maar ook je denkwijzen blootlegt.
“Compatible with all previous errors” bevat zeker een waarheid, maar de linkerkant van de balans is dat het systeem blijkbaar werkt en voldoende waarde bevat en dat het behouden van de zwakheden jammer is, maar veel minder risico dan opnieuw bedenken of migreren en wijzigen tegelijkertijd.
Het is ook mijn wijsheid dat je het wijzigen van software niet gepaard moet laten gaan met wijzigingen in functionaliteit. Want dat is een dubbele complexiteit en achteraf veel moeilijk in te schatten wat er nu fout is gegaan.
1 op 1 overgaan is wel tegen de intuïtie in. Je gaat investeren zonder dat je er functioneel op vooruit gaat.
Cruciaal is het inzicht dat andere software een organisatie verandering is! Processen zijn de aorta van een organisatie en software de organen. Even wat processen veranderen is niet makkelijk, als je deze tegelijk met het vervangen van organen gaat doen is het vragen om moeilijkheden.
Mijn advies is, zorg dat je *echt* je processen begrijpt en daardoor je business begrijpt (ik noem dat het schetsen van je wereldbeeld). Pas dan kun je software gaan veranderen of bouwen.
En de grootste fout die het vaakst gemaakt wordt is deze: Zelf bouwen heeft voordelen en nadelen. Standaard software kopen en gebruiken heeft voordelen en nadelen. Maatwerk bouwen op standaard software bevat alle nadelen van beide keuzen en geen van de voordelen. Maatwerk op standaard software is het slechts wat je kunt doen…. en dit is wel wat er in de praktijk het vaakst gebeurt!
Goed artikel, ben het er grotendeels mee eens.
Wat migratie vaak extra lastig maakt is dat de specs van de oude applicatie vaak niet meer voorhanden zijn. Indien het om een software only omgeving gaat, kun je met reverse engineering nog wel veel achterhalen, maar op het moment dat je in een embedded omgeving of andere combinatie van soft- en hardware zit kan dit heel lastig worden.
Jaren geleden heb ik met een omgeving gewerkt, die creditkaart automaten uitlas, de gegevens verwerkte en vervolgens alles doorstuurde naar betreffende banken. Dit draaide op een oud protocol (x.25) en met hardware waarvoor we de onderdelen op de rommelmarkt moesten zoeken. Als dit een nacht niet draaide hadden we een fixe schadeclaim aan onze broek hangen van de banken wegens gederfde inkomsten.
(erfenis van een overname van een ander bedrijf)
Het heeft heel lang geduurd voordat iemand het überhaupt aandurfde om dit te vervangen. Zelf heb ik de vervanging niet meer meegemaakt omdat ik van baan veranderde, maar het geeft aan dat vervanging van oude spullen niet altijd even simpel is als het klinkt
(waarmee ik overigens niets wil afdoen aan het prima artikel)
@Henri
over het algemeen is iets in het engels kernachtiger te verwoorden dan in het Nederlands. Daarnaast het, mijn, vakgebied is vnl. engels.
@Ben
dank voor je opmerking dat het niet om communicatie-infrastructuren gaat, ik maakte me al “ongerust” na zoveel jaar “zendingswerk” t.b.v. de ontwikkeling van communicatie toepassingen en communicatie-infrastructuren.
1 op 1 over zou wat mij betreft overigens lijken op verlenging van het onderhoudscontract…Maar ook dat zal wel komen door de volgende zin:
Er zijn kennelijk principiële verschillen zijn tussen IT en ICT…..