.jpg)
McKinsey rapporteert dat 70% van grote IT-transformatieprojecten faalt. Bij volledige systeemvervangingen ligt dat percentage nog hoger. Bart Demeulenaere, Competence Manager bij Elmos en specialist in software architectuur en modernisatietrajecten, ziet de oorzaak keer op keer terugkomen: de business kan niet drie tot vijf jaar wachten.
Dit artikel beschrijft waarom big bang trajecten mislukken en welke aanpak wél werkt: incrementele modernisatie met het strangler pattern.
Waarom big bang trajecten mislukken
De logica achter een volledige rewrite lijkt solide: bouw een nieuw systeem dat aan alle moderne eisen voldoet, zet het oude uit, klaar. In de praktijk stranden deze trajecten op drie voorspelbare problemen.
1. Je schiet op een bewegend doel
"Een groot traject duurt makkelijk drie tot vijf jaar," zegt Bart. "Maar het is onmogelijk om aan de business te vragen gedurende die tijd stil te staan."
Terwijl het nieuwe systeem wordt gebouwd, evolueert het oude verder. Nieuwe features, aangepaste processen, veranderende regelgeving. Het nieuwe systeem schiet continu op een bewegend doel.
2. De functionele gap
Bij volledige rewrites ontstaat vrijwel altijd een functionele kloof tussen wat het oude systeem doet en wat het nieuwe kan. ‘We starten met een MVP’, luidt het dan. De MVP blijkt in de praktijk zeer dicht bij volledige functionaliteit te liggen.
"Als je kijkt naar wat eindgebruikers nodig hebben om hun werk te doen, zit die MVP vaak heel dicht bij 100%," legt Bart uit. "Je kunt niet gradueel opleveren als gebruikers pas kunnen werken als alles er is."
3. De dubbele werklast
Wanneer het nieuwe systeem niet alle functionaliteit dekt, eindigen organisaties met medewerkers die "tijdelijk" in twee systemen moeten werken. Dat tijdelijk duurt vaak twee jaar of langer.
In onze projecten zien we dit patroon regelmatig: teams starten voor ze weten wat ze aan het doen zijn, moeten herbeginnen, en verliezen niet alleen geld maar ook goodwill bij de business.
De oplossing: incrementele modernisatie
Het alternatief voor big bang is incrementele modernisatie: het geleidelijk vervangen van componenten terwijl het bestaande systeem blijft draaien. De bekendste methodiek hiervoor is het strangler pattern.
Het strangler pattern
De naam komt van de strangler fig, een tropische plant die rond een boom groeit en deze geleidelijk vervangt. Het oude systeem blijft functioneren terwijl nieuwe componenten er omheen worden gebouwd.
Kernprincipes:
- Identificeer een afgebakend stuk functionaliteit
- Bouw de vervangende component naast het bestaande systeem
- Routeer verkeer geleidelijk naar de nieuwe component
- Verwijder de oude component pas wanneer de nieuwe bewezen werkt
Waarom dit werkt
"Kosten kunnen tijdelijk stijgen, maar risico's gaan naar beneden," zegt Bart. "Je hebt altijd een werkend systeem, ook als er iets misgaat met een nieuwe component."
Het 4-stappen modernisatieproces
Op basis van succesvolle trajecten bij onze klanten hanteren we een vier-stappen aanpak:
Stap 1: Component-mapping
Voordat je kunt moderniseren, moet je weten welke componenten je systeem heeft en hoe ze samenhangen. Maak een architectuurdiagram dat toont:
- Welke modules/services bestaan
- Welke data ze gebruiken
- Welke interfaces ze hebben (intern en extern)
Quick win deze week: Teken het huidige systeem uit met je team. Vaak is dit de eerste keer dat iemand het volledige plaatje ziet.
Stap 2: Prioritering op value × risk × complexity
Niet elke component verdient dezelfde urgentie. Prioriteer op drie dimensies:
- Business value - Hoeveel waarde levert modernisatie van dezeit component?
- Risico - Hoe groot is het security- of compliance-risico?
- Complexiteit - Hoe moeilijk is dezeit component te vervangen?
Componenten met hoge value, hoog risico en lage complexiteit zijn quick wins.
Stap 3: Strangler implementation
Per component volg je de strangler cyclus:
- Wrap: Plaats een facade rond de oude component
- Build: Bouw de nieuwe implementatie achter dezelfde interface
- Route: Stuur eerst 10%, dan 50%, dan 100% van verkeer naar nieuw
- Remove: Verwijder oude code wanneer nieuwe stabiel is
In onze projecten zien we dat elke gemigreerde component meetbare verbeteringen oplevert: snellere response times, lagere onderhoudskosten, of opgeloste security-issues.
Stap 4: Continue evaluatie
Modernisatie is geen eenmalig project maar een continu proces. Plan elk kwartaal een review:
- Welke componenten zijn gemoderniseerd?
- Welke nieuwe risico's zijn ontstaan?
- Waar ligt de volgende prioriteit?
Praktische takeaways
- Start met component-mapping. Plan deze week een whiteboard-sessie met je team om het huidige systeem uit te tekenen.
- Kies één low-risk component als pilot. Selecteer een component met beperkte afhankelijkheden voor je eerste strangler implementatie.
- Definieer "done" per component. Bepaal vooraf wanneer een component volledig is gemigreerd: welke metrics, welke tests, welke acceptatiecriteria.
- Budget voor tijdelijke complexiteit. Strangler implementations verhogen tijdelijk de complexiteit. Plan hier expliciet capaciteit voor.
- Communiceer incrementele successen. Elke gemigreerde component is een win. Communiceer dit naar stakeholders om momentum te behouden.
Conclusie
De 70% faalkans van grote IT-transformaties is geen natuurwet. Het is het gevolg van een aanpak die niet past bij hoe organisaties werken. Business kan niet stilstaan. Gebruikers kunnen niet jaren wachten.
Het strangler fig pattern biedt een alternatief: incrementele modernisatie waarbij elke stap waarde oplevert en risico's beheersbaar blijven.
"Je hebt altijd een werkend systeem," vat Bart samen. "Ook als er iets misgaat. Dat is het verschil tussen een gecontroleerde transitie en een gok."
Op zoek naar begeleiding bij secure modernization? Crafted by Elmos.
Bart Demeulenaere is Competence Manager bij Elmos met expertise in software architectuur en modernisatietrajecten.
.png)
