Zes principes van simplexity

Gepubliceerd op 2026-09-10 door William Visterin

Steeds meer internationale bedrijven gebruiken kunstmatige intelligentie om cv’s te beoordelen, werknemers te evalueren en zelfs beslissingen over bonussen en ontslagen te nemen.

Informatici moeten dagelijks met steeds complexere systemen werken, ongeacht het platform of de technologie die ze gebruiken. Werner Vogels, CTO bij AWS, deelde tijdens een recente keynote zes waardevolle lessen over complexiteit in IT. We overlopen ze samen met specialisten.

Complexiteit is onvermijdelijk, maar niet alle complexiteit is gelijk. “Bedoelde complexiteit – de complexiteit die we bewust in systemen inbouwen – is onvermijdelijk”, vindt Michael Bordash, principal cloud practice architect bij Rackspace. “De onbedoelde complexiteit die erin sluipt, kan er echter voor zorgen dat systemen moeilijk te beheren zijn.”

Principe 1. Focus op evolutie op lange termijn

Systemen groeien onvermijdelijk en architectuurkeuzes moeten regelmatig worden herzien. Werner Vogels benadrukte tijdens zijn keynote op re:Invent, de gebruikersconferentie van AWS, het verschil tussen wat hij omschrijft als evolvability (langetermijnstrategie) en maintainability (kortetermijnonderhoud).

“Een evolueerbare architectuur stelt je in staat om toekomstige veranderingen gemakkelijk toe te passen zonder disruptie voor gebruikers”, oppert hij. Het gaat om het bouwen van flexibele systemen die kunnen meegroeien met veranderende behoeften, zonder dat de kernfunctionaliteit in gevaar komt. “Maak evolvability een vereiste”, raadt Vogels aan.

Principe 2. Breek complexiteit op in kleinere stukken

Het is een bekende uitdrukking, ook in IT-kringen: ‘Hoe eet je een olifant? In kleine stukjes.’ Complexe diensten worden beter beheersbaar wanneer ze worden opgedeeld in kleinere componenten. Werner Vogels gebruikt de metafoor van de kikker in langzaam opwarmend water om te laten zien hoe complexiteit geleidelijk kan toenemen tot een onbeheersbaar niveau.

Door systemen op te splitsen in losjes gekoppelde, kleinere componenten met duidelijke API’s, die gemakkelijk met elkaar kunnen communiceren, ontstaat een flexibele architectuur die eenvoudiger te onderhouden en uit te breiden is, stelt hij. “Een belangrijk waarschuwingssignaal dat een systeem te complex is geworden, is wanneer de eigen engineers het niet meer volledig begrijpen.”

Principe 3. Stem je organisatie en teams af op architectuur

Complexe systemen vereisen een doordachte organisatiestructuur. Andy Warfield, AWS vice president and distinguished engineer, benadrukte twee essentiële principes. Enerzijds is het een kwestie om zelfgenoegzaamheid te vermijden. “Zelfs wanneer alles goed gaat, moet je blijven zoeken naar wat mis zou kunnen gaan en de status quo constructief blijven uitdagen”, suggereert hij.

Een tweede organisatorische tip betreft de focus op ownership. “Geef teams de ruimte om problemen zelfstandig op te lossen”, stelt hij. "Organisaties worden meestal minstens zo complex als de software die je bouwt”, waarschuwt Warfield. Dit betekent dat de organisatorische structuur en cultuur even belangrijk zijn als de technische architectuur.

Michael Bordash van Rackspace wijst op de indeling van de teams. “Bij ons is elk engineeringteam georganiseerd in pods”, vertelt hij. Podding is een op teams gebaseerde organisatiestructuur waarbij bedrijven hun personeel opsplitsen in kleinere, functie-overschrijdende groepen of pods. “We volgen daarbij ook het zogenaamde twee pizza’s per team-model, dat bekend is geworden door Amazon.”

Voormalig Amazon-CEO Jeff Bezos poneerde de pizza-regel dat geen enkel team zo groot mag zijn dat twee pizza’s onvoldoende zijn. Meer mensen betekent immers meer coördinatie, bureaucratie, chaos – eigenlijk alles wat de zaken vertraagt. Individuele prestaties lijden eronder en mensen raken minder betrokken.

Principe 4. Organiseer in cellen

Naarmate systemen groeien, kan elke verstoring in de werking gebruikers beïnvloeden. Daarom is er de raad om diensten op te delen in cell-based architectures om problemen te isoleren zonder andere units te beïnvloeden.

Hoe groot moet zo’n cel dan zijn? “Groot genoeg dat ze de grootste workload aankan die je kunt bedenken, maar ook klein genoeg om op volledige schaal te testen”, legt Vogels uit. “Dit blijft een afweging, maar helpt om betrouwbaarheid en veiligheid te garanderen en de impact van storingen te minimaliseren.”

Principe 5. Ontwerp voorspelbare systemen

Het bouwen van voorspelbare systemen vermindert de impact van onzekerheid. “Een event-driven architecture kan waardevol zijn, maar kan ook leiden tot onvoorspelbare workloads en knelpunten”, merkt Vogels op.

In sommige gevallen is een eenvoudigere, meer voorspelbare aanpak beter. Zo toonde Vogels tijdens zijn keynote aan hoe een systeem dat werkt met periodieke updates in plaats van real-time events vaak veel stabieler functioneert. “Eenvoud vereist discipline”, vindt Vogels. Door dit principe te omarmen, kunnen systemen volgens hem onnodige complexiteit vermijden en betrouwbaarder, schaalbaarder en efficiënter worden.

Principe 6. Automatiseer complexiteit

Tot slot benadrukte Vogels het belang van automatisering, ook om complexiteit te verminderen. “De echte vraag is niet ‘Wat moeten we automatiseren?’, maar ‘Wat juist niet?’”, zei hij.

Automatisering moet, volgens hem, de standaardbenadering zijn voor taken zoals het waarborgen van duurzaamheid, het schalen van capaciteit en configuratiebeheer. Moderne technologieën zoals AI-agenten kunnen routinetaken automatiseren, waardoor menselijke resources zich kunnen concentreren op taken waar hun expertise echt nodig is. “Handmatige interventie zou beperkt moeten zijn tot situaties die een significant oordeelsvermogen vereisen”, merkt Vogels op.

Michael Bordash van Rackspace sluit zich hierbij aan. “We maken binnen onze teams vaak grappen dat we automatiseren tot we onze eigen job overbodig hebben gemaakt”, stelt Bordash. “Maar de realiteit is dat er altijd ruimte voor verbetering is.”