

Official logo of Basque Country's public health care service: Osak

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 



Atmosphere of azure electric sky, with water, slope,

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Projectversterking 

Nieuw Softwareproject / Modernisering 

Productivity (Agile Analytics)

Onze expertises

Over ons

Nieuws

Contact

Succes! Je bent toegevoegd aan onze e-maillijst.

Abonneer u op onze e-maillijst en we houden u op de hoogte van nieuws en publicaties van ZEN Software

Abonneer op de nieuwsbrief van ZEN Software

1080_Zen-software-kantoor-8.jpg

1200_Zen-software-kantoor-8.jpg

1920_Zen-software-kantoor-8.jpg

2048_Zen-software-kantoor-8.jpg

256_Zen-software-kantoor-8.jpg

384_Zen-software-kantoor-8.jpg

3840_Zen-software-kantoor-8.jpg

640_Zen-software-kantoor-8.jpg

750_Zen-software-kantoor-8.jpg

828_Zen-software-kantoor-8.jpg

thumbnail_Zen-software-kantoor-8.jpg

Zen-software-kantoor-8.jpg

Productivity

1080_Frame 26 (2).png

1200_Frame 26 (2).png

256_Frame 26 (2).png

384_Frame 26 (2).png

640_Frame 26 (2).png

750_Frame 26 (2).png

828_Frame 26 (2).png

thumbnail_Frame 26 (2).png

Frame 26 (2).png

- Het Zwitsers zakmes voor DevOps-inzichten: meet en visualiseer de Developer Experience (DevEx), snelheid en efficiëntie met één krachtige tool.  
       
- Detecteer automatisch vertragingen in het ontwikkelproces met behulp van slimme AI-algoritmen, waardoor je proactief kunt bijsturen voordat het problemen worden. 
       
- Monitor de directe impact van wijzigingen in je werkwijze op de productiviteit van het team, zodat je altijd op basis van feiten beslist.  
      
- Eenvoudige, frictieloze integratie met jouw bestaande tech-stack, inclusief Jira, Git en CI/CD-tooling, om direct waarde toe te voegen aan je teamflow.  

Agile Analytics SaaS

Agile, Analytics

1080_Frame 31.webp

1200_Frame 31.webp

256_Frame 31.webp

384_Frame 31.webp

640_Frame 31.webp

750_Frame 31.webp

828_Frame 31.webp

thumbnail_Frame 31.webp

Frame 31.webp

- Creëer een centrale 'Single Source of Truth' waar alle documentatie, tooling en resources samenkomen – voor een workflow zonder vertragingen.  
       
- Elimineer de noodzaak voor eindeloze discussies in Slack; geef ontwikkelaars direct toegang tot alle benodigde API's, teamgegevens en tools op één overzichtelijke plek.  
       
- Versnel de onboarding van nieuwe developers aanzienlijk, omdat alle projectinstellingen en resources altijd klaarstaan en actueel zijn.  
     
- Direct gekoppeld aan Agile Analytics, waardoor je beschikt over één platform met één gedeelde waarheid voor zowel management als development.

 Integraal Softwareontwikkel Portaal

Softwareontwikkel, Portaal

Software ontwikkelen met behulp van AI en rekening houden met AVG, NIS2 en DORA compliance

ar1vht.webp

Zodra je een coding agent aan je codebase hangt, raak je drie regimes tegelijk. Niet omdat AI apart gereguleerd is, maar omdat het bestaande regels raakt op plekken waar je ontwikkelstraat er nooit eerder mee te maken had.

Zodra je een coding agent aan je codebase hangt, raak je drie regimes tegelijk.

Niet omdat AI apart gereguleerd is — de AI Act is een verhaal op zich — maar omdat AI-tooling bestaande regels raakt op plekken waar je ontwikkelstraat er nooit eerder mee te maken had. Je stuurt code naar een derde partij. Je haalt afhankelijkheden binnen die niemand handmatig gekozen heeft. Je verandert wie of wat een productiewijziging voorstelt.

*Dit artikel gaat over de engineeringkant. Het is geen juridisch advies — voor de precieze reikwijdte in jouw situatie heb je je eigen jurist of compliance officer nodig.*

Hier zit meteen verwarring, en die is bij ZEN extra voelbaar omdat wij beide betekenissen dagelijks gebruiken.

