#legacysysteem   #legacysoftware   #systeemmodernisering

Versla het Spaghetti Monster van legacy software & systemen

Paul Noordhuizen

 - 

19 min

Menige actiehelden-Hollywood-film of zelfhulpboek heeft als belangrijk thema “build a legacy”. Bouw iets op in je leven waar je trots op bent, zowel privé als zakelijk. Iets waarmee je waardevol bent voor de maatschappij. Gek eigenlijk dat “legacy” in software & systemen een heel andere betekenis heeft, eigenlijk 180 graden gedraaid.

Het Spaghetti Monster: verouderde software en systemen

Als we het (online) woordenboek er even bijpakken komen we een aantal mooie definities tegen van “legacy” in de informatica:

“Oude informatiesystemen die blijven functioneren binnen een organisatie”,

“Een legacy applicatie of systeem is mogelijk gebaseerd op verouderde technologieën, maar is van cruciaal belang voor de dagelijkse bedrijfsvoering”

En onze persoonlijke favoriet:

“Elk bedrijfskritisch softwaresysteem dat zich aanzienlijk verzet tegen wijzigingen. Falen ervan kan een aanzienlijke impact hebben op het bedrijf”.

spaghetti monster

We hebben een monster gecreëerd

Wij komen het keer op keer tegen: organisaties met grote softwaresystemen die al 10 jaar of nog langer in productie gebruikt worden en waar een hele business op draait en van afhankelijk is. Systemen waarvan de technologie inmiddels links en rechts is ingehaald, maar de systemen zo complex zijn geworden en zo breed worden gebruikt in de organisatie dat ze heel moeilijk te vervangen zijn.

Ontwikkelaars die de softwaresystemen onderhouden proberen dag-in-dag-uit een monster te temmen. Schijnbaar willekeurig vallen onderdelen van de software uit of vertonen raar gedrag. De systemen worden dag en nacht koortsachtig gemonitord om in actie te springen als iets eruit klapt. En dat gebeurt, regelmatig. Het piept en kraakt. Organisaties die zichzelf prijzen omdat ze goed zijn in het oplossen van incidenten. De business heeft er vaak last van als een onderdeel vastloopt, loopt omzet mis of de uitval zorgt voor niet-productieve medewerkers. Er is continu een gevoel van druk bij de ontwikkelaars, of nog erger: gelatenheid. Het is normaal geworden. De softwaresystemen zijn door de jaren heen een soort “black box” geworden. Een kluwen van verschillende applicaties en systemen die om historische redenen helemaal met elkaar verweven zijn: een ingewikkelde spaghetti.

Of met een mooi woord: Frankenstein Software.

Download dit blog als whitepaper (gratis)

Dowload de whitepaper!

Download nu »
legacy software whitepaper

Wereldwijd onderzoek: enorme verspilling van ontwikkelcapaciteit

De afgelopen 10 jaar is er veel veranderd in software ontwikkeling. Het watervalmodel is (bijna) overal vervangen voor Agile werken, de introductie van Low-Code oplossingen heeft een grote vlucht genomen en Software-as-a-Service maakt op steeds meer plekken ruimte voor Platform-as-a-Service. De druk om continu te blijven innoveren is één van de redenen om 2-wekelijks of dagelijks nieuwe software updates door te voeren. Stilstand betekent meer dan ooit een razendsnelle achteruitgang. Toch liggen er nog volop kansen als we kijken naar verspilling van ontwikkelcapaciteit.

Betaalprovider Stripe heeft in 2018 een wereldwijd onderzoek uitgevoerd onder duizenden C-level executives en software ontwikkelaars in zes verschillende landen. Wat blijkt? Veel software ontwikkelaars:

onderzoek stripe software ontwikkelaars

Van een 40-urige werkweek wordt ongeveer 18 uur verspild aan het verbeteren en werken met verouderde code / systemen. Bijna 50% van de tijd van de developers gaat ten koste van innovatie, en productiviteit.

Dit komt neer op zo’n 85 miljard dollar wat jaarlijks verloren gaat wereldwijd! Kortom, tijd voor actie!

Hoe is de spaghetti ontstaan?

“Hoe hebben we het zover laten komen?” is een veelgestelde vraag binnen organisaties die kampen met legacy software als blok aan hun been. Dat is eigenlijk best heel logisch als je de historie van de (op)bouw van legacy systemen beter bekijkt. Laten we eens inzoomen op een aantal bekende symptomen.

