Jump to content

Openai/69457f3e-d040-8006-b78a-a23accaf6668

From freem


This conversation was exported from ChatGPT[1]

gpt-5-2[edit | edit source]

User: Graag een samenvatting van het artikel dat je hier kunt aantreffen:[edit | edit source]

Graag een samenvatting van het artikel dat je hier kunt aantreffen: https://www.computable.nl/2025/12/19/acict-duo-eindelijk-op-goede-weg-met-systeem-bekostiging/

Assistant: Hier is een samenvatting van het artikel over DUO en de systeem-bekostiging zoals gepubliceerd op Computable op 19 dece…[edit | edit source]

Hier is een samenvatting van het artikel over DUO en de systeem-bekostiging zoals gepubliceerd op Computable op 19 december 2025:

Het Adviescollege ICT-toetsing (AcICT) oordeelt dat de Dienst Uitvoering Onderwijs (DUO) eindelijk op de goede weg is met de heroriëntatie van het langlopende moderniseringsproject voor de bekostigingssystemen van onderwijsinstellingen, maar er blijven belangrijke verbeterpunten. Computable.nl[2][edit | edit source]
- DUO werkt al bijna vijf jaar aan het project Doorontwikkelen Applicatielandschap Bekostiging (DAB) om systemen te vernieuwen die de bekostiging van scholen en andere onderwijsinstellingen regelen. Computable.nl[3][edit | edit source]
  • In 2021 kreeg het project een zeer negatief oordeel van het toenmalige BIT (nu AcICT), dat DUO adviseerde radicaal te stoppen met de oorspronkelijke aanpak. Computable.nl[4]
DUO heeft belangrijke keuzes herzien:[edit | edit source]
  • Het schrappen van het destijds gekozen platform Blueriq en overstap naar nieuwbouw met Java. Computable.nl[5]
  • Gebruik van de ALEF-generator van de Belastingdienst voor automatisering van regels en berekeningen, met meer aandacht voor continuïteit en stapsgewijze vervanging van systemen. Computable.nl[6]

Het resultaat: het traject is minder problematisch dan voorheen en biedt nu een beheersbaardere aanpak. Computable.nl[7]

AcICT blijft kritisch en noemt verschillende zaken die nog moeten worden verbeterd:[edit | edit source]
  • Organisatiecultuur en risicobeheersing moeten beter worden ingebed; de nieuwe aanpak is technisch verbeterd maar organisatorisch kwetsbaar. Computable.nl[8]
  • Het architectuurproces van het systeemlandschap is onvoldoende uitgewerkt, wat toekomstige onderhoudbaarheid en schaalbaarheid belemmert. Computable.nl[9]
Het adviescollege geeft concrete aanbevelingen, waaronder:[edit | edit source]
  • Beter vastleggen en beschrijven van de huidige én gewenste architectuur als geheel. Computable.nl[10]
  • Actiever zorgen voor tegengeluid en inhoudelijke discussies over architectuurkeuzes – met besluiten op directieniveau waar nodig. Computable.nl[11]
  • Terugdraaien van risicovolle keuzes (zoals eigen bouw van tools) en nadruk leggen op bewezen componenten zoals ALEF. Computable.nl[12]
  • Interne expertise versterken in plaats van afhankelijk zijn van externe krachten. Computable.nl[13]
AcICT benadrukt dat de grootste uitdagingen niet technologisch zijn, maar in de organisatiecultuur zitten – en dat de voltooiing van dit megaproject waarschijnlijk pas rond 2032 zal plaatsvinden. Computable.nl[14][edit | edit source]

Wil je een uitgebreide opsomming van de aanbevelingen of een duidelijk tijdpad van hoe DUO hier is gekomen en wat er daarna nog moet gebeuren?

User: Nu verschijnt op dit artikel de volgende reactie:[edit | edit source]

Nu verschijnt op dit artikel de volgende reactie:

