Coquille in IT beheer klinkt in eerste instantie als zo’n luxe metafoor die iemand op een managementdag verzint tussen de koffie en de PowerPoints door. Maar als je het terugbrengt naar de praktijk van IT-architectuur en beheer, klopt het akelig goed.
Iedereen ziet de uitkomst. Een systeem dat draait. Een release die “succesvol” is uitgerold. Monitoring die groen kleurt. Net zoals een perfect gebakken coquille op een bord: glanzend, simpel, ogenschijnlijk moeiteloos.
Wat niemand ziet, is wat er allemaal vooraf fout had kunnen gaan.
In IT-beheer begint het zelden bij het draaien van de knop. Het begint bij voorbereiding die zo vanzelfsprekend lijkt dat mensen hem vergeten te waarderen. Configuraties die exact kloppen. Dependencies die niet toevallig maar bewust zijn gekozen. Omgevingen die niet “ongeveer gelijk” zijn, maar gecontroleerd identiek genoeg om voorspelbaar gedrag te garanderen.
Dat is de droogte van je coquille. In IT-termen: rommel eruit voordat je überhaupt gaat deployen. Geen vocht, geen ruis, geen onvoorspelbare state. Want net zoals een natte coquille niet bakt maar stoomt, zo krijg je in IT geen stabiele release als je omgeving half gevuld is met onbekende variabelen en oude rommel.
Dan de temperatuur. Dat is je infrastructuur en performance baseline. Te koud betekent systemen die wel draaien maar nooit echt reageren zoals bedoeld. Alles leeft, maar traag, stroperig, alsof je applicatie eerst toestemming moet vragen om iets te doen. Te heet betekent systemen die wel snel zijn, tot ze onder druk instorten omdat niemand ooit echt heeft getest wat er gebeurt als het serieus wordt.
En timing. Dat is waar het meestal misgaat. Niet omdat mensen geen plan hebben, maar omdat ze het plan niet durven volgen. Deploy net iets te vroeg omdat “het toch wel goed lijkt”. Rollback net iets te laat omdat niemand graag toegeeft dat het misgaat. Monitoring die pas wordt bekeken als de geur van rook al in de kamer hangt.
De saus in dit verhaal is je architectuurlaag. Niet de decoratie, maar de manier waarop je betekenis geeft aan het geheel. Je kunt een goed systeem bouwen met standaardcomponenten, net zoals je een saus kunt maken met basis ingrediënten. Maar als je alles overspoelt met dezelfde smaaklaag, verdwijnt het onderscheid. In IT is dat het moment waarop alles “werkt”, maar niemand nog precies kan uitleggen waarom iets werkt of wat er gebeurt als één onderdeel faalt.
Daar zit vaak de denkfout. Meer tooling wordt gezien als betere smaak. Meer monitoring, meer dashboards, meer lagen. Maar in werkelijkheid maskeer je dan vaak de essentie in plaats van haar te versterken. Zoals een saus die zo dominant is dat je het product eronder niet meer herkent.
En dan de echte kern: consistentie onder druk.
Een enkele perfecte deployment zegt niets. Een demo die werkt is geen architectuur. Het punt is of je hetzelfde resultaat haalt op dag 1, dag 50 en tijdens een incident om 03:17 ’s nachts wanneer niemand nog enthousiast naar grafieken kijkt.
Daar zit het verschil tussen “het werkt” en “het is beheersbaar”. Het eerste is geluk. Het tweede is ontwerp.
In IT-beheer zie je vaak organisaties die goed kunnen koken als er tijd is, aandacht is en iedereen fris is. Mooie releases, nette documentatie, tevreden stakeholders. Maar zodra de druk stijgt, verandert het systeemgedrag. Dan worden processen overschreven, wordt logging genegeerd, worden shortcuts normaal.
Dat is het moment waarop blijkt of je architectuur echt klopt of alleen goed leek in rustige omstandigheden.
De realiteit is dat een IT-omgeving geen keuken is waar je één gerecht perfectioneert. Het is een restaurant waar dezelfde kwaliteit moet worden geleverd op drukke avonden, met wisselende teams, onverwachte verstoringen en systemen die je niet even “op pauze” zet.
En net zoals bij een coquille blijft één ding overeind: het eindproduct moet simpel lijken.
De complexiteit hoort nergens zichtbaar te zijn voor de gebruiker of klant. Die ziet geen configuratiemanagement, geen failover-strategieën, geen CI/CD-pijplijnen die drie lagen diep zijn opgezet om één update veilig door te duwen. Die ziet alleen of het klopt of niet.
En dat is precies waarom het vak zo vaak onderschat wordt.
Niet omdat het simpel is, maar omdat het pas goed is als het simpel lijkt.
De vraag is dus niet of je een systeem kunt laten werken. Dat is het minimale niveau. De vraag is of je het zo stabiel, voorspelbaar en gecontroleerd krijgt dat het onder druk hetzelfde blijft doen zonder dat iemand aan de achterkant in paniek hoeft te improviseren.
Want daar eindigt de vergelijking uiteindelijk: niet in koken, maar in beheersing.
En net zoals een coquille geen ruimte laat voor amateurisme, doet een goed ontworpen IT-architectuur dat ook niet.