English version: scroll down

Afgelopen week las ik een artikel over de promotie op 7 januari jl. van Erik Jochemsen over de beheersbaarheid van complexe informatiesystemen. Zijn proefschrift Shifting Information Systems Complexity maakt duidelijk dat senior management vaak onvoldoende grip en inzicht heeft in de werkelijke complexiteit van hun ICT-landschap. Ondanks ingrepen zoals systeemintegraties en architectuurprogramma’s blijven de resultaten structureel achter bij de verwachtingen.

Een belangrijke constatering is dat het ‘begrijpen van wat complexiteit ís’, al een eerste logische en dus noodzakelijke stap vormt, om die complexiteit überhaupt te kunnen overzien en beïnvloeden. Pas dán wordt het mogelijk om een ingewikkeld informatielandschap daadwerkelijk te managen.

Dit onderzoek deed mij denken aan een promotieonderzoek uit het begin van de jaren negentig aan de TU Twente: “Slack is altijd nodig”. Die studie onderzocht de opkomst van ERP-systemen, die waren gebaseerd op het idee dat alles planbaar en optimaliseerbaar was. In werkelijkheid kent elk systeem verstoringen, onvolkomenheden en onverwachte afwijkingen. Een planning die op 100% capaciteit is ingericht, loopt daarom per definitie vast — simpelweg omdat er geen ruimte is om fouten op te vangen.

Bij Fokker zagen we dit scherp terug bij de start van de productie van de Fokker 50 en 100. Het ERP-systeem was tot op de minuut ingepland om een extreem krappe planning te halen. Het resultaat was voorspelbaar: steeds grotere verstoringen, dalende efficiëntie, oplopende achterstanden en groeiende frustratie. Honderd procent efficiency is onmogelijk. 

Het verschil tussen ingewikkeld en complex

In mijn blog ‘Involution: meer inspanning zonder vooruitgang’ ga ik hier dieper op in. In systemen is altijd een zekere mate van slack nodig om onvolkomenheden — die altijd zullen optreden — te kunnen opvangen en herstellen. Hoe strakker een systeem wordt ontworpen en bestuurd, hoe gevoeliger het wordt voor – vaak niet-lineaire – verstoringen.

Hier ligt de grens tussen ingewikkeld (complicated) en complex. Een bekend onderscheid binnen Systems Engineering. Een ingewikkeld systeem kan uit zeer veel onderdelen bestaan, maar de relaties zijn voorspelbaar. Door het systeem te ontleden, is het te begrijpen en te beheersen — een vliegtuigmotor is daar een klassiek voorbeeld van.

Een complex systeem daarentegen kent dynamische interacties, emergente eigenschappen, feedbackloops en fundamentele onvoorspelbaarheid. Je kunt het gedrag vaak achteraf verklaren, maar niet deterministisch vooraf voorspellen. Kleine veranderingen kunnen grote, niet-lineaire effecten hebben. Complexiteit is daarmee zelden een ontwerp-keuze, maar vrijwel altijd het gevolg van slecht of onvoldoende beheer en/of onderhoud. En complexiteit heeft steeds grotere ‘slack’ nodig en wordt steeds inefficiënter.

Waarom worden informatiesystemen zo snel complex?

Elk informatiesysteem begint zijn leven als ingewikkeld. De processen die worden gemodelleerd, de data die door het systeem stroomt — alles is aanvankelijk goed beschrijfbaar en modelleerbaar. Chaos- en complexiteitstheorie laten echter zien dat zonder strak beheer van onderliggende subsystemen, nieuw en vaak onbegrepen systeemgedrag ontstaat uit interacties tussen componenten. Dit gedrag is niet terug te voeren tot afzonderlijke onderdelen maar ontstaat uit hun samenhang. 

Vooral bij adaptieve systemen en gecreëerde feedbackloops treedt dit verschijnsel op. In dat licht is de snelle opkomst van AI-agents zorgwekkend. Hun gedrag is per definitie niet volledig voorspelbaar, juist omdat van deze agents wordt verwacht dat zij leren. Hoe en op welke wijze dat leren plaatsvindt, kan verrassend uitpakken en leiden tot onbegrepen, moeilijk beheersbare complexiteit. AI fungeert hier niet als een nieuwe categorie, maar als een krachtige versneller van bestaande complexiteitswetten. Denk aan de hallucinerende AI-systemen die slimme geloofwaardige onzin creëren. 

Normalized Systems Theory en ‘shifting complexity’

Het verminderen van complexiteit voelt vaak als knijpen in een half opgeblazen ballon: je verschuift de complexiteit, maar vermindert haar niet. Dit fenomeen staat bekend als shifting complexity. Maatregelen elimineren de complexiteit niet, maar verplaatsen haar naar een ander deel van het systeem. Je moet de druk in de ballon verminderen, van binnenuit. 

