Low-code en no-code

Wat is low-code en no-code?

Low-code en no-code zijn twee manieren om software te bouwen met visuele bouwstenen in plaats van programmeercode. Je sleept blokken op een canvas, verbindt stappen met elkaar en vult instellingen in via formulieren. De tool vertaalt dat achter de schermen naar werkende software.

Het verschil tussen de twee zit in hoeveel code er nog aan te pas komt. Bij no-code is alles klikbaar: je schrijft geen enkele regel code en de tool is gemaakt voor mensen zonder technische achtergrond. Bij low-code werk je ook visueel, maar kan je code toevoegen op de plekken waar de blokjes tekortschieten: een formule, een query, een stukje maatwerk.

Die grens is vager dan de namen doen vermoeden. Zowat elke no-code tool heeft ergens een formuleveld dat verdacht veel op programmeren begint te lijken zodra je iets minder standaard wil. Zie de twee termen eerder als een glijdende schaal dan als twee aparte hokjes.

Vergelijk het met een keuken. No-code is de IKEA-keuken: standaardmodules die je snel plaatst, met een beperkt aantal opties. Low-code is de keukenbouwer die met standaardkasten werkt maar dat ene schuine hoekje op maat maakt. Klassiek programmeren is de schrijnwerker die alles van nul bouwt: alles kan, maar het duurt langer en je hebt er een vakman voor nodig.

No-code, low-code en pro-code naast elkaar

De drie aanpakken verschillen vooral in wie er bouwt, wat er mogelijk is en wie het resultaat onderhoudt.

No-code
De bouwer is de businessmedewerker zelf, zonder technische achtergrond. Wat kan: formulieren, goedkeuringsflows, eenvoudige apps en dashboards, binnen de grenzen die de tool voorziet. Het onderhoud ligt bij de maker, en daar wringt het zodra die van functie verandert of het bedrijf verlaat.

Low-code
Hier bouwen businessmedewerker en ontwikkelaar vaak samen. Microsoft noemt dat fusion development: wie het proces kent bouwt de eerste versie, een ontwikkelaar springt bij voor het maatwerk. Wat kan: een stuk meer, met honderden kant-en-klare connectoren naar andere systemen en eigen code waar nodig. Het onderhoud is gedeeld, wat afspraken vraagt over wie wat beheert.

Pro-code
Klassieke softwareontwikkeling, door ontwikkelaars, met programmeertalen en frameworks. Alles kan wat technisch mogelijk is. Het onderhoud verloopt via versiebeheer, geautomatiseerde tests en code review: volwassen praktijken die in low-code omgevingen maar gedeeltelijk bestaan.

Low-code en no-code in de datapraktijk

De kans is groot dat er al low-code in je organisatie draait zonder dat iemand het zo noemt. In een Microsoft-omgeving kom je het op vier plaatsen tegen.

• Power Automate voor flows: een goedkeuring die automatisch vertrekt, bijlagen die in de juiste map belanden, een melding in Teams bij een nieuwe bestelling.

• Dataflow Gen2 in Microsoft Fabric voor datatransformatie: je klikt stap voor stap door filteren, samenvoegen en opschonen, zonder SQL of Python te schrijven.

• Power Apps voor kleine bedrijfsapps: een formulier waarmee de werkvloer defecten registreert, rechtstreeks in een centrale databank in plaats van in een rondslingerende Excel.

• Copilot Studio voor chatbots en AI-agents die je samenstelt in een grafische editor.

Die tools horen net als Power BI tot het Power Platform van Microsoft. Buiten Microsoft is de categorie minstens even groot: platformen zoals Mendix en OutSystems mikken op volwaardige bedrijfsapplicaties in low-code. En eigenlijk past self-service analytics in hetzelfde plaatje: mensen zelf met data laten werken zonder dat IT elke vraag moet beantwoorden.

Wat levert het op?

De grootste winst zit niet in de tool maar in wie ze in handen heeft. De persoon die het proces door en door kent, bouwt zelf de oplossing. Er gaat geen kennis verloren in de vertaalslag van businessvraag naar technische specificatie naar oplevering.

Daar komt snelheid bij. Voor een klein intern probleem, een goedkeuringsflow of een invulformulier, wacht je niet tot het ontwikkelteam tijd heeft. Je bouwt het deze week zelf. Net die kleine ergernissen bleven vroeger jaren liggen omdat ze nooit zwaar genoeg wogen voor een IT-project.

Het werkt ook als leerschool. Wie een eerste flow bouwt, begrijpt daarna beter wat automatisering kan en stelt scherpere vragen aan het datateam.

De grenzen van low-code en no-code

Wees er eerlijk over: de aanpak heeft echte grenzen, en je botst er sneller op dan de demofilmpjes doen uitschijnen.

Complexe logica wordt onleesbaar
Tien geneste voorwaarden in blokjesvorm zijn moeilijker te volgen dan dezelfde logica in twintig regels code. Wat begon als een eenvoudige flow groeit soms uit tot een canvas waar zelfs de maker de weg kwijtraakt.

Volume is een zwak punt
Een flow die per record een actie uitvoert, werkt vlot voor tientallen records en kruipt bij tienduizenden. Voor serieuze datavolumes wint een datapijplijn of een script het ruimschoots, en licentiemodellen leggen bovendien vaak limieten op het aantal acties per dag.

