Als ik developers vraag waar ze mee bezig zijn, laten ze me code zien. Als ik business-stakeholders vraag wat ze nodig hebben, beschrijven ze problemen. De kloof tussen die twee antwoorden is waar de meeste softwareprojecten falen.
Ik heb mijn hele carrière geprobeerd die kloof te dichten. Niet door beter te worden in het vertalen van bedrijfsproblemen naar code, dat was altijd het verkeerde doel. Door bedrijfsproblemen zélf het primaire artefact te maken. Door systemen te bouwen waarin de bedrijfslogica expliciet, zichtbaar en verifieerbaar is, niet verborgen in implementatiedetails.
Decennialang voelde dit als tegen de stroom in zwemmen. De tools ondersteunden het niet. De economie werkte niet mee. De markt beloonde mensen die snel code konden schrijven, niet mensen die goed bedrijven konden modelleren.
Dat verandert. En wanneer ik het heb over "shifting left", over het terugkeren van ons vak naar Informatiesystemen-denken, dan is dit hoe het er in de praktijk uitziet. Geen filosofie. Concrete artefacten.
De verborgen kosten van code als primair artefact
Wat er gebeurt als je code als het primaire artefact behandelt: bedrijfskennis wordt gecodeerd in diep technische vormen. Een prijsregel wordt een conditional in code met geneste if-statements en cryptische variabelenamen. Een goedkeuringsproces voor klanten wordt een state machine verstopt in een Domain Service (als je geluk hebt). Een ordervalidatieregel wordt een custom exception class die alleen een developer kan lezen en aanpassen.
Dit werkt, technisch gezien. De code draait. De systemen verwerken transacties. Maar er is iets waardevols verloren gegaan in de vertaling.
De bedrijfsregel begon als een concept in iemands hoofd: "we kunnen geen orders boven de 50.000 euro verwerken zonder goedkeuring van een manager." Tegen de tijd dat het in code is ingebed, is het getransformeerd door lagen van technische abstractie. De oorspronkelijke bedrijfslogica is er nog, maar ze is verborgen. Als je wilt weten welke regels daadwerkelijk je bedrijf besturen, kun je het niet vragen aan een businessanalist of een productmanager. Je moet het vragen aan een developer, en die developer moet de oorspronkelijke intentie reverse-engineeren uit code die maanden geleden is geschreven door iemand die misschien niet meer bij het bedrijf werkt.
Wanneer die developers vertrekken, en dat zullen ze, loopt die kennis de deur uit. Je blijft achter met systemen waar niemand de bedrijfslogica volledig begrijpt zonder code te lezen. Je blijft achter met documentatie die niet meer in sync is met de werkelijkheid omdat de code veranderde maar niemand de specificatie bijwerkte. Je blijft achter met het uitleggen van je eigen bedrijf aan externe consultants die drie weken nodig hebben om alleen maar te begrijpen waarom je retouren verwerkt zoals je dat doet.
Helaas is dit nog steeds hoe de meeste organisaties opereren. En de verborgen kosten stapelen zich op over tijd.
Het alternatief: bedrijfskennis als eersteklas artefact
Er is een betere manier. Het begint met een fundamentele verschuiving: bedrijfsconcepten worden primaire artefacten. Code wordt implementatiedetail.
Dit is geen terugkeer naar waterfall-documentatie. Dit is geen specificatie van 200 pagina's die niemand leest en die onmiddellijk verouderd raakt. Dit is iets heel anders. Dit zijn werkende modellen die definiëren hoe je systemen daadwerkelijk zich gedragen.
Domeinmodellen: De taal van het bedrijf
Begin met domeinmodellen. Een domein is een afgebakend gebied van bedrijfskennis, een specifiek aandachtsgebied waar consistente taal en regels gelden. Een domein voor Orderbeheer. Een Klantdomein. Een Prijsdomein.
Binnen elk domein modelleer je de entiteiten en relaties die ertoe doen voor het bedrijf. Een Order heeft een Klant. Een Order bevat meerdere Orderregels. Een Orderregel verwijst naar een Product. Een Klant heeft een Afleveradres, een Factuuradres, een Voorkeursbetaalmethode.
Let op de taal. Order. Klant. Product. Orderregel. Dit zijn bedrijfstermen, geen technische abstracties. Je zult geen "CustomerDTO" of "OrderEntity" of "customer_service_response_wrapper" tegenkomen. Het model spreekt de taal van het bedrijf.
Zo ziet een domein eruit. In dit geval het productiedomein van een pizzeria. Let op hoe het de relatie met andere domeinen beschrijft, de primaire producten en diensten, en de terminologie die binnen het domein wordt gebruikt. Allemaal in bedrijfsterminologie.
Dit is waarom dat ertoe doet: iemand van je salesteam, je financiële afdeling of je operationele team kan naar dit model kijken en verifiëren dat het klopt. "Klopt het dat elke Order gekoppeld is aan precies één Klant?" Ja. "Kan een Order geen Orderregels hebben?" Nee, dat zou ongeldig zijn, we hebben minstens één item nodig. "Kan een Klant meerdere Afleveradressen hebben?" Absoluut, en daarom is het gemodelleerd als een collectie.
Deze modellen hebben waarde onafhankelijk van welke code dan ook. Het zijn geen diagrammen die achteraf getekend worden om een systeem te documenteren. Ze zíjn de specificatie. Wanneer code geschreven wordt, implementeert het deze modellen. Wanneer het bedrijf verandert, wanneer je beseft dat je klantgroepen moet ondersteunen, niet alleen individuele klanten, evolueert het model eerst. Dan volgt de implementatie.
Wat ik vaak zie bij volwassen organisaties is dat deze modellen organisatorische assets worden. Het domeinmodel is gezamenlijk eigendom van business-stakeholders en technisch architecten. Het is geversioned. Het wordt beoordeeld. Het is een gedeeld begrip van wat het bedrijf werkelijk is.
Procesmodellen: Bedrijfslogica expliciet maken
Maar entiteiten alleen zijn niet genoeg. Je moet ook processen modelleren, de reeksen van stappen, beslismomenten en transformaties die ruwe orders omzetten in verzonden goederen of die bepalen of een klant in aanmerking komt voor een bepaalde korting.
Een procesmodel maakt dit expliciet. Een orderverwerkingsworkflow zou er zo uit kunnen zien: Order Ontvangen → Valideren → Kortingen Toepassen → Belasting Berekenen → Voorraad Controleren → Voorraad Reserveren → Fulfillment Aanmaken → Klant Informeren.
Maar er zijn beslismomenten: "Is de order geldig?" Zo niet, afwijzen. "Is er voldoende voorraad?" Zo niet, nabestellen of annuleren. "Komt de klant in aanmerking voor loyaliteitsprijzen?" Toepassen of standaardtarief berekenen.
Het proces in zijn uitvoerbare vorm. Als er iets verandert aan het proces, dan verandert dit artefact als eerste.
Dit zijn geen abstracties, dit is hoe je daadwerkelijk opereert. En in tegenstelling tot code kan een procesmodel gelezen en geverifieerd worden door niet-technische stakeholders. "Wanneer controleren we de voorraad, voor of na het toepassen van kortingen?" Het model laat het zien. "Wat gebeurt er als het adres van een klant onvolledig is?" Het model toont de validatiestap en het beslismoment.
Het cruciale inzicht: dit procesmodel ÍS het systeemgedrag. Wanneer je verandert hoe je orders verwerkt, verander je niet alleen de code, je verandert eerst het model. Het model is de bron van waarheid. Code wordt eruit gegenereerd of implementeert het.
Bedrijfsregels: Governance zonder code
Binnen deze processen en domeinen heb je regels. Prijsregels. Geschiktheidsregels. Validatieregels. Goedkeuringsregels.
In traditionele systemen zijn deze regels verspreid. Eén regel is hardcoded in een microservice. Een andere is ingebed in een database-trigger. Een derde leeft ergens in een scheduled job. Niemand heeft een helder overzicht van alle bedrijfsregels die het systeem besturen. Wanneer een regel verandert, moet je door code spitten om alle plekken te vinden waar die geïmplementeerd is.
Wat als deze regels eersteklas burgers waren? Zichtbaar. Bestuurbaar. Geschreven in taal die het bedrijf kan lezen en verifiëren.
"Klanten in regio A krijgen 10% volumekorting op orders boven €10.000." Dat is een bedrijfsregel. Die zou expliciet vastgelegd moeten zijn, niet afgeleid uit code. "Orders boven €50.000 vereisen goedkeuring van een manager." Nog een regel. "Een klant kan geen nieuwe order plaatsen als er een openstaande factuur is die ouder is dan 30 dagen."
Voorbeeld van een bedrijfsregel beschreven in bedrijfstaal. Dit wordt gebruikt als de specificatie voor het systeem.
Deze regels zouden moeten zijn:
- Geschreven in natuurlijke bedrijfstaal, niet in codesyntax
- Eigendom van business-stakeholders (niet van developers)
- Geversioned en bijgehouden
- Eenvoudig te wijzigen zonder implementatiecode aan te raken
- Auditeerbaar, je kunt zien wanneer ze veranderd zijn en waarom
Dit is geen nieuw idee. Business Rule Management bestaat al decennia. Wat nieuw is, is dat AI de economie verandert. Nu kun je tools hebben die deze regels interpreteren, die ze consistent toepassen, die er code uit genereren, die systemen ertegen verifiëren. De kosten-batenanalyse verschuift.
Waarom deze artefacten code overleven
Dit is wat deze aanpak krachtig maakt: deze artefacten, domeinmodellen, procesmodellen, bedrijfsregels, productdefinities, overleven elke implementatie.
Je kunt je hele technologiestack herschrijven. Je kunt migreren van een monoliet naar microservices, of van microservices terug naar een modulaire monoliet. Je kunt verhuizen van on-premises naar de cloud, of van cloudprovider wisselen. Door dat alles heen blijven je domeinmodellen waar. Een Order is nog steeds een Order. Een Klant is nog steeds een Klant. De bedrijfsregels besturen het gedrag nog steeds op dezelfde manier.
Maar belangrijker nog: wanneer iemand je team verlaat, loopt de kennis niet de deur uit. De bedrijfslogica zit niet opgesloten in iemands hoofd of begraven in code die alleen zij begrijpen. Het is expliciet vastgelegd, in vormen die gelezen en geverifieerd kunnen worden. De volgende persoon die ingewerkt wordt, leest de modellen en leert hoe het bedrijf daadwerkelijk werkt.
In mijn ervaring is dit waar echte organisatorische lering plaatsvindt. Niet in architectuurmeetings of design reviews, maar in het proces van het bouwen van expliciete, accurate modellen van wat je bedrijf werkelijk is.
Dit is Shifting Left
"Shifting left" betekent niet alleen eerder testen, hoewel dat er ook bij hoort. Het betekent dat ontwikkeling zelf naar links verschuift. Het verschuift van implementatie naar modellering. Het verschuift van code schrijven naar het vastleggen van bedrijfskennis.
De waarde van een developer verandert. Een developer die 10.000 regels code per jaar kan schrijven, wordt nu gemeten aan iets betekenisvollers: Hoe goed heb je het bedrijfsdomein vastgelegd? Kunnen stakeholders je modellen lezen en verifiëren dat ze kloppen? Wanneer requirements veranderen, hoe snel past je modellering zich aan? Hoeveel bedrijfskennis zit opgesloten in je werk, en hoeveel is overdraagbaar?
Implementatie doet er nog steeds toe, iemand moet modellen omzetten in draaiende systemen. Maar die iemand hoeft geen menselijke developer te zijn. Die iemand kan AI zijn, gestuurd door heldere specificaties. De schaarse hulpbron wordt het vermogen om het bedrijf te begrijpen en dat begrip vast te leggen in expliciete vormen.
Wat zou er veranderen in jouw organisatie?
Stel je voor dat je ontwikkelteams heldere domeinmodellen hadden die stakeholders konden lezen en verifiëren. Stel je voor dat elke bedrijfsregel expliciet, zichtbaar en bestuurd was. Stel je voor dat je een requirement kon traceren van een bedrijfsconcept tot waar het geïmplementeerd was, of je hele systeem kon begrijpen door de domeinen en processen te begrijpen in plaats van miljoenen regels code te lezen.
Stel je voor wat dat zou betekenen voor kennisbehoud. Voor onderhoudbaarheid. Voor de snelheid waarmee je systemen kunt veranderen. Voor het betrekken van niet-technische stakeholders bij het definiëren van hoe hun eigen bedrijf opereert.
Dat is niet hypothetisch. Dat is hoe geavanceerde organisaties nu systemen bouwen.
Welke bedrijfsconcepten zitten verborgen in jouw code? Hoe zou het eruitzien om ze expliciet te maken? Wat zou er gebeuren als je je teams niet meet op outputsnelheid maar op de kwaliteit en helderheid van vastgelegde bedrijfskennis?
Deze vragen raken aan iets reëels. Want de toekomst van het vak, het daadwerkelijk waardevolle werk dat developers zullen doen, gaat minder over code schrijven en meer over het begrijpen van het bedrijf en dat begrip overdraagbaar maken.
De code volgt vanzelf. De modellen zijn wat ertoe doet.