- **AVG** — de Nederlandse implementatie van de GDPR. Gaat over persoonsgegevens: welke je verwerkt, waarom, en waar ze terechtkomen.
- **NIS2** — Europese richtlijn over cyberbeveiliging voor essentiële en belangrijke entiteiten. Legt de nadruk op risicobeheer, ketenverantwoordelijkheid en het melden van incidenten. De Nederlandse omzetting heeft vertraging opgelopen; check de actuele stand voordat je op een datum plant.
- **DORA** — hier twee dingen. De **Digital Operational Resilience Act** geldt voor de financiële sector en gaat over ICT-risico’s en je afhankelijkheid van externe ICT-dienstverleners. En **DORA-metrics** zijn de vier leverstatistieken uit DevOps-onderzoek. Ze hebben niets met elkaar te maken, en in een vergadering waar zowel compliance als engineering zit, is dat vijf minuten uitleg waard.

De regels zijn niet nieuw. Wat verandert, is waar ze raken.

Voorheen liep je code van je repository naar je pipeline naar productie, allemaal binnen grenzen die je zelf had getrokken. Met een coding agent gaat er een deel van die code — en soms de context eromheen — naar een dienst die je niet beheert. Dat is geen ramp, maar het is wel een verwerking en een afhankelijkheid, en beide moet je kunnen benoemen.

De kernvraag is niet “gebruiken we AI” maar “wat sturen we mee”.

Code zelf is meestal geen persoonsgegeven. Maar de context eromheen kan dat wel zijn: een testfixture met echte klantnamen, een stack trace met e-mailadressen, een databasedump waar iemand snel iets in wilde opzoeken, een logfile die je erbij plakt om een bug uit te leggen.

Wat je praktisch wilt weten:

- **Welke tooling stuurt wat naar buiten?** IDE-plugins, CI-integraties en agents verschillen sterk in wat ze meesturen.
- **Waar staat de verwerking?** Regio en subverwerkers doen ertoe, net als bij elke andere clouddienst.
- **Wordt jouw invoer gebruikt voor training?** Dat is bij zakelijke abonnementen meestal uit te zetten, maar het is een bewuste keuze die iemand moet maken en vastleggen.
- **Staan die tools in je verwerkingsregister?** Als AI-tooling breed gebruikt wordt maar nergens genoteerd staat, is dat het eerste gat dat opvalt.

NIS2: je AI-leverancier zit nu in je keten

NIS2 legt veel nadruk op de beveiliging van je toeleveringsketen. Een AI-codeerassistent die schrijftoegang heeft tot je repository’s, of die in je pipeline draait, is onderdeel van die keten.

Dat betekent dat de vragen die je al aan andere leveranciers stelt, hier ook gelden: welke toegang heeft dit, wat gebeurt er bij een storing of een compromittering aan hun kant, en hoe merken wij dat?

Er komt één ding bij dat specifiek is voor AI-tooling: **afhankelijkheden die niemand gekozen heeft.** Als een agent een package voorstelt en dat komt door de review, dan is er een leverancier aan je keten toegevoegd door een model. Dat is precies het soort beslissing dat NIS2 zichtbaar wil hebben, dus laat je dependency-scanning en je goedkeuringsroute voor nieuwe packages niet ongemoeid als het volume omhoog gaat.

DORA: aantoonbaarheid, niet alleen beleid

Val je onder de Digital Operational Resilience Act, dan verschuift de lat van “we hebben beleid” naar “laat maar zien”.

Je moet kunnen laten zien welke ICT-diensten van derden je gebruikt, welke risico’s daaraan hangen en hoe je systeem zich houdt als er iets misgaat. Een AI-codeerdienst die betrokken is bij het maken van je productiecode, hoort in dat overzicht thuis.

De praktische consequentie is documentatie die niet los van je systeem staat: welke tooling betrokken was bij een wijziging, wie hem heeft goedgekeurd, en dat je controles daadwerkelijk gedraaid hebben. Dat is geen extra administratie als je het uit je pipeline haalt — en een hoop werk als je het achteraf met de hand moet reconstrueren.

Vier dingen die alle drie de regimes tegelijk bedienen, en die geen van drieën echt duur zijn:

