Voordat we onszelf "developers" noemden, hadden we een andere naam.
De verschuiving van Informatiesystemen naar Informatica naar Developer ging zo geleidelijk dat de meeste mensen zich niet eens herinneren dat er een keuze was. Het voelde onvermijdelijk, als vooruitgang. Maar het wás een keuze — een economische, gemaakt door universiteiten, de industrie en de markt. En dertig jaar lang trok die keuze ons weg van iets fundamenteel belangrijks.
In mijn ervaring denken de beste technische leiders met wie ik heb gewerkt allemaal op dezelfde manier: ze beginnen bij het bedrijfsprobleem, niet bij de code. Ze vragen welke informatie waarheen moet stromen, welke beslissingen ondersteuning nodig hebben, welke processen niet werken. Ze denken in systemen. Dat is geen toeval. Velen van hen studeerden Informatiesystemen, geen Informatica. Ze erfden een andere traditie.
Die traditie heeft een naam en een geschiedenis. En begrijpen waar die vandaan komt, verklaart zowel waarom AI op dit moment zo belangrijk is voor ons vak, als waarom velen van ons het gevoel hebben dat we eindelijk thuiskomen.
De systeemdenkers
Edward Yourdon was niet in de eerste plaats een programmeur. Hij was een systeemanalyist. Toen hij in de jaren zeventig en tachtig Structured Analysis and Design Technique ontwikkelde, was zijn doel niet om code te optimaliseren. Het was om te modelleren hoe bedrijven werkten, zodat systemen ontworpen konden worden die hen ondersteunden. Data Flow Diagrams waren geen mooie abstracties. Het waren communicatiemiddelen. Een businessanalist kon informatiestromen door een verkoopafdeling, een financieel team of een magazijnoperatie tekenen. Developers konden die diagrammen lezen en begrijpen wat ze moesten bouwen én waarom het ertoe deed.
James Martin breidde dit denken uit in de jaren tachtig met Information Engineering. Opnieuw was de focus glashelder: informatie is het artefact. Hoe stroomt het? Hoe wordt het getransformeerd? Hoe ondersteunt het besluitvorming? Vanuit die modellen volgden systemen. De informatie kwam eerst — filosofisch en praktisch.
In universitaire programma's door heel Noord-Amerika en Europa waren afdelingen Informatiesystemen serieuze plekken. Ze onderwezen bedrijfsprocesanalyse, datamodellering, systeemdenken. Ze leerden je dat een computersysteem in de kern een systeem is voor het verwerken van informatie ter ondersteuning van de doelen van een organisatie. Het "computer"-gedeelte was bijna bijzaak ten opzichte van het grotere doel.
Hier ligt de echte uitdaging van dat tijdperk: de economie klopte niet.
De kloof tussen die prachtige Data Flow Diagrams en daadwerkelijk draaiende code was enorm. CASE-tools (Computer-Aided Software Engineering) en MDA (Model Driven Architectures) beloofden die kloof te overbruggen. Teken het model, genereer de code. Zo werkte het bijna nooit. Hoe dichter je bij de implementatie kwam, hoe meer de werkelijkheid afweek van het model. Veranderingen in bedrijfsprocessen betekenden dat modellen bijgewerkt moesten worden. Updates aan modellen vereisten soms het herbouwen van systemen. De kosten om die afstemming in stand te houden groeiden sneller dan de waarde die het opleverde.
Tegen de jaren negentig begon de verschuiving bij universiteiten. Informaticaprogramma's groeiden. Ze onderwezen algoritmen, datastructuren, taalontwerp, optimalisatie. Praktische dingen. Dingen die rechtstreeks verbonden waren met een baan in softwareontwikkeling. Programma's voor Informatiesystemen kromp. Waarom zou je trage, dure analyse studeren als je kon leren programmeren? De markt sprak duidelijk: bouw sneller, itereer constant, vraag vergiffenis in plaats van toestemming.
Het vak volgde het geld. Tegen het begin van de jaren 2000 was "developer" de standaardidentiteit geworden. We stopten met onszelf te zien als analisten die informatiesystemen ontwerpen en werden ambachtslieden die code schrijven. De businessfocus verdween niet helemaal — het werd iemand anders' taak. Productmanagers, businessanalisten, stakeholders. De taak van het ontwikkelteam was om requirements aan te nemen en te implementeren. Snel.
De korte poging om het te herinneren
Eric Evans' Domain-Driven Design verscheen in 2003, en als je weet waar je op moet letten, is het een stille roep om te herinneren wat we vergeten waren. DDD plaatste het bedrijfsdomein centraal. Developers zouden het businessmodel diepgaand moeten begrijpen. Systemen zouden georganiseerd moeten worden rond hoe het bedrijf over zijn problemen denkt. Ubiquitous Language betekende dat bedrijfsterminologie en codeterminologie hetzelfde zouden moeten zijn.
Het was in essentie Informatiesystemen-denken toegepast op het tijdperk van objectgeoriënteerd programmeren.
Ironisch genoeg werd DDD nooit mainstream op de manier die het verdiende. Waarom? Opnieuw: economie. Systemen bouwen op de DDD-manier vereiste een aanzienlijke voorafgaande investering in het begrijpen van het bedrijf. Het vereiste developers die konden denken als businessanalisten. Het vereiste het onderhouden van die afstemming tussen domeinmodellen en code gedurende de hele levensduur van het systeem. Het werkte prachtig wanneer organisaties het zich konden veroorloven. Voor alle anderen voelde het als een luxe die ze niet konden volhouden.
Dus bleven we bouwen zoals we gewend waren. Snel, iteratief, requirements-gedreven. En we werden er heel goed in. Moderne architecturen, microservices, platformdenken — allemaal oprechte verbeteringen. Het tempo van oplevering versnelde. Maar er bleef iets hardnekkigs bestaan: de kloof tussen wat het bedrijf nodig had en wat we bouwden. Niet altijd catastrofaal. Maar merkbaar. Verkeerd begrepen requirements. Systemen die technisch werkten maar net niet pasten. De noodzaak om constant te refactoren omdat aannames waren veranderd.
De grondoorzaak was altijd dezelfde: we dachten niet meer als Informatiesystemen-professionals. We dachten als Informatica-professionals die probeerden bedrijfsproblemen op te lossen. Andere discipline. Andere tools. Ander startpunt.
Wat we werkelijk verloren
Begrijp het onderscheid goed. Informatica vraagt: Hoe laten we computers dingen efficiënt doen? Het is een rijke, belangrijke vraag. Algoritmen doen ertoe. Prestaties doen ertoe. Elegante oplossingen doen ertoe. We hebben mensen nodig die deze vragen stellen.
Informatiesystemen stelt een andere vraag: Wat moeten computers doen om dit bedrijf te ondersteunen? Het is niet minder technisch. Het is anders gericht. Het begint met informatiestromen, processen, beslissingen. Het denkt in termen van systeemgedrag, niet van computationele efficiëntie. Waar data vandaan komt. Waar het naartoe moet. Welke transformaties het ondergaat. Welke beslissingen ervan afhangen.
We zijn niet gestopt met het nodig hebben van IS-denken. We zijn alleen gestopt het zo te noemen, het systematisch te onderwijzen, het vak eromheen te organiseren. En decennialang betaalden we de prijs in verkeerd afgestemde systemen, mislukte implementaties en het constante gevoel dat technologie niet helemaal de juiste problemen oploste.
Wat we verloren was geen nostalgie naar SADT of CASE-tools. Die hoorden bij hun tijdperk, en moderne tools zijn objectief beter in het omgaan met complexiteit. Wat we verloren was het startpunt. We verloren de aanname dat het begrijpen van het bedrijf deel uitmaakte van je werk. Dat systeemdenken kern was van softwareontwikkeling. Dat het kunnen modelleren van informatiestromen en processen een professionele vaardigheid was, niet een taak voor de businessanalist.
Thuiskomen met betere tools
Dit is wat er veranderde: AI en moderne platformarchitecturen maakten de IS-aanpak eindelijk weer economisch haalbaar.
Bedenk wat er altijd ontbrak: de kloof tussen prachtige modellen en draaiende code, tussen bedrijfsrequirements en implementatie. Die kloof bestaat omdat het vertalen van modellen naar code duur is. Je hebt iemand nodig die slim genoeg is om beide domeinen te begrijpen en ertussen te vertalen. Dertig jaar lang was die persoon schaars en duur, dus namen we er minder van aan.
Stel je nu voor dat die kloof kleiner wordt. Stel je AI voor die kan deelnemen aan die vertaling. Bedrijfsdomeinmodellen uitgedrukt in meerdere vormen — tekstuele beschrijvingen, gestructureerde diagrammen, eventmodellen. Codegeneratoren die domeintaal begrijpen. Platformcapaciteiten die expliciet gebouwd zijn rond bedrijfsconcepten in plaats van technische primitieven. De economie verschuift onmiddellijk.
Moderne platformen (goede, tenminste) operationaliseren wat Yourdon en Evans altijd begrepen: bedrijfsmodellen moeten primaire artefacten zijn. Geen documentatie die uit sync raakt met code. Geen wegwerp-requirements geschreven in Word-documenten. De daadwerkelijke structuur van het systeem, zichtbaar en onderhoudbaar.
Wat te duur was, wordt praktisch. De IS-aanpak — beginnen bij bedrijfsinformatie en -processen, systemen eromheen ontwerpen, die afstemming onderhouden — wordt opnieuw economisch rationeel.
Erkenning, geen nostalgie
Dit is geen nostalgie naar de jaren tachtig. De tools waren oprecht beperkt. De snelheid was oprecht laag. Het vermogen om complexiteit te hanteren was oprecht begrensd. Moderne architectuur is beter. AI-mogelijkheden zijn revolutionair. Platformdenken is fundamenteel solide.
Maar de filosofie, het startpunt, was altijd juist.
Als je Informatiesystemen hebt gestudeerd, leerde je geen verouderde discipline. Je leerde iets dat uit de mode raakte om economische redenen, niet omdat het fout was. En nu veranderen die economische redenen.
Als je Informatica hebt gestudeerd en developer bent geworden, heb je iets oprecht waardevols geleerd: het ambacht om computers dingen te laten doen, efficiënt en betrouwbaar. Dat heb je nog steeds nodig. Dat zal altijd zo blijven.
Maar beide disciplines zijn nodig. De CS-traditie gaf ons snelheid en schaal. De IS-traditie stelde altijd de juiste vraag: welk probleem lossen we eigenlijk op?
We naderen eindelijk een tijdperk waarin we beide kunnen doen. Waarin nadenken over informatie en processen niet als overhead wordt behandeld, maar als het fundament van wat we bouwen. Waarin "developer" geleidelijk kan gaan betekenen: iemand die zowel code als bedrijfscontext begrijpt. Waarin AI een deel van de vertaallast overneemt die de IS-aanpak te duur maakte.
Herinner je je nog toen we het Informatiesystemen noemden? Herinner je je de aanname dat het begrijpen van het bedrijf van je klant — écht begrijpen — deel uitmaakte van het werk?
Hoe zou je carrière eruitzien hebben als de economie anders was geweest? Als het modelleren van bedrijfsprocessen en informatiestromen zo centraal was gebleven in softwareontwikkeling als het had moeten zijn?
We komen erachter. En het werd tijd.
