Low-code is hot, en dat is niet vreemd. Low-codeplatformen maken het ontwikkelproces sneller door het automatiseren van tachtig procent van de repetitieve programmeerwerkzaamheden. Hierdoor kunnen ontwikkelaars zich richten op de overgebleven twintig procent die specifiek is voor de applicatie die ze ontwikkelen. Met low-code kun je ook complexe applicaties bouwen om regel- en data-intensieve processen te automatiseren. Hoe je dat doet, lees je deze blog.
Core-applicaties moeten exact aansluiten op de context van de organisatie. Dat kan door gebruik te maken van de krachtige combinatie van data en bedrijfsregels, die een robuust framework vormen waarin het datamodel en de bedrijfsregels zijn gecombineerd. Denk aan processen op een luchthaven. Vanaf het moment dat je bij de self-servicebalie je koffer incheckt, ‘stroomt’ data door tientallen applicaties. Elke keer dat je je instapkaart voor een poortje houdt of dat jouw koffer met unieke code langs een poortje komt, wordt data verrijkt en doorgestuurd naar een volgende applicatie.
Met low-code op basis van businessregels kun je niet alleen een complete applicatie bouwen, maar ook headless microservices die ervoor zorgen dat andere applicaties op de juiste manier data uitwisselen. Het zou voor de luchthaven bijvoorbeeld jaren duren om alle bestaande applicaties te vervangen. Het is veel sneller om de functionaliteit uit de bestaande applicaties te behouden en ervoor te zorgen dat ze door nieuwe microservices informatie met elkaar uitwisselen.
Vier stappen naar een complexe core applicatie
Met low-code kun je dankzij de business rule-aanpak applicaties ontwikkelen voor specifieke regel- en data-intensieve situaties. Dit doe je in vier stappen
- Wat wil je bereiken?
Je begint met nadenken over wat je met de applicatie wilt gaan doen. Wat willen we precies bereiken? En hoe hangt dit samen met de andere processen in ons bedrijf?
- Business rules
Als je weet wat het doel is van de applicatie, bedenk je in stap 2 welke regels (business rules) er in deze specifieke case gelden. Deze bedrijfsregels leg je vast op een centrale plek.
- Het datamodel
Vervolgens beschrijf je de data die je nodig hebt om het proces uit te voeren en de manier waarop je die data gaat vastleggen. Ofwel: je omschrijft het datamodel. Welke tabellen gebruik ik? Welke veldtypen zitten er in zo’n tabel? Heeft een veld een een-op-een-relatie met een ander veld of een een-op-meer-relatie? En in welke andere tabellen bevinden die velden zich dan? Anders dan bij traditioneel ontwikkelen hoef je hier geen code voor te schrijven, je klikt het datamodel eenvoudig bij elkaar. Let op, dit is geen taak die citizen developers ook wel kunnen uitvoeren, je hebt grondige kennis van relationele modellen nodig om een (goed) datamodel te ontwikkelen. Conceptueel moet je weten waar je mee bezig bent.
- Technische uitwerking
De laatste stap is om de in stap 2 beschreven regels technisch uit te werken. Op dit punt komen de business rules en het datamodel samen en bouw je dus de applicatie. Daarbij hoef je als ontwikkelaar niet continu groot te denken over hoe een onderdeel samenhangt met andere onderdelen in de applicatie. Je kunt je steeds opnieuw focussen op het technisch uitwerken van één business rule. Als deze business rule conflicteert met een andere regel, dan blijkt dat vanzelf.
Safaritenten
Als voorbeeld een resort. In de eerste stap beschrijf je het doel van de applicatie: wat wil het resort allemaal met de applicaties kunnen doen? Daarna definieer je business rules, bijvoorbeeld: hotelklanten mogen gratis gebruikmaken van de wellness; klanten uit het huisjespark en in de safaritenten betalen een bepaald bedrag. Deze regels worden vastgelegd in gewone, begrijpelijke taal. In het datamodel beschrijf je welke data je nodig hebt: klantdata uit het crm-systeem, transactiedata van alle kassa’s op het resort, reserveringsdata van de boekingssites waar het resort bij is aangesloten, et cetera. In de laatste stap koppel je de business rules en het datamodel door elke regel apart technisch uit te werken. In deze stap komen ook de conflicterende business rules aan het licht.
Deze wijze van software-ontwikkeling plaatst de data altijd op de eerste plek. Je denkt na over de regels in bepaalde stukjes data, de rules engine laat alle losse stukjes tegelijk werken. De rules engine bekijkt alle informatie en pas als alles klopt, worden de data gewijzigd. In deze aanpak modelleer je immers eerst de database. Pas daarna komt de vraag wanneer je data toevoegt, ververst of weggooit. Dat laatste wordt bepaald door de business rules. Die geven aan: als de data aan deze en deze voorwaarden voldoet, dan mag je het oude veld overschrijven.
Met bovenstaande vier stappen zorg je ervoor dat core-applicaties exact aansluiten op de context van de organisatie. Door de makkelijke aanpasbaarheid worden organisaties wendbaar en kunnen zij makkelijk inspelen op veranderingen in de markt en de wereld. De tijd dat low-code alleen voor eenvoudige applicaties werd ingezet, is hiermee definitief voorbij.
(Auteur Frans-Willem Duijnhouwer is pre-sales consultant bij USoft.)
Hoe vreemd dat de stappen die worden uitgelegd precies, maar dan ook exact overeenkomen met het ontwikkelproces zoals het al (volgens mij in elk geval) tientallen jaren gebeurt (of hoort te gebeuren).
En ook opvallend is dat de meest complexe zaken (business rules en technische uitwerking) het minst gedetailleerd zijn.
Low code wordt gepresenteerd alsof je met een taal die lijkt of scratch (https://projects.raspberrypi.org/en/pathways/scratch-intro) wel eventjes een interface met allerhande barcode scanners, en purpose built machinerie kunt maken. En dan ook nog eventjes alle regels van alle bedrijven gewoon met wat klikjes uitvoeren en klaar is Klara…
Verder valt het me op dat over responsetijden niet wordt gesproken. En er zijn heel erg veel koffers die langs een band gaan die heel foutloos en relatief snel door het sorteercentrum moeten stromen. Kijk maar naar de hoeveelheid bagage die in Schiphol dagelijks uit het systeem komen (en niet kunnen worden verwerkt omdat de handmatige verwerking stokt).
Ongetwijfeld zullen er casussen (casi?) die met blokjes klikken of hoog-over-taalconstructies te realiseren zijn. Maar dit artikel doet voorkomen alsof alles met low code is op te lossen.
Werkt voor 10% misschien 20% van de gevallen (en daar misschien nog maar de helft van), maar bijna gegarandeerd niet voor alle andere gevallen.
Ketenprocessen, integratie, APIs, compliancy aan van alles, onprem/cloud, schaalbaarheid, exit strategie, bedrijfsleven zegmaar.
Laten we net doen of die er niet zijn en meteen beginnen met datamodellen aan mekaar clicken.
ow, “je hebt grondige kennis van relationele modellen nodig om een (goed) datamodel te ontwikkelen. Conceptueel moet je weten waar je mee bezig bent.”
Blijkbaar wordt uitgegaan van een relationele database en schaalbaarheid gaat vanzelf. En je moet verstand van zaken hebben, das een tegenvaller.
Kosten per transactie, cpu cycles of vaste maandelijkse kosten ? Lijkt niet zo te boeien, kosten worden niet genoemd in het artikel. Bij een restaurant betekent dat vaak dat ze duur zijn.
Ff de business rules bepalen, al eens geprobeerd in een organisatie ?
Al blij als je iemand tegenkomt die weet waar je over hebt. Meestal doet Pietje ergens een spreadsheet vullen die maandelijks gecopieerd wordt naar HR die
er dan waarschijnlijk ook wat mee doet. Dwz Marietje was daar mee bezig, was die niet overgeplaatst naar andere afdeling ?
“de rules engine laat alle losse stukjes tegelijk werken.”
Zou ik ook zeggen als pre-sales consultant was 🙂
Tja … de vraag is denk ik of je complexe systemen als een bagage afhandelings systeem als een “applicatie” mag zien. Een applicatie kenmerkt zich mijns inziens door interactie met een gebruiker. Vanaf het moment dat je je koffer afgeeft/incheckt tot dat deze in op het karretje of in het vliegtuig geladen wordt komt er onder normale omstandigheden geen mens aan te pas …
Overigens wordt zo’n systeeem in bepaalde zin met een soort low-code ontworpen: het ontwerp vindt plaats op basis van standaard bouwblokken, en middels het ontwikkelplatform wordt vervolgens een groot deel van de besturingssoftware gegenereerd.
Maar zoals CPT meer dan terecht opmerkt: de uitdaging zit in de business rules en technische uitwerking binnen dat platform.
Dit is voor iedere industrie uniek waardoor voor de echt complexe producten low code als concept misschien interessant is, maar heel veel werk vergt om het werkbaar te krijgen
De business rules en het datamodel zijn de spreekwoordelijke olifant in de kamer die iedereen ziet maar waar niemand iets over zegt. Het kan wel maar het mag niet van een onrechtmatig gebruik van klantdata levert hierdoor conflicterende situaties op als we kijken naar juridische ontwikkelingen aangaande transparantie in de algoritmen, zeker als je met low-code een brug over de gebruikelijke silo’s heen legt.
Aan de andere kant is de businesscase interessant want het gaat vooral om sensors en een interessant architectuurprincipe hierin is ‘privacy by design’ als we kijken naar een verwerking van gegevens. Wat betreft de voorwaarden hiervan denk ik dat je daarom niet zomaar even een datamodel bij elkaar klikt als je daarmee veel meer gegevens verkrijgt dan je nodig hebt.
En de business rules conflicteren dan ook steeds vaker met de regels doordat er eigenlijk niet zo goed nagedacht is over het informatiemodel, de aanvullende datasynthese vanuit een ‘situational awareness’ biedt tenslotte meer dan de transactiedata als we kijken naar de ontsluiting van allerlei silo’s middels machine learning. Want eenvoudige applicaties kunnen tenslotte tot een complex informatiesysteem samengevoegd worden.
Oja, de knelpunten in de wachtrijtheorie met de koffers lijken me vooral om de belading van de vliegtuigen te gaan. En leuk of niet zullen we toch meer moeten automatiseren omdat arbeid duurder is dan CPU cycles als ik kijk naar de businesscase van selfservice. Want goedkoop coderen met citizen developers maar duur ontwikkelen lijkt me achteruit automatiseren als ik kijk naar de complexiteit in afhankelijkheid van bedrijfsprocessen. Kent iemand nog een olifantenpaadje?
Een aanpak die al niet werkt vanaf de jaren 80 van de vorige eeuw:
feiten komen in een database en (bedrijfs)regels in een rulebase.
Waar deze aanpak op stuk loopt is het relevantieprobleem (fka: frameprobleem):
“hoe verklaren we ons schijnbare vermogen om beslissingen te nemen op basis van alleen wat relevant is voor een bestaande situatie zonder expliciet rekening te houden met alles wat niet relevant is?”
https://plato.stanford.edu/entries/frame-problem/
Hier kunnen we heel moeilijk over doen, maar het is heel eenvoudig: als ik een appeltaart ga maken kijk ik niet hoeveel aardappelen of koffie ik nog in huis heb.
Voor applicatiebouw moeten we dus niet uitgaan van data (stap 3) of regels (stap 2) maar van de doelen en subdoelen (stap 1) die een actieve rol spelen in de werking van een applicatie.
De vraag is niet “wat je met een applicatie wilt gaan doen” maar wat een applicatie met zowel klanten als bedrijfsmedewerkers (en de verdere Omgeving van de organisatie) gaat doen. En dat is uiteraard een ethisch vraagstuk.
Feiten en regels zijn afkomstig uit de natuurwetenschap en techniek (regelmachines) maar bij applicatiebouw gaat het om natuurlijke taal.
Interessant verhaal en interessante reacties. Mijn vraag is alleen, gaat deze aanpak in het artikel leiden tot architectonische concessies (zoals aan schaalbaarheid en prestaties als in de reacties al opgemerkt)? Of is het eindresultaat op ieder front optimaal. Nauw verstrengeld met het uitgewerkte datamodel heb je stored procedures nodig (sorry Dino/OudLid) waar alle materiefunctionaliteit in is uitgewerkt zonder ook maar een geringste concessie aan welke secundaire voorwaarde dan ook. Dat impliceert voor mj dat alle code voor zowel het functioneren als API-client als als API-Host in de database moet zitten, deze JSON parameters produceren en consumeren en iedere toegang tot tabellen of queries van buiten de database onmogelijk is. Deze stored procedures zijn zeer goed formaliseerbaar en kun je relatief eenvoudig met lowcode generereen.
Voor wat betreft de werking hebben we de huidige menselijke gebruikers als leidraad. Terecht wordt in de reacties opgemerkt dat dit een heel ander niveau van functioneren vergt van de bestaande gebruikers en dus grote gevolgen heeft. O.a. GUI’s op een veel hoger procesniveau.
Jack, mag ik je wijzen op de situational awareness van de temperatuur van de oven? We hebben namelijk een minister die zich hier niet van bewust is als we kijken naar het succes van de appeltaart. Want je opmerking over aardappelen en koffie als je een appeltaart wilt bakken is van hetzelfde niveau. Dus hoe lang nog voordat ze in Den Haag gaan roepen dat we maar taart moeten gaan eten als het brood onbetaalbaar wordt?