3

Stukje-bij-beetje-bijbouwen

Toen wij 20 jaar geleden begonnen met software ontwikkeling met webtechnologie waren er nog vrijwel geen frameworks en (open-source) componenten beschikbaar: je bouwde ongeveer alles zelf. Toen kwamen zo’n 15 jaar geleden de eerste frameworks op en stond je met je bestaande software voor een belangrijke beslissing: ga ik verder met mijn eigen ontwikkelde ‘framework’ of gaan we migreren naar een groot (open-source) framework?

En welke framework kiezen we dan? Het heeft toch wel veel weg van een paardenrace: je kunt je vooraf goed verdiepen in de verschillende frameworks, maar welke gaat de race om de beste te zijn winnen? En wat houdt het in om de beste te zijn? Migratie naar zo’n framework vraagt om een beste investering. Veel organisaties durfden die stap niet te nemen en ging liever door met het stapsgewijs doorontwikkelen en uitbreiden van hun bestaande zelfbouw applicatie. Totdat deze applicatie zo groot is geworden dat het overgaan naar een framework nog moeilijker is geworden en een serieuze impact kan hebben. Je loopt vast.

5

Wisseling van developers / team(s)

Als je al 10+ jaar bezig bent met het doorontwikkelen van een software systeem is het niet gek dat in de loop der jaren verschillende ontwikkelaars betrokken zijn geweest en er wisselingen zijn geweest in het development team. De lead developer die het systeem destijds heeft opgezet is vertrokken voor een nieuw avontuur binnen of buiten de organisatie. Een nieuwe CTO focust zich volledig op andere technologie, waardoor bestaande developers vertrekken en daarmee veel kennis van de software systemen de deur uit loopt. We hebben het vaker zien gebeuren.

Zo ontstaat ook die “black box” waar we het eerder over hadden. De kennisoverdracht van de ene naar de andere developer is vaak maar beperkt. Bestaande documentatie laat erg te wensen over. Zo kan een volgende developer maar moeilijk alle ins & outs overzien en vraagt inwerken een aanzienlijke tijd.

1

Losse software-ontwikkeling, verspreid over jaren

We komen ook veel legacy systemen tegen, waaraan niet doorlopend is ontwikkeld maar er in losse ontwikkelprojecten aan is gewerkt, vaak verspreid over jaren en met verschillende developers waardoor er bij elk project vaak best “opportunistisch” is ontwikkeld om de projectdoelen te realiseren en niet breder te kijken naar onderhoudbaarheid en uitbreidbaarheid van het systeem.

Zo ontstaat de spaghetti van verschillende ontwikkelinspanningen die maar beperkt rekening houden met eerder gedaan werk en tegelijkertijd erg in elkaar vervlochten zijn.

4

Druk met deadlines om features te releasen, ‘geen tijd voor refactoring’

In het verlengde van het vorige punt krijgen ontwikkelaars vaak weinig tot geen tijd om de software tijdig te refactoren. Vaak wordt er gestuurd op het zo snel mogelijk releasen van nieuwe features en voelen ontwikkelaars de druk om die vooral te leveren terwijl tegelijkertijd de ‘technical debt’ flink toeneemt.

Deze ophoping van technical debt zorgt ervoor dat het steeds moeilijker wordt om nieuwe features te realiseren en/of dat er veel regressie ontstaat waarmee er steeds meer test & fix tijd nodig is om een stabiele release de deur uit te doen. Je belandt zo in een vicieuze cirkel van steeds meer stroperigheid in de ontwikkeling en groeiende onvrede bij zowel de business als de ontwikkelaars zelf.

4

Software decay

Een software systeem kan ook achteruit gaan door zogeheten ‘software decay'. Elk software systeem heeft een houdbaarheidsdatum en die gaat gelden als de software van een systeem niet actief wordt onderhouden of als er niet op een goede manier aan het systeem wordt gewerkt, zoals we hierboven hebben gezien. Software decay zorgt er uiteindelijk voor dat het systeem niet meer houdbaar is en stopt met functioneren.

