RD Workx AI Node Manager

NX als gedeelde bouwlaag voor je AI delivery teamDeze pagina legt uit hoe NX binnen RD Workx gebruikt hoort te worden: niet als technische build-uitleg, maar als vaste bibliotheek en beslislaag voor herbruikbare componenten die AINM-gestuurde stories sneller, consistenter en slimmer laat opleveren via ALM.

Rol in deliveryHerbruikbare bouwlaag

NX is hier geen technische uitlegpagina, maar de plek waar het AI delivery team gedeelde componenten, patronen en bouwblokken hoort te zoeken en te beheren.

Wanneer teamleden NX gebruikenBij elke nieuwe story

Voor development start, moet eerst worden gecontroleerd of login, datumselectie, beheer-tabs, LLM-selectie of andere gevraagde UI al als standaard bouwblok bestaat.

Wie NX activeertAINM + AI executors

AINM beheert de stories en fases; het delivery team hoort NX als vaste bron voor hergebruik mee te nemen tijdens refinement, development en rollout.

DeploymentmodelALM levert apps uit

NX levert de gedeelde bouwstenen en afspraken; ALM blijft de plek waar concrete applicaties worden gebouwd en gedeployed naar DEV/OTAP.

Wat NX binnen RD Workx betekent

Werkwijze

Binnen RD Workx is NX de gedeelde productlaag voor herbruikbare componenten, patronen en featureblokken die meerdere apps binnen de suite kunnen gebruiken. Denk aan authenticatie, datum pickers, beheer-tabs, LLM-selectie, formulieren, dashboards en andere vaste bouwstenen.

Wat AINM ermee moet doen

Werkwijze

AINM moet user stories niet behandelen alsof elke app vanaf nul begint. De ontwikkelstroom hoort eerst te toetsen of de gevraagde functionaliteit al bestaat in NX, daarna pas nieuw werk te bouwen. Alleen wat echt nieuw is, wordt custom ontwikkeld.

Wat het oplevert voor je AI devteam

Werkwijze

Minder dubbel werk, consistente UX, snellere delivery en een duidelijker proces: eerst hergebruik, dan pas maatwerk. Daardoor kan je AI-team sneller stories afronden en houd je je suite consistenter terwijl ALM de uiteindelijke deploy verzorgt.

De gewenste werkelijkheid in AINM

Procesdoel

De NX-pagina hoort het operating model van je AI-team uit te leggen: eerst hergebruik toetsen, daarna pas bouwen.

AINM beheert vandaag al backlog-items, delivery-fases en uitrolrichtingen via ALM.
De huidige NX-pagina moet daarom niet vooral uitleggen hoe je buildt, maar hoe het delivery team NX in de dagelijkse flow hoort te gebruiken.
De gewenste werkwijze is: story komt binnen in AINM → team checkt NX op bestaand hergebruik → alleen ontbrekende delen worden nieuw gebouwd → waardevolle nieuwe delen worden daarna teruggepromoveerd naar NX.
Hiermee wordt NX de gedeelde bron voor suite-brede UI en featurehergebruik, terwijl apps nog steeds zelfstandig via ALM worden opgeleverd.

Wat je hiermee afdwingt

Waarde

NX moet de suite slimmer maken door standaardisatie actief onderdeel van delivery te maken.

Voorkom opnieuw bouwen

Een story voor een loginpagina, datumselectie of beheer-tab hoort eerst te starten met: bestaat dit al in NX?

Geen nieuwe auth-flow bouwen als een standaard login-module al beschikbaar is.
Geen losse datum-picker per app maken als dezelfde interactie al eerder is opgelost.
Geen aparte LLM-keuzepagina ontwerpen als er al een breed inzetbaar selectiepatroon bestaat.

Maak promotie naar standaard eenvoudig

Goede componenten uit bestaande apps moeten terug de gedeelde bibliotheek in kunnen stromen.

Als een app al een sterke LLM-selectiepagina heeft, moet die kunnen worden opgeschoond en omgezet naar een NX-standaardcomponent.
De businessregel is niet: laat het in de app staan. De regel is: als meerdere apps dit kunnen gebruiken, promote het naar NX.
Zo groeit NX op basis van bewezen werk, niet op basis van theoretische abstrahering.