whatever, gaat erom dat er niet iets met SOA, 5GL of beslissingstabellen wordt ingevoerd. Gelukkig geeft good-old Javatechnologie gecombineerd met iets met Agile goede hoop. Veel herorientatie ook. Das altijd mooi. Weet je wat, doe gelijk maar “een andere technologie” 😛

“Een ander zwak punt is het architectuurproces. De onderhoudbaarheid van het toekomstig landschap wordt bemoeilijkt door een gebrekkige opzet daarvan. Een passende architectuur biedt structuur en is de drager van systeemkwaliteiten als schaalbaarheid, aanpasbaarheid en beveiliging. Het proces om tot die architectuur te komen moet daarom worden verbeterd.”

Wat een taal. “Wordt bemoeilijkt door een gebrekkige opzet daarvan.” Zucht In gewoon Nederlands: Het deugt niet omdat het allemaal verrot is. enneEueehh, moet allemaal beter. ..

Net een analyse van een voetballer meteen na een slechte wedstrijd, waar die tegengoal die het niets kwam nooit had mogen gebeuren en dat ze daarna achter de feiten aanliepen. Hoe dat kan, we moeten het nog eens analyseren..

Nog ff Geduld, dankzij die wendbare ALEF generator is het 2032 alweer klaar. Zeggen ze dan..

Graag een analyse.

Assistant: Hier is een analyse van de reactie, op het niveau van retoriek, houding en impliciete aannames dus niet feitelijk-techn…[edit | edit source]

Hier is een analyse van de reactie, op het niveau van retoriek, houding en impliciete aannames (dus niet feitelijk-technisch, maar hermeneutisch — aansluitend bij jouw voorkeur voor retorische valsheid).

De reactie is consequent ironisch en licht sarcastisch van toon:[edit | edit source]

  • “whatever”, “gelukkig”, “das altijd mooi”, “zeggen ze dan”
  • Emoji 😛 versterkt de afstand en het niet-serieus-nemen

👉 Dit is geen poging tot inhoudelijke weerlegging, maar een affectieve positionering:

Dat is op zichzelf een begrijpelijke reactie op bestuurlijk-technocratische taal, maar het blokkeert ook eigen precisie.

De schrijver reduceert het artikel tot een technologisch smaakconflict:[edit | edit source]

  • SOA, 5GL, beslissingstabellen → “gelukkig niet”
  • Java + Agile → “good-old”, “geeft hoop”
  • ALEF → “wendbaar”, maar met hoorbare spot

Dit is een retorische versimpeling:

  • Architectuurproblemen worden voorgesteld als modegrillen
  • Alsof eerdere mislukkingen vooral veroorzaakt zijn door verkeerde buzzwords

👉 Daarmee verdwijnt de structurele kritiek van AcICT (governance, besluitvorming, architectuurproces) uit beeld.

Het geciteerde AcICT-fragment wordt taalkritisch gefileerd:[edit | edit source]

De reactie vertaalt dit scherp naar:

Hier raakt de schrijver wel degelijk een kern:

  • De AcICT-taal is depersonaliserend, procesmatig en verantwoordelijkheidsloos
  • Niemand doet iets fout; “het wordt bemoeilijkt”

👉 Dit is een klassiek probleem van ambtelijke waarheidsproductie: taal die problemen erkent zonder iemand aanspreekbaar te maken.

De vergelijking met een voetbalinterview is zeer raak:[edit | edit source]

  • “Die tegengoal had nooit mogen gebeuren”
  • “We liepen achter de feiten aan”
  • “We moeten het analyseren”

Dit benoemt een ritueel van schijnreflectie:

  • Er is erkenning van falen
  • Maar geen nieuwe inzichten, breuk, of verantwoordelijkheid

👉 De reactie suggereert:

Dat is een sterke hermeneutische observatie.

:[edit | edit source]

Hier wordt de tijdsdimensie gebruikt als delegitimatie:

  • “Wendbaarheid” ↔ zeven jaar resterende doorlooptijd
  • Innovatietaal ↔ uitgestelde realiteit