Ondanks de naam ‘software decay' is niet de software zelf de boosdoener. Het is eerder de basis waarop de software is gebouwd: variërend van de hardware en het besturingssysteem tot aan de programmeertalen en bibliotheken. Deze ‘lagen’ kunnen door de tijd heen zodanig veranderen dat de software niet meer compatible is met deze lagen.

software stack voorbeeld

Je kunt software decay vergelijken met een huis op een slechte fundering dat wordt verwoest door een aardbeving. Daarbij is het huis de software zelf. De slechte fundering bestaat uit de verschillende lagen die door de tijd heen onvoldoende en slordig zijn bijgehouden met veel shortcuts en workarounds. De aardbeving staat voor een doorslaggevende update van een bepaalde laag of een nieuwe feature die de boel doet escaleren tot een noodtoestand.

De pijn van legacy software & systemen

“Mijn oude, vertrouwde software draait nog prima door. Is het dan erg dat het wat verouderd is? Waarom zou ik iets vervangen dat nog werkt?” Dat zijn gewoon logische vragen om te stellen. Maar wanneer gaan legacy software & systemen pijn doen?

2

Beveiligingsrisico’s

Als frameworks of belangrijke systeemcomponenten “end-of-life” zijn en daarmee niet meer onderhouden worden met o.a. security updates, loop je risico op misbruik daarvan door hackers. Denk aan datalekken of ander misbruik van je software. Je wilt toch niet op die manier het 8 uur journaal halen.

Je kunt ook issues krijgen met compliance. Als je bijvoorbeeld creditcardbetalingen via je software laat verlopen, moet je ervoor zorgen dat de beveiliging van je systemen op orde is. Nog een belangrijke prikkel om je legacy software & systemen aan te gaan pakken.

5

De continuïteit in gevaar

Bedrijfskritische legacy systemen die zo complex zijn geworden dat niemand meer goed overzicht heeft over de historische spaghetti, leiden vaak tot instabiliteit van je dienstverlening. Ongeplande down-time, productieverstoringen waarmee je team druk is om zo snel mogelijk op te lossen en een hoge mate van brandjes blussen. Dit brengt je core business in gevaar of in ieder geval belangrijke bedrijfsprocessen die soepel moeten verlopen.

4

Rem op innovatie en vernieuwing

Met verouderde software & systemen waarvan eigenlijk niemand meer de ins & outs kent, doe je steeds langer over het ontwikkelen van nieuwe features. Zoals we al zagen bij het wereldwijde onderzoek naar verspilling van ontwikkelcapaciteit is legacy software een serieuze rem op innovatie en vernieuwing van je organisatie. Kun je dan nog wel de concurrentieslag winnen?

Versla het Spaghetti Monster in 4 levels

Ga in 4 stappen het gevecht aan met je Spaghetti Monster en verlos jezelf van verouderde, bedrijfskritische applicaties met behoud van continuïteit.

Deze aanpak heeft een zeer interessante Return-On-Investment (ROI) met:

4

20-50% winst in productiviteit & werkvreugde van ontwikkelaars

4

30-75% kortere time-to-market van nieuwe features en goede ideeën

1

30-50% langere levensduur van technologie

Weten hoe? Lees snel verder!

infographic versla het spaghetti monster van legacy systemen en software

1Level 1: Breng het applicatielandschap in kaart

Start met het uittekenen van je Spaghetti Monster. En dan bedoelen we niet van die leuke groene poppetjes uit je schoolschrift van destijds. ;-)

Laten we er even een voorbeeld bij pakken. Hieronder hebben we een overzicht gemaakt van alle systemen die draaien binnen een fictieve organisatie, hoe deze high-level met elkaar zijn verbonden.

applicatielandschap voorbeeld

Dit is een mooi startpunt om verder de diepte in te gaan: down the rabbit hole. Inventariseer per systeem wat de belangrijkste features zijn en groepeer deze per bedrijfsproces om een goed beeld te krijgen wat elk systeem allemaal doet en wat de business waarde is. Verouderde systemen zijn vaak monolitisch en bevatten daarmee veel functionaliteit die je in volgende stappen wil isoleren en verplaatsen, vervangen of verwijderen. Goed documenteren in deze eerste stap gaat je erg helpen voor de volgende levels.

2Level 2: Bepaal je aanpak per applicatie

Hoe nu verder? Onderstaande beslissingsmatrix (1) kan je erg helpen om dit scherp te krijgen. Pak je lijstje van applicaties en systemen erbij uit de vorige stap en bepaal per applicatie in welk vakje van de matrix die thuis hoort:

beslissingsmatrix legacy systemen

Heb je al applicaties en systemen in het gele vak rechtsboven? Helemaal goed. Voor die software gewoon doorgaan met goed onderhoud, waarover zo meer in level 4. Valt een applicatie in het vlak rechtsonder en is het niet duur om te onderhouden, ook gewoon lekker doorgaan. Kost zo’n applicatie echter veel geld, maar heeft het weinig waarde voor je organisatie. Overweeg om daarmee te stoppen.

Legacy systemen zul je meestal aan de linkerkant plaatsen. Bedrijfskritische legacy applicaties zijn high value en moeten gemoderniseerd worden om de kwaliteit te verhogen. Van legacy systemen met low value kun je het beste snel afscheid gaan nemen.

Ok, je weet nu per applicatie wat je te doen staat. Nu is de vraag nog hoe.

3Level 3: Ontrafel de spaghetti terwijl de business doordraait

Hoe moderniseer je legacy applicaties? Dit zijn vaak monolitische systemen die complex en omvangrijk zijn. Wij zijn grote fans van een microservice architectuur, waarbij je stapsgewijs overgaat naar kleinere applicaties die via koppelingen slim met elkaar samenwerken. Dit zorgt voor meer flexibiliteit om in de toekomst uit te breiden en/of onderdelen te vervangen door veranderingen in de markt of nieuwere technologie. De kosten en de scope zijn dan ook veel overzichtelijker.

Om daar te komen, pak je opnieuw je lijstje erbij van applicaties, waarvan je in de vorige stap tot de conclusie bent gekomen dat die gemoderniseerd moeten worden.

Belangrijk is nu om de juiste mix te bepalen van bewezen technieken om te moderniseren met behoud van continuïteit voor de business. We hebben de technieken op een rij gezet:

1

Geautomatiseerde migratie

Met geautomatiseerde migratie zet je je verouderde ontwikkelplatform en databases over naar moderne oplossingen met behulp van softwaretools zoals geautomatiseerde parsers en converters. Enkele voorbeelden zijn migratie van data uit verouderde databases naar een moderne (serverless) database en herstructurering van je applicatie door het elimineren van dead code die nooit wordt uitgevoerd.

Automatische migratie houdt in dat het transformatieproces zoveel mogelijk automatisch verloopt, en relatief weinig menselijke intelligentie vereist. Dit is tevens een techniek om een legacy systeem naar meer flexibele omgevingen te verplaatsen.

4

Re-hosting

Met geautomatiseerde migratie zet je je verouderde ontwikkelplatform en databases over naar moderne oplossingen met behulp van softwaretools zoals geautomatiseerde parsers en converters. Enkele voorbeelden zijn migratie van data uit verouderde databases naar een moderne (serverless) database en herstructurering van je applicatie door het elimineren van dead code die nooit wordt uitgevoerd.

1

Pakketimplementatie

Pakketimplementatie houdt in dat je een legacy systemen vervangt door standaard softwarepakketten. Deze optie richt zich op het bouwen van een portfolio met de beste pakketten en componenten die verkrijgbaar zijn bij externe leveranciers. Hergebruik van bestaande verouderde bedrijfslogica is met deze benadering echter niet mogelijk. Desondanks zijn er bij een standaardpakketten vaak wel mogelijkheden voor kleine wijzigen of beperkte maatwerk opties, zodat je je bedrijfslogica tot op zekere hoogte kan herschrijven.

4

Reengineering / Rearchitecting

Reengineering of rearchitecting is de meest efficiënte modernisering techniek om legacy systemen te transformeren. Met deze aanpak verzamel je de requirements van de bestaande legacy systemen om deze vervolgens te herontwikkelen op nieuwere platforms met behulp van moderne technologieën.

0

Wrapping

Wrapping houdt in dat je de bedrijfslogica, gegevens en herbruikbare services uit je legacy systeem blootlegt en de bestaande applicatie-interfaces vervolgens “omhult” via een service wrapper. Hiermee creëer je (micro) services die die op een nieuw platform kunnen draaien voor stapsgewijze overgang. Wrapping is de eenvoudigste en meest kostenbesparende manier om de legacy modernisering aan te pakken.

0

Re-vamping