Hoe NX in de deliveryflow gebruikt hoort te worden

AINM → Team → ALM

Dit is de beoogde operationele flow voor stories die door AINM worden beheerd en door je AI delivery team worden uitgevoerd.

Stap 1

Refinement: herken hergebruik al in de story

Tijdens refinement moet het team expliciet markeren welke delen van de story mogelijk al als standaard bestaan. 'Maak een inlogpagina' is niet alleen een bouwvraag, maar eerst een reuse-vraag.

AINM hoort dus niet alleen acceptance criteria te beheren, maar ook de check: bestaat dit al in NX of moet het nieuw worden toegevoegd?

Stap 2

Development: kijk eerst in NX, bouw pas daarna

Wanneer development start, is de eerste stap niet direct coderen maar controleren of het component, patroon of de feature al als gedeelde bouwsteen beschikbaar is.

Bestaat het al? Gebruik het. Bestaat het deels? Breid het uit. Bestaat het niet? Bouw het app-specifiek met zicht op latere promotie.

Stap 3

Promotie: haal bewezen componenten uit apps terug naar NX

Als een app een sterk herbruikbare oplossing oplevert, zoals een LLM-selectiepagina of een beheer-tabstructuur, moet het team dat actief kunnen promoveren tot standaardcomponent in NX.

De vraag is dan: welke app-specifieke logica haal je eruit zodat er een nette, suite-brede bouwsteen overblijft?

Stap 4

Delivery: lever de app uit via ALM, niet NX zelf

NX is de bron van de herbruikbare bouwblokken. De uiteindelijke app wordt nog steeds via het normale RD Workx deliveryproces gebouwd, gevalideerd en via ALM uitgerold.

Dus: NX standaardiseert wat gebouwd wordt; ALM levert het resultaat uit naar de omgeving.

Stap 5

Lerend systeem: elke afgeronde story kan NX sterker maken

Na oplevering hoort het team te beoordelen of nieuw gemaakte UI of logica eigenlijk suite-breed waardevol is. Zo wordt NX stap voor stap rijker en daalt de hoeveelheid maatwerk per volgende app.

Dit maakt van NX een actieve delivery-versneller in plaats van een passieve documentatielaag.

Als een story zegt: maak een loginpagina

Praktijk

De standaardreactie is niet direct bouwen, maar eerst hergebruik toetsen.

1. Zoek in NX naar bestaande auth/login bouwstenen

Kijk eerst of de functionaliteit al als standaard bestaat.

2. Bepaal of de story volledig, deels of niet kan leunen op NX

Gebruik bestaand werk waar mogelijk.

3. Bouw alleen het ontbrekende deel app-specifiek

Voorkom kopieën van al bestaande patronen.

4. Evalueer na oplevering of nieuwe varianten terug moeten naar NX

Laat de library groeien op basis van bewezen usage.

Als een bestaande app al iets goeds heeft

Praktijk

Goede schermen of componenten mogen niet opgesloten blijven in één app.

1. Benoem het onderdeel als kandidaat voor promotie

Bijv. LLM-selectie, datum-picker, beheer-tabs, wizard of auth-flow.

2. Haal app-specifieke aannames eruit

Maak props, configuratie en states generiek genoeg voor meerdere apps.

3. Leg vast wat het standaardcontract wordt

Welke inputs, outputs, states en extensiepunten gelden suite-breed?

4. Laat volgende stories dit nieuwe NX-bouwblok als eerste keuze gebruiken

Promotie heeft pas waarde als hergebruik daarna verplicht wordt meegewogen.

Hoe het AI delivery team NX hoort te gebruiken

Gebruik

NX moet een vast beslispunt in de deliveryflow zijn.

Bij refinement: markeer reuse-kansen in de story.
Bij development: check NX vóórdat maatwerk wordt gebouwd.
Bij review: toets of een nieuw onderdeel suite-breed nuttig is.
Bij deployment: lever de app uit via ALM, maar houd het gedeelde stuk in NX beheerd.
Bij volgende stories: hergebruik het standaardcomponent als voorkeursroute.

Welke type onderdelen hier thuishoren

Gebruik

