Complex versus Ingewikkeld

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 creëert uit zichzelf een steeds hogere entropie in de vorm van wanorde, chaos of onzekerheid.

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. Op het leven van een vliegtuig gemiddeld zeven tot tien keer.

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.

Door: Hans Timmerman (foto)