Waarom zou je bestaande software herbouwen?
Technische schuld (Technical debt) en veroudering
Technische schuld (eigenlijk noemt iedereen het in goed Nederlands `tech debt`) ontstaat wanneer ontwikkelaars kortetermijnoplossingen kiezen die op de lange termijn problemen veroorzaken. Verouderde technologieën kunnen leiden tot beveiligingsrisico's, verminderde prestaties en hogere onderhoudskosten. Herbouwen kan deze problemen oplossen door de toepassing te moderniseren met de nieuwste technologieën. De oplossing hiervoor klinkt simpel: kies altijd voor lange termijn oplossingen. We zien echter regelmatig dat doordat de product en of business kant druk legt op ontwikkelaars om nieuwe functionaliteit toe te voegen. Deze druk zorgt ervoor dat er toch regelmatig voor de korte termijn gekozen wordt.
Beperkingen in architectuur
Oude softwarearchitecturen zijn vaak niet ontworpen om te groeien met de moderne eisen van schaalbaarheid en prestaties. Dit is een reëel probleem wat vaak terug gezien wordt bij systemen zoals die van de Belastingdienst of de Rechtspraak. Het is niet eenvoudig om delen van het systeem te vervangen, en het is vaak decennia oud. Keuzes die toen gemaakt zijn, zijn genomen in een hele andere context. Door de software opnieuw te bouwen, kan een flexibele en schaalbare architectuur worden geïmplementeerd die beter aansluit bij hedendaagse behoeften.
Gebruikers- en zakelijke behoeften
Veranderingen in gebruikersverwachtingen en bedrijfsstrategieën kunnen een heroverweging van de software vereisen. Herbouwen biedt de mogelijkheid om nieuwe functies en gebruiksvriendelijke interfaces te integreren die beter aansluiten bij de huidige eisen van gebruikers en bedrijven. Denk hierbij bijvoorbeeld aan een startup, die zich eerst richt op een gebruikersgroep, maar moet 'pivotten' naar een andere groep; die weer andere eisen met zich meebrengen.
Voorbeelden uit de praktijk
Succesverhalen zoals Netflix en Amazon, die hun platforms hebben herbouwd om te voldoen aan de hoge eisen van gebruikers en het veranderende technologische landschap, illustreren de voordelen van herbouw. Ze bereikten betere prestaties, hogere klanttevredenheid en verbeterde schaalbaarheid.
Alternatieven voor herbouw: modernisering versus complete rebuild
Code refactoring
Code refactoring houdt in dat de bestaande code wordt verbeterd zonder de kernfunctionaliteit te veranderen. Deze iteratieve aanpak kan de onderhoudbaarheid en prestaties verbeteren zonder de risico's van een volledige herbouw. Er zijn veel manieren om hetzelfde doel in code te bereiken, maar de vuistregel is: hoe eenvoudiger, hoe beter. Als een ontwikkelaar complexe code heeft geschreven en vervolgens het bedrijf verlaat, kost het een andere ontwikkelaar veel moeite om de code te doorgronden. Zonder de gehele software opnieuw op te bouwen, kun je dus stukje bij beetje refactoren om de code leesbaarder en begrijpelijker te maken.
Modulaire migratie
Bij modulaire migratie wordt software opgesplitst in kleinere, beter beheersbare modules. Deze modules kunnen afzonderlijk worden gemoderniseerd, waardoor het risico van een volledige herbouw wordt verminderd. Deze aanpak heeft potentie, maar bij Bergfort zagen we het regelmatig misgaan. Dit komt vaak doordat de zakelijke kant blijft vragen om nieuwe functionaliteit voor de 'oude' modules. Hierdoor wordt een nieuwe module ontwikkeld op basis van functionaliteit in de oude module, terwijl die functionaliteit ondertussen verandert.
Legacy software en integratie
API's en microservices maken het mogelijk om oude systemen te behouden en te integreren met nieuwe technologieën. Dit biedt een manier om functionaliteit uit te breiden zonder een volledige herbouw noodzakelijk te maken.
Kosten-batenanalyse van modernisering versus herbouw
Bij de keuze tussen modernisering en herbouw moeten zowel de financiële kosten als de impact op de bedrijfsprocessen worden overwogen. Modernisering kan vaak kostenefficiënter zijn, terwijl herbouw op de lange termijn meer voordelen kan opleveren.
Het "Not Invented Here"-syndroom en de drang om nieuw te bouwen
Definitie van het NIH-syndroom
Het "Not Invented Here"-syndroom verwijst naar de neiging van ontwikkelaars om voorkeur te geven aan het ontwikkelen van eigen oplossingen, in plaats van bestaande technologieën of producten te gebruiken.
Psychologie achter het NIH-syndroom
Ontwikkelaars hebben vaak een voorkeur voor het zelf bouwen van code vanwege trots op eigen werk en de overtuiging dat ze een betere oplossing kunnen creëren. Dit kan echter leiden tot inefficiënte besluitvorming.
Risico’s van NIH
Er zijn tal van voorbeelden waarin het NIH-syndroom heeft geleid tot onnodige herbouwprojecten, wat resulteerde in verspilling van tijd, middelen en soms zelfs projectfalen.
Manieren om NIH te herkennen en aan te pakken
Het herkennen van NIH begint met bewustwording binnen teams. Het bevorderen van een cultuur van openheid en samenwerking kan helpen om de neiging tot onnodig herbouwen te verminderen.
Uitdagingen en risico’s van een complete herbouw
Complexiteit van de bestaande functionaliteiten
Bij een herbouwproject wordt vaak de complexiteit van bestaande functionaliteiten onderschat. Het is cruciaal om alle functionaliteiten grondig te documenteren en te begrijpen voordat de herbouw begint.
Functionele en technische vereisten vergeten
Het risico bestaat dat tijdens een herbouw kleine maar belangrijke functionaliteiten worden overgeslagen. Dit kan leiden tot ontevredenheid bij gebruikers en verlies van essentiële functionaliteit.
Gebruikersovergang en acceptatie
Een nieuwe versie van de software kan weerstand oproepen bij gebruikers, vooral als de interface of functionaliteit verandert. Het is belangrijk om gebruikers bij het proces te betrekken en hen te trainen in de nieuwe software.
Data migratie
Het overzetten van data van een oude naar een nieuwe architectuur is complex en risicovol. Zorgvuldige planning en testen zijn noodzakelijk om dataverlies of corruptie te voorkomen.
Tijd en kosten van herbouw
Realistische planning en inschatting
Onrealistische planning en onderschatting kunnen leiden tot budgetoverschrijdingen en gemiste deadlines. Het is essentieel om een gedetailleerde planning en begroting te maken en rekening te houden met onvoorziene uitdagingen.
Kosten van herbouw versus doorontwikkeling
Het is belangrijk om de directe en indirecte kosten van herbouw te vergelijken met die van doorontwikkeling. Hoewel herbouw initieel duurder kan zijn, kan het op de lange termijn meer waarde opleveren.
Impact op de dagelijkse operatie
Herbouw kan de dagelijkse bedrijfsvoering verstoren, vooral als teamleden zich voornamelijk op de herbouw moeten richten. Het is belangrijk om een balans te vinden tussen lopende operaties en het herbouwproces.
Vooruitgang in technologieën en tools die het herbouwproces kunnen versnellen
Automatisering en AI
Nieuwe tools die codeherkenning en transformatie automatiseren, maken het mogelijk om sneller en efficiënter te herbouwen. AI kan helpen bij codegeneratie en refactoring, waardoor ontwikkeltijd wordt verkort.
Low-code en No-code oplossingen
Low-code en no-code platforms bieden een manier om snel complexe functionaliteiten te ontwikkelen zonder uitgebreide codering, wat het herbouwproces kan versnellen.
Cloud-native architecturen en DevOps
Cloud-native architecturen en DevOps-praktijken verbeteren schaalbaarheid en continue integratie, waardoor herbouwprojecten sneller en efficiënter kunnen worden uitgevoerd.
Codeanalyse en Model-based Development
Tools voor codeanalyse en modelgebaseerde ontwikkeling helpen bij het automatisch analyseren van bestaande code en het omzetten naar herbruikbare ontwerpen, wat het herbouwproces vereenvoudigt.
Projectbeheer en change management bij een rebuild
Risico’s in planning en scope creep
Scope creep is een veelvoorkomend probleem bij grote projecten zoals een herbouw. Het is belangrijk om duidelijke doelstellingen en een strak omschreven scope te hebben om te voorkomen dat het project uit de hand loopt.
Betrokkenheid van stakeholders
Het betrekken van stakeholders en eindgebruikers gedurende het herbouwproces is cruciaal om ervoor te zorgen dat de nieuwe software voldoet aan hun eisen en verwachtingen.
Iteratieve benadering versus Big Bang-herbouw
Overwegingen voor een gefaseerde herbouw kunnen minder disruptief zijn dan een volledige "big bang"-release. Iteratieve benaderingen bieden de mogelijkheid om geleidelijk veranderingen door te voeren en feedback te integreren.
Wanneer en waarom een herbouw wel de beste optie kan zijn
Evaluatiecriteria voor een herbouwbesluit
Er zijn specifieke criteria die een herbouw rechtvaardigen, zoals ernstige architecturale beperkingen, hoge onderhoudskosten door verouderde technologieën, of als de software niet meer voldoet aan de bedrijfsdoelen.
Verouderde technologieën en platformondersteuning
Wanneer technologieën niet langer worden ondersteund, en het onderhouden van het systeem duurder wordt dan herbouw, kan herbouw de beste optie zijn.
Voorbeelden van succesvolle herbouw
Bedrijven zoals Spotify en Slack hebben met succes hun platforms herbouwd om te profiteren van nieuwe technologieën, wat resulteerde in verbeterde prestaties en gebruikerstevredenheid.
Impact op concurrentievoordeel en schaalbaarheid
Een succesvolle herbouw kan de schaalbaarheid en flexibiliteit van de software verbeteren, waardoor bedrijven een concurrentievoordeel kunnen behalen en beter kunnen inspelen op toekomstige behoeften.
Conclusie: bestaande software herbouwen of niet?
Samenvatting van de afwegingen
De beslissing om bestaande software te herbouwen moet zorgvuldig worden overwogen, rekening houdend met technische schuld, architecturale beperkingen, gebruikersbehoeften en zakelijke doelstellingen.
Aanbevelingen
Herbouw kan een verstandige keuze zijn wanneer de kosten van onderhoud en modernisering hoger zijn dan die van herbouw, of wanneer de huidige software niet langer voldoet aan de bedrijfsdoelstellingen.
Blik op de toekomst
Ontwikkelingen in technologie, zoals AI en automatisering, zullen de besluitvorming over herbouw in de toekomst beïnvloeden, en kunnen het proces vergemakkelijken en versnellen.