1. **Leg vast welke AI-tooling waar draait en wat hij mag.** Eén overzicht, met toegang en verwerkingslocatie erbij. Dit is het document dat je bij elke audit als eerste nodig hebt.
2. **Markeer AI-ondersteunde wijzigingen.** Een vlag op PR-niveau volstaat. Het maakt zowel je risicogesprek als je effectmeting mogelijk — en zonder is beide giswerk.
3. **Automatiseer je controles in de pipeline.** Dependency-scanning, secret-detectie, policy-checks op infrastructuur. Als de hoeveelheid code omhoog gaat, is dit het enige wat meeschaalt; handmatige review doet dat niet.
4. **Bewaar het bewijs dat die controles gedraaid hebben.** Niet omdat een toezichthouder het mooi vindt, maar omdat “we scannen altijd” geen antwoord is en een pipelinelog dat wel is.

AI-tooling introduceert zelden een nieuw regime. Het verplaatst bestaande verplichtingen naar je ontwikkelstraat, waar ze eerder niet zaten.

AVG gaat over wat je meestuurt. NIS2 gaat over wie er in je keten zit, inclusief de afhankelijkheden die een model heeft voorgesteld. DORA gaat over of je het kunt aantonen.

Alle drie komen ze uit op hetzelfde punt: weten wat er gebeurt in je pipeline, en dat kunnen laten zien. Dat is precies de reden dat meten geen compliance-oefening is maar gewoon goed engineeringwerk — en waarom het, nu code goedkoop wordt, het deel is dat ertoe doet.

Wat dertig minuten wachten per engineer per dag echt kost

ajet8k.webp

Een half uur per dag. Zo weinig lijkt het. Maar reken het door en het is €5.000 per engineer per jaar, of een half miljoen euro bij honderd engineers — geld dat op geen enkele regel van je P&L staat en dat niemand ooit heeft goedgekeurd.

Een half uur per dag. Zo weinig lijkt het.

Je wacht op een build. Je wacht tot iemand je pull request bekijkt. Je wacht op een omgeving die vrijkomt, op een goedkeuring, op een pipeline die twaalf minuten doet over iets wat in twee zou moeten. Niemand noteert het, want het voelt niet als tijd die je kwijtraakt. Het voelt als het werk.

Reken het door en het is €5.000 per engineer per jaar. Bij honderd engineers een half miljoen euro. Elk jaar, en op geen enkele regel van je P&L.

Er zit geen truc in. Je kunt hem zelf natrekken met je eigen cijfers:

- Een half uur per werkdag is **2,5 uur per week**.
- Bij ongeveer **220 werkbare dagen** per jaar is dat **110 uur per engineer per jaar**.
- Reken je met een belaste kostprijs van zo’n **€45 per uur**, dan kom je op **€4.950** — afgerond €5.000.
- Honderd engineers: **€495.000 per jaar**.

Vul gerust je eigen tarief in. Het punt verandert niet: dit is geen randverschijnsel, het is een salarispost ter grootte van een klein team, en er staat geen factuur tegenover.

Als je erop gaat letten, blijkt het bijna nooit één groot blok te zijn. Het zijn kleine stukjes die zich opstapelen:

- **Wachten op builds en tests.** Een pipeline van acht minuten die je vijf keer per dag draait, is veertig minuten. Draait hij niet betrouwbaar, dan draai je hem vaker.
- **Wachten op review.** Meestal de grootste post, en bijna nooit apart gemeten. Je pull request staat klaar; je collega zit in een meeting.
- **Wachten op omgevingen.** Één staging, drie teams.
- **Wachten op goedkeuring.** Iemand moet een vinkje zetten en die iemand heeft vandaag iets anders te doen.
- **De verborgen kosten van het schakelen.** Dit is de pijnlijkste. Vijftien minuten wachten kost je zelden vijftien minuten: je begint aan iets anders, en de weg terug naar waar je was kost nog eens tien.

Cloudkosten zie je, want er komt een factuur. Licenties zie je, want er komt een factuur. Wachttijd komt van niemand, dus komt hij nergens binnen.

Er is ook geen moment waarop iemand een besluit neemt. Niemand heeft ooit goedgekeurd dat de pipeline acht minuten duurt; hij is er in de loop van twee jaar naartoe gegroeid, stap voor stap, en elke afzonderlijke stap was verdedigbaar.

En de mensen die er het meest last van hebben, zijn precies de mensen die het het minst snel melden. Wachten voelt niet als een probleem dat je escaleert. Het voelt als hoe het werk nu eenmaal is.

Dit is het deel dat de meeste teams verrast.