Dit zijn typische kandidaten voor NX-standaardisatie binnen de RD Workx suite.

Authenticatieblokken: loginpagina's, provider-knoppen, sessiestatus, guards.
Form en invoercomponenten: datum pickers, selectors, filters, tabellen, statuschips.
Beheerpatronen: beheer-tabs, detailpanelen, CRUD-shells, feedbackmodals, sidebars.
AI/LLM-specifieke UI: providerkeuze, modelselectie, promptinstellingen, usage-overzichten.
Deliverypatronen: story-statuskaarten, GWR-indicatoren, deploymentbewijs, activitywidgets.

Hoe je een nieuw herbruikbaar component toevoegt aan NX

Promotiepad

Gebruik dit pad wanneer een bestaand onderdeel uit een app te waardevol is om app-specifiek te blijven.

1. Signaleer standaardisatiekansen vroeg

Niet wachten tot drie apps hetzelfde probleem opnieuw hebben opgelost.

Komt dezelfde behoefte terug in meerdere stories of apps? Dan is het een NX-kandidaat.
Heeft een component een duidelijke businessbetekenis, zoals login, LLM-selectie of beheer-tabnavigatie? Dan hoort standaardisatie direct in beeld te komen.
Blijft het volledig uniek voor één scherm of één klantcase? Dan blijft het lokaal in de app.

2. Promote vanuit bestaand werk, niet uit theorie

Gebruik bewezen app-implementaties als bron voor NX-standaardcomponenten.

Neem een werkend onderdeel uit een bestaande app als startpunt.
Strip app-specifieke labels, API-koppelingen, permissies en layout-aannames weg.
Houd alleen het suite-brede contract over dat meerdere apps kunnen consumeren.

3. Definieer het herbruikbare contract

Een standaardcomponent moet duidelijk beschrijven wat vast is en wat configureerbaar is.

Leg props, staten, validaties en hooks vast op basis van businessbetekenis.
Ondersteun varianten via configuratie, niet via copy-paste forks.
Zorg dat volgende apps het component kunnen inzetten zonder de originele bronapp te kennen.

4. Maak hergebruik onderdeel van delivery discipline

Het team moet niet vrijblijvend kiezen of het NX bekijkt.

Voeg in refinement/development expliciet de vraag toe: 'welke NX-bouwstenen gebruiken we hier?'.
Laat stories of uitvoeringsprompts verwijzen naar het relevante standaardcomponent zodra het bestaat.
Behandel het overslaan van bestaande NX-bouwstenen als procesafwijking, niet als neutrale keuze.

5. Laat NX meegroeien met de suite

Elke goede generieke oplossing moet toekomstige stories versnellen.

Voeg nieuwe standaardonderdelen toe zodra hergebruik realistisch en waardevol is.
Werk de beschrijving van het componentgebruik bij zodat het AI-team weet wanneer dit de voorkeursroute is.
Bewaak dat NX een productieve bibliotheek blijft en geen dumpplaats van half-afgemaakte componenten wordt.

Bronnen van waarheid

Governance

Businessdoel van NXGedeelde componenten en featureblokken voor meerdere apps in de RD Workx suite

ProcestriggerElke nieuwe story moet eerst op mogelijk hergebruik worden beoordeeld

Story-orchestratieAINM beheert de stories, fasen en delivery-aansturing

GebruiksmomentRefinement en development moeten NX expliciet meenemen

PromotierouteBewezen componenten uit bestaande apps terugbrengen als NX-standaard

DeploymentConcrete apps blijven via ALM gebouwd en uitgerold worden

VoorbeeldenAuth, datum pickers, beheer-tabs, LLM-selectie, gedeelde delivery-UI

Guardrails voor het team

Niet vergeten

Gebruik NX niet als technische etalage, maar als operationele reuse-laag voor het AI delivery team.
Bij nieuwe stories eerst checken of het bouwblok al bestaat; pas daarna nieuw maatwerk maken.
Promoveer alleen onderdelen naar NX die echt meerdere apps kunnen bedienen.
Haal app-specifieke logica weg voordat iets als standaardcomponent wordt opgenomen.
NX standaardiseert bouwstenen; ALM blijft verantwoordelijk voor de concrete app-deployments.