Home / Blog / Softwareontwikkeling / Is Low-Code en No-Code softwareontwikkeling de toekomst?
De laatste jaren is er een duidelijke opkomst geweest van de Low-Code en No-Code platformen. De mogelijkheden zijn in een snel tempo toegenomen en een aantal platformen zijn echt volwassen aan het worden. Is dit het juiste moment om met deze platformen te gaan werken en hoelang is er nog behoefte aan “traditioneel” maatwerk software?
Wat is nu eigenlijk een low-code of no-code platform? Sinds jaar en dag wordt software gemaakt door het schrijven van code. Van machinecode en Assembly tot programmeertalen van latere generaties zoals C#, PHP, Python, TSQL, JavaScript, Go en ga zo maar door.
Deze “moderne” programmeertalen hebben verschillende syntax (opbouw van de taal) en verschillende inzetgebieden (Web applicaties, mobile, database, etc.), maar ze hebben ook veel gemeen: Uiteindelijk wordt alle programmacode gecompileerd of getranspileerd naar code die de computer kan uitvoeren.
De moderne tools en frameworks worden steeds beter en nemen veel gecompliceerde taken uit handen zodat softwareontwikkelaars zich kunnen focussen op het bouwen van de functionaliteit. Maar ondanks alle tooling en frameworks: je hebt nog steeds softwareontwikkelaars nodig die code kunnen schrijven en kennis moeten hebben van (1 maar vaak meerdere) programmeertalen, protocollen, security, dataopslag en distributie van de applicatie.
Een Low-Code of No-Code platform biedt mogelijkheden voor het ontwikkelen van software zonder dat je een kundige softwareontwikkelaar nodig hebt. Een dergelijk platform biedt een visuele manier van applicaties bouwen. Door drag & drop functionaliteit kun je bijvoorbeeld een workflow in elkaar slepen of een User Interface opbouwen. Hieronder zie je een workflow gemaakt in Microsoft’s Power Automate. Wanneer er een afbeelding in een bepaalde OneDrive map geplaatst wordt, dan wordt er een e-mail verstuurd. Vervolgens wordt er in een Excel bestand bijgehouden wanneer welk bestand is toegevoegd en in de planner wordt een taak aangemaakt om over een maand actie uit te voeren. Nadat het weerbericht bij de foto is opgezocht, wordt de foto met de informatie over het weer op Twitter geplaatst.
Dit voorbeeld toont de diversiteit van PowerAutomate. En dit is pas het begin want zo zijn er honderden connectors met verschillende acties en triggers. Zonder een regel code te typen kun je op deze manier in een paar minuten een complex werkproces automatiseren. Dit is dus een voorbeeld van een No-Code oplossing.
Binnen het PowerPlatform van Microsoft is naast PowerAutomate ook PowerApps beschikbaar. Dit is een voorbeeld van een Low-Code platform. Met PowerApps is een gebruiker in staat om snel schermen op te bouwen door elementen zoals knoppen, lijsten, tekstvelden en labels te plaatsen en deze te koppelen aan databronnen. Aan de knoppen kunnen “Excel-achtige” formules gekoppeld worden of PowerAutomate flows geactiveerd worden. Mocht je bijvoorbeeld validatie willen toevoegen op de tekstvelden dan kun je dat oplossen door een formule op te stellen, maar mocht het wat ingewikkelder worden, dan is er de mogelijkheid om JavaScript code toe te voegen en zo de functionaliteit die niet out-of-the-box beschikbaar is, toch zelf toe te voegen. Dan hebben we het dus over een Low-Code oplossing.
In deze blog haal ik een aantal keer de producten van Microsoft aan, maar er zijn veel meer aanbieders. Allemaal met hun eigen functionaliteiten en voor- en nadelen. Gartner voorziet een groei van de Low-Code ontwikkelingen en heeft een indeling gemaakt van hoe de huidige aanbieders in de markt staan. Daarin zien we onder andere Microsoft, Mendix (Siemens), Salesforce, Appian en Outsystems bij de leiders genoemd worden.
De productvideo’s op de websites van verschillende aanbieders zijn indrukwekkend en kunnen je laten denken “Wow, Low-Code is de toekomst! Eruit met die software ontwikkelaars”! Maar is Low-code en No-Code de oplossing voor alles? De platformen doen me vooral denken aan Lego. Mensen van mijn generatie kunnen zich het liedje onder de reclame nog wel herinneren. “Van Lego kun je alles maken, een boot een vliegtuig of een trein”. Met Low-Code bouw je je applicatie ook met kant en klare bouwstenen, snel en gemakkelijk. De bouwstenen zijn zo gemaakt dat ze breed inzetbaar zijn.
Nu zijn Lego blokjes over het algemeen hoekig en vierkant. Dat is prima als je hoekige vierkante dingen wilt bouwen, maar probeer maar eens een voetbal te bouwen met Lego. En daar begint de schoen een beetje te wringen. Zolang je de componenten gebruikt die standaard aanwezig zijn gaat het over het algemeen redelijk goed, maar wanneer je toch iets anders wilt zul je “Custom code” moeten gaan toevoegen. Zoals de hierboven genoemde custom validatie toevoegen met JavaScript. Wanneer je applicatie gaat groeien en erop steeds meer plekken custom code toegevoegd gaat worden, dan wordt het een exponentieel groeiende uitdaging om al deze code te onderhouden, testen en versioneren.
Van Lego kun je prima een huisje bouwen van 15 cm hoog. Een Lego huis van een meter is al een grotere uitdaging, maar er is een reden dat we de huizen waarin we wonen niet massaal met Lego bouwen. Dan loop je tegen uitdagingen aan rondom structurele complexiteit, de onderhoudbaarheid en de weerbaarheid tegen de elementen. En zo is het mijns inziens ook met Low-Code en No-Code platformen. In projecten van beperkte omvang en duidelijk afgebakende situaties kan het zeker een interessante oplossing bieden, maar naarmate een project complexer wordt of meer bedrijfskritisch is, dan wordt de inzetbaarheid van deze platformen snel niet meer aan te raden.
Er zitten grote verschillen tussen de verschillende Low-Code en No-Code platformen. Het is daarom moeilijk om te generaliseren, maar ik denk dat er een aantal uitdagingen is waar alle platformen geen of slechts beperkte oplossingen voor bieden.
Als we kijken naar “traditionele” softwareontwikkeling zijn er een aantal processen die we gebruiken om de kwaliteit van de softwareoplossing zo goed mogelijk te garanderen:
Een volgende uitdaging is de context waarin de applicaties draaien. De logica die je bouwt voor de applicatie is over het algemeen alleen bruikbaar binnen de context van de Low-Code applicatie. Bijvoorbeeld: een powerapp is alleen uit te voeren in een PowerApp omgeving. Wil je de logica bijvoorbeeld ook aanbieden als service of als native app, dan kan dat niet. Bij een traditionele applicatie waarbij de user interface, de logica en de dataopslag van elkaar gescheiden zijn, is het eenvoudiger om logica anders aan te bieden of hergebruiken.
Het ontwerpen van een goed doordachte en logische user interface is een vak apart. Wanneer de schermen opgebouwd worden door iemand die niet getraind is om applicaties te ontwikkelen heb je een groot risico op rommelige of onlogische schermen. Ook hiervoor geldt dat een kleine applicatie met een handvol schermen nog goed te overzien is in een Low-Code of No-Code platform, maar zodra de applicatie groeit en complexer wordt, wordt het steeds moeilijker om een consistente gebruikerservaring te realiseren.
Zoals eerder aangegeven werken Low-Code en No-Code platformen goed wanneer je van de standaard functionaliteit gebruik kunt maken. Maar op een gegeven moment loop je tegen beperkingen van het platform aan. Je zult dan “eromheen” moeten gaan werken om toch de gewenste functionaliteit te realiseren. Deze oplossingen zijn over het algemeen lelijke oplossingen waarvan het maar de vraag is of het blijft werken als er in de toekomst een update op het platform plaatsvindt.
Licenties en de daarbij behorende prijzen kunnen in de papieren gaan lopen. Bij bepaalde platformen betaal je een abonnementsprijs per gebruiker per maand. Aan de ene kant is het interessant dat de kosten meeschalen met het gebruik, maar aan de andere kant kan het daardoor in de loop van de tijd ook wel eens een heel prijzige oplossing blijken te zijn.
Ik heb het tot het laatste bewaard, maar persoonlijk vind ik dit nog misschien nog wel de uitdaging waar het beste over nagedacht moet worden: Kan ik het me veroorloven dat de applicatie volledig afhankelijk is van het gekozen platform?
Een applicatie die gemaakt is in een bepaald Low-Code of No-Code platform kun je niet oppakken en ergens anders weer functioneel maken. De applicatie is 1 op 1 verbonden aan het platform en dat betekent dat je volledig afhankelijk bent van de leverancier wat betreft de kosten en de beschikbaarheid van het platform. Veel applicaties hebben een levensduur van meerdere jaren of zelfs decennia. Geen van de leveranciers van de Low-Code en No-Code platformen zal je kunnen garanderen dat het platform over 5 jaar nog bestaat (in de huidige vorm).
Microsoft en alle andere aanbieders investeren nu flink in deze platformen, maar helaas is dat geen garantie voor een lange toekomst. Zo zal Google App Maker begin 2021 stoppen met werken en zijn er nog tientallen andere producten van Google te noemen die de tand des tijds niet hebben doorstaan. Voor Microsoft geldt hetzelfde: dat ze ergens flink in investeren wil niet zeggen dat het een succes wordt en blijft (ik denk even aan Windows Phone, Windows RT, Silverlight, enz.)
Voor bedrijfskritische applicaties kun je eigenlijk niet 100% vertrouwen op een bepaald platform en zul je een scenario moeten hebben waarmee het mogelijk moet zijn om binnen een redelijke tijd up & running te zijn bij een andere aanbieder. Maatwerk software biedt daar nu eenmaal veel meer mogelijkheden toe.
Voor de duidelijkheid: Ik zeg niet dat Low-Code en No-Code platformen geen toekomst hebben. Sterker nog, ik ben het met Gartner eens dat de komende jaren er een duidelijke groei zit in het gebruik van deze platformen. En dat is prima! Er moet echter goed worden gekeken naar waar deze platformen tot hun recht komen en waar niet.
Draait je afdeling op een of andere Excel sheet en wil je het nu beter aanpakken? Wil je een workflow automatiseren zodat bijvoorbeeld je Sharepoint omgeving een actie uitvoert in een ander product? Heb je een intranet nodig waar medewerkers documenten kunnen vinden rondom ISO certificering? Kijk dan vooral eens naar de mogelijkheden van Low-Code en No-Code platformen.
Wil je een applicatie die doorontwikkeld moet worden? Is de applicatie bedrijfskritisch? Kun je het je niet veroorloven dat een applicatie tijdelijk niet beschikbaar is? Is er zoveel te ontwikkelen dat er een team mensen aan het project werkt? Wil je geen concessies doen aan functionaliteit? En als laatste; is het een groot probleem als het platform stopt met de ondersteuning van je applicatie? Waarschijnlijk is dan een maatwerk applicatie laten bouwen de beste oplossing.
Uiteraard zijn er ook combinaties mogelijk waarbij de kern van de applicatie in eigen beheer en platformonafhankelijk ontwikkeld wordt, maar aangrenzende processen met Low-Code of No-Code worden opgelost.
Senet is als applicatiebouwer helemaal thuis in de maatwerk applicaties, maar we hebben ook kennis en ervaring met (hybride combinaties met) Low-Code en No-Code platformen. Mocht je vragen hebben of twijfelen of Low-Code/No-Code platformen de juiste oplossing zijn in jouw situatie, neem dan vooral contact met ons op voor een vrijblijvend advies.
We nemen contact met u op!
Senet Eindhoven Gestelsestraat 258 5654 AM Eindhoven Bekijk op kaart
+31(0)40-2930395
KvK nummer: 17115078 Btw nummer: NL807989083B01
