Bedrijfsoplossingen die draaien op softwaresystemen die al weer even in gebruik zijn, voldoen niet altijd meer aan de wensen van de gebruiker. Kortom: het is tijd voor een migratie of vervanging van de softwaresystemen. Afhankelijk van de bouwkunst van verouderde softwaresystemen, kan het probleem van spaghetticode op het bord van de it’er terechtkomen.
Bijna elke organisatie loopt met de tijd tegen performance issues dankzij gedateerde softwaresystemen. Maar ook het beheersen van bedrijfsoplossingen of een naadloze aansluiting op moderne technieken en omgevingen ondervinden soms hinder van softwaresystemen die al weer even meegaan. In een enkel geval wordt de ondersteuning niet meer geleverd door de leverancier, bijvoorbeeld support voor VB6 IDE. En dan is het tijd voor migratie of vervanging van verouderde softwaresystemen.
De broncode van programmatuur van softwaresystemen die al langer in gebruik zijn, voelt vaak aan als het bekende bord spaghetti. Toch is het verstandig om ook eens na te denken over een portie lasagne, waarbij verschillende ingrediënten (objecten) onderverdeeld zijn in meerdere lagen (componenten).
Door een oud softwaresysteem te vervangen, wordt het geheel weer beheersbaar en makkelijk te lezen. Er ontstaat structuur, door het systeem als een lasagne op te bouwen in lagen. Daarbij moet wel opgemerkt worden dat het vervangen van verouderde software-systemen veel invloed heeft op gebruikers. Daarnaast is het bijbehorende traject vaak langdurig en zijn de kosten ook nog eens relatief hoog. Het vervangen van verouderde softwaresystemen is dus niet altijd toepasbaar voor elke organisatie. En bij geen of onvolledige documentatie (het recept) voor de broncode (de spaghetti) is een vervanging van een verouderde softwaresysteem zelfs niet verstandig.
In dat laatste geval, biedt migreren met behulp van een migratietool een oplossing. Afhankelijk van de bouwkunst van de verouderde softwaresysteem kan dit goed uitpakken. Maar mocht de basis er toch niet zijn, dan blijft er na de migratie spaghetticode op het bord liggen. Wat de broncode dan nog rest is een cosmetische ingreep, waarbij de huidige functionaliteiten behouden blijven.
Een cosmetische veranderingen bestaat bijvoorbeeld uit het opschonen van de broncode volgens de bedrijfstandaarden, het introduceren van concrete lagen en componenten, de vermindering van redundante business logica of het hergebruiken van objecten. Ook reverse engineering hoort er bij. Hiermee kan de organisatie verborgen functionaliteit traceren, om dit alsnog vast te leggen in een document.
Wat er uiteindelijk op het menu staat, is afhankelijk van verschillende factoren. Duidelijk is wel dat bedrijven er niet aan ontkomen verouderde softwaresystemen vroeg of laat te vervangen of migreren. Immers, om de continuïteit van processen binnen de organisatie te ondersteunen, moeten softwaresystemen up to date blijven.
Bon appetit!
Wat is dan de oplossing? Een migratietool en dan toch nog silo’s in stand houden? Dan creeer je weer nieuwe spaghetti (ofwel: nieuwe legacy)
Peter Klerkx geeft het al aan, een bagger product wordt niet beter door het te converteren mbv een tooltje.
De hele rotzooi opnieuw laten ontwikkelen is ook geen garantie dat het resultaat weer een puinhoop wordt.
Er moeten gewoon eens eisen gesteld worden aan ontwikkelaars (vooral hun werkgevers) zodat ze gedwongen worden hun software op een fatsoenlijke manier te schrijven.
Welicht moeten meer opdrachtgevers gewoon eisen dat zij de beschikking krijgen en eigenaar worden van de broncode. Maar dat vinden heel wat ontwikkelaars eng getuige vele anti OSS geluiden.
Programmeurs schrijven spaghetticode met een reden: http://www.venganza.org/
Hier wordt slechts één aspect benoemd, maar het geheel is natuurlijk veel gecompliceerder
Want:
– als je een bord spaghetti vervangt door een bord lasagne heb je een wezenlijk ander product met een andere smaak, waarvan het de vraag is of het nog aan de wensen van de klant voldoet
Ofwel: als je van je spaghetticode lasangecode maakt, zul je aan moeten gaan tonen dat het product nog steeds hetzelfde doet en kan.
Hopelijk kun je in dat geval volstaan met een aantal regressietesten, maar in het slechtste geval zul je het hele product opnieuw moeten gaan testen. In sommige sectoren, waar testtijd heel duur is, kan dit een belangrijke overweging zijn om bij de spaghetti te blijven
– niet iedere klant zit erop te wachten dat zijn spaghetti vervangen wordt door lasagne. Immers, als het werkt, waarom zou ik het dan vervangen willen hebben?
– en als je de spaghetti al wil vervangen, dan kan dat (afhankelijk van het product) een hele logistieke operatie met zich meebrengen om alles te vervangen. Dit aspect wordt vaak onderschat. Een paar klanten in je eigen land, of enkele duizenden installaties wereldwijd maakt nogal een verschil
Ten onrechte wordt in dit, overigens boeiende, artikel spaghetti tegenover lasagne geplaatst; alsof het één het ander zou uitsluiten. Onderbelicht blijft allereerst dat juist het toepassen van Service Oriented Architecture een evolutie van multitier-architecturen mogelijk maakt, hetgeen leidt tot een architectuur die tegenwoordig top down op z’n minst zal bestaan uit een presentatielaag (GUI,selfservice), een business flow laag, een composite services laag en een basic services laag.
Een reden om legacy te migreren naar moderne multitier-architecturen is niet alleen het hier beschreven spaghetti-probleem, maar vooral ook het feit dat verouderde bedrijfssoftware vaak nog batchgeorienteerd is. En dat staat haaks op het realtime willen afhandelen van klantwensen door middel van selfservice.
De flowchart-technieken die tegenwoordig worden toegepast binnen Business Process Management (BPM) voor het modelleren van de businessflow-laag laten mooi zien hoe binnen de lasagne opnieuw spaghetti kan ontstaan.