Creëren we vandaag de legacy systemen van morgen?

In de vorige blog zijn we te weten gekomen wat een legacy systeem precies is. In dit blog vragen we onszelf af of men tegenwoordig de legacy systemen van de toekomst bouwt of juist niet.

legacy systeem, software rot, software decay, legacy systemen van de toekomst

Waarom zijn de systemen van 10 - 30 jaar terug nu ‘legacy’?

Voordat we induiken op de vraag of de software van vandaag morgen legacy is kijken we allereerst naar de legacy systemen van nu. Hoe zijn de systemen van 10 - 30 jaar terug eigenlijk ‘legacy’ geworden? Een belangrijke verklaring is dat veel van de huidige verouderde systemen zijn gebouwd in een tijd waarin computerverwerking en opslagcapaciteit veel duurder waren dan nu [1]. Met als gevolg dat efficiëntie vaak voorrang kreeg boven het begrijpen en onderhouden van het systeem, laat staan het netjes bijhouden van documentatie. Dit heeft het onvermijdelijke gevolg dat deze systemen in de loop van de tijd achteruit zijn gegaan [2].

Software decay

Een software systeem kan daarnaast ook achteruit gaan dankzij het zogeheten ‘software decay'. Software decay vindt plaats als de software van een systeem niet actief wordt onderhouden of als er met een slechte werkwijze aan het systeem wordt gewerkt. Software decay resulteert er uiteindelijk in dat het systeem 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 compatibel meer is met deze lagen.

software stack

Voorbeeld: bedrijf X bouwt nieuwe features aan een systeem. Het bedrijf neemt daarnaast geen tijd om het systeem te herstructureren of reorganiseren. Een tijd later wil het bedrijf weer een nieuwe feature bouwen, maar de bestaande laag kan de nieuwe feature niet helemaal ondersteunen. Dit lost bedrijf X op met een workaround. Vervolgens bouwt het bedrijf daarna nóg een nieuwe feature met een 'shortcut': de nieuwe feature praat direct met de database, omdat de api het nog niet ondersteund. Nu heeft bedrijf X een probleem. Het kan niet meer voor een ander database type kiezen, omdat bedrijf X het systeem met deze slordige aanpassingen te rigide heeft gemaakt.

Je kunt software decay vergelijken met een huis op een onstabiel fundament dat wordt verwoest door een aardbeving. Daarbij is het huis de software zelf. Het onstabiele fundament 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 verwoesting.

Creëren we vandaag de legacy van morgen?

Dan komen we nu bij de vraag of we vandaag de legacy van de toekomst creëren.

Ondanks dat legacy systemen van vandaag flinke gebreken kunnen vertonen is dit niet automatisch de voorspelling van hoe de systemen van nu er in de toekomst bij zullen staan. Tegenwoordig ligt bij veel softwarebedrijven namelijk de nadruk op een doordachte architectuur, hergebruik van componenten en het werken met bibliotheken die regelmatig worden geupdate of soms zelfs automatisch worden geupdate. Deze moderne manier van software ontwikkelen kan het onderhoud van systemen aanzienlijk versimpelen, waardoor ook onderhoudskosten stukken lager uitvallen.

Maar kunnen we legacy ook helemaal voorkomen? Helaas (nog) niet. Ook een softwaresysteem van vandaag zal over een aantal jaar legacy worden. Je kunt dit verouderingsproces wel vertragen door het systeem op een doordachte en duurzame wijze te bouwen en onderhouden en dus niet op de wijze zoals we in het voorbeeld hierboven zagen!

Meer lezen over legacy systemen?

Lees ook de blog wat is een legacy systeem? en kom achter of jouw organisatie te maken heeft met een legacy systeem.

Vragen over legacy systemen?

Bel met een expert

Paul Noordhuizen

06 484 31 088

Paul

Bronnen

[1] Economist, ‘After Moore’s Law’, The Economist Technology Quarterly, (2016).

[2] M.M. Lehman, ‘Laws of Software Evolution Revisited’, Software Process Technology (2005) Volume 1149 p108-124 Springer.