Ik heb gewerkt met slimme mensen, in organisaties met goede intenties en moderne werkwijzen. En toch zag ik steeds dezelfde dingen misgaan. Op dezelfde plekken. Dat zette mij aan het denken.
Developers vonden security remmend. Securityteams vonden developers roekeloos. Beheer wilde stabiliteit terwijl management snelheid en innovatie wilde.
De gebruikelijke diagnose is dan: een communicatieprobleem. Teams moeten meer samenwerken. Vaker overleggen. Meer begrip voor elkaar hebben. En dus: meer meetings, meer alignment-sessies, meer gezamenlijke retrospectives.
Ik heb dat advies vaak horen geven. En ik heb gezien hoe weinig het structureel oploste. Want een jaar later zat dezelfde organisatie met dezelfde spanning, alleen nu met een voller agenda.
Meer overleg lost niets op als mensen vanuit fundamenteel verschillende logica’s opereren. Dan praten ze niet langs elkaar heen omdat ze elkaar niet kennen — maar omdat ze elkaar juist heel goed begrijpen en het toch oneens zijn over wat belangrijk is.
Ik kijk daar waarschijnlijk ook anders naar door mijn achtergrond. Naast mijn werk in IT heb ik bestuurskunde gestudeerd. Tijdens die studie las ik Jane Jacobs en haar boek Systems of Survival. Jacobs beschrijft hoe samenlevingen functioneren vanuit twee fundamenteel verschillende morele systemen. Sommige systemen zijn gericht op bescherming, stabiliteit en controle. Andere juist op handel, vernieuwing en beweging. Beide zijn noodzakelijk, maar ze kijken fundamenteel anders naar risico, verantwoordelijkheid en verandering.
Jaren later begon ik dezelfde patronen terug te zien — eerst in IT-organisaties, daarna ook in industriële omgevingen.
Cybersecurity, operations en beheer functioneren grotendeels vanuit een beschermende logica. Continuïteit bewaken. Afrekening op verstoringen, incidenten en beschikbaarheid. Vanuit dat perspectief is voorzichtigheid rationeel. Controle is rationeel. Standaardisatie is rationeel.
Developmentteams en innovatie-afdelingen functioneren vaak vanuit een tegenovergestelde logica. Verandering mogelijk maken. Beloond voor snelheid, nieuwe functionaliteit en groei. Vanuit dat perspectief voelt governance als vertraging. Extra controle voelt als frictie.
En ineens begon voor mij veel gedrag logisch te worden.
De developer die gefrustreerd raakt van change procedures is niet per definitie onvolwassen. De security engineer die aanvullende controles eist is ook niet automatisch bureaucratisch. Deze teams botsen niet omdat mensen lastig zijn, maar omdat ze verschillende morele logica’s dienen.
In industriële omgevingen wordt die spanning nog scherper
Een IT-developer die iets wil uitrollen kan in het ergste geval terugdraaien. Een procesoperator op een productievloer werkt met fysieke installaties, veiligheidssystemen en processen die niet zomaar even worden herstart. Een firmware-update op een PLC is geen sprint-taak — het is een change met potentieel fysieke gevolgen, waarbij de mensen in de buurt van de installatie er belang bij hebben dat jij voorzichtig bent.
Ik heb in dat soort omgevingen gewerkt. En wat mij altijd opviel: de spanning zat zelden in de techniek zelf. De techniek was oplosbaar. De spanning zat in de naden — de interfaces tussen systemen, tussen teams, tussen verantwoordelijkheden.
Maar ik zag diezelfde dynamiek ook buiten technische omgevingen. Toen ik betrokken was bij een grootschalige onderwijsvernieuwing — nieuwe didactische modellen, programmatisch toetsen, anders organiseren — herkende ik precies hetzelfde patroon. Docenten die de kwaliteit en continuïteit van het onderwijs bewaken. Vernieuwers die snelheid willen omdat de wereld verandert en het onderwijs moet mee. Twee groepen met goede intenties, maar met fundamenteel verschillende definities van succes. En de spanning zat ook daar niet in de mensen, maar in de naden — de plekken waar roosters, toetssystemen en werkvormen niet op elkaar aansloten omdat ze vanuit verschillende logica’s waren ontworpen.
Dat was het moment waarop ik besefte dat dit patroon niet sector-specifiek is. Het zit in elke organisatie die tegelijkertijd iets moet bewaken én iets moet veranderen.
Dat inzicht veranderde ook mijn kijk op architectuur.
Veel organisaties zien architectuur nog steeds als een technische discipline: systemen ontwerpen, standaarden opstellen, infrastructuren modelleren. Maar de moeilijkste vraagstukken zijn zelden puur technisch.
Hoe geef je development voldoende snelheid zonder controle volledig los te laten? Hoe voorkom je dat security een rem wordt op innovatie? Hoe bescherm je stabiliteit zonder elk experiment onmogelijk te maken?
Dat zijn uiteindelijk geen puur technische vragen. Het zijn bestuurlijke vragen. En het is precies die combinatie — technisch én bestuurlijk — die ik in mijn werk het meest waardevol vind.
Misschien is dat ook waarom veel DevOps- en DevSecOps-transformaties weerbarstiger blijken dan verwacht. Organisaties proberen twee verschillende logica’s dichter bij elkaar te brengen, maar behandelen de spanning alsof die volledig oplosbaar is. Ik denk dat dat een misvatting is.
Een gezonde organisatie heeft juist beide systemen nodig. Zonder beschermende logica ontstaat chaos en fragiliteit. Zonder vernieuwende logica ontstaat stilstand en verlies van aanpassingsvermogen.
Maar wat dan wel?
Als meer overleg de oplossing niet is, en de spanning inherent is aan hoe organisaties werken — wat doe je er dan mee?
Mijn antwoord is: behandel het als een architectuurvraag, niet als een procesvraag.
De meeste organisaties proberen de spanning te managen met betere governance. Duidelijkere procedures, snellere change-boards, meer disciplines aan tafel. Dat helpt marginaal. Het fundamentele probleem blijft: controle zit als een gate ná het development-proces, dus het voelt structureel als rem.
Wat wél helpt, zijn drie principes die ik in de praktijk steeds terugzie werken.
Ontwerp de grens, niet het gedrag. Stop met proberen te controleren wat er binnen een team of systeem gebeurt. Controleer in plaats daarvan de interfaces — de plekken waar systemen en teams elkaar raken. Binnen die grens: vrijheid. Over die grens heen: governance. In industriële omgevingen is dit al jaren praktijk — zones en conduits, ISA-95, Purdue-model. De IT-wereld kan daar meer van leren dan ze vaak beseft.
Maak het veilige pad ook het snelle pad. Als de veilige optie meer moeite kost dan de onveilige, kiezen mensen structureel voor de onveilige. Niet uit onwil, maar uit tijdsdruk. De oplossing is niet strengere handhaving — het is het verlagen van de drempel voor de goede keuze. Pre-goedgekeurde infrastructuur, geautomatiseerde checks, standaardoplossingen die developers gewoon kunnen pakken. De vrijheid blijft bestaan, maar de frictie zit op de juiste kant.
Differentieer op risico. Niet elke verandering is gelijk. Een aanpassing aan de UI is fundamenteel anders dan een wijziging in authenticatielogica of een update op een PLC die een fysiek proces aanstuurt. Organisaties die één change-proces hebben voor alles creëren zelf de frustratie. Wie het risico serieus neemt, maakt onderscheid — en geeft lage-risico veranderingen de ruimte om snel te gaan.
Het overkoepelende principe achter dit alles: de spanning tussen bescherming en vernieuwing los je niet op door mensen dichter bij elkaar te brengen. Je lost het op door de architectuur zo te ontwerpen dat snelheid en veiligheid niet langer elkaars tegenpolen zijn.
Dat is uiteindelijk wat een architect doet. Niet kiezen tussen de twee logica’s — maar de omgeving bouwen waarin beide kunnen bestaan.