Het verkooppraatje van 'low-code' klinkt zo verleidelijk. Wie wil er immers een maandenlang softwareproject starten bij een ploeg van dure, eigengereide ontwikkelaars, als je ook simpelweg een paar doorsnee werknemers kunt inzetten. Low-code is in opkomst, dankzij tools met intuïtieve interfaces voor het bouwen van software, stelt mensen in staat met een paar klikken applicaties in elkaar te zetten, of althans, in slechts een paar honderd klikken.
Maar aan het voordeel kleven enkele nadelen die het complexer maken dan het lijkt als je naar evangelisten luistert. Achter deze programmeerhulpjes en gedachtelezen interface schuilen enkele duistere geheimen die wat van de glans van de blinkende low-code belofte halen. Laten we even kijken naar de minder vaak besproken elementen.
1. Vendor lock-in
Zoals met zoveel technologieën het geval is, hangt de hoeveelheid werk die je met low-code kunt doen af van de proportionele controle die je hebt. Door werk over te dragen aan de tool, word je er afhankelijker van en hoe meer controle hij krijgt over je proces. Na verloop van tijd begint wat begon als een 'partnerschap' een (mogelijk ongezonde) afhankelijkheidsrelatie met hun stack te worden.
Er zijn manieren om de lock-in te beperken als je low-code tools gebruikt. Je kunt de code schrijven voor portabiliteit, je bedrijfslogica zoveel mogelijk scheiden en isoleren, om vervolgens te verbinden aan een lokale low code API. Als je goed plant, is het niet onmogelijk over te stappen op een andere dienst, maar je verruilt de ene voor de andere en hebt nog steeds die afhankelijkheid. Als je alles naar de eigen servers wilt verplaatsen moet je, je voelt de bui al hangen, de overige code toch zelf schrijven.
2. Slechte onderhandelingspositie op prijs
Cloudplatforms trekken je aandacht met aantrekkelijke prijzen en krikken die later op, als dat enigszins mogelijk is. Omdat je deels afhankelijk bent geraakt van het platform, ben je ook afhankelijk van de prijs die ze stellen. Tenzij je een langetermijncontract tekent, weet je niet zeker wat het product over vijf jaar gaat kosten. Maar als je low-code producten van die back-end afhankelijk is, heb je geen goede onderhandelingspositie en je weet dat de platformprovider dit goed in het achterhoofd houdt bij prijsonderhandelingen.
Het verdienmodel kan bijvoorbeeld veranderen. Een dienst die ooit iets leverde per keer dat je het aansprak, kan in een nieuw model verschuiven naar prijs per bandbreedte. Of misschien komen ze met een hybride-vorm. Je zal waarschijnlijk niet veel andere keuze hebben dan meegaan met het nieuwe model, omdat er anders te veel kosten gemoeid zijn met aanpassingen en toch weer die dure developers.
3. Blackbox
De meeste low-coders houden zich niet bezig met wat er achter de schermen gebeurt. De platforms zijn aantrekkelijk juist omdat ze deze zorgen wegnemen. Maar soms wil je weten wat er precies aan de hand is en dan is het erg lastig om daarachter te komen. Misschien is de code achter de schermen propriëtair. Misschien zitten er echte geheimen achter die API-call, het soort dat beschermt dient te worden. Misschien wil niemand vragen beantwoorden omdat dat het beleid is en de juristen maken het proces taai. Of misschien vindt hun ontwikkelteam je irritant.
Dit is vooral een issue als er toezichthouders bij betrokken zijn. Banken krijgen bijvoorbeeld vragen over aan wie ze leningen verstrekken en om welke redenen. Een AI-dienst in een low-code platform kan wel heel soepel werken, maar veel succes als je vervolgens iemand van de overheid wilt uitleggen wat er precies van binnen is gebeurd om tot deze conclusie te komen.
4. Inefficiënties om problemen uit te sluiten
Het is leuk om de controle uit handen te kunnen geven aan API's, library's en stacks, maar de code achter de schermen is minder efficiënt, omdat het rekening moet houden met een heleboel mogelijkheden. Heeft een sufferd een nullpointer opgegeven? Hebben de functieargumenten de juiste structuur? Dit zijn details die steeds opnieuw worden gecontroleerd, terwijl jouw low-code versie door alle lagen van de code werkt.
Low-code leveranciers moeten de code wel zo foolproof mogelijk maken, want je weet niet wat voor idiote actie je gaat tegenkomen. Dat is technisch allemaal briljant, maar het is een beetje zoals een pantserwagen: veel sterker, maar ook veel langzamer.
5. Beperkte mogelijkheden
De demonstratie is doorgaans fantastisch. Knappe en enthousiaste koppen maken nieuwe, schattige hondendatingsites door een paar regels code te plakken en de createHondenDatingsite-functie op te roepen die heel toevallig in het framework van de code is verwerkt.
Low-code platforms zijn in de regel zo generiek mogelijk zodat het breed toepasbaar is, maar de kans is groot dat je niet zo makkelijk de kracht van de ingebouwde functies gaat vinden. Misschien wil je zowel honden als katten verwerken, maar mogen ze elkaar niet tegenkomen. Misschien is het een asymmetrische relatie, laten we zeggen goudvissen en honden, en de datastructuren moeten hun behoeftes gescheiden kunnen houden.
De details zijn belangrijk voor je - en daarom bouw je de app - maar een low-code leverancier kan onmogelijk al deze behoeftes voorspellen. Software kan flexibel zijn en zich aanpassen naar de behoefte, maar dan moet je er wel bij betrokken zijn. Dat wil zeggen, je moet de code schrijven die het zo aanpasbaar maakt. Hoe flexibeler we het willen, hoe meer code je nodig hebt om dat te specificeren. Meer code is uiteraard geen low-code.
6. Monocultuur
De engste bugs zijn de kwetsbaarheden die we vinden in populaire library's. Als iemand een probleem vind met libssh, om maar een dwarsstraat te noemen, vind je die terug in elke Unix- of Linux-server in het datacenter.
Succesvolle low-code platforms maken een 'monoculture by design' en dat is prima, totdat er een probleem verschijnt en iedereen hetzelfde issue heeft. De netwerkeffecten waar investeerders op zoek naar zijn betekenen meer dan rijkdom: soms betekent het dat alles uit elkaar valt als er een fatale fout zit in het netwerk.
Hier kun je niet omheen. Het goede nieuws is dat iedereen gemotiveerder is om het gat te dichten, omdat we allemaal in hetzelfde zinkende schuitje zitten.
7. Uniformiteit
Een paar jaar geleden ontdekte een hobbyist dat het niet zo lastig is om fabrikanten van auto-onderdelen zover te krijgen delen van hun voorraad op te sturen om ze met de hand samen te stellen. Hij besteedde bijna al zijn spaargeld aan een prachtige eigen carrosserie. Het viel andere autofans op. Is die deurhendel niet van Volkswagen? Zijn dat niet de stoelen van een Porsche 911? Is dat een stuur van een Ford?
Low-code projecten leveren hetzelfde effect op. Ze lijken op elkaar, omdat de ontwikkelaars met dezelfde serie onderdelen werken. Als de code alleen maar een interne taak hoeft te doen, bijvoorbeeld het bijhouden van een inventaris in een magazijn, maakt dat niet uit. Maar als de software onderdeel is van je merkbeleving, gaat die wel heel erg lijken op die van de concurrentie.
8. Verlamming
Met een krachtig low-code platform werken is alsof je in een idyllisch stukje bos aan het spelen bent. Alles is prachtig en simpel, totdat je probeert te vertrekken. Het bos om je heen is gevuld met duisternis, onzekerheid en twijfel - en een heleboel werk. Als er een ingebouwde functie is voor wat je nodig hebt, is het framework geweldig, totdat je iets anders wilt doen. Dan zal verlamming je deel zijn.
Leveranciers prediken graag hun openheid. Elke code is te koppelen. Maar dat het kan, betekent niet dat het makkelijk is. De initiële arbeidskosten van het uitdokteren van de interface kan tien keer complexer zijn dan de simpele feature die je wilt toevoegen. Het is frustrerend om uren, dagen, weken of zelfs maanden te wrikken om te leren hoe je jouw project uitbreidt, maar vaak is dat wel de praktijk van de investering in het platform.
9. Na-apers
Als het makkelijk voor je is om iets te creëren, is het net zo makkelijk voor iemand anders om het te kopiëren. Low-code platforms vermijden in de regel exclusieve relaties. Als de software een ander bedrijf gaat steunen met diens eigen competitieve voordeel, prima. Maar als het maken van die software je bedrijfsmodel is, ga je een heleboel concurrentie krijgen.
-
-
Er zijn nog geen reacties.Reageer
Preview