Theorieën zoals de Normalized Systems Theory (NST) – zie mijn blog daarover – beschrijven hoe je modulariteit zó ontwerpt dat deze verschuiving wordt voorkomen. Modulair opgebouwde systemen beschouwen software als een kapitaalgoed dat decennialang onderhoudbaar en vernieuwbaar moet blijven. Zoals softwarepionier Douglas McIlroy het treffend verwoordde:
“De echte held van programmeren is degene die negatieve code schrijft.”

In mijn blog hierover verwijs ik naar de wet van toenemende complexiteit van Manny Lehman (1980), die stelt dat naarmate een zich ontwikkelend programma voortdurend wordt aangepast, de complexiteit onvermijdelijk toeneemt — tenzij er actief wordt gewerkt aan het behouden of verminderen ervan. Het toevoegen van functionaliteit aan bestaande informatiesystemen maakt deze in de loop der tijd steeds complexer en kostbaarder in onderhoud. Alleen intensief onderhoud en continue, rigoureuze vernieuwing kunnen de kwaliteit van software structureel in stand houden.

Als iets complex wordt, verlies je de grip

De kernuitdaging voor systeembeheerders is om een ingewikkeld systeem — dat helder en logisch functioneert — nooit complex te laten worden. Onderhoud moet daarom actief gericht zijn op het elimineren van opkomende complexiteit: niet-afgebakend gedrag en ongewenste feedbackloops moeten direct worden aangepakt. Dat kan door het systeem in meer subsystemen onder te verdelen.

Onze huidige informatiewereld, met multicloud-omgevingen en onbeheerde data-spaces, is voor veel mensen steeds moeilijker te overzien en dus te managen. Een bij oplevering ingewikkeld, maar nog beheersbaar systeem zal daardoor in de loop der tijd vrijwel altijd complexiteit opbouwen — en daarmee zijn beheersbaarheid verliezen. Net als de natuur: het systeem creeërt uit zichzelf de hoogste entropie. 

Negatieve code en de zwarte doos

De beroemde anekdote van Apple-ontwikkelaar Bill Atkinson luidt: “Pas wanneer een wijziging in de programmabron het aantal regels code doet afnemen (‘negatieve code’), zal de algehele kwaliteit, leesbaarheid of snelheid verbeteren.”Als een systeem in de loop der tijd groeit door updates en aanpassingen, is de enige remedie om die groei elders weer te elimineren. Dus lucht uit de ballon laten ontsnappen. 

Daarnaast is een basisarchitectuur nodig die geen combinatorische explosies toestaat bij vooraf gedefinieerde wijzigingen. Systems Engineering biedt hiervoor zeer concrete handvatten. Met mijn achtergrond in de vliegtuigbouw was de centrale vraag altijd eenvoudig: hoe lang kan ik een vliegtuig — ondanks alle MRO (maintenance, repair and overhaul) — vele decennia lang, aantoonbaar luchtwaardig houden? Door keer op keer het vliegtuig te strippen en weer op te bouwen.

In één van mijn recente blogs, ‘Zwarte doos om AI-agents te bewaken?’, grijp ik bewust terug op die luchtvaartmetafoor door de flight recorder te introduceren voor informatiesystemen. Het gedrag van een vliegtuig wordt continu vastgelegd, zodat verstoringen en veranderingen achteraf altijd te reconstrueren zijn — zelfs na een crash. Zie ook mijn blog ‘Na de crash: ook IT heeft een black box nodig!’.

In tijden van ransomware is dat laatste ook voor datacenters essentieel: hoe bepaal je na een gijzeling waar en hoe een incident is begonnen? Maar ook sluipend veranderend, complexiteit verhogend, systeemgedrag kan via dergelijke ‘flight recorders’ worden gemonitord en geanalyseerd. Daarmee ontstaat de mogelijkheid om opnieuw ‘negatieve code’ te schrijven of delen te strippen: zorgen dat een systeem wel ingewikkeld blijft, maar niet complex wordt.

Photo by Phyllis Lilienthal

—————————-Translated by ChatGPT  —————————

Complex versus Complicated

Last week I read an article about the PhD defense on January 7th of Erik Jochemsen on the manageability of complex information systems. His dissertation Shifting Information Systems Complexity clearly shows that senior management often lacks sufficient control and insight into the real complexity of their ICT landscape. Despite interventions such as system integrations and enterprise architecture programs, results structurally fall short of expectations.

One key observation is that understanding what complexity actually is already constitutes a first logical — and therefore necessary — step toward being able to oversee and influence it at all. Only then does it become possible to truly manage a complicated information landscape.

This research reminded me of a PhD study from the early 1990s at the University of Twente titled “Slack is Always Necessary.” That study examined the rise of ERP systems, which were based on the assumption that everything could be planned and optimized. In reality, every system is subject to disturbances, imperfections, and unexpected deviations. A plan designed for 100% capacity will therefore fail by definition — simply because it leaves no room to absorb errors.

