Het aantal low-code aanbieders is de afgelopen jaren enorm gestegen. Met de toenemende vraag naar automatisering en integraties, zijn de voorspellingen dat deze markt blijft groeien. Niet gek, want standaard applicaties en automatiseringen lijken gemakkelijk te maken met low-code tools. Veelal zien we blogs voorbij komen over hoe snel en eenvoudig er met low-code een applicatie gemaakt wordt. Is dat wel echt zo? 

We namen de proef op de som vanuit twee perspectieven, technisch en business, en ontwikkelden een CRUD applicatie (Create, Read, Update en Delete) in low-code. Om integratiemogelijkheden te testen en kosten te besparen, koppelden we de applicatie met een externe data-opslag, zoals te zien in de afbeelding hieronder.

Opzet van onze applicatie in low-code

In deze blog lees je onze ervaring met low-code en wanneer je voor low-code of voor traditionele software-ontwikkeling moet kiezen! 

Wat is low-code?

Low-code is een manier van software-ontwikkeling waarbij het schrijven van code versimpeld is door bijvoorbeeld te werken in een visuele 'drag-and-drop' omgeving. Voorbeelden van low-code aanbieders zijn Mendix, Appian en Outsystems. Low-code is vaak modelgedreven met de gedachte dat je applicaties maakt zonder complexe code te gebruiken. Applicatiegedrag, logica, processen en user interface sleep je in elkaar met standaard onderdelen. Op deze manier heb je minder programmeerkennis nodig dan bij traditionele software-ontwikkeling. 

App Form template in Mendix Studio 9.5.1. 

Standaardisatie vs. maatwerk 

Het grootste verschil tussen low-code en traditionele software-ontwikkeling is de mate van standaardisatie. In low-code tools is er veel gestandaardiseerd. Dit vermindert de complexiteit van software-ontwikkeling. Non-functionals, zoals veiligheid en schaalbaarheid, zijn al ingesteld. Standaard User Interface (UI) templates staan voor je klaar. Laad en structureer je data op de juiste manier, sleep de benodigde componenten bij elkaar, koppel deze en je basis staat. Wanneer je binnen de standaarden blijft, heb je relatief snel een basisapplicatie gemaakt.

Het nadeel: door met standaarden te werken, ben je afhankelijk van de kaders van het platform. Het beperkt vrijheid die je met traditionele software-ontwikkeling wel hebt. Bijvoorbeeld bij het integreren van applicaties of het toevoegen van UI-elementen. In de praktijk ondervonden wij dat de standaarden van low-code niet altijd voldoen aan de requirements van de klant. Dingen die we juist verwachtten als standaardcomponenten in low-code, zoals fuzzy search op een database, werden niet aangeboden. De oplossing hiervoor is het toevoegen van plugins van derden of om eigen code toe te voegen. 

Als je een simpele applicatie wil maken en weinig wil nadenken over randvoorwaarden, kan low-code een oplossing voor je zijn. Wees je ervan bewust dat wanneer je steeds meer niet-standaard dingen wil toevoegen, je mogelijk steeds meer eigen code aan het schrijven bent. Is low-code het dan nog waard of kan je beter de gehele applicatie zelf ontwikkelen? 

Kies voor low-code wanneer:	Kies niet voor low-code wanneer:
De standaarden van low-code voldoende zijn voor de applicatie	Het gaat om complexe toepassingen
Je niet wil nadenken over de non-functionals van software-ontwikkeling	Je vrijheid wil in zowel functionals als non-functionals

Benodigde kennisniveau en specifieke kennis

Doorgaans claimen low-code tools gemakkelijk in gebruik en voor iedereen toepasbaar te zijn. Dit onderzochten we van twee perspectieven: als software-ontwikkelaar en vanuit de business.

In beide gevallen moet je tijd investeren in het leren van low-code om een werkbare applicatie te bouwen. Zonder kennis van low-code weet je niet welke bouwblokken nodig zijn voor bepaald applicatiegedrag. Daarnaast is technische kennis cruciaal, omdat je met low-code te maken hebt met technische termen en principes. Naast het leren van low-code principes, is er ook tijd nodig om te leren hoe custom code werkt in een low-code applicatie. Hiervoor is kennis van programmeren vereist. Zelfs als ervaren software-developer vergt dit een andere aanpak dan traditionele software-ontwikkeling. Zo was er per toegevoegd stukje custom code de mogelijkheid om invulling te geven aan één Java-klasse, code kon niet gemakkelijk opgedeeld worden in logische herbruikbare onderdelen en externe dependencies toevoegen was niet gemakkelijk. Hierdoor was het toevoegen van custom code tijdrovender en ingewikkelder dan wanneer een software-developer traditionele code schrijft. Onze ervaring vanuit beide perspectieven is opvallend. Wel of niet technisch onderlegd, het benodigde kennisniveau is zodanig hoog dat je de eerste keer vele uren moet investeren om een goede basisapplicatie te kunnen bouwen. 

