De afgelopen jaren zijn grote ict-projecten, zeker bij de overheid, meer dan eens uit de hand gelopen. Miljoenen euro’s zijn in rook opgegaan, omdat gaandeweg bleek dat het niet lukte een project tot een goed einde te brengen.
Er zijn uiteraard uiteenlopende redenen waarom projecten mislukken. En het is voor een buitenstaander niet altijd goed te bepalen wat die redenen zijn. Maar veel projecten wekken in ieder geval de indruk dat ze te groot, te ambitieus en te complex waren en daardoor onbeheersbaar werden.
Aanpak
Bij vervanging of modernisering van grote ict-omgevingen doet zich altijd de vraag voor welke aanpak de beste is. In het algemeen zijn drie benaderingen mogelijk: replace, rewrite en reuse.
Bij replace vervang je de bestaande omgeving met een standaardpakket. De term ‘standaardpakket' is overigens misleidend, want ook bij deze software zijn nog heel veel voorwerk en ontwikkeling nodig om een werkende oplossing te krijgen.
Bij rewrite ga je de bestaande systemen volledig opnieuw ontwikkelen. Dat kost uiteraard heel veel tijd en heel veel geld.
Bij reuse neem je de bestaande systemen als uitgangspunt en breng je de code met behulp van moderniseringtools over naar een nieuw platform. Alle logica en regels gaan één-op-één over naar een modern platform, waardoor je je systemen na de migratie verder kunt moderniseren en bijvoorbeeld geschikt kunt maken voor ontsluiting naar het internet.
Reuse is zo gek niet
Het zou de moeite waard zijn om eens een paar grote projecten naast elkaar te zetten en te bekijken welke benadering gekozen is. Het zou mij niet verbazen als rewrite- en replace-projecten er negatief uitspringen voor wat betreft een succesvol eindresultaat. Reuse is zo gek nog niet, ook niet in de ict.
Huib Klink
Senior consultant / preSales
Micro Focus
hoe groot is groot en hoe complex is complex in deze context?
Baseren we dit op aantal regels code, aantal functiepunten, taal, platform, aantal gebruikers?
Hergebruik, ofwel reuse, kan in een aantal scenario’s absoluut helpen, maar dit staat of valt voor een groot deel met onderliggende architectuur en OS.
Zeker in het geval van omvangrijkere projecten, bijvoorbeeld >1000 entiteiten, sluit ik me aan bij het moderniseren van een bestaand systeem. Minder belastend voor de organisatie, minder risico en grote slagingskans van het project. Geen “big bang”, maar stap voor stap. Bij moderniseren is het belangrijk om te starten met die onderdelen van de bestaande applicatie die aan veel veranderingen onderhevig zijn of waar veel onderhoud op plaatsvindt. Juist die onderdelen moeten als eerste naar een nieuwe onderhoudbare technologie worden gebracht. De keuze voor de modernisatietool is daarbij cruciaal, codeconverters zouden hierbij niet mijn voorkeur hebben, aangezien de onderhoudbaarheid van de code doorgaans niet verbetert. Modelgedreven oplossingen kunnen uitkomst bieden.
Hans Keukenschrijver
Thinkwise Software
@PaVaKe
“Groot” als in b.v. https://www.computable.nl/artikel/ict_topics/infrastructuur/3020529/2379248/mislukt-ictproject-kost-van-lanschot-55-miljoen.html. Of snuffel eens in https://www.computable.nl/artikel/ict_topics/ictbranche/3203753/2379258/2009-22-spraakmakende-ictfiascos.html
Met name oudere (mainframe/legacy) systemen kunnen soms verrassend eenvoudig geporteerd worden naar LUW (Linux/UNIX/Windows). Daarbij hoeft (@Hans K) het leeuwendeel van de broncode niet eens gewijzigd te worden.
Natuurlijk zijn er veel (exotische) platformen, maar replatforming is vaak mogelijk, al dan niet met een bepaalde hoeveelheid conversie. Modernisering behoeft in veel gevallen geen of slechts beperkte codeconvert te impliceren.
En zelfs de oude legacy systemen hoeven lang niet altijd aangepast te worden. Er zijn diverse systemen waar de database en/of batchverwerking op de oude (stabiele!) omgevingen draaien en waar vervolgens een (web based) interface voor gezet is. De presentatie aan de gebruiker en de plaats waar de data staat is niet aan elkaar gekoppeld dus is het ook niet nodig om met een nieuwe gebruikersinterface ook meteen de hele backend op zijn kop te zetten.
@Huib
Als ik even snel door die artikelen heen lees, wordt groot uitgedrukt in geld.
Dit vind ik altijd gevaarlijk, in die zin dat het een nogal vertekend beeld kan geven:
– er wordt in het voortraject (vooral bij overheden) al een klein kapitaal uitgegeven om goede tenders te schrijven, en het hele aanbestedingstraject juridisch en inhoudelijk goed te krijgen
– veel gemeenten geven kapitalen uit op jaarbasis aan consultants, ook dit is behoorlijk van invloed op de prijs
Een migratieintegratie van een paar duizend mainframe gebruikers van lokatie A naar lokaktie B, is dat groot?
Projecten waarin miljoenen regels code zitten in een em bedded omgeving, is dat groot?
Een migratie van 500 ontwikkelaars van een XP naar Windows 7 omgeving, is dat groot?
Voor de één wellicht een peuleschilletje of routineklus, voor de ander een “groot” project