Als code sneller geschreven wordt, wordt er niet minder gewacht — er wordt méér gewacht. Meer wijzigingen bereiken sneller de wachtrij voor review. Meer pull requests concurreren om dezelfde reviewers. Meer builds vechten om dezelfde runners. De bottleneck verdwijnt niet, hij verschuift naar de plek waar geen model bij kan.

Dat is precies waarom code goedkoper maken de kosten niet wegneemt maar concentreert. We hebben dat argument uitgewerkt in [onze kijk op AI in softwareontwikkeling](/ai-solutions): zodra schrijven niet langer je beperking is, wordt alles eromheen je beperking — en dan pas blijkt of je dat ooit gemeten hebt.

Je hoeft hier geen groot programma voor op te tuigen. Drie dingen brengen het grootste deel in beeld:

- **Splits je lead time op in fases.** Eén getal van commit tot productie verbergt precies wat je zoekt. Zodra je schrijven, wachten op review, testen en uitrollen apart ziet, springt de grootste post er meteen uit.
- **Meet review-latency apart.** De tijd tussen “klaar voor review” en “iemand kijkt ernaar”. In de meeste teams is dit de grootste enkele post, en bijna nergens staat hij op een dashboard.
- **Meet de doorlooptijd van je pipeline, niet alleen of hij slaagt.** Slagingspercentage zegt niets over de tijd die je eraan kwijt bent.

Meet een maand voordat je iets verandert. Zonder nulmeting kun je achteraf niet aantonen dat je iets verbeterd hebt, en dan wint degene met de sterkste mening.

De ingrepen zijn zelden spectaculair, en dat is precies waarom ze blijven liggen.

- **Spreek een reviewtermijn af.** “Pull requests onder de 300 regels worden binnen 24 uur bekeken” haalt vaak meer weg dan welke technische ingreep ook.
- **Maak je pull requests kleiner.** Kleinere wijzigingen worden sneller bekeken, en de wachttijd daalt harder dan de omvang.
- **Versnel je pipeline met caching en parallelle tests.** Acht minuten naar drie is over honderd engineers een aanzienlijk bedrag.
- **Geef elke wijziging een eigen omgeving** in plaats van te wachten op de gedeelde staging.
- **Haal goedkeuringen weg die niets tegenhouden.** Een vinkje dat altijd gezet wordt, is geen controle maar vertraging.

Halveer je die dertig minuten, dan haal je bij honderd engineers een kwart miljoen euro per jaar terug. Dat is geen besparing die je hoeft te bevechten in een budgetronde — je hoeft alleen te weten dat hij er is.

Wachttijd is de grootste kostenpost die niemand op zijn begroting heeft staan.

Een half uur per engineer per dag is €5.000 per jaar per persoon en een half miljoen bij honderd. Het staat op geen factuur, niemand heeft het goedgekeurd, en het groeit vanzelf terwijl je nergens op let.

En zodra AI het schrijven versnelt, wordt dit het enige dat er nog toe doet. Meet het voordat je erin investeert, anders weet je straks alleen dat je sneller code produceert — niet of je sneller iets oplevert.

Van monolith naar microservices met behulp van het strangler pattern

c124f787-7a87-4c74-be31-7ab9bf204292.webp

Het strangler pattern is een techniek uit Dave Farley's 'Continuous Delivery' voor het transformeren van een monolithisch softwaresysteem naar een op microservices gebaseerde architectuur. Het houdt in dat delen van een groot monolithisch softwaresysteem geleidelijk worden vervangen door kleinere microservices, waardoor de monoliet in de loop van de tijd wordt "gewurgd" totdat deze volledig is vervangen. De naam 'strangler pattern' is afgeleid van de wurgliaan die op een andere boom groeit en deze als fysieke steun gebruikt, terwijl hij ook zonlicht en voedingsstoffen van de boom steelt, wat uiteindelijk de gastheerplant doodt.

Het **strangler pattern** is een techniek uit Dave Farley's 'Continuous Delivery' voor het transformeren van een monolithisch softwaresysteem naar een op microservices gebaseerde architectuur. Het omvat het geleidelijk vervangen van delen van een groot monolithisch softwaresysteem door kleinere microservices, waardoor de monolith na verloop van tijd wordt "gewurgd" totdat deze volledig is vervangen. De naam 'strangler pattern' is afgeleid van de wurgliaan die op een andere boom groeit en deze als fysieke steun gebruikt, terwijl hij ook zonlicht en voedingsstoffen van de boom steelt, wat uiteindelijk de gastheerplant doodt.

