We staan aan het begin van een nieuw decennium. En in die komende tien jaar gaat low code doorbreken. Sterker nog: de meeste applicaties worden via low code-platformen ontwikkeld. Dat vertelt Matt Calkins, oprichter en ceo tijdens de Appian-gebruikersconferentie in Londen.
Low code bestaat zo’n vijf jaar en heeft zich volgens de ceo inmiddels bewezen. Het stelt organisaties staat om in een korte tijd snel en goede applicaties te ontwikkelen. En dat is volgens Calkins hard nodig. ‘Er is een exponentiële groei aan het aantal applicaties dat organisaties gebruiken. En er zijn onvoldoende ontwikkelaars beschikbaar om aan die groei te voldoen.’
Om toch die groei aan applicaties te realiseren, moeten developers efficiënter werken. En dat kan volgens de Appian-topman via low code. ‘Vroeger ging programmeren voornamelijk via het toetsenbord. Dat is gericht op het schrijven van instructies. Via low code programmeer je met de muis. In een paar muisklikken ontwerp en bouw je een applicatie. Dat is gericht op de menselijke aspect.’ Hij is ervan overtuigd dat low code het ontwikkelproces versnelt, juist doordat het een kwestie van drag and drop is.
Einde aan legacy
Naast deze versnelling in het ontwikkelproces, moet low code de kwaliteit van applicaties verbeteren. Dit doordat de apps makkelijker updaten naar de hedendaagse standaarden. ‘Iedere organisatie heeft te maken met legacy-applicaties’, vervolgt Calkins. ‘Het is moeilijk om deze verouderde apps naar de hedendaagse standaarden te updaten. En daardoor blijft een organisatie gebonden aan het verleden. Dat mag niet getolereerd worden.’
Volgens hem brengt low code, en specifiek het Appian-platform, hier verandering in. ‘Alle applicaties die op ons platform worden ontwikkeld, draaien native op elk soort apparaat. Van laptops tot smartphones en tablets. En dat voor elk besturingssysteem. En de apps worden automatisch voorzien van de laatste updates.’
Een ander belangrijk voordeel van Appian, is dat de taken binnen de ontwikkelde applicaties ook offline uitgevoerd kunnen worden. ‘Je kunt de taken online cashen en vervolgens offline de taken uitvoeren. De uitgevoerde werkzaamheden worden vervolgens bij internetverbinding automatisch bijgewerkt. En doordat alle applicaties dus altijd up to date zijn, zijn deze apps dus ook beter dan traditionele applicaties.’
Appian
Het Amerikaanse Appian is in 1999 opgericht door Matthew Calkins en medeoprichters Michael Beckley, Marc Wilson en Robert Kramer. De organisatie leverde software voor business process management (bpm). Sinds 2016 biedt het een low-code ontwikkelingsplatform dat voornamelijk grote organisaties helpt om zakelijke applicaties te ontwikkelen en in gebruik te nemen. Wereldwijd heeft het bedrijf zo’n 1.200 medewerkers in dienst. Het Benelux-kantoor is gevestigd in Amsterdam.
Het is wachten op een bedrijf dat met ‘no-code’ oplossingen komt. Nog snellere ontwikkeltijden!
Vele low-code platformen vereisen nog veel Slow-code, het kloppen van code, dus dan is het nog steeds “deels” (s)low-code. Ook de verdienmodellen zijn bij low-code platformen nog steeds “deels” voorspelbaar. Bij een no-code platform is dat beter geregeld, want er hangt geen onvoorspelbare ontwikkelroadmap aan vast. No-code bespaart je ook letterlijk 70 tot 90% software-ontwikkeltijd. Wij hebben vele best-practice cases bij grote enterprise en ook bij kleinere bedrijven en MKB+ bedrijven.
(Deze reactie is aangepast, omdat hij teveel reclame voor de eigen onderneming bevatte. Daarvoor moet men adverteren – red)
Idd gaaf. No-code is de toekomst. Als business analyst heel snel een applicatie bouwen in overleg met de klant en daarbij 70-90% tijdsbesparing op software’-ontwikkeling realiseren, daar gaat het om, dan verlies je ook die tijd niet in je eigen demand cycle (je eigen klant kant). It wordt dan leuk en je realiseert ook nog een roi op het stroomlijnen en optimaliseren van je bedrijfsprocessen, op een visuele manier.
‘online cashen’
typo die de bedoelingen wel duidelijk maakt
Ik ben kritisch over dit soort platformen en dit is waarom.
low-code platformen zitten mijn inziens een beetje met deze filosofie in elkaar: Een business process (dit is de nr 1 target voor low code platformen) is een workflow van stappen, en loops. In iedere stap vind er een bewerking van data plaats, informeer je of heb je een formulier met daarin velden verbonden aan de database en knoppen “die iets doen” zoals opslaan of volgende. Data bestaat uit velden of een tabel voor de child records. Door ook nog een mooie widget te maken voor logica kun je diverse business rules uitvoeren zoals “Bedrag mag niet negatief zijn” of “Moet veld moet leeg blijven als er nog lopende order open staat”.
Plat gezegd elke applicatie of toepassing bevat een proces, formulieren, data, knoppen en business rules die op vriendelijke wijze kunnen worden aangepast en vormgegeven.
Waar gaat het dan mis?
1) Processen zijn veel complexer en rommeliger in de praktijk, dan in theorie. Logica van business rules (decision table genoemd) passen vaak niet, of vergen alsnog expertise en behoorlijk veel code.
2) Het ziet er niet uit en is gewoon niet gebruiksvriendelijk en vrij primitief. Maar goed, kantoor werk en processen hoeven niet sexy te zijn.
3) Processen veranderen en maken daarmee de uitzonderingen in de nieuwere versies extreem veel complexer. Je hebt dan wel een “simpele” interface, maar de onderliggende cluster-fuck zorgt dat er van alles mis gaat. Je hebt dan ook weer dure consultants nodig om dit te beheersen. Alleen nu heb je een vette vendor lock-in. Dat snelle in het begin, wordt nu juist een EXTRA laag. De software maakt tussentijds allemaal verbeteringen door, maar jij kan er niet van profiteren omdat je in feite al met je legacy processen zit.
4) Systemen worden *altijd* complexer hoe langer je ze gebruikt. Complexe systemen komen altijd voort uit simpele systemen die evolueren. Generieke software verplaatst deze complexiteit naar allemaal gekke plaatsen. Vroeger kon je simpel een query bakken omdat het datamodel rigide was. Doordat het datamodel (en ja; interface wordt ook onderdeel van je datamodel) generieker wordt zijn de query’s veel complexer en lastiger te doorgronden.
5) Processen staan nooit op zichzelf en zijn verbonden aan processen buiten je low-code platform of aan andere stromen binnen dat platform. Je hebt te maken met “extract load transform (ETL)” processen of data die komt van andere microservices op bijvoorbeeld de shop van je website of het logistieke proces van levering. En al die reut moet nu ineens in het generieke gedeelte geperst worden… en dat past helemaal niet! Dus dure consultants, lock-in.
Het is verleidelijk. Even een applicatie binnen twee weken live zetten. Maar die winst “aan de voorkant” wordt veelal dubbel en dwars betaald met technische schuld aan de achterkant. Als je dit soort platforms inzet moet je mijn inziens ook rigide zijn in het organisatorische proces. Dus proces niet wijzigen, uitzonderingen beperken, het alleen toepassen op een klein stukje van het proces en alleen voor de happy flow (de standaard en meest wenselijke vorm). Dus ga intelligent om met hoe je het inzet en zet het vooral slim in waar winst te behalen valt.
Ik ben heel benieuwd naar use cases die het toestaan dat de deelnemers in die use case bevraagd worden. En er zullen successen zijn, dat geloof ik graag. Maar een meerderheid van apps maken met low code platforms? Nah.
Daarnaast is het lezen vaak abstract, beter kijk je naar de details en wees waakzaam voor “de snelle jongens” die zonder goede voorbereiding er ineens vol voor gaan om “alles” dan ineens maar low-code te doen.
Zie een Appian demo hier:
https://www.youtube.com/watch?v=Sk6HuQ_klxY
Dat low-code en nocode-tools nog niet de toekomst hebben is een kwestie van doortellen:
3GL – How
4GL – What
5GL – Why
Low-code en nocode zijn hooguit 4GL, maar als iemand daar anders over denkt zie ik graag oplossingen tegemoet op:
https://dmcommunity.org/challenge/challenge-march-2019/
@Henri:
Enigszins off-topic:
Elke vendor, groot of klein, stimuleert het gebruik van zijn eigen specifieke functies. Enerzijds omdat ze zich daarmee onderscheiden van concurrenten; anderzijds omdat het dan lastig (onmogelijk?) wordt om te switchen zonder hoge transitiekosten.
Dat maakt dat elke technologiekeuze (hardware, software, diensten of een combinatie) per definitie een vender-lock is op het moment dat je gebruik maakt van die specifieke functies.
Terug on-topic:
Als het gaat om low-code/no-code platformen is de situatie van nu dezelfde als die van “de cloud” een paar jaar geleden: onbekend maakt onbemind.
Feit blijft dat traditionele, 3GL/4GL softwareontwikkeling (waterval of agile – maakt geen verschil) vooral veel mensenwerk met zich meebrengt. Mensen die dit soort werk kunnen worden steeds schaarser (en daarmee duurder). Om de continuïteit te borgen zit er voor bedrijven niet veel anders op dan op zoek te gaan naar alternatieven. De inzet van een low-code/no-code platform lijkt me dan ook meer dan de moeite van het onderzoeken waard.
Voor de olifanten-organisaties die tot stand gekomen zijn op basis van overnames/fusies is dit misschien niet direct een voor de hand liggend keuze omdat ze vanwege hun geschiedenis inderdaad te kampen hebben met een complexe processen- en tech-debt.
Maar een low-code/no-code platform in combinatie met microservices levert nu wel een vehicle om daar eens wat aan te gaan doen zonder dat het ze de kop gaat kosten.
Maar voor MKB-ers die serieus overwegen om een stuk software ontwikkeling zelf ter hand te nemen lijkt het me een no-brainer. Als er al een processen-/tech-debt is, is die te overzien.
Dat je te maken hebt met omvangrijke ETL-processen is maar zeer de vraag; zeker op het moment dat je werkt met microservices. De marsroute achter microservices is gebaseerd op het ophakken van applicatiecode en data in vele kleine mootjes. Om ze zoveel mogelijk als een zelfstandige entiteit te laten functioneren. De communicatie tussen die microservices gebeurt via een API.
Even los van de uitdagingen rondom security/governance (d.w.z. IGA als onderdeel van IAM):
In hoeverre is er dan nog een noodzaak om allemaal die externe data naar één plek/platform te trekken?
Kortom – moest ik onder de huidige markt en maatschappelijke(!) omstandigheden iets willen doen rondom softwareontwikkeling, dan zou dat zwaar leunen op low-code/no-code. Waarbij platformen als Appian en WEM zeker op de shortlist terecht zouden komen.
🙂