"Waarom duurt het zo lang voordat we iets kunnen releasen?" Het is een vraag die Filip Verlee vaak hoort van gefrustreerde IT-managers. Hun organisaties zitten vast in een patroon van trage releases, nerveuze uitrolmomenten en incidenten waarbij niemand écht weet wat er aan de hand is.
De gevolgen zijn tastbaar. Frustraties en overbodige stress. Je verliest de beste developers aan concurrenten. Je kunt niet snel genoeg inspelen op marktveranderingen. En ondertussen wordt de druk om te moderniseren steeds groter.
DevOps klinkt overweldigend, maar hoeft geen grote transformatie te zijn die alles overhoop gooit. Ontdek hoe je klein begint met concrete stappen die aansluiten bij je moderniseringsreis. Van cultuurverandering tot praktische quick wins die snel resultaat opleveren.
Filip V. is DevOps en cloud specialist met jarenlange ervaring in het begeleiden van enterprise organisaties door hun DevOps transformatie. In dit artikel deelt hij zijn pragmatische aanpak voor organisaties die de stap naar DevOps willen zetten.
Herken je dit scenario? Waarom organisaties vastlopen in traditionele werkwijzen
De klassieke situatie die Filip tegenkomt? Organisaties met grote monolithische applicaties die maar om de maand of per kwartaal kunnen releasen. Bij elke release worden enorm veel wijzigingen tegelijk doorgevoerd. Dat levert telkens weer veel risico en nervositeit op.
Nog problematischer zijn de incidenten. Bij een P1 of P2 incident zitten dertig tot veertig mensen voor dagen in vergaderingen, maar slechts twee of drie mensen hebben écht de kennis en weten waar de kink in de kabel zit. Dit zijn de klassieke Brent-personages die je terugvindt in het DevOps boek “Phoenix Project”: mensen met de beste bedoelingen die alles weten, problemen kunnen oplossen, maar die hun kennis niet delen. Er is geen cultuur van transparantie.
Ook een watervalstructuur heeft concrete gevolgen. Moderne developers willen niet werken voor bedrijven zonder agile en DevOps praktijken. Je verliest talent aan concurrenten die wél vooruitstrevend werken. En het verschil is meetbaar: volgens het 2024 DORA rapport (oktober 2024) behalen elite DevOps teams gemiddeld 973 keer snellere time-to-market dan low performers. Hun change failure rate ligt onder de 5%, terwijl low performers tussen de 46% en 60% zitten.
Filip ziet dit patroon nog steeds regelmatig: "Dit is helaas nog steeds de realiteit bij veel organisaties. Ze geraken letterlijk verstikt in hun manier van werken."
.jpg)
DevOps komt niet zomaar - waar de transformatievraag ontstaat
Bij veel organisaties zijn er al geïsoleerde DevOps initiatieven aan de gang. Een klein team rond het marketingplatform werkt al agile, met snelle releases en moderne tooling. Maar de rest van de organisatie? Die zit nog in het oude patroon. DevOps komt binnen via twee verschillende richtingen, ziet Filip in de praktijk.
Enerzijds zijn er development teams die een moderne werkwijze willen omarmen. Ze willen werken zoals ze dat bij andere bedrijven zien of lezen in vakbladen. Anderzijds heb je infrastructuur teams die de delivery van infrastructuur willen vereenvoudigen. Beide groepen merken dat hun huidige manier van werken niet meer volstaat.
Deze evolutie gaat hand in hand met technologische ontwikkelingen. Organisaties stappen over naar cloud, hybride platforms en SaaS of PaaS oplossingen. We zijn steeds minder bezig met fysieke infrastructuur en dozen bouwen in datacenters. Filip legt uit: "DevOps komt binnen door technologische ontwikkelingen die men wil omarmen. Daardoor begint men ook te begrijpen: we gaan een andere manier van werken moeten introduceren."
In Europa speelt daar nog een extra factor bij: regulatory requirements. Door NIS2 en DORA spreek je vandaag eigenlijk niet meer van DevOps, maar van DevSecOps. Security moet by default ingebouwd zijn, afhankelijk van de sector waarin je organisatie zich bevindt. Die voorwaarden worden gewoon afgedwongen. Als je er niet aan beantwoordt, stel je jezelf bloot aan mogelijke sancties zoals boetes.
Binnen elke organisatie onderscheidt Filip drie groepen mensen. Een kleine groep pioniers die vooruit willen trekken en elkaar stimuleren. Dan een grote middenmoot die redelijk comfortabel zit waar ze zijn, maar wel openstaan voor verandering als je ze de voordelen kunt tonen. En tot slot een kleine groep die achteraan hangt en het liefst blijft zitten waar ze zitten.
Het belangrijkste inzicht? "DevOps kan alleen volledig werken als jullie business end-to-end die cultuur begint te omarmen," benadrukt Filip. "Je kunt wel bepaalde projecten op een agile DevOps manier aanvliegen, maar als je business proces nog altijd heel strak beweegt en alleen in grote blokken veranderingen wil doen, krijg je het niet volledig geïntegreerd."
Begin niet met tooling - start met je grootste pijnpunt
De grootste fout die Filip ziet bij organisaties die DevOps willen invoeren? Ze pakken een framework met een handboek en gaan dat letter voor letter uitvoeren. "Daar wordt niemand enthousiast van," waarschuwt hij.
Een ander veelvoorkomend probleem is het "new shiny thing on the horizon" syndroom. Er komt een nieuwe tool, iedereen gooit alles overboord en men wil dat nu vastpakken. Dat is zelden een goed idee. Neem het voorbeeld van Azure DevOps versus GitHub in het Microsoft landschap. Al meer dan tien jaar zeggen mensen dat Azure DevOps gaat verdwijnen en alles naar GitHub moet. Filip durft zijn hand ervoor in het vuur te steken: "Azure DevOps gaat niet verdwijnen. Het is er nog de dag dat ik op pensioen ga."
Waarom? GitHub is een krachtige tool vanuit een engineering perspectief, maar mist tot vandaag de integratie richting businessprocessen die Azure DevOps wél heeft. Voor grote organisaties die hun agile proces willen integreren met de business, is dat een fundamenteel verschil. Die klanten gaan die investering niet zomaar uithalen.
De juiste aanpak werkt anders. Filip legt uit: "Voordat je aan DevOps begint, moet jouw organisatie begrijpen wat de problemen zijn op dat moment." Pas daarna kun je identificeren welke van die problemen je met een DevOps manier van werken kunt oplossen.
Een praktijkvoorbeeld uit Filip's ervaring: een organisatie had bij elke release performance issues door wijzigingen aan store procedures. Die performance decrease merkten ze pas op ná de release. Niet bepaald ideaal.
Filip pakt dit momenteel aan met load testing op een geïsoleerde omgeving met refreshed data. Ze definieerden een baseline voor performance. Bij elke wijziging lieten ze de testen opnieuw lopen en vergeleken ze de resultaten met die baseline. Ze simuleerden complete end-to-end flows vanuit het perspectief van de gebruiker en maten daar de performance van.
Het cruciale onderdeel? De cultuur die eromheen werd gebouwd. Als de performance in negatieve zin een bepaald percentage afweek, ging die release niet door. Punt. Terug naar de tekentafel, code evalueren en garanderen dat de performance minimaal gelijk blijft of bij voorkeur verbetert.
"Dat is een cultuur die je moet inpakken voordat je zegt: we zijn klaar voor onze volgende release," benadrukt Filip. "Je gaat meten en evalueren of de kwaliteit van je code en proces niet op een negatieve manier geïmpacteerd is. Bij voorkeur hebben we beter gedaan."
Dit is DevOps in de praktijk: meet en valideer kwaliteit voordat je released. Geen frameworks volgen, maar echte problemen oplossen.
De gouden volgorde - cultuur, proces, dan pas tooling
De volgorde waarin je DevOps aanpakt, bepaalt grotendeels je succes. Filip is daar heel duidelijk in: cultuur eerst, dan proces, en pas daarna tooling. "Als je op papier niet krijgt uitgelegd hoe je van A naar B gaat, begin dan alsjeblieft niet met een regel code of een tool of wat dan ook."
Cultuur eerst: waarom doen we dit?
Het begint met de vraag waarom je DevOps wilt invoeren. Niet omdat het hip is of omdat iedereen erover praat, maar vanwege de waarde die het creëert. Het grote probleem waar veel IT afdelingen mee worstelen, is dat ze als kostenpost worden gezien omdat ze die waarde niet tastbaar kunnen maken.
Een DevOps manier van werken helpt juist om value identificeerbaar te brengen. Je kunt aantonen dat je in staat bent om in kaart te brengen wat je doet.
Filip benadrukt: "DevOps is wel een manier om te zorgen dat je value identificeerbaar brengt, dat je kunt aantonen wat je doet. Door je methodes te hanteren kun je je hefboom identificeren."
Proces definiëren: hoe pakken we dit aan?
Pas als je cultuur helder is, ga je je proces definiëren. Hoe ga je van A naar B? Welke stappen doorloop je? Hoe valideer je je werk? Dit moet je op papier kunnen uitleggen voordat je ook maar iets anders doet.
Hier zit vaak een valkuil. Organisaties willen te snel naar de uitvoering. Maar zonder helder proces eindig je met chaos en frustratie. Neem de tijd om uit te tekenen hoe je werkwijze eruitziet.
Tooling ondersteunen: waarmee werken we?
Tooling komt als laatste. En het belangrijkste principe: kies pragmatisch wat werkt voor jouw organisatie. Of je nu met de Microsoft stack werkt of met open source tools, of je Azure DevOps gebruikt of GitHub, de principes blijven hetzelfde. Een tool is een tool.
Filip waarschuwt voor het "new shiny thing" syndroom dat we eerder zagen. Niet zomaar overstappen omdat er iets nieuws is. Kijk naar wat je organisatie nodig heeft. Wat past bij je landschap? Wat ondersteunt je proces het beste?
Deze volgorde is niet vrijblijvend. Als je tooling voor proces zet, dicteert je tool hoe je werkt. Als je proces voor cultuur zet, krijg je processen die niemand omarmt. Volg de juiste volgorde en je DevOps transformatie heeft een veel grotere kans van slagen.
Quick win 1 - start klein met niet-kritische applicaties
Begin met een klein team (4-5 mensen) op een niet-kritische applicatie waar je expliciet ruimte geeft om fouten te maken, bouw zo vertrouwen op en schaal geleidelijk op naar kritische systemen.
De balans tussen transformatie en business continuïteit is cruciaal. Disruptie is onvermijdelijk als je DevOps introduceert, maar die moet beheersbaar blijven. Het advies van Filiip: begin klein en strategisch.
Focus in het begin op kleine teams bij voorkeur. Kies bewust applicaties die niet direct de grootste impact hebben als er iets fout gaat. Geef expliciet ruimte om fouten te maken, want dat is essentieel voor leren. "Fouten gaan gemaakt worden. Fouten moeten gemaakt worden," legt Filip uit. "Dat is de enige manier hoe je leert en lessen trekt."
Kies bij voorkeur componenten die nog geen deel uitmaken van je dagelijkse operatie. Of zorg dat je gemakkelijk kunt garanderen dat er een fallback is als het fout loopt. Je wilt tijdens die leerperiode je business niet impacteren.
Het gaat om een iteratief proces. Je begint klein, bouwt vertrouwen op en toont maturiteit. Dan pas kun je stap voor stap aan meer kritische systemen werken. Door die manier van werken bouw je het vertrouwen op binnen je organisatie dat nodig is voor bredere adoptie.
Cijfers ondersteunen deze aanpak. Organisaties die agile en DevOps toepassen, behalen volgens Microsoft Azure research (2024) 60% snellere time-to-market. Maar die winst realiseer je niet door alles tegelijk om te gooien. Je bereikt het door klein te beginnen en systematisch op te schalen.
Filip benadrukt het belang van geduld: "Door vertrouwen op te bouwen en te zorgen dat proces in maturiteit toeneemt, kun je stukje bij stukje aan meer en meer kritische zaken gaan werken." Die maturiteit forceer je niet, die bouw je op.
Quick win 2 - haal geleidelijk functionaliteiten uit je monoliet
Pak je monoliet stukje per stukje aan door kleine functionaliteiten eruit te halen als zelfstandige micro-applicaties, zodat je sneller kunt releasen en problemen binnen één dag kunt oplossen in plaats van weken.
Zolang je vastzit aan een grote monolithische applicatie, blijft die een blokkade voor volledige DevOps optimalisatie. De evolutie naar moderne applicatie architectuur vraagt om een andere aanpak: functionaliteiten opdelen in kleine deel-applicaties die je onafhankelijk van elkaar kunt ontwikkelen.
Het voordeel? Je kunt verschillende componenten in verschillende snelheden ontwikkelen, zonder dat de interactie tussen die componenten geïmpacteerd wordt. Maar zo'n transformatie doe je niet in één keer.
Filip legt de gefaseerde aanpak uit die in de praktijk werkt. Eerst identificeer je wat je gemakkelijk uit de monoliet kunt halen. Dan pak je deel per deel aan. Per functionaliteit maak je een team verantwoordelijk dat in die specifieke DevOps practices kan groeien.
Een concreet voordeel van deze aanpak: als er een issue is met een van die micro-applicaties, kun je heel vlot en snel ingrijpen. Je kunt zelfs dezelfde dag nog releasen. Je trekt de focus enkel op wat geblokkeerd moet worden, in plaats van een waslijst aan functionaliteiten te moeten testen en valideren zoals bij de monoliet.
"Dat is iets wat je vrij snel kunt doorgaan, ook al is het op dit moment mogelijk nog deels of grotendeels manueel," benadrukt Filip. "Dat maakt deel uit van je evolutie. Stukje per stukje kun je vertrouwen en kwaliteit opbouwen. Zodanig dat je ook meer en meer door automatisering kunt doen."
De belangrijkste nuance: zelfs als het proces in het begin nog deels handmatig verloopt, is dat geen probleem. Dat hoort bij de leerweg. Door op die manier te werken bouw je het vertrouwen op binnen je organisatie. Teams zien dat snelle interventies mogelijk zijn. De business merkt dat wijzigingen sneller doorgevoerd kunnen worden.
Filip vervolgt: "Zodanig dat je als team kunt focussen op wat je als team wilt doen. Op het verbeteren van je business, van je applicaties. Alles wat je daar rond bouwt naar deployment, naar testing, wil je zorgen dat je dat makkelijk kan delen door middel van templates en modules."
Die templates en modules maken het proces schaalbaarder. Wat je leert bij één micro-service, kun je hergebruiken bij de volgende. Zo bouw je systematisch je DevOps praktijk op zonder telkens het wiel opnieuw uit te vinden.
Quick win 3 - installeer blameless feedback loops
Zet een iteratieve cyclus op waarin je continu valideert, uitvoert en evalueert zonder blame cultuur, zodat fouten leermomenten worden en automatisering vanzelf ontstaat als het proces een automatisme wordt.
Een iteratief proces opstarten en blijven doorlopen is essentieel voor succesvolle DevOps. Het draait om een continue cyclus: valideren, uitvoeren en opnieuw valideren. Door dat cirkeltje blijf je gaan als team en als organisatie.
De praktische implementatie begint bij de juiste tools en werkwijze. Werk met source control systemen voor transparantie. Daardoor faciliteer je collaboratie en maak je het makkelijk om kennis te delen binnen het team. Zet guardrails op zodat fouten tijdig gedetecteerd worden. Installeer een vangnet voordat fouten échte impact hebben.
Het belangrijkste principe: geen blame cultuur toepassen. Dat is fundamenteel voor het succes van je DevOps transformatie. Als er iets fout gaat, evalueer je dat retroactief als team. Je stelt vier cruciale vragen: Hoe zijn we hier geraakt? Waarom zijn we hier geraakt? Wat kunnen we naar de toekomst toe beter doen? Hoe pakken we dat anders aan?
Filip legt uit hoe dit in de praktijk werkt: "Door die manier van werken zorg je dat kwaliteit naar boven gaat, dat je changes klein en compact houdt, dat je zo regelmatig mogelijk door dat cirkeltje gaat. Het wordt uiteindelijk een automatisme. En doordat het een automatisme wordt, heb je de opportuniteit om bepaalde onderdelen van dat proces ook effectief met code te automatiseren."
Dat laatste punt is cruciaal. Pas als het proces een automatisme wordt, ontstaat ruimte voor échte automatisering met code. Veel organisaties proberen te vroeg te automatiseren, voordat het proces zelf goed loopt. Dat leidt alleen tot geautomatiseerde chaos.
De impact van zo'n blameless culture is significant. Volgens het DORA rapport 2024 (oktober 2024) hebben elite teams een 6,5 keer lagere burnout rate. Dat komt door psychological safety en een cultuur waarin fouten leermomenten zijn in plaats van momenten om mensen af te rekenen.
Door continue door die feedbackloop te gaan, bouw je kwaliteit op. Je changes blijven klein. Je releasefrequentie gaat omhoog. En uiteindelijk wordt het zo natuurlijk dat automatisering zich vanzelf aandient.
.png)
Conclusie
DevOps transformatie hoeft geen big bang te zijn die je organisatie ontwricht. Begin klein met je grootste pijnpunt, kies bewust een niet-kritische applicatie waar je ruimte hebt om te leren, en bouw stap voor stap het vertrouwen en de maturiteit op die nodig zijn voor bredere adoptie. De sleutel ligt in de juiste volgorde: eerst cultuur (waarom), dan proces (hoe), dan pas tooling (waarmee).
Door iteratief te werken, fouten als leermomenten te zien en systematisch te meten, creëer je een cultuur waarin automatisering vanzelf ontstaat. Je transformeert IT van een kostenpost naar waardecreatie die je organisatie agile maakt en je concurrentiepositie versterkt. Filip's ervaring leert dat een klein team van vier tot vijf mensen voldoende is om te starten en een cultuurverandering in gang te zetten.
