# 01 — Objectief oordeel + verifieerbare bronnen

> Christian heeft expliciet gevraagd om een **onafhankelijk, objectief oordeel** op zijn stelling, mét verifieerbare bronnen. Dit document is dat oordeel. Het is niet bedoeld om Christian "gelijk te geven" — alleen wat aantoonbaar uit gevestigde literatuur en praktijk volgt wordt bevestigd; nuances en correcties worden expliciet benoemd.

## 1. De stelling van Christian, scherp samengevat

> *"Schiet niet in technische oplossingen — zeker niet met AI. Begin met een functioneel ontwerp op menselijk niveau. Werk eerst uit hoe je het zou doen met (gratis) mensen. Pas daarna: hoe kunnen AI-agents (delen van) die taken overnemen? Werk eerst op enterprise-architectuur-niveau, daarna IT-architectuur. Leg alles expliciet en deterministisch vast."*

Vier ladingen zitten hierin:

| # | Stelling | Aard |
|---|----------|------|
| S1 | Solution-jumping (vooral naar techniek/AI) is fout | proces-principe |
| S2 | Functioneel ontwerp vóór technisch ontwerp; problem-framing vóór oplossingsruimte | methode-principe |
| S3 | "Stel je voor dat je gratis mensen kon aannemen" als heuristiek vóór agent-ontwerp | denkoefening |
| S4 | Alles expliciet, deterministisch, in één repository | governance-principe |

## 2. Oordeel per stelling

### S1 — Solution-jumping is fout — **EENS, met nuance**