Afgezien van custom code, is low-code door de standaardcomponenten gemakkelijker te leren dan traditioneel programmeren. Hierbij moet de kanttekening gemaakt worden dat het met low-code gaat om zeer specifieke kennis die alleen toepasbaar is voor een bepaalde low-code tool. Het leren van programmeren duurt langer, maar daar kan je dan ook meer mee. Met low-code zal je altijd vastzitten aan platformspecifieke kennis. De vraag is of dit de investering waard is op langere termijn?

Kies voor low-code wanneer:	Kies niet voor low-code wanneer:
Je nog geen programmeerkennis hebt een een standaard applicatie wil maken	Je de principes van programmeren wil leren
Je weinig kennis hebt over non-functionals, zoals veiligheid en schaalbaarheid	Je gemakkelijk gebruik wil maken van verschillende soorten frameworks

Vendor lock-in: je verandert niet makkelijk van leverancier

Wikipedia leert ons: "Vendor lock-in maakt een klant afhankelijk van een leverancier voor producten en diensten, omdat hij niet in staat is om van leverancier te veranderen zonder substantiële omschakelingskosten of ongemak."

De meeste low-code platformen bieden een totaalpakket aan, waardoor je zelf niet meer hoeft na te denken over samenwerking met verschillende partijen of non-functionals zoals veiligheid. Dit maakt ook dat je voor alle facetten van software-ontwikkeling afhankelijk bent van één aanbieder. Buiten de kaders van je low-code tool werken is moeilijk. Ondanks dat low-code tooling onderling gelijkenissen heeft, is het lastig om over te stappen naar een andere aanbieders. Eenmaal gekozen, moet je dus zeker zijn dat je met de juiste partij in zee gaat.

Met traditionele software-ontwikkeling ligt vendor lock-in net anders, omdat de software wordt geschreven in code. Goed geschreven code is leesbaar en schaalbaar, waardoor veel software-developers hiermee kunnen werken. Het publiek dat kan programmeren is naar ons inziens groter dan low-code programmeurs, waardoor het makkelijker is om te schakelen van aanbieder. Met traditionele software-ontwikkeling ben je dus minder afhankelijk van de software-aanbieder dan met low-code.

Kies voor low-code wanneer:	Kies niet voor low-code wanneer:
Je een totaalpakket vanuit één platform wil	Je meer mogelijkheden wil hebben in het aanbod van software developers/bedrijven die software maken

Basisveiligheid of liever zelf de touwtjes in handen?

Veiligheid is een belangrijk vlak binnen de softwarewereld. Low-code platformen bieden daarin een helpende hand. Zij gaan uit van een standaard veiligheidsniveau, waar je zelf niet over hoeft na te denken. Vooral als je de hosting uitbesteed aan datzelfde platform, ben je zelf geen tijd kwijt aan veiligheid op dergelijk niveau. Echter, is de vraag bij wie de verantwoordelijkheden van veiligheid liggen. De gehanteerde veiligheid kan in tegenstrijd zijn met eisen vanuit je eigen bedrijf of klant. Bijvoorbeeld ISO27001 waaraan je moet voldoen of de locatie van je data. Met standaard beveiliging kan het zijn dat je hier geen invloed op hebt en ben je afhankelijk van de low-code aanbieder. Daarnaast ben je afhankelijk van derden als je plugins toevoegt. Iets wat zowel bij low-code als traditioneel programmeren een belangrijk punt is. In beide gevallen zijn er facetten van veiligheid die buiten je eigen invloed liggen. Grote communities bij traditioneel programmeren brengen hier een voordeel. Hoe meer mensen ergens mee werken, hoe meer veiligheid ter discussie wordt gesteld.  

Kies voor low-code wanneer:	Kies niet voor low-code wanneer:
Basis veiligheidsniveau voldoende is	Je niet afhankelijk wil zijn van veiligheid van de aanbieder
Je wil dat veiligheid voor je geregeld wordt	Je specifieke veiligheidseisen hebt

User Experience en gestandaardiseerde UI 

Voor User Experience Designers biedt low-code voor- en nadelen. Vooral designers die weinig weten van (front-end) code, zetten met low-code gemakkelijk een design in elkaar. Kleuren zijn vaak makkelijk in te stellen en er is keuze uit een aantal typografieën. Daarnaast zijn er standaard templates die helpen.

User Interface ontwerp in low-code is wel anders dan in designtools, zoals Figma of Sketch. De vrijheid die je in designtools hebt, heb je in low-code tools niet. Om een applicatie juist te laten werken, moeten bouwelementen op de juiste manier in elkaar gezet en met elkaar gekoppeld zijn. Een UX Designer wordt daarmee beperkt in zijn designs. Het wordt vooral lastig wanneer er klant-specifieke wensen zijn die niet in het straatje passen van je low-code tool. Bijvoorbeeld huisstijlelementen die niet standaard aangeboden worden. Dit kan leiden tot het stellen van beperkingen aan de requirements die je klanten hebben, omdat de mogelijkheden in low-code niet toereikend zijn.