At Fokker, we saw this very clearly during the start of production of the Fokker 50 and 100. The ERP system was scheduled down to the minute to meet an extremely tight production plan. The outcome was predictable: increasing disruptions, declining efficiency, growing backlogs, and rising frustration. One hundred percent efficiency is impossible.

The difference between complicated and complex

In my blog “Involution: more effort without progress” I explore this distinction in more depth. Systems always require a certain amount of slack to absorb and recover from imperfections — which will inevitably occur. The tighter a system is designed and governed, the more sensitive it becomes to non-linear disturbances.

This is where the boundary lies between complicated and complex — a well-known distinction in Systems Engineering. A complicated system may consist of many components, but the relationships between them are predictable. By decomposing the system, it can be understood and controlled — a jet engine is a classic example.

A complex system, by contrast, exhibits dynamic interactions, emergent properties, feedback loops, and fundamental unpredictability. Its behavior can often be explained retrospectively, but not deterministically predicted in advance. Small changes can lead to large, non-linear effects. Complexity is therefore rarely a design choice; it is almost always the result of poor or insufficient governance. And increasing complexity demands ever more slack.

Why do information systems become complex so quickly?

Every information system starts its life as complicated. The modeled processes, the data flowing through the system — everything is initially well describable and modelable. However, chaos and complexity theory show that without strict governance of underlying subsystems, new and often poorly understood system behavior emerges from interactions between components. This behavior cannot be traced back to individual parts, but arises from their interdependencies.

This phenomenon is especially visible in adaptive systems and deliberately created feedback loops. In that light, the rapid rise of AI agents is concerning. Their behavior is inherently not fully predictable, precisely because they are expected to learn. How and in what way that learning unfolds can be surprising and lead to poorly understood, difficult-to-manage complexity. AI is not a new category here, but a powerful accelerator of existing complexity laws — think of hallucinating AI systems that generate highly convincing nonsense.

Normalized Systems Theory and “shifting complexity”

Reducing complexity often feels like squeezing a half-inflated balloon: you shift the complexity, but you do not reduce it. This phenomenon is known as shifting complexity. Measures do not eliminate complexity; they merely move it elsewhere in the system — you reduce pressure in one place by increasing it in another.

Theories such as Normalized Systems Theory (NST) — see my blog on this topic — describe how to design modularity in such a way that this shifting is prevented. Modular systems treat software as a capital asset that must remain maintainable and renewable for decades. As software pioneer Douglas McIlroy famously put it:
“The real hero of programming is the one who writes negative code.”

In that same blog, I refer to Manny Lehman’s Law of Increasing Complexity (1980), which states that as an evolving program is continuously modified, its complexity inevitably increases — unless active work is done to maintain or reduce it. Adding functionality to existing information systems makes them increasingly complex and costly to maintain over time. Only intensive maintenance and continuous, rigorous renewal can preserve software quality in a sustainable way.

Once something becomes complex, you lose control

The core challenge for system owners and operators is to ensure that a complicated system — one that functions clearly and logically — never becomes complex. Maintenance must therefore actively focus on eliminating emerging complexity: ill-defined behavior and unwanted feedback loops must be addressed immediately. One effective approach is further decomposition into well-defined subsystems.

Our current information world, with multi-cloud environments and unmanaged data spaces, has become increasingly difficult for people to oversee and therefore to manage. A system that is complicated but still manageable at delivery will, over time, almost inevitably accumulate complexity — and with it lose controllability. Much like nature itself, which tends toward maximum entropy.

Negative code and the black box

The famous anecdote by Apple developer Bill Atkinson goes as follows:
“Only when a change to the source code reduces the number of lines (‘negative code’) will the overall quality, readability, or performance improve.”
If a system grows over time through updates and modifications, the only remedy is to eliminate that growth elsewhere — letting air escape from the balloon.

In addition, a foundational architecture is required that does not allow combinatorial explosions under predefined changes. Systems Engineering provides very concrete tools for this. With my background in aircraft manufacturing, the central question was always simple: how long can I keep an aircraft — despite all MRO (maintenance, repair, and overhaul) — demonstrably airworthy for many decades? By repeatedly stripping it down and rebuilding it.

In one of my recent blogs, “A black box to monitor AI agents?”, I deliberately return to this aviation metaphor by introducing the flight recorder for information systems. An aircraft’s behavior is continuously logged so that disruptions and changes can always be reconstructed afterward — even after a crash.

In times of ransomware, this is also essential for data centers: how do you determine where and how an incident started after a system has been held hostage? But slowly changing, complexity-increasing system behavior can also be monitored via such “flight recorders.” This creates the opportunity to once again write negative code — or to strip systems back — ensuring that a system remains complicated, but does not become complex.