**Onderbouwing:**
- Solution-jumping (ook wel *premature solutioning*, *fix-first bias*, *technische tunnel-visie*) is in de probleemoplossingsliteratuur sinds de jaren '80 beschreven als hardnekkig antipatroon. Donald Gause & Gerald Weinberg behandelen dit in *Are Your Lights On? How to Figure Out What the Problem Really Is* (1990) — de hele eerste helft van het boek gaat over "what's the problem?" als kernvraag die in de praktijk wordt overgeslagen.
- In Design Thinking (IDEO, Stanford d.school) is "double diamond" — eerst probleem-divergeren/convergeren, dán oplossing-divergeren/convergeren — een van de canonieke proces-modellen juist om dit te voorkomen.
- In Lean problem-solving (Toyota's *A3 thinking*) is "huidige toestand → ideale toestand → root cause → tegenmaatregel" een verplichte volgorde. *Eskes/Liker, The Toyota Way*.

**Nuance:** "Nooit techniek-eerst" is **te absoluut**.
- Lean Startup (Eric Ries, 2011) introduceert de *spike* / *technische probe*: een korte, expliciet leerend-bedoelde technische verkenning om haalbaarheid te toetsen. Mits er een leerhypothese onder ligt is dit géén solution-jumping.
- In AI specifiek geldt: soms is een snel proof-of-concept (POC) goedkoper dan een lange functionele analyse om vast te stellen of een capability überhaupt bestaat. De fout zit niet in *techniek aanraken*, maar in *techniek committeren* zonder probleemdefinitie.

→ Scherpere formulering: "Schiet niet in **technische commitments** voordat probleem en oplossingsruimte gedeeld zijn. Korte, time-boxed technische verkenningen mét leerdoel zijn toegestaan en soms wenselijk."

**Bronnen:**
- Gause, D. & Weinberg, G., *Are Your Lights On?*, Dorset House, 1990.
- Ries, E., *The Lean Startup*, Crown Business, 2011.
- Liker, J., *The Toyota Way*, McGraw-Hill, 2004.
- IDEO Design Thinking — designthinking.ideo.com
- Stanford d.school — dschool.stanford.edu

### S2 — Functioneel vóór technisch; enterprise vóór IT — **EENS, dit is de standaard**

**Onderbouwing:**
- **TOGAF Standard (The Open Group, versie 10, 2022)** schrijft de ADM-cyclus voor: A *Vision* → B *Business Architecture* → C *Information Systems Architectures* → D *Technology Architecture* → E *Opportunities & Solutions* → F *Migration Planning* → G/H. Business gaat aantoonbaar vóór technologie.
- **Zachman Framework** (John Zachman, 1987, actueel 3.0) ordent zes rijen: Scope (Contextual) → Business → System → Technology → Component → Operations. De stelling "eerst business, dan technologie" is hier letterlijk de y-as.
- **Dragon1 framework** (Mark Paauwe, dragon1.com) hanteert vier niveaus: *Conceptueel → Logisch → Fysiek → Implementatie*, en stelt expliciet dat conceptueel en logisch ontwerp leveranciers-onafhankelijk en techniek-onafhankelijk moeten zijn. Dit is precies wat Christian bedoelt met "enterprise-architectuur vóór IT-architectuur".
- **ArchiMate 3.2 (The Open Group, 2023)** modelleert in drie lagen: Business → Application → Technology — met de relatie *realiseert* van onder naar boven; de business-laag is causaal primair.

**Nuance:** Wat in de literatuur niet wordt verzwegen, en in Christians stelling ondergesneeuwd raakt:
- Strikt sequentieel werken (eerst alle business af, dan pas technologie) creëert *analysis paralysis* en is in moderne praktijk (agile, continuous architecture) verlaten ten gunste van *iteratief mét primaat van business*. De volgorde geldt per epic/feature, niet per heel programma.
- **Conway's Law** (Mel Conway, 1968, "How Do Committees Invent?"): de structuur van wat je bouwt weerspiegelt de communicatiestructuur van wie het bouwt. Dit ondersteunt Christians punt: tech-first bouwen produceert een systeem dat de organisatie niet bedient, omdat de organisatie nooit eerst tot gedeelde taal kwam.

**Bronnen:**
- The Open Group, *TOGAF Standard, 10th Edition*, 2022 — opengroup.org/togaf
- Zachman, J., *A Framework for Information Systems Architecture*, IBM Systems Journal, 1987.
- Paauwe, M., Dragon1 framework — dragon1.com
- The Open Group, *ArchiMate 3.2 Specification*, 2023 — opengroup.org/archimate
- Conway, M., "How Do Committees Invent?", *Datamation*, April 1968.
- **Gartner Business Architecture** — Gartner research notes "Business Architecture Connects Business Strategy to Execution"; "Business-Outcome-Driven Enterprise Architecture" (BODEA) framework — gartner.com (toegevoegd na vermelding door Christian in WhatsApp aan Peter, 2026-06-12 09:59).
- **BABOK Guide v3** — IIBA, *A Guide to the Business Analysis Body of Knowledge*, 2015 — iiba.org. Hoofdstuk 3 (Business Analysis Planning) en 5 (Requirements Analysis and Design Definition) onderschrijven probleem-eerst, oplossing-later (toegevoegd na vermelding door Christian).

### S3 — "Stel je voor: gratis mensen" als pre-agent denkoefening — **EENS, productieve heuristiek**

**Onderbouwing:**
- Het opzettelijk wegnemen van een schaarste-constraint om denken vrij te maken is een gevestigde techniek uit creatief probleemoplossen: *TRIZ "ideal final result"*, *Disney's "wishful thinking" methode*, *unconstrained design* in human-centered design.
- Specifiek voor knowledge work en automatisering is dit bekend als de *"if we had infinite junior staff" thought experiment*. Het dwingt expliciet uitspreken: WAT zou er gebeuren, los van WIE (mens of agent) het doet. Daarmee scheidt het *werk-ontwerp* van *werk-allocatie*.
- Dit is precies de volgorde die Anthropic aanbeveelt in *Building Effective Agents* (december 2024): "find the simplest solution possible, and only increase complexity when needed" — wat in praktijk neerkomt op: definieer het werk, kies dan de eenvoudigste agent-structuur die het werk doet (vaak: een prompt-chain of een workflow, géén autonome agent).
- In de Knowledge Elicitation literatuur (zie ook S4) wordt het werk eerst gemodelleerd als *task-flow tussen rollen* (Cognitive Task Analysis — Crandall, Klein, Hoffman, *Working Minds*, 2006). Wie de rol vervult (mens, software, agent) is een tweede beslissing.

**Nuance:** Gratis mensen zijn **niet 1-op-1 vervangbaar** door AI-agents.
- Mensen brengen judgment, ethiek, common sense en escalatie-intuïtie mee die agents (nog) niet hebben.
- Mensen hebben coördinatie-overhead (vergaderingen, miscommunicatie) die agents niet hebben — maar agents hebben weer monitoring- en correctie-overhead.
- De waarde van de oefening zit in het uitspreken van *taken en interacties*, niet in 1-op-1 vertaling.

**Bronnen:**
- Anthropic, *Building Effective Agents*, december 2024 — anthropic.com/engineering/building-effective-agents
- Crandall, B., Klein, G., Hoffman, R., *Working Minds: A Practitioner's Guide to Cognitive Task Analysis*, MIT Press, 2006.
- Altshuller, G., *The Innovation Algorithm* (TRIZ), 1999.

### S4 — Alles expliciet, deterministisch, in één repository — **EENS, mits niet absoluut**

**Onderbouwing:**
- "Single Source of Truth" is een gevestigd principe in zowel software engineering (Git-based monorepos, Pragmatic Programmer's *DRY*) als enterprise architectuur (Zachman: *one fact, one place*).
- Voor AI/agent-systemen specifiek is determinisme een actief onderzoeksveld: zonder vastliggende prompts, instructies, contextbronnen en evaluatie-criteria zijn agent-uitkomsten niet reproduceerbaar. Anthropic noemt dit expliciet in agent-documentatie. Zie ook OpenAI's *Evals* framework en de praktijk van *prompt versioning*.
- Christians keuze voor **vectorgraphics + YAML/JSON-data** is methodologisch verstandig: het scheidt *inhoud* (data) van *presentatie* (renderer), wat iteratie deterministisch maakt. Dit is conceptueel hetzelfde als *infrastructure-as-code* en *diagram-as-code* (PlantUML, Mermaid, Structurizr DSL — laatste is door Simon Brown ontworpen voor C4-architectuur en expliciet bedoeld voor deterministische diagrammen).

**Nuance:**
- "Alles expliciet vastleggen" kan ontaarden in over-documentatie. *Agile Manifesto*: "working software over comprehensive documentation". Het juiste niveau van vastlegging is *zo expliciet als nodig om gedeelde betekenis te garanderen* — niet meer.
- Determinisme bij LLM-output is fundamenteel beperkt (temperature > 0, model-updates door provider). Wat je deterministisch kunt maken zijn de *inputs* (prompts, context, tools, evaluatie-criteria) en de *grenzen* van geaccepteerde outputs.

**Bronnen:**
- Brown, S., *The C4 model for visualising software architecture* — c4model.com en Structurizr DSL.
- Hunt, A. & Thomas, D., *The Pragmatic Programmer*, 1999 (DRY-principe).
- Beck, K. et al., *Agile Manifesto*, 2001 — agilemanifesto.org
- OpenAI Evals — github.com/openai/evals

## 3. Synthese

| Stelling | Oordeel | Sterk advies |
|---|---|---|
| S1 — geen solution-jumping | EENS met nuance | "Nooit techniek-eerst" → vervang door "geen techniek-**commitment** zonder probleem-definitie; time-boxed POCs zijn ok" |
| S2 — functioneel vóór technisch, enterprise vóór IT | EENS — dit is de gevestigde standaard | Werk iteratief, niet sequentieel-watervalachtig |
| S3 — gratis-mensen-heuristiek | EENS — productieve denkoefening | Vertaal niet 1-op-1; gebruik om *werk* van *werker* te scheiden |
| S4 — expliciet & deterministisch in repo | EENS met nuance | Documentatie volgt inzicht; vastlegging is middel, niet doel |

## 4. Specifieke validatie voor de Gerben-casus

De casus uit de prompt — *"vraag was: kennis uit hoofd Gerben halen, Gerben ontlasten, meer mensen kunnen wat Gerben kan; antwoord werd: ERP-flow + database + AI + management-mail"* — vertoont **alle drie** de klassieke antipatronen:

1. **Solution-mismatch:** het antwoord lost een ander probleem op dan de vraag. Gerben-ontlasten ⇒ kennis-elicitatie en kennis-verspreiding. ERP+DB+AI+mail ⇒ data-pipeline en rapportage. Dit zijn verschillende werelden.
2. **Hammer-and-nail:** beschikbare techniek (eigen ERP, AI) dicteert oplossingsrichting. Zie Maslow's adagium: *"if all you have is a hammer, everything looks like a nail"*.
3. **Skipping the diamond:** geen verkenning van alternatieve oplossingen (SOPs, training, buddy-systeem, video-handleidingen, beslisbomen) voordat naar één oplossing wordt geconvergeerd.

Christians interventie ("wat was de vraag?") is methodologisch gezien **exact de juiste reset** — het is woord-voor-woord wat Gause & Weinberg adviseren als eerste stap.

## 5. Wat dit document NIET claimt

- Niet dat AI of agents geen rol spelen — alleen dat ze laat in het proces worden geselecteerd op basis van *fit-to-need*, niet op basis van enthousiasme.
- Niet dat Christian "alles weet" — alleen dat zijn proces-stelling overeenstemt met gevestigde literatuur.
- Niet dat het team van Peter inhoudelijk fout zit — alleen dat de proceslogica (vraag → oplossing) is omgekeerd (oplossing → terug-redenering naar vraag).