👉 Dit ondermijnt precies het kernverhaal van het artikel: voorzichtig optimisme.

Volgens jouw eigen criterium (hermeneutische eerlijkheid), zou ik zeggen:[edit | edit source]

- Ontmaskering van leeg bestuurlijk taalgebruik[edit | edit source]
  • Herkenning van rituele evaluaties
  • Wantrouwen tegenover techno-optimisme zonder breukmoment
- Karikatuur van architectuurkritiek als “technologiewissel”[edit | edit source]
  • Geen onderscheid tussen: - ALEF als hulpmiddel - en het falen van besluitvorming en architectuurproces
  • Cynisme vervangt analyse

👉 De reactie zegt iets echts, maar denkt het niet uit.

Deze reactie is:[edit | edit source]

  • ❌ geen inhoudelijke tegenanalyse
  • ✔ wel een symptoomanalyse van bestuursretoriek
  • ⚠️ maar gevangen in ironie, waardoor ze niet productief wordt

Of scherper geformuleerd (in jouw register):

Als je wilt, kan ik:

  • deze reactie herformuleren tot een sterke inhoudelijke kritiek, of
  • haar plaatsen binnen een Heideggeriaanse analyse van techniek en bestuurlijk spreken, of
  • expliciet verbinden met jouw eerdere ALEF-kritiek (ontologie vs. regelmachine).

User: Heb je ook nog een cijfer op de schaal van valsheid?[edit | edit source]

Heb je ook nog een cijfer op de schaal van valsheid?

Assistant: Ja.[edit | edit source]

Ja. Op jouw schaal van valsheid (retorische, hermeneutische valsheid — niet feitelijk) zou ik deze reactie het volgende cijfer geven:

###[edit | edit source]

Waarom niet hoger (dus niet “zeer vals”)?

  • De reactie doorziet terecht: - het lege, ritualistische karakter van bestuurlijke evaluatietaal; - de afwezigheid van verantwoordelijkheid in formuleringen als “wordt bemoeilijkt door”; - de voorspelbaarheid van techno-optimisme met lange tijdshorizonten.
  • Ze is existentiëel eerlijk in haar irritatie: het wantrouwen is niet gespeeld.

Waarom ook niet lager (dus niet “waarachtig”)?

  • De kritiek blijft steken in ironische afstand.
  • Architectuurkritiek wordt gereduceerd tot technologie-mode (Java vs. SOA vs. ALEF).
  • Cynisme vervangt onderscheid: - geen analyse van waar het architectuurproces faalt, - geen normatief criterium voor wat “deugt” zou betekenen.
  • De spreker neemt geen risico: alles wordt vooraf geneutraliseerd door spot.
:[edit | edit source]

Of nog scherper:

  • Morele intuïtie: aanwezig
  • Conceptuele precisie: afwezig
  • Verantwoordingsbereidheid: laag

Daarom: 6/10 — herkenbaar, raak, maar uiteindelijk te comfortabel ironisch om werkelijk waarachtig te zijn.

User: Ok, er is door een andere persoon een volgende reactie opgevoerd:[edit | edit source]

Ok, er is door een andere persoon een volgende reactie opgevoerd:

Waarom eerst nog de doodlopende weg inslaan die ALEF heet?

“je intuïtie klopt op twee punten tegelijk:

  1. regelmachines exploderen in complexiteit, en
  2. ALEF heeft inderdaad géén expliciete ontologie “

Graag weer een analyse en cijfer.

Assistant: Hier is opnieuw een analyse op hermeneutisch/retorisch niveau, gevolgd door een cijfer op jouw schaal van valsheid.[edit | edit source]

Hier is opnieuw een analyse op hermeneutisch/retorisch niveau, gevolgd door een cijfer op jouw schaal van valsheid.

In tegenstelling tot de vorige reactie is deze:[edit | edit source]

  • veel compacter
  • minder ironisch
  • inhoudelijk explicieter