Hier zijn de stappen om een monolithisch softwaresysteem te transformeren naar een op microservices gebaseerde architectuur met behulp van het strangler pattern:

1. **Bepaal de grenzen**: De eerste stap is het identificeren van de afzonderlijke grenzen binnen het monolithische systeem die kunnen worden opgesplitst in afzonderlijke microservices. Dit kan gebeuren op basis van zakelijke mogelijkheden, functionele domeinen of technische afhankelijkheden.
2. **Bepaal de interfaces**: Zodra de grenzen zijn bepaald, is de volgende stap het definiëren van de interfaces tussen de microservices en de monoliet. Dit omvat het specificeren van de gegevens die zullen worden uitgewisseld tussen de microservices en de monoliet en de API's die zullen worden gebruikt voor de communicatie. (tip: gebruik technieken uit Domain Driven Design om dit proces te begeleiden)
3. **Implementeer de microservices**: Als de interfaces gedefinieerd zijn, is de volgende stap om de microservices één voor één te implementeren. Dit houdt in dat je een nieuwe service maakt die een klein deel van de functionaliteit van de monolith implementeert en de API definieert die gebruikt zal worden voor de communicatie.

4. **Routeer het verkeer naar de microservices**: De volgende stap is om het verkeer naar hen te routeren zodra de microservices geïmplementeerd zijn. Dit kan gedaan worden door geleidelijk de routeringsregels van de monoliet aan te passen om verkeer naar de microservices te sturen in plaats van naar de monoliet.
5. **Bruik de monoliet**: Naarmate meer en meer verkeer naar de microservices wordt gerouteerd, wordt de monoliet minder kritisch. Uiteindelijk, wanneer microservices alle functionaliteit van de monoliet hebben vervangen, kan de monoliet buiten gebruik worden gesteld.

Het strangler pattern is een geleidelijk en iteratief proces; het is belangrijk om klein te beginnen en je eerst te richten op de meest kritieke onderdelen van de monoliet. Na verloop van tijd kan steeds meer functionaliteit worden gemigreerd naar microservices totdat de monoliet niet langer nodig is.

Het verhaal van het schip van Theseus is een filosofische paradox die de vraag oproept naar identiteit in de tijd. Het verhaal gaat dat de Atheners het schip van Theseus in een dok bewaarden als een gedenkteken voor hun held. Naarmate de jaren verstreken, begonnen de planken van het schip te rotten en werden ze één voor één vervangen totdat er geen originele plank meer overbleef. **De vraag rijst dan: is het schip dat overblijft nog steeds het schip van Theseus, of is het een geheel nieuw schip?**

Op dezelfde manier houdt het strangler pattern in dat delen van een monolithisch softwaresysteem geleidelijk worden vervangen door microservices totdat het oorspronkelijke systeem volledig is vervangen. De vraag rijst dan: is het resulterende systeem nog steeds hetzelfde systeem als de oorspronkelijke monoliet, of is het een volledig nieuw systeem?

In beide gevallen wordt de identiteit van de oorspronkelijke entiteit in twijfel getrokken door de geleidelijke vervanging van de samenstellende delen. In het geval van het strangler pattern is het resulterende systeem functioneel nog steeds hetzelfde als de oorspronkelijke monoliet, maar het is geherstructureerd tot een nieuwe architectuur.

Uiteindelijk illustreren het Schip van Theseus verhaal en het strangler pattern de uitdagingen van de geleidelijke vervanging van onderdelen van een groter systeem (monoliet/schip). Beide gevallen roepen vragen op over continuïteit en verandering. Het strangler pattern is de beste manier om een anders extreem riskante vervangingsoperatie van een monoliet minder risicovol te maken. Als je zorgvuldig plant welke delen van de monoliet in welke volgorde migreren, kun je veilig genieten van een transformatie die anders veel hartzeer en stress zou veroorzaken.

Productivity

AgileAnalyticsSaaS

IntegraalSoftwareontwikkelPortaal

Gerelateerd Nieuws & Artikelen

Software ontwikkelen met behulp van AI en rekening houden met AVG, NIS2 en DORA compliance

Wat dertig minuten wachten per engineer per dag echt kost

Van monolith naar microservices met behulp van het strangler pattern