Het beheer van de lifecycle van sofware is bij elke organisatie een grote uitdaging. Elk bedrijf dat enigszins serieus met software ontwikkeling bezig is probeert ook rekening te houden met de laatste fase in het leven van software: de decommisioning ofwel het uit productie nemen van de software. In de praktijk blijkt 'de dood' van software echter behoorlijk overdreven; het is niet uit te roeien.
Vaak blijkt dat het leven van software meerdere malen verlengd wordt door het op te lappen en draaiende te houden, soms zelfs aan het infuus of de monitor. De reden hiervoor is dat het goedkoper is om de bestaande software nog wat langer in de lucht te houden, zelfs als daarvoor nog aanpassingen moeten worden gedaan om het bijvoorbeeld mogelijk te maken aan te sluiten op nieuwere technologie zoals een update van het database management of operating system of de manier waarop met andere componenten wordt gecommuniceerd. Veelal is dit ook iets wat er langzaam insluipt en op een gegeven moment kan men bijna niet meer terug; er is al zó veel in geïnvesteerd. Net als bij een auto, wanneer wordt onderhoud te duur en moet hij naar de sloop?
Ondertussen blijkt men zich in een steeds diepere kuil in te graven. De software die eigenlijk uitgefaseerd had moeten worden volgens de oorspronkelijke plannen (en afschrijving) is eigenlijk bijna niet meer te vervangen omdat het zo’n belangrijke (spil)functie vervult in het gehele applicatielandschap en de integratie is erg ‘hecht’. Ook is menig beheerder aan de software gehecht. En het heeft ook zo veel geld gekost! Feit is wel dat het stuk verouderde software ondertussen de verdere evolutie van het applicatielandschap en de daarop landende bedrijfsprocessen tegenhoudt. Maar wanneer geef je de betreffende software een spuitje?
Er is in software lifcycle management vaak wel aandacht en budget voor onderhoud van software. Dit budget wordt gebruikt om bugs op te lossen en kleine changes door te voeren. Ook is er budget voor de operatie van software, zoals beheer en support. Bijna nooit is er echte aandacht voor de laatste fase, het uit productie nemen van software. Wel wat betreft procedures, maar niet wat betreft budget. Software kan natuurlijk niet zomaar uit productie worden genomen, er dient vervanging voor geregeld te worden in de meeste gevallen. En er dient een migratie uitgevoerd te worden. Maar waarom moet het project om deze nieuwe, vernieuwende software in te zetten eigenlijk boeten, of misschien zelfs wel tegengehouden worden vanwege de hoge kosten om de oude software uit te faseren? De oude software is afbetaald en afgeschreven en voor de nieuwe software is budget, maar waar is het geld voor migratie en ‘uitzetten’ en verwijderen van de oude software?
Een oplossing is denk ik wel mogelijk. Waarom introduceren we bijvoorbeeld niet de verwijderingsbijdrage voor software? Een vast bedrag of percentage van de originele ontwikkel- of aanschafkosten dat opzij wordt gezet ten tijde van de aanschaf of ontwikkeling, om latere uitfasering en uitproductiename te financieren? Of misschien in de vorm van een verzekeringspremie voor ‘het pensioen’ en later ‘de uitvaart’ van software? Eigenlijk zou één van deze twee varianten bij elke nieuwe implementatie van software in de projectkosten moeten worden meegenomen, zodat de toekomstige generatie geen last heeft van het ouder, onderhoudsintensiever en minder of zelfs non-functioneel worden van software. Zelfs software heeft recht op een mooi pensioen en een waardige uitvaart en de nieuwe generatie heeft recht op een probleemloze, veelbelovende start om verdere evolutie mogelijk te maken.
Of je de kosten op het budget van de oude of nieuwe software zet blijft uiteindelijk toch borstzak-vestzak. Bij het besluit een oud pakket wel of niet te vervangen is het juist goed om alle kosten en baten op te nemen. Onder welke noemer ze dan vallen maakt niet uit.
De verwijderingsbijdrage voor software bestaat al lang. Microsoft heeft een beleid waarbij software in de extended periode ieder jaar verdubbeld als je tenminste een contract afsluit. Dus de bedrijven die server 2003 gebruiken en daar support op hebben betalen dit jaar 1 en volgend jaar 2.
Het zijn niet de leveranciers die de software in bedrijf willen houden, het zijn de bedrijven die niet bereid zij. Om te veranderen en daar heeft Microsoft al op ingespeeld, anderen volgen soms of hebben een opmerkelijk beleid voor het Uitfaseren van software.
ook kunnen ICT afdelingen een steentje bijdragen door de applicatie elk jaar duurder te maken in het gebruik omdat een ICT afdeling steeds meer effect moet steken in het in bedrijf houden van software die niet meer functioneert op de ICT infrastructuur.
Gijs,
Er is inderdaad nog weleens te weinig aandacht voor de end-of-life van software/systemen maar dat komt ook doordat er vaak afhankelijkheden zijn waardoor applicaties/systemen langer in de architectuur actief blijven dan bedoeld. Deze legacy applicaties/systemen hebben namelijk nog weleens het onverwachte voordeel dat ze uitermate stabiel zijn omdat de kinderziekten er uit zijn. En het kan daarom dus economisch voordeliger zijn om de pensioenleeftijd op te hogen.