De openingszin:

is normatief en risicovol: de spreker neemt een standpunt in dat falsifieerbaar is. Dat is hermeneutisch al een winst.

De aanhalingstekens en de formulering “je intuïtie klopt op twee punten tegelijk” doen twee dingen:[edit | edit source]

  1. Ze verankeren de uitspraak in een eerder betoog (kennelijk een discussie over ALEF).
  2. Ze positioneren de spreker niet als roeper, maar als iemand die een reeds ontwikkeld inzicht samenvat.

Dat geeft de reactie epistemische ernst: ze pretendeert niet alles nieuw te zeggen, maar iets te bevestigen.

De twee punten zijn inhoudelijk sterk geformuleerd:[edit | edit source]

- Dit is een structurele kritiek, geen smaakverschil.[edit | edit source]
  • Impliceert: - combinatorische explosie, - ondoorzichtigheid, - verlies van beheersbaarheid.
  • Sluit direct aan bij bekostigingslogica, uitzonderingen, overgangsregimes.

Dit punt raakt de kern van waarom eerdere trajecten faalden.

Dit is het meest wezenlijke punt, zeker in het licht van jouw eerdere opmerkingen:[edit | edit source]
  • Geen expliciete ontologie betekent: - geen expliciet begrip van wat er is (entiteiten, relaties, statussen), - alleen procedures en transformaties.
  • Daardoor: - betekenis ontstaat pas in uitvoering, - niet in een gedeelde, toetsbare wereldbeschrijving.

👉 Dit is geen technisch bezwaar, maar een filosofisch-architectonisch bezwaar.

Impliciet wordt hier iets belangrijks blootgelegd:[edit | edit source]

  • AcICT spreekt over: - onderhoudbaarheid, - architectuurproces, - systeemkwaliteiten.
  • Deze reactie benoemt waarom die problematisch blijven: - omdat zonder ontologie architectuur procedureel blijft, - en dus niet normatief richtinggevend kan zijn.

Dit is precies de ontbrekende schakel in veel ICT-rapporten.

De reactie is sterk, maar niet af:[edit | edit source]

  • “Doodlopende weg” wordt niet verder onderbouwd: - Is het doodlopend per definitie? - Of alleen bij deze schaal en governance?
  • Ontologie wordt genoemd, maar niet gespecificeerd: - domeinontologie? - juridische ontologie? - bekostigingsontologie?

Dit is geen valsheid, maar onafheid.

###[edit | edit source]

✔ Hermeneutisch waarachtig[edit | edit source]
  • Neemt een expliciet standpunt in.
  • Benoemt structurele oorzaken, geen symptoombestrijding.
  • Vermijdt ironische distantie.
  • Sluit aan bij eerdere doordenking (continuïteit van inzicht).

⚠️ Beperkingen

  • Compactheid laat veel impliciet.
  • Vereist voorkennis bij de lezer.

Maar: dat zijn geen retorische trucs, eerder tekenen van inhoudelijke concentratie.

:[edit | edit source]

In jouw register:

  • Intuïtief juist
  • Conceptueel raak
  • Retorisch sober

Daarom: 3/10 valsheid — dicht bij hermeneutische eerlijkheid.

User: En dan is er nog een derde reactie van weer een ander persoon:[edit | edit source]

En dan is er nog een derde reactie van weer een ander persoon:

Het enige wat je nodig hebt is een goede “general purpose” programmeertaal en een message queue.

En liefst een gecompileerde programmeertaal zoals C++ of Rust. Maar JIT talen zoals C# en Java zijn ook acceptabel. Iedereen die Python of JavaScript voorstelt moet er meteen uitvliegen.

Qua architectuur moet het gewoon een monoliet zijn. Geen microservices of CQRS.

Ook weer graag een analyse.

Assistant: Hier is opnieuw een hermeneutische analyse, in dezelfde lijn als eerder — en ik voeg ook een cijfer op de schaal van va…[edit | edit source]

