Te vaak wordt bij modernisatie van softwareapplicaties niet goed gekeken naar de technische staat van de huidige applicatie. Techneuten vinden al snel dat het helemaal opnieuw moet, terwijl de business geen geld wil verspillen aan technische mooimakerij. Een analyse van de ‘technical debt’ helpt dan om de discussie op het juiste niveau te voeren.
Met het groeiend aantal softwareapplicaties in organisaties, groeit ook het aantal applicaties dat al langer meegaat. Er kunnen diverse redenen zijn om te besluiten een bestaande applicatie te moderniseren. Soms is de directe aanleiding een verouderd of niet meer ondersteund onderliggend platform. Andere applicaties kunnen niet meer voldoende mee in de veranderende behoeften. De keuze voor een strategie voor modernisering hangt in grote mate van af van wat de aanleiding is.
Een strategie kan gericht zijn op een volledig nieuw ontwerp, een zogenaamd grand re-design, maar ook op een puur technische migratie met zoveel mogelijk hergebruik van bestaande investeringen. Grand re-design is een relatief dure oplossing, zonder garantie op succes. Daarentegen brengt het behoud van bestaande investeringen meestal met zich mee dat veel van de bestaande problemen ook worden behouden. Het is daarom belangrijk eerst een goed beeld te hebben van de huidige staat van de applicatie en welke problemen precies opgelost moeten worden door het modernisatieproject.
Technical debt
Technical debt is een metafoor die helpt om over de gevolgen van technische problemen te praten zonder te verzanden in de technische details. Technical debt treedt op als er, al dan niet bewust, voor een oplossing wordt gekozen die op de korte termijn voordelig is (of lijkt) en gelijktijdig op de langere termijn extra kosten met zich meebrengt. Deze technical debt kan worden vergeleken met financiële schuld in de zin dat er kosten naar de toekomst worden doorgeschoven. Zolang de kortetermijnoplossing niet wordt omgezet in een structurele oplossing brengt dit diverse, vaak verborgen kosten met zich mee. Relatief eenvoudige aanpassingen blijken ineens veel meer tijd te kosten, er treden onverwacht veel fouten op en nieuwe ontwikkelaars hebben meer tijd nodig om zich de applicatie eigen te maken. Deze verborgen kosten kunnen worden gezien als de rente die men betaalt voor het hebben van de schuld. Om de schuld in te lossen moet de kortetermijnoplossing worden omgezet in een structurele oplossing.
Technical debt is evenals een financiële schuld niet per definitie slecht. Er zijn situaties waarin bijvoorbeeld een deadline belangrijk genoeg is om een schuld te accepteren als die deadline daardoor kan worden gehaald. Net als bij een financiële schuld kun je afwegen of de totale kosten van de schuld, de rente plus de aflossing, opwegen tegen de baten van het halen van de deadline. De randvoorwaarde is dan wel dat de lasten van de nieuwe schuld, in combinatie met die van eventueel eerder opgedane schuld, gedragen kunnen worden. Op dezelfde manier kan ervoor worden gekozen een al bestaande schuld voor langere tijd te laten bestaan. Bijvoorbeeld omdat het een onderdeel betreft waar relatief weinig onderhoud op wordt gepleegd en waarvoor de rente dus laag is ten opzichte van de kosten voor het aflossen. Het is belangrijk dat deze keuze bewust en weloverwogen gemaakt wordt.
Behoud van technical debt bij applicatiemodernisatie
Technical debt kan zich op verschillende niveaus bevinden. Hierbij valt te denken aan onduidelijke namen voor variabelen, gedupliceerde code, het niet voldoen aan codeerstandaarden, onoverzichtelijke codestructuren, een slecht genormaliseerd datamodel of het niet volgen van een passende applicatiearchitectuur. Afhankelijk van het type en de hoeveelheid technical debt dat aanwezig is zijn verschillende strategieën tot applicatiemodernisatie meer of minder geschikt om deze technical debt aan te pakken.
Bij een sterk geautomatiseerde modernisatie is er een grote kans dat veel van de bestaande technical debt behouden blijft. Tools die bijvoorbeeld code vertalen van de ene naar de andere programmeertaal, laten doorgaans de structuur in de basis ongewijzigd. Hier geldt dan ook het principe ‘garbage in, garbage out’. De kans is zelfs groot dat er nieuwe problemen bijkomen. De code voldoet bijvoorbeeld niet aan de gangbare standaarden voor het doelplatform. Daardoor kunnen ontwikkelaars die ervaring hebben met het doelplatform de code moeilijk lezen. Het resultaat is vergelijkbaar met een Google-translate vertaling van het Nederlands naar het Engels; het is voor een Engelstalig persoon met enige moeite wel min of meer te begrijpen, maar het lijkt niet op iets wat een ‘native speaker’ zelf geschreven zou hebben. Ook de voordelen van de nieuwe omgeving worden doorgaans niet optimaal benut. Na de migratie kunnen de nieuwe mogelijkheden van het doelplatform wel alsnog worden gebruikt. Veel moderne ontwikkelomgevingen beschikken over tools die kunnen helpen om een deel van de technical debt na de migratie alsnog weg te werken.
Een andere veel toegepaste strategie is het één-op-één herbouwen van de bestaande applicatie in nieuwe technologie. Meestal moet dit, bij ontbreken van een up-to-date functioneel ontwerp, gedaan worden op basis van alleen de broncode. Bij deze strategie is het wel mogelijk een groot deel van de technical debt op code en soms zelfs architectuurniveau weg te werken. Ook kunnen de specifieke voordelen van het nieuwe platform beter benut worden. Net als bij gebruik van een migratietool is er bij één-op-één herbouw wel nog steeds een reëel risico dat technical debt uit de oude code doorsijpelt naar de nieuwe code. Ontwikkelaars moeten ‘aannemen’ dat het huidige gedrag dat zij aflezen uit de code ook het gewenste gedrag is. Vooral als er al veel technical debt is, is het lezen van de oude code erg lastig waardoor het moeilijk is de bedoeling te ontrafelen. Slecht onderhouden code heeft bijvoorbeeld vaak ‘bijzonder’ gedrag in situaties die in de praktijk nooit voorkomen. Als dit gedrag één-op-één herbouwd wordt ‘omdat dat de opdracht was’, dan leidt dit weer tot onnodig complexe code. In veel gevallen is het bijzondere gedrag echter helemaal niet het gewenste gedrag, maar een gevolg van eerder opgelopen technical debt. In het ergste geval worden bugs bewust opnieuw ingebouwd of worden complete features, die al enige tijd niet meer gebruikt werden, toch opnieuw gebouwd.
Voorkom verrassingen achteraf
Een technical debt is zoals gezegd niet per definitie slecht. Het is daarom ook niet per definitie slecht dat (een deel van) de bestaande technical debt na een modernisatieproject nog steeds terug te vinden is in de nieuwe applicatie. Het is natuurlijk wel prettig als dat een weloverwogen keuze is. Het komt helaas te vaak voor dat de resterende technical debt als een vervelende verassing achteraf komt, omdat verondersteld werd dat met de modernisatie ‘alle problemen zouden worden opgelost’.
Om een goede keuze te maken voor de modernisatieaanpak, is het belangrijk eerst een duidelijk beeld te hebben van wat er precies gemoderniseerd moet worden. Daarom is het raadzaam eerst goed in kaart te brengen welke technical debt er in de huidige applicatie aanwezig is. Vervolgens kan besloten worden welk deel daarvan als onderdeel van de modernisatie aangepakt moet worden. De te kiezen strategie, variërend van ‘grand re-design’ tot ‘geautomatiseerde conversie’ kan daar dan op worden afgestemd. Resterende technical debt kan alsnog kort na het modernisatieproject worden opgepakt of, zoals men gewend was, uitgesteld worden tot ‘een geschikt moment in de toekomst’.
Een erg leuke metafoor.
Alleen dat “geschikt moment in de toekomst” wil nog wel eens dwars zitten.
Jammer genoeg al een paar keer gezien dat van uitstel afstel komt, en je jaren later nog steeds tegen de keerzijde van de keuzes van weleer aanloopt als er onderhoud gedaan moet worden op de software.
Zoals dan ook de rente / eventuele boetes bij een bank oplopen, zo lopen ook de kosten van het blijven onderhouden van je product op.
Hoi Frank, leuk artikel om te lezen. Je snijdt hier een punt aan die inderdaad velen organisatie op dit moment ervaren. De analyse moet dus ook goed uitgevoerd worden. Ik ervaar ook veel dat de organisatie het systeem volgt en dat dit soms niet meer efficient is.
Het herscrhijven van een applicatie heeft daarom ook soms het voordeel dat naast nieuwe technologie ook de processen verbeterd (efficienter) kunnen worden.
Het zal de IT nog jaren bezig houden want elke nieuwe app wordt uiteindelijk weer oud.
Om technical debt te voorkomen is het verstandig om de bestaande (ik neem aan maatwerk) applicatie te laten voor wat deze is, dus met technical debt.
Vervolgens begint men om requirements vast te stellen op basis van dit moment en daarbij een standaard applicatie te zoeken en deze te implementeren.
Bij het aanpassen van bestaande applicaties kom je steeds tot de conclusie dat er technical debt aanwezig is en aanwezig zal blijven.
@Pa Va Ke, een grote valkuil bij het laten oplopen van technical debt is inderdaad de ‘negatieve schulden spiraal’ waardoor menig applicatie uiteindelijk totall loss is geraakt. Bij technical debt is dit gevaar vaak groter dan bij een financiële schuld omdat men zich nog minder bewust is van het feit dat er een schuld is. Door hier bewust van te zijn kun je beter bijsturen voor het te laat is.
@Ruud, herschrijven is inderdaad in sommige gevallen het enige resterende alternatief. Het is dan vooral belangrijk de requirements opnieuw tegen het licht te houden. Anders is de kans groot dat je tijd en geld aan de verkeerde dingen besteed.
@Willem, ik denk zeker niet dat het in alle situaties het beste is om de bestaande applicatie af te schrijven en helemaal opnieuw te beginnen. Als de technical debt heel hoog is opgelopen is dit soms helaas wel de enige oplossing. Beter is om het oplopen van technical debt in de hand te houden en doorlopend te moderniseren.
Technical debt is voornamelijk de divergentie, die veroorzaakt wordt door de tijd tussen wat een infrastructuur beidt en wat de organisatie nodig heeft, veroorzaakt door de inflexibiliteit van een infrastructuur.
Op zich is daar niets mis mee, maar ook, juist het van scratch beginnen lijkt dan een rigoureuze en alles oplossende stap is dat natuurlijk niet.
Dat inzicht vergt echter kennis en ervaring
@Maarten,
Ik heb je eerste volzin meerdere malen gelezen, maar ik begrijp eerlijk gezegd niet goed wat je bedoeld. Ik heb het idee dat je hier een redelijk nauwe definitie van het begrip technical debt beschrijft.
Technical Debt is een metafoor die oorspronkelijk bedacht is door Ward Cunningham. Het is een metafoor die een veel situaties toegepast kan worden. Het wordt veel gebruikt in de context van software development, maar kan ook worden toegepast op infrastructuur of andere enginering disciplines en met een beetje fantasie op handmatige procedures, organisatie inrichting etc. Zoals iedere metafoor moet je ook opletten dat je het niet te ver doortrekt want een ’technical debt’ in nu eenmaal niet exact hetzelfde als een financiële schuld. De metafoor is een hulpmiddel in de communicatie, als het helpt pas je hem toe, als het niet helpt dan pas je hem vooral niet toe. Je kunt daarom niet eenduidig definiëren wat technical debt voornamelijk wel of niet is.
Ik ben gek op Technical Debt als term. Hier wellicht ook een voorbeeld uit mijn doos.
Er zijn twee SQL Servers waaruit data gebruikt wordt voor een applicatie. Om deze data te combineren wordt er een link (koppeling) gemaakt tussen deze twee databases zodat je gemakkelijk de data uit deze databases kunt ophalen en combineren. Een goede oplossing voor de korte termijn, maar niet houdbaar als er geschaald moet worden. Door de tijd heen worden er steeds meer query’s en mogelijkheden gebaseerd op deze koppeling. Overgaan op de lange termijn oplossing wordt steeds moeilijker en duurder waardoor de overstap steeds verder wordt uitgesteld, maar er vervolgens ook steeds verder wordt doorgebouwd op deze koppeling.
De schuld wordt op een gegeven moment zo hoog dat men zich in allerlei bochten gaat wringen om de schuld niet te hoeven inlossen met het gevolg dat dit alleen maar erger wordt.
Zoals Frank beschrijft hoeft een schuld niet per se slecht te zijn, als men er maar bewust van is. Je kunt de schuld namelijk niet zien. De oplossing voldoet aan alle zichtbare requirements.
Zo kan ik nog wel tien voorbeelden noemen. Dit is echt een reëel fenomeen en een echt gevaar en daarom dus heel relevant.
@Frank
ik poogde ermee de discussie wat minder grijs en wat meer zwart wit te maken, omdat TD uitgelegd wordt zoals het een ieder dan uitkomt. Daarbij komt, maar misschien is het meer kenmerkend voor de C in iCt dat ook al sluit een communicatie-infrastructuur nauw aan bij oplevering en initieel gebruik, later divergeert dat…..
@Maarten, Ik ben zelf meer van het grijs dan van het zwart wit, of liever zelfs kleur want dan zie je veel meer nuances :-). In de situatie die jij beschrijft gaat de technical debt metafoor denk ik ook op. Het is niet de eerste situatie waar ik aan denk maar dat zal mijn eigen tunnelvisie zijn.
Zelf gebruik ik de term TD vooral voor zaken die in eerste instantie al niet zo netjes zijn opgelost, maar functioneel wel voldoen. Door deze technical debt worden bijvoorbeeld (relatief kleine) veranderingen in de functionele wensen ineens veel duur dan men zou verwachten.
@ Frank,
om zwart en wit uit elkaar te trekken moet je goed overweg kunnen met de tussenliggende grijstinten. 🙂 Divergentie is op zich aardig, maar met de convergentie, mits die volgt op de divergentie, is het mogelijk om naar een volgende stap te gaan.
Zeker kan bij het begin, de aanvang van het gebruik…, van een infrastructuur al sprake zijn van TD. Ik ging nog uit van het “ideale” geval dat dat pas later, “ruim” na het begin zou ontstaan.
Het wordt er in feite alleen maar “erger” door, dan ik al “dacht”. 🙁