Re-vamping is het vernieuwen van de user interface van je applicatie met een nieuw ontwerp. Dit is ook wel het meest zichtbare onderdeel van elk systeem of applicatie. Het doel van re-vamping is de bruikbaarheid en gebruiksvriendelijkheid van het systeem te verbeteren.

Nu tijd voor actie om goed voorbereid de legacy systemen te moderniseren en/of vervangen!

4Level 4: Versla het Spaghetti Monster en verleng de

Nu je stapsgewijs los komt van je legacy systemen en overgaat naar moderne, kleinere applicaties binnen een microservice architectuur is het tijd voor onze secret sauce: Auto-Evergreen. Voorkom dat je vandaag de legacy creëert van morgen, maak je nieuwe applicaties future-proof en verleng de levensduur van (web)technologie.

Wat betekent Auto-Evergreen? Altijd up-to-date met je framework, componenten, bibliotheken, services, browsers, etc.. Dat klinkt als veel werk, maar dat kun je goed automatiseren met de juiste aanpak en tooling. Door op die manier legacy proactief tegen te gaan verleng je de levensduur van je technologie aanzienlijk en gaat er veel minder tijd verloren aan handmatige updates. Hierdoor kunnen ontwikkelaars hun tijd en creativiteit besteden aan klantwaarde: leveren van stabiele, kwalitatieve features.

Auto-Evergreen bestaat uit een aantal ingrediënten om in te regelen:

5

Continuous Integration & Continuous Delivery (CI/CD)

3

Goede test coverage met unit-tests, integration-tests en end-to-end-tests

1

Selectie van een tool voor automatische checks van alle dependencies van je applicatie, bijvoorbeeld dependabot

1

Automatische pull-requests voor versie-updates van dependencies in je applicatie(s), waarbij je CI/CD pipeline automatisch de gehele test suite uitvoert om te controleren of de versie-update voor falende tests zorgt

1

Bij alle tests ‘in the green’ automatische merge met je productieversie voor geautomatiseerde deployment

0

Bij falende tests automatische notificatie aan je ontwikkelteam om issues met versie-updates op te lossen

2

Review apps kunnen hier erg bij helpen, waarbij er automatisch een ontwikkelomgeving beschikbaar wordt gemaakt met precies die versie van de code. Een ontwikkelaar krijgt dan een linkje naar de ontwikkelomgeving om direct het issue aan te pakken, zonder de gebruikelijke overhead van uitchecken van de juiste branche en commit, uitvoeren van datamigraties, etc.

Kom in actie en ga in 4 stappen het gevecht aan met je “Spaghetti Monster”. Verlos jezelf van verouderde, bedrijfskritische applicaties met behoud van continuïteit.

Conclusie

Een mooie toekomst voor je organisatie wordt in belangrijke mate bepaald door het aanpassingsvermogen om snel in te spelen op veranderingen in de markt en de maatschappij. Dit betekent dat de software waar je organisatie op draait ook flexibel moet zijn om mee te bewegen.

Legacy applicaties en systemen verzetten zich aanzienlijk tegen veranderingen. Uit wereldwijd onderzoek blijkt dat ontwikkelaars bijna 50% van hun tijd verspillen aan het werken met verouderde software en systemen. Dit gaat ten koste van hun productiviteit en de innovatie binnen je organisatie.

Kom in actie en ga in 4 stappen het gevecht aan met je “Spaghetti Monster”. Verlos jezelf van verouderde, bedrijfskritische applicaties met behoud van continuïteit:

  1. Breng het applicatielandschap in kaart
  2. Bepaal je aanpak per applicatie
  3. Ontrafel de spaghetti terwijl de business doordraait
  4. Versla het Spaghetti Monster en verleng de levensduur van technologie met Auto-Evergreen

Deze aanpak heeft een zeer interessante Return-On-Investment (ROI) met:

5

20-50% winst in productiviteit & werkvreugde van ontwikkelaars

0

30-75% kortere time-to-market van nieuwe features en goede ideeën

4

30-50% langere levensduur van technologie

Dit blog downloaden als whitepaper?

Wil je dit blog als een mooie PDF downloaden om later nog eens terug te kunnen lezen of met anderen te delen? Dat kan! Vul je gegevens in en ontvang de whitepaper direct in je inbox.

legacy systeem whitepaper