Een fout in een begrip kost je niet één keer. Een verkeerd gekozen naam, een onzuiver domeinmodel of een halfklare abstractie wordt een raakpunt waar elke latere verandering doorheen moet: nieuwe functionaliteit, integraties, migraties, rapportages, autorisaties, beheer, nieuwe mensen. Daarmee is zo'n fout geen incident, maar een belasting op alle toekomstige verandering die dat begrip kruist.
Hogere kwaliteit vandaag betekent daarom minder hypotheek op morgen. Niet als abstract kwaliteitsideaal, maar heel praktisch: je betaalt wanneer de blast radius nog klein is, in plaats van wanneer een verkeerd begrip door het hele systeem, de data, de rapportages en de organisatie is vertakt.
Het doel is betere software. Software die het werk scherper begrijpt, processen zuiverder ondersteunt, data betrouwbaarder maakt en minder schuld doorschuift naar de toekomst. AI maakt dat doel beter bereikbaar, niet omdat architectuur ineens sneller kan worden uitgevoerd, maar omdat processen, data, domeinmodellen en kwaliteit veel intensiever kunnen worden onderzocht voordat ze in software worden vastgezet.
Architectuur begint bij processen en data
Softwarearchitectuur begint zelden bij ontwerp en nooit bij code. In organisaties begint softwarearchitectuur bij processen en data. Een proces is in essentie georganiseerde presentatie en manipulatie van data: iemand ziet iets, registreert iets, wijzigt iets, keurt iets goed, corrigeert iets, verrijkt iets, draagt iets over of neemt ergens verantwoordelijkheid voor. Wat een organisatie "proces" noemt, is meestal een keten van datagebeurtenissen met rollen, regels, uitzonderingen, rechten, plichten en betekenissen eromheen.
Wie software maakt, formaliseert dus niet alleen schermen en workflows. Software legt vast hoe een organisatie haar werkelijkheid mag waarnemen, benoemen, veranderen en verantwoorden. Dat maakt software veel minder neutraal dan vaak wordt aangenomen. Een systeem registreert niet alleen de werkelijkheid; het bepaalt mede welke werkelijkheid nog registreerbaar is.
Naming is architectuur, geen cosmetiek
Daar begint naming.
Zodra processen en data worden onderzocht, ontstaat de kernvraag welke dingen officieel mogen bestaan. Is iets een aanvraag, een melding, een afspraak, een bezoek, een machtiging, een status, een correctie, een gebeurtenis, een besluit of een relatie tussen dingen? Die woorden lijken onschuldig. Ze voelen als voorbereiding op het echte werk. Maar ze zijn het echte werk. Een woord dat in software wordt vastgelegd, wordt onderdeel van de administratieve werkelijkheid waarin gebruikers moeten leven.
Daarom is naming geen cosmetische activiteit. Het is architectuur. Een slecht gekozen begrip is niet alleen een ongelukkige tabelnaam, een matige API-term of een onhandig label op een scherm. Het wordt een kader waarbinnen gebruikers hun werk moeten uitvoeren, ontwikkelaars hun code structureren, datamodellen hun relaties afdwingen, rapportages hun conclusies trekken en bestuurders hun besluiten nemen. Wat niet benoemd is, krijgt vaak geen plek. Wat verkeerd benoemd is, blijft vaak jarenlang verkeerd doorwerken. Wat ooit als tijdelijke categorie begon, kan via software een institutionele werkelijkheid worden.
Legacy is niet alleen oude code
Dit is precies waar AI softwarearchitectuur fundamenteel sterker kan maken. Niet door het denkwerk over te nemen, maar door het herzien van begrippen, modellen en aannames veel vanzelfsprekender te maken. Een domeinmodel hoeft niet meer te worden behandeld als een nette tekening die vroeg in het traject wordt gemaakt en daarna vooral moet blijven staan. Het kan worden behandeld als wat het werkelijk is: een hypothese over de werkelijkheid van een organisatie.
Die hypothese moet worden getoetst. Aan taal. Aan gedrag. Aan historische data. Aan uitzonderingen. Aan migratiepaden. Aan rechtenstructuren. Aan rapportagebehoeften. Aan toekomstig verandervermogen. AI maakt het mogelijk om die toets vaker, scherper en systematischer uit te voeren. Klopt dit begrip nog? Dekt dit woord het domein? Zijn twee concepten ten onrechte samengevoegd? Worden vijf namen gebruikt voor hetzelfde ding? Wordt een oud vervuild model nog steeds als vanzelfsprekend uitgangspunt genomen, alleen omdat het er al jaren ligt?
Dat laatste is cruciaal. Veel complexiteit ontstaat niet door nieuwe functionaliteit, maar door vasthouden aan oude modellen die hun betekenis hebben verloren. Legacy is niet alleen oude code. Legacy is ook oude taal. Oude categorieën, oude statussen, oude uitzonderingen, oude datavelden en oude procesbeelden die ooit logisch waren, maar inmiddels vooral afdwingen dat de organisatie zichzelf blijft beschrijven in een taal die niet meer klopt.
Domeinmodellen en datamigratie maken dat genadeloos zichtbaar. Een nieuw model kan inhoudelijk zuiver lijken, terwijl historische data een ander verhaal vertelt. Oude categorieën blijken vervuild. Betekenissen blijken verschoven. Uitzonderingen blijken structureel. Rapportages blijken afhankelijk van woorden die niemand meer goed kan uitleggen. Integraties blijken niet gekoppeld aan werkelijkheid, maar aan de manier waarop een oud systeem die werkelijkheid ooit heeft versimpeld.
Juist daarom krijgt model-driven architecture door AI een echte impuls. Niet omdat AI "het model maakt", maar omdat model shaping eindelijk beter kan aansluiten bij de werkelijkheid van het vak: iteratief, onderzoekend, confronterend en voortdurend in gesprek met proces, data, migratie en gebruik. Het model wordt geen vooraf dichtgetimmerd schema, maar een werkend denkobject. Iets dat mag botsen, mag terugkomen, mag worden herzien en juist daardoor beter wordt.
Productkwaliteit en datakwaliteit horen samen
Hier raken ISO 25010 en ISO 25012 elkaar. ISO 25010 gaat over productkwaliteit: onderhoudbaarheid, betrouwbaarheid, security, performance-efficiency, portability, usability en functionele geschiktheid. Die eigenschappen bepalen of software duurzaam waarde blijft leveren. ISO 25012 voegt daar datakwaliteit aan toe: accuracy, completeness, consistency, credibility, currentness, traceability, understandability, availability, portability en recoverability. Die combinatie is bij domeinmodellering, naming en migratie geen theoretische luxe, maar noodzakelijk.
Een systeem kan technisch werken en toch inhoudelijk verkeerde data produceren. Een migratie kan technisch slagen en toch betekenis verliezen. Een rapport kan draaien en toch de werkelijkheid verkeerd benoemen. Een veld kan verplicht gevuld zijn en toch het verkeerde verschijnsel meten. Een audit trail kan volledig zijn en toch alleen vastleggen hoe een fout begrip jarenlang consequent is toegepast.
Datakwaliteit is daarom geen apart technisch thema naast softwarekwaliteit. De kwaliteit van data wordt mede bepaald door de kwaliteit van de begrippen waarmee die data wordt vastgelegd. Accuracy gaat niet alleen over correcte waarden, maar over de vraag of het juiste verschijnsel wordt gemeten. Completeness gaat niet alleen over gevulde velden, maar over de vraag of het systeem ruimte heeft voor wat in het domein werkelijk voorkomt. Consistency gaat niet alleen over uniforme formats, maar over begrippen die door het systeem heen hetzelfde betekenen. Traceability gaat niet alleen over audit trails, maar over kunnen reconstrueren waarom een classificatie, status of betekenis ooit zo is gekozen.
Eén woord, twee meetstelsels, 12.000 medewerkers
Voor de apotheekbranche verzorgden wij de verlof- en overwerkberekeningen voor ruim 12.000 medewerkers. Het systeem kende het begrip verlofdag. Een onschuldig woord — tot je ziet wat het stilzwijgend aannam: dat een dag een vaste hoeveelheid uren is. Dat klopt voor een voltijder, maar het overgrote deel werkte in deeltijd, in wisselende contracten, met diensten die niet op hele dagen vielen.
Op zichzelf was verlofdag nog hanteerbaar. Het echte probleem ontstond ernaast: het systeem kende óók een ziektedag. En een ziektedag is geen variant van een verlofdag — het leeft in een totaal ander meetstelsel. Ziekteverzuim volgt de systematiek van het UWV: wachttijden, percentages van loondoorbetaling, opbouw- en hersteltermijnen die niets te maken hebben met de roostersystematiek waarin verlof wordt opgenomen. Twee begrippen die door dezelfde eenheid — "dag" — werden gepresenteerd, maar in onverenigbare dimensies meten. De ene telt geplande afwezigheid in roosteruren; de andere telt een wettelijk gereguleerde verzuimtoestand in een heel ander stelsel.
Daarmee raakte één naming-keuze drie kwaliteitsattributen tegelijk. Verlofdag mat niet wat het pretendeerde (accuracy: het verkeerde verschijnsel voor deeltijders). Het model had geen ruimte voor de contractafhankelijke werkelijkheid (completeness). En doordat verlofdag en ziektedag dezelfde eenheid suggereerden terwijl ze in verschillende stelsels rekenden, betekende "dag" niet overal hetzelfde (consistency). De berekeningen wérkten — schermen vulden, rapportages draaiden, audit trails waren compleet — en legden jarenlang consequent twee onvergelijkbare grootheden vast alsof ze optelbaar waren.
De correctie zat niet in betere code, maar in betere begrippen: erkennen dat verlof en verzuim verschillende meetdimensies zijn, elk met een eigen eenheid en eigen wettelijk kader, in plaats van ze te verbergen achter één woord "dag". Eén modelbeslissing — vroeg genomen, of jarenlang uitgesteld — bepaalde of 12.000 berekeningen klopten of stilzwijgend scheef stonden.
Van sluitpost naar methode
Daarmee verschuift kwaliteit van sluitpost naar methode. In de klassieke duivelsdriehoek van tijd, functionaliteit en kwaliteit — waarin elke hoek alleen kan winnen ten koste van een ander — is kwaliteit vaak de meest kwetsbare hoek. Hij laat zich het makkelijkst inleveren, omdat het verlies pas later zichtbaar wordt. Agile werken heeft dat deels verbeterd. Kortcyclisch leveren, sneller feedback ophalen en transparanter prioriteren voorkomen dat kwaliteit pas helemaal aan het einde zichtbaar wordt. Maar agile lost het probleem niet volledig op, omdat functionaliteit tastbaar is en onderliggende kwaliteit veel minder.
Een scherm werkt. Een API levert data. Een workflow is af. Dat laat zich demonstreren. Domeinzuiverheid, onderhoudbaarheid, migratiebestendigheid, security-by-design, datakwaliteit en modelconsistentie zijn minder zichtbaar. Ze leven over meerdere sprints, releases, systeemlagen en migraties heen. Ze passen niet altijd netjes in kleine tickets met direct zichtbare output. Precies daar ontstaat de verborgen schuld aan de toekomst: niet door één rampzalige keuze, maar door een reeks redelijke kortetermijnbesluiten die samen leiden tot vervuilde modellen, broze code, onduidelijke data en afnemend verandervermogen.
AI verandert dat speelveld. Niet door kwaliteit automatisch te leveren, maar door het moeilijker te rechtvaardigen dat kwaliteit niet wordt meegenomen. Als begrippen, modellen, migratiescenario's en ontwerpvarianten sneller kunnen worden onderzocht, wordt het minder verdedigbaar om een halfbegrepen model vast te zetten. Als inconsistenties eerder zichtbaar kunnen worden gemaakt, wordt het minder verdedigbaar om ze stilzwijgend door te schuiven. Als oude vervuilde modellen beter kunnen worden blootgelegd, wordt het minder verdedigbaar om ze opnieuw als fundament te gebruiken.
De waarde zit dus in betere ontwerpbeslissingen eerder in het proces. Duidelijkere domeinmodellen leiden tot betere code, betere data, betere migraties, betere rapportages en betere communicatie met gebruikers en stakeholders. De architectuur wordt minder afhankelijk van eenmalige analyse en meer van voortdurende reflectie. Kwaliteit wordt niet iets wat later nog een keer gerepareerd moet worden, maar iets wat methodisch wordt ingebouwd in de manier waarop software ontstaat.
Snelheid en kostenreductie zijn daarbij reële ondernemersvoordelen. Voor een softwarearchitect die ook business value, ROI en toekomstbestendigheid moet borgen, zijn die voordelen relevant: minder verspilling, betere voorspelbaarheid, minder herstelwerk, kortere feedbackloops en eerder zicht op risico's. Maar snelheid en kosten zijn afgeleiden. Ze zijn prettig, niet leidend. Als ze het primaire doel worden, gaat het mis.
Het risico: snelheid zonder discipline
Het grootste risico is het nieuwe normaal waarin AI wordt vertaald naar: sneller leveren, dus minder geduld voor kwaliteit. Dat is precies de verkeerde conclusie. AI zonder kwaliteitsdiscipline versnelt vooral de productie van ongefundeerde output. Slechte begrippen worden sneller verspreid. Zwakke modellen worden sneller geïmplementeerd. Oude vervuilde structuren worden sneller gereproduceerd. Documentatie klinkt overtuigender terwijl het model niet klopt. De snelheid van AI kan dan juist een kwaliteitsrisico worden, omdat slechte keuzes sneller institutioneel worden vastgezet.
De juiste conclusie is omgekeerd: omdat AI het werk versnelt, moet kwaliteit zwaarder worden verankerd. Niet als sluitpost, maar als vast onderdeel van de methode. ISO 25010 en ISO 25012 horen daarin samen thuis: productkwaliteit en datakwaliteit zijn onlosmakelijk verbonden zodra software processen en data formaliseert. Architectuur moet expliciet sturen op onderhoudbaarheid, betrouwbaarheid, security en usability, maar evenzeer op betekenis, volledigheid, consistentie, herleidbaarheid en begrijpelijkheid van data.
AI is daarmee geen truc om meer output te maken. Het is een middel om betere architectuur te bedrijven: preciezer luisteren, scherper benoemen, vaker herzien, eerder botsingen zien, oude vervuilde modellen durven loslaten, technische schuld voorkomen en software- én datakwaliteit dieper in het proces verankeren.
De waarde zit uiteindelijk niet in de snelheid waarmee gebouwd wordt, maar in de zorgvuldigheid waarmee wordt bepaald wat gebouwd moet worden. Software wordt gemaakt van code, maar organisaties leven in de begrippen die die code officieel maakt. Wie betere software wil bouwen, moet dus eerder beginnen: bij processen, bij data, bij betekenis, en bij de woorden die straks bepalen welke werkelijkheid het systeem nog kan zien.
Hoe Flowmesh dit aanpakt
Dit is geen vrijblijvende overtuiging, maar onze werkwijze. Wij toetsen domeinbegrippen vóór de bouw, niet erna. Wij hanteren ISO 25010 en ISO 25012 als één kwaliteitslens — productkwaliteit en datakwaliteit samen, omdat een technisch werkend systeem nog steeds de verkeerde werkelijkheid kan vastleggen. En wij herzien modellen iteratief in plaats van ze eenmalig vast te zetten, juist op het moment dat herzien nog goedkoop is. Zo betaalt u voor kwaliteit wanneer de blast radius klein is — niet wanneer hij door uw hele systeem is vertakt.