Hier is opnieuw een hermeneutische analyse, in dezelfde lijn als eerder — en ik voeg ook een cijfer op de schaal van valsheid toe, omdat dit nu impliciet onderdeel van het spel is geworden.

Deze reactie is radicaal normatief:[edit | edit source]

  • “Het enige wat je nodig hebt…”
  • “moet het gewoon…”
  • “Iedereen die X voorstelt moet eruit vliegen”

Dit is geen analyse, maar een beslissingsretoriek: de spreker presenteert zich als iemand die boven het debat staat.

Hermeneutisch gezien is dit een sluitende houding: het gesprek wordt beëindigd in plaats van geopend.

De kernclaim is:[edit | edit source]

Dat blijkt uit:

  • focus op programmeertalen (C++, Rust, Java, C#)
  • afwijzing van andere talen op quasi-morele gronden
  • reductie van architectuur tot monoliet vs microservices

👉 Dit is technisch essentialisme: alsof falen en slagen primair voortkomen uit taalkeuze en deploymentstijl.

Daarmee wordt alles wat AcICT juist problematiseert — besluitvorming, veranderlijkheid van wetgeving, semantiek van bekostiging — buiten beeld gehouden.

De pleidooi voor:[edit | edit source]

  • monoliet
  • message queue
  • compiled languages

is niet onzinnig op zichzelf. Integendeel:

  • het is een reactie tegen over-engineering;
  • het weerspiegelt ervaring met falende microservices.

Maar hermeneutisch gebeurt hier iets belangrijks:

👉 Complexiteit wordt verplaatst van het domein naar de techniek in plaats van begrepen als inherent aan de werkelijkheid (bekostiging, recht, uitzonderingen).

De monoliet wordt zo een mythisch object:

Dat is precies de illusie die eerdere generaties systemen óók hadden.

In contrast met de tweede reactie:[edit | edit source]

  • Geen enkel woord over: - wat het systeem is, - welke entiteiten bestaan, - hoe juridische betekenis wordt vastgelegd.
  • Alles is: - uitvoering, - performance, - discipline.

👉 Daarmee bevestigt deze reactie onbedoeld de kritiek op ALEF: ook hier is er geen expliciete ontologie, alleen een uitvoeringsideaal.

Ironisch genoeg staat deze reactie dus dichter bij ALEF-denken dan haar auteur vermoedelijk wil.

Zinnen als:[edit | edit source]

zijn hermeneutisch problematisch:

  • Ze vervangen argumentatie door loyaliteitstoetsing.
  • Ze creëren een ingroup van “echte engineers”.
  • Ze suggereren dat falen veroorzaakt wordt door domme mensen i.p.v. door structurele omstandigheden.

👉 Dit is retorische agressie vermomd als pragmatisme.

Positief (en dat telt):[edit | edit source]

  • Er spreekt ervaring uit.
  • Er is weerzin tegen modieuze architecturen.
  • Er is een verlangen naar: - stabiliteit, - eenvoud, - beheersbaarheid.

Maar: dit verlangen wordt niet doordacht, slechts geproclameerd.

###[edit | edit source]

❌ Hermeneutisch onwaarachtig[edit | edit source]
  • Sluit betekenis af in plaats van haar te ontsluiten.
  • Verwisselt technische discipline met waarheid.
  • Doet alsof complexiteit een keuze is, geen gegeven.
  • Ontkent impliciet de normatieve dimensie van het domein.

✔ Niet maximaal vals

  • Geen ironie of cynisme.
  • Oprechte overtuiging.
  • Ervaring als bron.

Maar overtuiging ≠ waarachtigheid.

:[edit | edit source]

In jouw termen:

  • Retorisch krachtig
  • Hermeneutisch arm
  • Ontologisch leeg

Daarom: 7,5/10 valsheid — overtuigend gebracht, maar fundamenteel reductionistisch.

Als je wilt, kan ik deze drie reacties:

  • naast elkaar leggen in één schema,
  • of expliciet verbinden met Heidegger: Gestell vs. wereldontsluiting,
  • of herformuleren tot één inhoudelijk serieuze tegenkritiek op het AcICT-rapport.

User: naast elkaar leggen in één schema[edit | edit source]

naast elkaar leggen in één schema

Assistant: Hier is een schema waarin de drie reacties expliciet naast elkaar worden gelegd, langs dezelfde hermeneutische assen.[edit | edit source]

Hier is een schema waarin de drie reacties expliciet naast elkaar worden gelegd, langs dezelfde hermeneutische assen. Dit maakt zichtbaar waar ze elkaar raken, waar ze elkaar missen, en waar het debat ontspoort.

| | | | |[edit | edit source]

| --- | --- | --- | --- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Je ziet hier drie fundamenteel verschillende manieren om met falen om te gaan:[edit | edit source]

  1. Reactie 1 zegt: “Ik doorzie het spel en doe niet meer mee.” → scherp, maar steriel.
  2. Reactie 2 zegt: “Hier ontbreekt een wereldbeschrijving; dáárom ontspoort alles.” → inhoudelijk dragend.
  3. Reactie 3 zegt: “Stop met denken, begin met discipline.” → daadkrachtig, maar blind.

Hermeneutisch gezien is reactie 2 de enige die werkelijk ontsluit: zij benoemt wat er ontbreekt zonder het gesprek te sluiten.

- Reactie 1: 6 / 10[edit | edit source]

  • Reactie 2: 3 / 10
  • Reactie 3: 7,5 / 10

Of in één zin:

Als je wilt, kan ik dit schema ook:

  • herleiden tot één kernconflict (ontologie vs. uitvoering),
  • of expliciet Heideggeriaans duiden (Gestell, wereld, spreken),
  • of omzetten in een inhoudelijk weerwoord op het AcICT-discours.

User: Hoe waardeer je de 3 reacties inhoudelijk ten aanzien van wat gesteld wordt in het hoofdartikel?[edit | edit source]

Hoe waardeer je de 3 reacties inhoudelijk ten aanzien van wat gesteld wordt in het hoofdartikel?

Kun je hier ook cijfers voor geven?

Assistant: Hier is een inhoudelijke waardering van de drie reacties ten opzichte van het hoofdartikel het AcICT-oordeel over DUO/D…[edit | edit source]

Hier is een inhoudelijke waardering van de drie reacties ten opzichte van het hoofdartikel (het AcICT-oordeel over DUO/DAB), los van toon of retoriek. Dus: in hoeverre raken ze feitelijk en conceptueel wat het artikel zelf stelt en problematiseert?

Ik sluit af met cijfers per reactie.

Referentiekader: wat stelt het hoofdartikel inhoudelijk?[edit | edit source]

Samengevat zegt het artikel (en het AcICT-rapport):

  1. DUO is technisch rustiger vaarwater ingeslagen (af van Blueriq, meer stapsgewijs).
  2. ALEF wordt gezien als bewezen hulpmiddel, mits verstandig ingezet.
  3. De grote zwakte zit niet primair in technologie, maar in: - architectuurproces, - besluitvorming, - borging van onderhoudbaarheid, - en organisatorische volwassenheid.
  4. Architectuur wordt expliciet benoemd als drager van systeemkwaliteiten, maar: - het proces om die architectuur te ontwikkelen schiet tekort.
  5. De risico’s zijn structureel en langdurig (doorlooptijd tot ~2032).

Dit is het ijkpunt.

Reactie 1 – Ironisch cynisme[edit | edit source]

Inhoudelijke relatie tot het artikel[edit | edit source]
  • ✔ Raakt terecht: - de leegte en ritualisering van bestuurlijke taal; - het spanningsveld tussen “wendbaarheid” en extreem lange doorlooptijd.
  • ❌ Mist: - onderscheid tussen technische verbetering en organisatorisch falen; - de kern van AcICT’s architectuurkritiek.
  • ❌ Zet ALEF weg als hype, terwijl het artikel juist voorwaardelijk positief is.
Inhoudelijke waarde[edit | edit source]

Deze reactie leest het artikel vooral als genre, niet als analyse. Ze bekritiseert hoe er gesproken wordt, maar nauwelijks wat er wordt vastgesteld.

Cijfer (inhoudelijk t.o.v. artikel)[edit | edit source]

5 / 10

Begrijpt de sfeer en de zwakte van het discours,
maar mist de analytische kern van het rapport.

Reactie 2 – Ontologische kritiek op ALEF[edit | edit source]

Inhoudelijke relatie tot het artikel[edit | edit source]
  • ✔ Sluit direct aan op het architectuurprobleem: - waarom blijft onderhoudbaarheid problematisch? - waarom explodeert complexiteit?
  • ✔ Verheldert iets wat het artikel niet expliciet benoemt, maar wel impliceert: - architectuur zonder ontologie blijft procedureel en fragiel.
  • ⚠️ Gaat verder dan het artikel: - noemt ALEF principieel “doodlopend”, terwijl AcICT dat niet zo stelt.
Inhoudelijke waarde[edit | edit source]

Deze reactie is niet volledig in lijn met het artikel, maar verdiept het. Ze levert een verklarend kader voor precies de zwakte die AcICT signaleert.

Cijfer (inhoudelijk t.o.v. artikel)[edit | edit source]

8 / 10

Niet letterlijk wat er staat,
maar inhoudelijk het meest verklarend voor waarom AcICT gelijk heeft.

Reactie 3 – Technisch absolutisme (monoliet + taalkeuze)[edit | edit source]

Inhoudelijke relatie tot het artikel[edit | edit source]
  • ❌ Gaat langs het kernprobleem heen: - AcICT bekritiseert geen programmeertalen; - ook microservices vs monoliet is geen centraal punt.
  • ❌ Negeert: - governance, - architectuurproces, - betekenismodellering.
  • ✔ Sluit alleen zijdelings aan bij: - kritiek op over-engineering (impliciet aanwezig in rapport).
Inhoudelijke waarde[edit | edit source]

Deze reactie projecteert een ander debat op het artikel: een engineering-cultuuroorlog die het rapport juist probeert te vermijden.

Cijfer (inhoudelijk t.o.v. artikel)[edit | edit source]

3 / 10

Technisch herkenbaar,
maar inhoudelijk grotendeels irrelevant voor wat AcICT daadwerkelijk zegt.

Overzicht in één tabel[edit | edit source]

| Reactie | Inhoudelijke aansluiting op artikel | Cijfer | | ----------------------- | ----------------------------------- | ------ | | Reactie 1 – ironisch | Raakt discours, mist analyse | 5 / 10 | | Reactie 2 – ontologisch | Verdiept architectuurkritiek | 8 / 10 | | Reactie 3 – technisch | Projecteert ander probleem | 3 / 10 |

Eindobservatie (belangrijk)[edit | edit source]

Wat hier zichtbaar wordt, is iets fundamenteels:

Het hoofdartikel probeert het debat te verplaatsen
van technologie naar architectuur en besluitvorming.
  • Reactie 1 blijft steken in retorische kritiek.
  • Reactie 3 valt terug naar technische zekerheden.
  • Alleen reactie 2 beweegt in dezelfde richting als het rapport, maar dan radicaler.

Als je wilt, kan ik dit nog:

  • expliciet koppelen aan AcICT-rapporttaal vs. werkelijkheid,
  • of omzetten in een inhoudelijk sterk LinkedIn-commentaar dat boven deze reacties uitstijgt.

References[edit | edit source]

  1. "Samenvatting artikel DUO systeem". ChatGPT. Retrieved 2025-12-20.
  2. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  3. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  4. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  5. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  6. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  7. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  8. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  9. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  10. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  11. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  12. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  13. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
  14. "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.