Testen en versiebeheer zijn magerder
Bij code zijn geautomatiseerde tests, versiegeschiedenis en review ingeburgerd. In low-code omgevingen bestaan daar wel oplossingen voor, maar in de praktijk test je vaak door de flow te laten draaien en te kijken wat er gebeurt.

Licentiekosten lopen op
De rekenmodellen verschillen per tool: per gebruiker per maand, per flow of per bot. Connectoren naar systemen buiten Microsoft 365 zitten bij Power Automate vaak in de premium-categorie, waarvoor je een betaald plan nodig hebt. Wat gratis leek binnen je bestaande abonnement, groeit zo uit tot een stevige jaarlijkse kost.

Waar moet je op letten bij het gebruik van low-code en no-code

Mensen die zonder IT-achtergrond zelf bouwen, worden citizen developers genoemd. Dat is de kracht van het model en tegelijk het risico. Zonder afspraken eindig je met tientallen flows en appjes waarvan niemand nog weet wat ze doen, wie ze bouwde of welke data erdoor stroomt.

Het herkenbaarste scenario: een collega bouwt in de loop van de jaren vijftien flows op een persoonlijk account en verlaat dan het bedrijf. Het account wordt afgesloten en de flows vallen een voor een stil, meestal op het slechtst denkbare moment. Hetzelfde eigenaarschapsprobleem duikt op bij de on-premises data gateway die ooit door een vertrokken collega werd geïnstalleerd.

Een paar afspraken houden het beheersbaar:

• Zet bedrijfskritische flows op een serviceaccount of geef ze meerdere eigenaars, zodat ze niet aan één persoon hangen.

• Hou een inventaris bij van wat er draait: wie bouwde het, waarvoor, met welke databronnen. Voor het Power Platform biedt Microsoft daar het CoE Starter Kit voor aan, een dashboard dat alle apps en flows in kaart brengt.

• Vraag een minimum aan documentatie per flow: doel, eigenaar en databronnen volstaan al. Een jaar later moet iemand anders nog begrijpen wat het ding doet.

• Beperk met Data Loss Prevention-regels welke connectoren gecombineerd mogen worden, zodat bedrijfsdata niet ongemerkt naar een externe dienst stroomt.

• Spreek af wanneer iets promoveert van handig hulpmiddel naar beheerd bedrijfsproces, met een eigenaar in het team in plaats van een enthousiaste maker.

Dat laatste punt heeft een logisch vervolg: soms is de juiste beheersmaatregel de flow herbouwen als echte software, met tests en versiebeheer. Dat is geen mislukking van het low-code verhaal. Het prototype heeft dan net bewezen wat het proces nodig heeft, en dat inzicht maakt het ontwikkelwerk een pak goedkoper.

Wanneer kies je toch meteen voor code?

Een paar vuistregels waarbij je beter niet aan blokjes begint:

• De logica zit vol uitzonderingen en speciale gevallen. Wat in code twintig leesbare regels is, wordt in blokjes een doolhof.

• Het volume is groot of de prestatie-eisen zijn strak. Duizenden records per uur verwerken is werk voor een datapijplijn, niet voor een flow.

• Het systeem voedt andere systemen en moet jaren mee. Dan wil je tests, versiebeheer en meerdere mensen die de oplossing kunnen onderhouden.

• Er bestaat geen standaardconnector voor het systeem dat je wil koppelen. Een eigen connector bouwen kan, maar dan ben je feitelijk al aan het programmeren en valt het snelheidsvoordeel weg.

De omgekeerde vuistregel geldt ook. Voor een intern goedkeuringsproces, een meldingsflow of een invulformulier is maatwerksoftware meestal overkill. Daar is low-code precies voor bedoeld.

FAQ over low-code en no-code

1. Vervangt dit onze ontwikkelaars?
Nee. Het verschuift hun werk. De kleine automatiseringen bouwt de business voortaan zelf, waardoor ontwikkelaars tijd overhouden voor de systemen waar hun vakkennis het verschil maakt: integraties, datamodellen en software die jaren mee moet.

2. Is het veilig?
De platformen zelf zijn degelijk beveiligd, het risico zit in het gebruik. Wie een flow bouwt, kan data verplaatsen naar plekken waar ze niet thuishoort. Toegangsbeheer, aparte omgevingen voor test en productie en Data Loss Prevention-regels horen daarom bij de basishygiëne.

3. Is Excel dan ook no-code?
Eigenlijk wel, en het is meteen het oudste succesverhaal van de categorie: miljoenen mensen bouwen rekenmodellen zonder zichzelf programmeur te noemen. Microsoft baseerde Power Fx, de formuletaal achter Power Apps, niet toevallig op Excel-formules.

4. Hoe begin je eraan?
Kies één klein, afgebakend proces dat vandaag manueel verloopt, bijvoorbeeld een goedkeuring die nu via e-mail gaat. Bouw daar een flow voor, evalueer na een maand en leg meteen de basisafspraken vast rond eigenaarschap en documentatie. Klein beginnen met duidelijke afspraken werkt beter dan groot aankondigen.