Wat is een legacy-software-assessment en wanneer heeft u het nodig?

Bij verouderde software wordt de beslissing vaak genomen op basis van indrukken. Iemand vindt het systeem traag, iemand anders vindt vervangen te duur, en een leverancier brengt een voorstel uit dat lastig te beoordelen is omdat niemand precies weet wat er onder de motorkap zit.

Een assessment maakt daar een einde aan. Het is een afgebakend onderzoek, meestal enkele dagen tot enkele weken, dat vaststelt wat er is, wat het waard is en welke wegen openliggen.

Wat wordt onderzocht

Architectuur

Hoe is het systeem opgebouwd, uit welke onderdelen bestaat het, en hoe hangen die samen. Dit bepaalt of onderdelen los te maken zijn of dat alles aan alles vastzit. Het is de belangrijkste factor voor de vraag of gefaseerd vernieuwen mogelijk is.

Broncode

Is de code beschikbaar, leesbaar en onderhoudbaar. Hoeveel ervan wordt werkelijk gebruikt. Welke delen zijn in de loop der jaren aangepast door verschillende mensen. Dode code en dubbele logica zeggen veel over wat aanpassen zal kosten.

Infrastructuur

Waar draait het, op welke versies, en tot wanneer worden die ondersteund. Hier komt meestal de eerste harde deadline naar boven.

Data

Hoe zit de database in elkaar, hoe schoon zijn de gegevens, en worden velden gebruikt zoals ze bedoeld waren. Dat laatste is bijna nooit het geval, en het bepaalt in belangrijke mate hoe zwaar een migratie wordt.

Koppelingen

Wat is er verbonden met wat, en via welke weg. Vaak blijken er koppelingen te bestaan die niet gedocumenteerd zijn en waar niemand nog van wist.

Processen

Hoe wordt het systeem werkelijk gebruikt, inclusief de omwegen. De feitelijke werkwijze wijkt bijna altijd af van de beschreven werkwijze, en het is de feitelijke die u moet vervangen.

Beveiliging en kennis

Welke risico's staan open, wie kan het systeem onderhouden, en wat is er vastgelegd. Als één persoon de enige is die het begrijpt, is dat een bevinding op zich.

Wat het oplevert

Een bruikbaar assessment eindigt niet met één advies, maar met vier onderdelen.

• Een risicoanalyse – wat kan er misgaan, hoe waarschijnlijk is dat, en wat is de impact op de werking
• Meerdere scenario's – doorgaans drie: minimaal ingrijpen, gefaseerd vernieuwen, volledig vervangen
• Een roadmap – welke stappen in welke volgorde, en waarom die volgorde
• Een kostenindicatie per scenario – met bandbreedtes en de aannames erbij

Krijgt u één scenario met één prijs, dan hebt u geen assessment gekregen maar een offerte. Dat is iets anders, en het maakt vergelijken onmogelijk.

Wanneer u er een nodig hebt

Er zijn vijf situaties waarin het zich vrijwel altijd terugverdient.

De leverancier stopt, wordt overgenomen of kondigt end-of-life aan. Er ligt een groeiplan dat het systeem moet ondersteunen. Offertes van verschillende partijen lopen zo ver uiteen dat ze onvergelijkbaar zijn. Er is niemand meer die het systeem volledig begrijpt. Of er staat een investering op de agenda die groot genoeg is om eerst te willen weten waar u aan begint.

In dat laatste geval is de verhouding meestal gunstig: het onderzoek kost een fractie van het traject dat erop volgt, en bepaalt of dat traject de juiste is.

Waar u op let

Laat het onderzoek uitvoeren door iemand die zowel de code als het proces bekijkt. Een puur technische analyse mist waarom bepaalde omwegen bestaan; een puur functionele analyse mist wat technisch haalbaar is.

Vraag vooraf om de opzet: wat wordt bekeken, met wie wordt gesproken, en in welke vorm komt de uitkomst. En vraag of u de scenario's ook zonder de onderzoekende partij kunt uitvoeren. Is het antwoord nee, dan koopt u geen advies maar een voorselectie.

Wil u weten waar u aan toe bent? Lees meer over onze analyse van bestaande legacy-systemen.