{"id":87308,"date":"2026-09-30T01:27:15","date_gmt":"2026-09-30T01:27:15","guid":{"rendered":"https:\/\/hanstimmerman.me\/?p=87308"},"modified":"2026-09-30T01:27:15","modified_gmt":"2026-09-30T01:27:15","slug":"technical-debt-en-de-badkuipkromme","status":"publish","type":"post","link":"https:\/\/hanstimmerman.me\/en\/technical-debt-en-de-badkuipkromme\/","title":{"rendered":"Technical debt en de badkuipkromme"},"content":{"rendered":"

English version: scroll down<\/span><\/em><\/span><\/p>\n

Afgelopen week hoorde ik tijdens een CIO-bijeenkomst een spreker twee prioriteiten noemen die mij bijbleven: <\/span>\u2018reduce the technical debt and renew the foundation.\u2019<\/i><\/b> Twee korte zinnen, maar eigenlijk een complete IT-strategie. Ik heb de afgelopen jaren weinig leiders in de informatiewereld deze twee zaken zo expliciet naast elkaar horen zetten. Terwijl juist dit volgens mij de twee lastigste aandachtspunten zijn in een snel veranderende digitale wereld.<\/span><\/span><\/p>\n

Elk technisch systeem kent immers een soort badkuipkromme. Aan het begin zijn er kinderziektes: problemen die in de praktijk nog moet worden opgelost. Daarna volgt een periode waarin het stabiel en betrouwbaar functioneert. Maar aan het einde van de levensduur keert de problematiek terug. Componenten verouderen, kennis verdwijnt, onderdelen worden moeilijker verkrijgbaar, software wordt niet meer ondersteund en nieuwe eisen passen steeds minder goed bij de oorspronkelijke architectuur. De onderhoudskosten lopen op.<\/span><\/p>\n

Dat is het moment waarop technical debt ontstaat. Niet omdat het systeem ineens slecht is geworden, maar omdat we het te lang niet fundamenteel hebben vernieuwd. En hoe langer je daarmee wacht, hoe groter de schuld wordt.<\/span><\/p>\n

Onderhoud is niet hetzelfde als vernieuwing<\/b><\/span><\/p>\n

Een belangrijk onderscheid wordt daarbij vaak vergeten. Onderhoud houdt een systeem in bedrijf. Vernieuwing zorgt ervoor dat het systeem ook in de toekomst in bedrijf kan blijven. In de techniek kennen we daarvoor de mooie afkorting MRO: Maintenance, Repair and Overhaul. Onderhoud dus, repareren wanneer dat nodig is, maar vooral ook periodiek reviseren. Dat levert sustainability: instandhouding op lange termijn.<\/span><\/p>\n

De vliegtuigindustrie is daarvan een prachtig voorbeeld. Een vliegtuig wordt tijdens zijn levensduur niet simpelweg steeds verder onderhouden totdat het uiteindelijk uit elkaar valt. Het wordt periodiek grondig ge\u00efnspecteerd, gemodificeerd en gereviseerd en waar nodig voorzien van nieuwe systemen en componenten. Ook structurele onderdelen worden gecontroleerd en vervangen of versterkt.<\/span><\/p>\n

Het doel is niet om een oud vliegtuig nieuw te maken. Het doel is te voorkomen dat ouderdom leidt tot technische onbetrouwbaarheid. De F-16 is daarvan een mooi voorbeeld. Het ontwerp stamt uit de late jaren zestig, de eerste vlucht vond plaats in 1974 en het toestel werd einde van de jaren zeventig operationeel. Toch vliegen F-16\u2019s nog steeds. Niet omdat het oorspronkelijke vliegtuig onveranderd bleef, maar dankzij een lange reeks van onderhouds-, modificatie- en moderniseringsprogramma’s.<\/span><\/p>\n

De oorspronkelijk ontworpen levensduur van veel F-16’s lag rond de 8.000 vlieguren. Met structurele aanpassingen en service-life-extension programma’s is die voor bepaalde toestellen aanzienlijk verlengd, in sommige gevallen tot 12.000 vlieguren. Oud hoeft dus niet gammel te betekenen. Maar daar is wel een voorwaarde aan verbonden: \u2018je moet blijven vernieuwen<\/i>\u2019.<\/span><\/p>\n

Het fundament vernieuwen<\/b><\/span><\/p>\n

Daarmee komen we terug bij de tweede uitspraak van genoemde CIO: \u2018renew the foundation\u2019<\/i>. Want om een systeem te kunnen vernieuwen, moet het fundament die vernieuwing wel kunnen dragen. Een systeem is uiteindelijk niet sterker dan het fundament waarop het gebouwd is. Dat klinkt vanzelfsprekend, maar in de informatiewereld vergeten we het opvallend vaak. We vervangen applicaties, voegen functionaliteit toe, koppelen nieuwe databronnen en introduceren AI. Ondertussen blijft daaronder soms een infrastructuur staan die twintig of dertig jaar geleden is ontworpen.<\/span><\/p>\n

Dan ontstaat een merkwaardige situatie. We zetten een nieuwe verdieping op een gebouw waarvan de fundering nooit voor die extra belasting is ontworpen. Op een bepaald moment helpt onderhoud niet meer. Je kunt blijven repareren, maar het fundament begint de vernieuwing zelf tegen te houden.<\/span><\/p>\n

Daar komt \u2018creative destruction<\/i>\u2019 van Schumpeter om de hoek kijken. Soms moet je iets gecontroleerd afbreken om ruimte te maken voor iets nieuws. Dat is misschien wel een van de moeilijkste vormen van leiderschap. Waarom zou je iets vervangen dat vandaag nog werkt? Waarom geld investeren in iets wat gebruikers nauwelijks zien? Waarom een fundament vernieuwen als de business gewoon door moet? Juist die vragen zorgen ervoor dat technical debt zich kan opstapelen.<\/span><\/p>\n

Informatietechniek is nog jong<\/b><\/span><\/p>\n

De vliegtuigindustrie heeft ruim een eeuw ervaring met het ontwerpen, bouwen, onderhouden, modificeren en uiteindelijk vervangen van complexe systemen. De informatietechniek is in vergelijking pas half zo oud. Onze informatie-industrie heeft fundamentele architectuur-veranderingen doorgemaakt: van mainframes naar client\/server, van eigen datacenters naar internet en cloud. En nu naar gedistribueerde systemen, edge computing, microservices en AI-agents.<\/span><\/p>\n

Opvallend is dat de architectuur steeds lijkt terug te komen in nieuwe gedaanten. Het mainframe verdween niet echt, maar werd op een andere manier georganiseerd. De cloud bracht centrale reken- en opslagcapaciteit opnieuw als dienst terug. En nu zien we weer een beweging naar meer gedistribueerde intelligentie, waarbij microservices steeds vaker door en als AI-agents worden aangestuurd. De verpakking verandert, het onderliggende principe veel minder.<\/span><\/p>\n

Want uiteindelijk staat de meest geavanceerde cloud nog steeds in een datacenter. Een magazijn vol hardware, verbonden door netwerken en gevoed door elektriciteit. In die hardware worden elektronen door halfgeleiders gestuurd en ontstaat de fysieke basis waarop software, algoritmen en AI kunnen functioneren. We bouwen steeds nieuwe lagen bovenop dezelfde fysieke en technische werkelijkheid. En hebben nog steeds warmte als \u2018afval-product\u2019.\u00a0<\/span><\/span><\/p>\n

Voorkom dat je IT een oldtimer wordt<\/b><\/span><\/p>\n

Daarom vind ik de twee prioriteiten van die CIO zo interessant. \u2018Constantly reduce the technical debt & renew the foundation<\/i>\u2019. Het zijn geen technische projecten, maar twee voorwaarden om als organisatie te kunnen blijven vernieuwen. Wie technical debt laat oplopen, krijgt uiteindelijk steeds meer onderhoud en steeds minder ruimte voor vernieuwing. Het systeem is eerst als youngtimer: nog bruikbaar, maar steeds gevoeliger voor storingen, duurder om te onderhouden en lastiger aan te passen.<\/span><\/p>\n

En als je nog langer wacht, wordt het een oldtimer. Een oldtimer kan prachtig zijn, technisch perfect onderhouden zijn en nog jaren rijden. Maar je gebruikt hem anders. Voor een mooie rit op zondag is hij uitstekend; voor dagelijks, betrouwbaar en intensief transport is het een ander verhaal. Dat onderscheid zie ik ook in de informatiewereld. Bij veel organisaties staan systemen die al lang youngtimers zijn. Sommigen zijn zelfs regelrechte oldtimers geworden. Ze functioneren nog, maar iedere verandering wordt moeilijker, iedere koppeling complexer en iedere storing duurder.<\/span><\/p>\n

Daarmee wordt de \u2018technische schuld’<\/i> niet alleen een technisch probleem, maar een strategisch probleem. Werkelijk leiderschap betekent daarom niet alleen zorgen dat de systemen vandaag functioneren. Het betekent ook ervoor zorgen dat het fundament sterk genoeg blijft voor de systemen van morgen. Dat vraagt visie en technisch inzicht, maar vooral leiderschap, budget en doorzettingskracht. Creative destruction is zelden populair. Iets afbreken dat het nog doet, voelt als geld weggooien. Dat geld kunnen we immers ook aan veel leukere dingen besteden.<\/span><\/p>\n

Maar juist daarom is vernieuwend leiderschap nodig. Niet wachten tot de badkuipkromme je dwingt tot vernieuwing, maar vernieuwen voordat je aan het einde van de kromme bent aangekomen. Goed management van technische schuld is misschien wel een van de belangrijkste voorwaarden om een onderneming of organisatie duurzaam en toekomstbestendig te houden.
\n<\/span><\/p>\n

Photo by Erik Mclean<\/a><\/p>\n

\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014-\u00a0 <\/span>Translated by ChatGPT\u00a0 <\/span>\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014<\/span><\/p>\n

Technical Debt and the Bathtub Curve<\/b><\/span><\/p>\n

Last week, at a CIO gathering, I heard a speaker mention two priorities that stayed with me: \u201creduce the technical debt and renew the foundation.\u201d<\/i><\/b> Two short sentences, but in many ways a complete IT strategy. Over the past few years, I have heard few leaders in the world of information technology put these two issues together so explicitly. And yet, in my view, they are among the most difficult challenges we face in a rapidly changing digital world.<\/span><\/p>\n

Every technical system follows something like a bathtub curve. At the beginning, there are the inevitable teething problems: issues that still need to be discovered and solved in practice. Then comes a period in which the system operates in a stable and reliable way. But towards the end of its lifecycle, the problems start to return. Components age, knowledge disappears, parts become harder to source, software is no longer supported, and new requirements fit the original architecture less and less. Maintenance costs begin to rise.<\/span><\/p>\n

That is when technical debt starts to emerge. Not because the system has suddenly become bad, but because we have waited too long to fundamentally renew it. And the longer we wait, the greater the debt becomes.<\/span><\/p>\n

Maintenance is not the same as renewal<\/b><\/span><\/p>\n

An important distinction is often overlooked. Maintenance keeps a system running. Renewal ensures that the system can continue to run well into the future. In engineering, there is a useful acronym for this: MRO \u2014 Maintenance, Repair and Overhaul. Not just fixing things when they break, but periodically taking the system apart, inspecting it, improving it and renewing what needs to be renewed. In other words: long-term sustainability.<\/span><\/p>\n

The aviation industry is a great example. An aircraft is not simply maintained throughout its life until it eventually falls apart. It is regularly inspected, modified and overhauled, with new systems and components installed where necessary. Structural elements are inspected as well and strengthened or replaced when required.<\/span><\/p>\n

The goal is not to make an old aircraft new again. The goal is to prevent age from automatically turning into technical unreliability. The F-16 is a good example. Its design dates back to the late 1960s, its first flight took place in 1974, and it entered operational service towards the end of the 1970s. Yet F-16s are still flying today. Not because the original aircraft has remained unchanged, but because it has gone through a long series of maintenance, modification and modernization programmes.<\/span><\/p>\n

The originally designed service life of many F-16s was around 8,000 flight hours. Through structural modifications and service-life-extension programmes, that has been significantly extended for some aircraft, in certain cases to as much as 12,000 flight hours. Old does not necessarily mean fragile. But there is one important condition: you have to keep renewing<\/i>.<\/span><\/p>\n

Renew the foundation<\/b><\/span><\/p>\n

That brings us back to the CIO\u2019s second statement: \u201crenew the foundation.\u201d<\/i> To renew a system, the foundation underneath it must be able to support that renewal. Ultimately, a system can never be stronger than the foundation on which it is built.<\/span><\/p>\n

That sounds obvious, but in the world of information technology we tend to forget it. We replace applications, add functionality, connect new data sources and introduce AI. Meanwhile, underneath all of that, there may still be infrastructure that was designed twenty or thirty years ago.<\/span><\/p>\n

This creates a peculiar situation. We are adding a new floor to a building whose foundations were never designed to carry the additional load. At some point, maintenance is no longer enough. You can keep repairing things, but eventually the foundation itself starts to prevent further renewal.<\/span><\/p>\n

This is where Schumpeter\u2019s concept of creative destruction<\/i> comes in. Sometimes you have to deliberately dismantle something to create room for something new. That may be one of the hardest forms of leadership. Why replace something that still works today? Why spend money on something users barely notice? Why renew the foundation when the business needs to keep moving?<\/span><\/p>\n

Those are precisely the questions that allow technical debt to accumulate.<\/span><\/p>\n

Information technology is still young<\/b><\/span><\/p>\n

The aviation industry has more than a century of experience in designing, building, maintaining, modifying and eventually replacing complex systems. Compared with that, information technology is still relatively young. In a remarkably short period, our information industry has gone through several fundamental architectural shifts: from mainframes to client\/server, from on-premises data centres to the internet and cloud, and now towards distributed systems, edge computing, microservices and AI agents.<\/span><\/p>\n

What is striking is how often the underlying architecture seems to return in new forms. The mainframe never really disappeared; it was reorganized. The cloud brought centralized computing and storage back as a service. And now we are seeing another move towards distributed intelligence, with microservices increasingly being orchestrated by \u2014 and sometimes embodied in \u2014 AI agents.<\/span><\/p>\n

The packaging changes. The underlying principles change much less.<\/span><\/p>\n

Because ultimately, even the most advanced cloud still runs in a data centre. A warehouse full of hardware, connected by networks and powered by electricity. Inside that hardware, electrons move through semiconductors, creating the physical foundation on which software, algorithms and AI can operate.<\/span><\/p>\n

We keep building new layers on top of the same physical and technological reality. And we still produce heat as a by-product.<\/span><\/p>\n

Don’t let your IT become a classic car<\/b><\/span><\/p>\n

That is why I find the CIO\u2019s two priorities so interesting: \u201cConstantly reduce the technical debt and renew the foundation.\u201d<\/i> They are not two technical projects. They are two conditions for an organization to remain capable of continuous renewal.<\/span><\/p>\n

When technical debt keeps accumulating, maintenance takes up an ever-growing share of our attention and resources, leaving less room for innovation. The system first becomes a kind of youngtimer: still perfectly usable, but increasingly sensitive to failures, more expensive to maintain and harder to adapt.<\/span><\/p>\n

And if you wait even longer, it becomes a classic car.<\/span><\/p>\n

A classic car can be beautiful, perfectly maintained and capable of running for many more years. But you use it differently. It may be wonderful for a Sunday drive; it is a different proposition when you need reliable, intensive transportation every day.<\/span><\/p>\n

I see the same distinction in the world of information technology. Many organizations are running systems that have long since become youngtimers. Some have effectively become classic cars. They still work, but every change becomes more difficult, every integration more complex and every failure more expensive.<\/span><\/p>\n

Technical debt therefore becomes more than a technical problem. It becomes a strategic one.<\/span><\/p>\n

Real leadership is not only about making sure that systems work today. It is also about ensuring that the foundation remains strong enough for the systems of tomorrow. That requires vision and technical understanding, but above all leadership, budget and perseverance.<\/span><\/p>\n

Creative destruction is rarely popular. Dismantling something that still works can feel like throwing money away. After all, there are many more attractive things we could spend that money on.<\/span><\/p>\n

But that is precisely why renewal requires leadership. Do not wait until the bathtub curve forces you to act. Renew before you reach the end of the curve. Good technical-debt management may well be one of the most important conditions for keeping an organization sustainable and future-ready.<\/span><\/p>","protected":false},"excerpt":{"rendered":"

Creative destruction is rarely popular. Dismantling something that still works can feel like throwing money away. After all, there are many more attractive things we could spend that money on.<\/p>\n

But that is precisely why renewal requires leadership. Do not wait until the bathtub curve forces you to act. Renew before you reach the end of the curve. Good technical-debt management may well be one of the most important conditions for keeping an organization sustainable and future-ready.<\/p>","protected":false},"author":3,"featured_media":87311,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[275,1024,194,75,138],"tags":[109,119,122,457,631,1143,1144,1145,1146,1147],"class_list":["post-87308","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architectuur","category-economische-groei","category-transformatie","category-innovation","category-strategie","tag-innovation","tag-ai","tag-sustainability","tag-technicaldebt","tag-digitaltransformation","tag-itleadership","tag-technologystrategy","tag-mro","tag-aviation","tag-futureready"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/hanstimmerman.me\/wp-content\/uploads\/2026\/09\/pexels-introspectivedsgn-8266855-scaled-e1790731307911.jpg?fit=1690%2C862&ssl=1","_links":{"self":[{"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/posts\/87308","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/comments?post=87308"}],"version-history":[{"count":4,"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/posts\/87308\/revisions"}],"predecessor-version":[{"id":87313,"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/posts\/87308\/revisions\/87313"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/media\/87311"}],"wp:attachment":[{"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/media?parent=87308"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/categories?post=87308"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hanstimmerman.me\/en\/wp-json\/wp\/v2\/tags?post=87308"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}