Soms is het moeilijk om niet met je ogen te rollen als er een nieuwe hype ontstaat rondom een technologische trend. Low-code/no-code is een van die trends waarbij de hype kan afleiden van de werkelijke waarde die deze benadering van applicatieontwikkeling biedt.
De drie redenen waarom low-code op dit moment overhyped is, zijn:
- Het is niet de eerste poging om de ontwikkeling van applicaties te vergemakkelijken. We hebben eerder al initiatieven gezien, denk maar aan het Microsoft Oslo-project uit 2007. Er zal wellicht een dag komen dat er weinig programmering nodig is, maar als je een laag van ’business logic’ moet genereren, zal je altijd moeten programmeren en moet je dus die kennis in huis hebben.
- Het lijkt onwaarschijnlijk dat organisaties met gevoelige bedrijfsinformatie hun werknemers ongehinderde toegang geven tot low-code-tools. De overgrote meerderheid van deze tools zijn clouddiensten die worden gehost door meerdere leveranciers, alleen al dat zou alarmbellen moeten doet afgaan bij jouw chief information security officer.
- Veel van deze tools lijken een ui-laag te bieden boven op bestaande applicaties, waardoor je geen toegang hebt tot de kerngegevens in deze systemen. Dat betekent niet alleen dat je medewerkers met programmeerkennis nodig hebt om deze belangrijke systemen te onderhouden, maar ook dat je kennis van business logic moet hebben om de low-code-ui met jouw kerngegevens te laten werken.
Wendbaar
Hoewel low-code mankementen kent, heeft het ook een zekere waarde. Het kan organisaties helpen wendbaar te zijn en snel op de kansen in de markt in te spelen. Daarnaast kampen we op dit moment met een tekort aan geschoolde it-medewerkers. Low-code-modellen kunnen bedrijven helpen om bepaalde aspecten van de appontwikkeling te automatiseren en zo tijd, middelen en mensen te besparen. Er is dan een duidelijk kostenbatenargument voor low-code.
Als je low-code succesvol wil gebruiken binnen jouw organisatie, dan is het verstandig om dezelfde best practices te gebruiken die voor andere applicatieontwikkelingen ook gelden. Gedisciplineerde processen en goed beheer mogen daarbij niet ontbreken. Dat betekent dat je streng moet toezien op hoe tools interacteren met jouw bestaande omgeving. Ze hebben natuurlijk toegang nodig tot backend-datasystemen, maar die toegang moet niet onbeperkt zijn vanwege veiligheidsoverwegingen.
Als je je daarnaast zorgen maakt dat low-code de wildgroei aan applicaties in de hand werkt, moet je bepalen wie een verzoek voor apps kan doen en wie welke toegangs- en levelcontroles mag hebben. Apps moeten correct worden gebouwd, beheerd worden aan de hand van specifieke normen en een proces voor goedkeuring en kwaliteitscontrole volgen.
Sprookje
Als Deen weet ik wel iets af van sprookjes. Ik wil niet zeggen dat no-code-ontwikkeling een sprookje is, maar iedereen die je vertelt over het potentieel van dergelijke ontwikkelingen zou net zo goed een koninkrijk hier ver vandaan kunnen beschrijven. De reden waarom verhalen zoals Hansje en Grietje zo goed werken, is omdat ze ook best eng waren. Nu wil ik niet zeggen dat iemand die een low-code/no-code-strategie goedkeurt bang zou moeten zijn, maar je moet wel goed weten waar je aan begint. En vooral: geloof niet in de hype. Low-code is even goed een vorm van programmeren. Je hebt nog steeds programmeerkennis nodig als je het goed wilt implementeren en het vereist discipline en goed beheer om het correct te laten werken. Jouw it-team dat applicatieontwikkelingsmodellen in de onderneming implementeert, moet worden opgeleid zodat ze begrijpen wat er van hen wordt verwacht en welke code ze gebruiken.
Low-code; het is geen wondermiddel voor alle behoeften op het gebied van appontwikkeling, maar het kan helpen om het tekort aan personeel en skills op te vangen.
(Auteur Claus Jepsen is cto bij Unit4.)
Volgens https://www.computable.nl/artikel/blogs/digital-transformation/7339779/5260614/zo-ontdek-je-nieuw-it-personeel.html een week geleden in dit theater precies het omgekeerde verhaal : “Ze schatten in eerste instantie dat het ongeveer zes maanden zou duren om deze klus te klaren. Maar met behulp van een low-code-oplossing was het werk in slechts vier dagen klaar.” .. “Met low-code kan iedereen, van analisten tot productiemanagers, zelf de bedrijfsprocessen en -functies structureren die ze nodig hebben.”
misschien kunnen de gestoorde procedures van robbie hulp bieden, of de next gen taal van jack. Anders terugvallen op ewouts uitgefaseerde productlijn van risc is more, met continuous replatforming naar nog meer moois.
Uit het oog, uit het hart Dino?
Wat ik mis bij dit soort artikelen is dit: Wat blijft er hier nu hangen? Met welke stukje kan ik iets?
Geef voorbeelden van echte gevallen. Waar werkte een low code app wel? Waar niet? Want in de details zit het verschil.
Een form voor CRUD is simpel, maar business logica, aanpasbaarheid en herstellen van zaken die niet volgens de happy flow gingen, daar gaat veel tijd en moeite in zitten.
Maar zo overhyped lijkt low-code niet… het blijft mijn inziens vooral niche…
De vermelde 3 redenen zijn zeer valide; daarom adviseer ik een 5GL in plaats van een Low of Nocode. Wel graag in combinatie met een 4GL/SQL naar keuze.
https://dmcommunity.org/2021/09/02/is-sql-for-business-or-it/
De inzichten in dit korte artikel zijn deels gebaseerd op discussies in dit theater; één volzin heb ik letterlijk overgenomen van Will Moonen en alleen maar vertaald in het Engels met de gewaardeerde hulp van deepl.com. Namelijk:
Lowcode/nocode is all about speeding up application building – the underlying database structure and/or language is hardly relevant there, if at all.
Gestoorde procedures, je zou bijna denken dat het kwaadaardige opzet van Dino is. En wat betreft het platform is blijven hangen natuurlijk ook een optie alleen kom je dan in de ‘legacy trap’ omdat technologie een voortschrijdende ontwikkeling kent. Replatforming – de overdracht van een legacy-systeem naar een nieuw doelplatform – wordt dan ook vaak gezien als een eerste stap om kosten te besparen om zodoende een langdurige re-engineering mogelijk te maken. Tenslotte brengt het opnieuw creëren van een functioneel equivalent ecosysteem op een ander platform aanzienlijke technische en organisatorische uitdagingen met zich mee.
Het cynisme van Dino klotst – net als de onwetendheid van Robbie – over de randvoorwaarden waardoor mijn oeverloos gelul heerlijk uit zijn context getrokken kan worden maar zie anders de discussie van 7 april 2020 in dit theater over COBOL en mainframes. Tenslotte is niet onbelangrijk – een punt voor Henri – de bedrijfslogica want Jack wil graag 5GL maar hoeveel eerdere bedrijfslogica is er de afgelopen 60 jaar geschreven in 3GL?
Van LPAR tot sPAR kunnen we door blijven stapelen waarbij de ‘lift & shift’ van replatforming gedaan kan worden met virtualisatie, het ‘rechippen’ van een OS is niet echt nieuw als ik kijk naar de horizontale combinatie van emulatie welk voor een gelaagdheid in de architectuur zorgt met ook eens vertikale in silo’s. Maar zoals Robbie al zegt is onderliggende technologie niet interessant als je maar aan de goede kant van het loket staat. Een ‘viewpoint’ in de architectuur van achter gesloten deuren oplossingen welke tot steeds meer achterstallig onderhoud leidt.
Oja, ik ben het eens met de strekking van het verhaal maar wel benieuwd naar het addertje onder het gras aangaande de best practice. Ik vermoed dat deze niks te maken heeft met het coderen maar alles met de regie aangaande de gegevensverwerking. Want de randvoorwaarde van een rechtmatige verwerking is juridisch net even anders is dan de rechtvaardige verwerking, de onweerlegbare bewijslast kan een happy flow behoorlijk verstoren als we kijken naar het digitale optimisme. Wat dat betreft ben ik het bij hoge uitzondering met Henri eens aangaande de gestoorde procedures;-)
Veel code maar dan 5 en 4 GL volgens jack.
helpt overal tegen, alleen leek mij 5/4GL zo’n beetje de legacy lowcode, nu alweer toe aan overhyped 2.0.
lpar en spar en oeverloos enzo. ewout laat weer eens zien dat hij geen hulp nodig heeft met uit context halen, owja verticale silos. je vraagt je af hoeveel happy flow je moet slikken om het allemaal te kunnen verzinnen.
henri wil eerst weten waar we nou eigenlijk over praten, alsof dat ertoe doet 😉
Mijn ervaring met NoCode is van dezelfde categorie als alle andere Cloud-diensten: het geeft kansen en mogelijkheden. Maar is zeker niet voor alles inzetbaar. Een voorbeeld waarbij het meer dan goed gewerkt heeft.
Medewerkers van de EG kunnen belastingvrij spullen kopen. Daartoe moeten die mensen de bonnetjes en een declaratieformulier indienen bij de belastingdienst. Waarna ze de betaalde belastingen terugbetaald krijgen. En de bijbehorende leverancier dit in mindering gebracht krijgt op de af te dragen belastingen.
Die papierenwinkel werd op enig moment aangevuld met het gebruik van een credit card. Als mensen betaalde met die credit card werd op het moment van betalen alle belastingen op alle relevante plekken automatisch bijgewerkt. Handig voor de koper, verkoper en belastingdienst.
Dat gebruik van een credit card begon ooit eens met de bouw van een java applicatie. Tot voor een jaar of 2 terug hebben daar effectief 6-12 mensen dik 5 jaar aan gewerkt. Dit is exclusief dingen als procesmatige analyses en de afstemming met de belastingdienst.
Omdat nieuwe functies toevoegen en de verwerking van nieuwe regelgeving steeds lastiger en prijziger werd is de switch gemaakt naar een NoCode platform – in dit geval iets dat heet WEM. Die ombouw is door 2-3 mensen gedaan en heeft bij elkaar 4 maanden geduurd. In die periode zijn ook de gewenste nieuwe functies toegevoegd.
Technisch en functioneel applicatiebeheer is teruggebracht van 2 fte naar 1 parttimer. Nieuw en verbouw wordt nu gedaan door 2-3 fte. Deze fte’s doen dan samen ook de procesmatige analyses; waaronder de verwerking van nieuwe regelgeving
In termen van TCO zijn de kosten per jaar meer dan gehalveerd in vergelijking met de java aanpak. Dit is inclusief de bouw van nieuwe functies.
En Will toont nog eens aan dat je met 3 gl prima kunt innoveren ook voor louche praktijken, waarbij het natraject met suffe nocode ftes ingevuld kan worden 🙂
Dat zijn mooie en terechte aanvullingen, Will!
En levert voor mij weer nieuwe inzichten:
Lowcode/Nocode werkt wel als het eenvoudig is en eenvoudig blijft; dan kun je stateless processen maken en dat eventueel in de Cloud.
Lowcode/Nocode werkt niet als het complex is of complex wordt; dan moeten je processen stateful zijn en daarmee veel minder geschikt of ongeschikt voor Cloud-diensten.
Dat ‘eenvoudig is en eenvoudig blijft’ is natuurlijk een behoorlijke valkuil, want veel applicaties beginnen eenvoudig en worden complex!
En dan ben je met low/nocode wel in de aap gelogeerd 🙂
Ofwel: trap niet in de flowchartspaghettival, zoals hier:
https://methodandstyle.com/stateful-decision-models/