In veel low-code tools is het mogelijk om niet-standaard elementen toe te voegen via custom code of plugins. Ook kan vaak styling aangepast worden via CSS, waardoor je niet afhankelijk hoeft te zijn van standaard templates. Als je de juiste kennis bezit, kan je afwijken van de standaard UI-elementen van een low-code tool. Ook hier geldt weer: wanneer je buiten de standaarden van low-code treedt, moet je eigen code schrijven. Is het dan nog voordelig om de applicatie in low-code te maken?

Kies voor low-code wanneer:	Kies niet voor low-code wanneer je:
Je standaard templates wil	Je vrijheid wil in het design van je applicatie
Je geen verstand hebt van CSS	Je specifieke requirements hebt

Ontwikkeltijd en kosten

Voor software-ontwikkeling zitten de meeste kosten in ontwikkeltijd. In die ontwikkeltijd wil je zo veel mogelijk waarde creëren. Wanneer een applicatie voor de gebruiker de juiste functionaliteit heeft en productiewaardig is, kan er gesproken worden van waarde. 

Bij traditionele software-ontwikkeling zit de uitdaging in het laatste deel, in productie gaan. Het ontwikkelen van de applicatie gaat met een vaardige ontwikkelaar en duidelijke requirements bijna net zo snel als een vaardige low-code ontwikkelaar. Echter, omdat veel bij de low-code gestandaardiseerd is, haal je hier direct het voordeel op non-functional requirements. Zo hebben low-code aanbieders vaak een eigen cloudomgeving om hun applicaties op te draaien of een duidelijk vooraf gedefinieerde manier van uitrollen. Hierdoor hoef je als ontwikkelaar hier niet meer over na te denken en behaal je daar tijdswinst. Wanneer de standaard kaders van low-code voldoende zijn voor jouw applicatie en je voldoende kennis hebt over het low-code platform, zal je ontwikkeltijd korter zijn dan bij traditionele software-ontwikkeling. Dit betekent dan ook lagere kosten voor ontwikkeltijd, mits je geen hulp nodig hebt van een low-code consultant.

Na ontwikkeling, zijn er kosten om je applicatie draaiende te houden. Bij de licentiemodellen waarmee low-code tools werken betaal je vaak per gebruiker en lopen de kosten snel op wanneer je meer resources tot je beschikking wil hebben. Traditionele software-ontwikkeling gaat op maat, waardoor omgevingen op elkaar afgestemd zijn. Hierdoor kunnen de kosten bij traditionele software-ontwikkeling op dit gebied weer lager zijn, omdat je precies betaalt voor wat je nodig hebt.

Wanneer is low-code de juiste keuze en wanneer is het minder geschikt?

Wanneer de standaard kaders van low-code voldoende zijn voor jouw applicatie en je zelf niet wil nadenken over allerlei randvoorwaarden is low-code een goede keuze. Ook voor het tekort aan goede softwareontwikkelaars is low-code ontwikkeling een oplossing, omdat low-code makkelijker te leren is dan traditioneel programmeren. In low-code kan je met voldoende kennis snel een basisapplicatie maken.

Dat je ogenschijnlijk makkelijk en snel een applicatie maakt in low-code, betekent niet dat je dit ook altijd moet doen. Low-code is niet zo flexibel als dat je soms nodig hebt. Standaardisatie heeft zo zijn voordelen, maar zeker ook zijn beperkingen. Als je specifieke wensen hebt in functionaliteiten, User Interface of non-functionals zoals veiligheid of hosting, kan je beter niet voor low-code gaan. Customisation leidt snel tot eigen custom code toevoegen. Dat is zonde, omdat je daarmee minder profiteert van de snelheid van low-code en verzandt in de gelimiteerde mogelijkheden van het toevoegen van code. Op het eind van de dag is ook low-code gewoon software, welke bugs kan bevatten waar je zelf erg weinig invloed op hebt. 

Zowel low-code als traditionele software-ontwikkeling hebben zijn voor- en nadelen. Elke applicatie en elk bedrijf heeft zo zijn eigen behoeften op het gebied van requirements, ontwikkeltijd, kosten, veiligheid en hosting. Hopelijk helpt deze blog jou met het kiezen wat aansluit op jouw wensen en eisen.

Naast onze eigen ervaring, hebben we ook de volgende bronnen geraadpleegd voor deze blog:

• https://owasp.org/www-project-top-10-low-code-no-code-veiligheid-risks/
• https://www.darkreading.com/edge-articles/addressing-the-low-code-veiligheid-elephant-in-the-room
• https://thestack.technology/low-code-no-code-veiligheid-risks/
• https://lichtenstein.io/low-code-ux
• https://medium.com/optimajethq/low-code-vs-custom-development-what-are-the-real-differences-a1c7acdbce17
• https://www.forbes.com/sites/ilkerkoksal/2020/04/29/the-rise-of-low-code-app-development/?sh=16e512d96807
• https://www.gartner.com/en/newsroom/press-releases/2022-12-13-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-20-percent-in-2023