Software is overal om ons heen. Naarmate meer systemen en apparaten digitaal worden en verbonden zijn met het internet, valt steeds meer op dat ze eigenlijk helemaal niet zo ‘smart’ zijn. Vaak kunnen ze niet met elkaar communiceren waardoor de grootste kansen onbenut blijven.
Smart city’s, smart homes, smart devices. De opkomst van ‘slimme dingen’ is niet te stuiten. Deze ontwikkeling maakt echter ook steeds meer duidelijk dat die dingen, zolang ze niet met elkaar praten, eigenlijk best wel dom zijn.
Leuk hoor, dat je een slimme koelkast hebt die kan aangeven dat de melk bijna op is, maar als je hem open doet, kun je dat zelf ook zien. Het wordt pas interessant als je koelkast zelf melk voor je kan bestellen, of melk op je boodschappenlijstje kan zetten. Of anders op zijn minst een berichtje stuurt zodat je onderweg naar huis melk kunt kopen. Simpel toch? Waarom kan dit dan nog niet? Dat komt doordat apparaten en softwaresystemen niet dezelfde taal spreken.
De toren van Babel
De essentie wordt dan dat er koppelingen komen tussen de ‘traditionele’ transactieverwerkende systemen en de ‘nieuwe’ embedded software. Denk bij transactieverwerkende softwaresystemen aan het overmaken van geld of het doen van boekingen. Die koppelingen zijn nu lastig omdat er verschillende softwaretalen worden gebruikt. Er ontstaat een soort softwaretoren van Babel: de systemen kunnen elkaar niet verstaan.
Om dit op te lossen moeten er platforms komen die internet of things-apparaten in staat stellen met verschillende softwareplatformen te communiceren via een uniform model. Hier is een wereld te winnen voor automatiseerders. Op dit moment is het namelijk zo dat webservices, het onderliggende protocol van software, alleen beschrijft welke taal een systeem spreekt, maar niet wat de code betekent. Daar heb je alleen iets aan als het andere systeem deze taal machtig is.
Om dit op te lossen is dus een model nodig dat ervoor zorgt dat de boodschap aankomt, ongeacht welke talen de devices en systemen spreken. Een geautomatiseerde vertaling van de verzender naar de ontvanger. Als je ervan uitgaat dat alle softwarecode handmatig wordt gecreëerd, is dit een bijna onmogelijke opgave. Met modelgedreven codegeneratie wordt het echter wel mogelijk. Hierbij zijn functionaliteiten immers volgens een vast stramien vastgelegd zodat ze snel te herkennen zijn en eenvoudiger geautomatiseerd omgezet naar een andere taal.
De gouden eeuw van low-code
Modelgedreven softwareontwikkeling is na dertig jaar eindelijk tot wasdom gekomen, zo concludeerde ik eerder al, maar het heeft nog een gouden toekomst in het verschiet. Ik zie in low code-platformen de oplossing die het genereren van embedded software én de koppelingen mogelijk maakt. Daardoor kan niet alleen IoT écht smart worden, maar de ontwikkelaars ook. Dat zal echter nog best een uitdaging zijn. Het leuke van standaarden is immers dat er er genoeg zijn om uit te kiezen en er is er altijd wel één die niet past.
De eerste ontwikkelingen op het gebied van embedded software zijn inmiddels op de markt en zie je vooral in sectoren als de maakindustrie en de zorg, maar ook de automotive maakt veelvuldig gebruik van embedded systemen. Persoonlijk kan ik niet wachten tot embedded systemen echt gemeengoed zijn en zolang de oplossing die ik zoek nog niet te genereren is, zet ik het gewoon zelf in elkaar. Zo heb ik onze Roomba robotstofzuiger thuis via sensoren gepromoveerd tot muizenverjager, maar dat vereist wel low level coding in zowel php, Python, Javascript, Perl als Json. Ik kan niet wachten totdat ik die interfaces kan modelleren en genereren.
De eerste stappen zijn gezet en de komende tijd zullen er steeds meer voorbeelden komen van fysieke apparaten die gekoppeld zijn met niet-fysieke (software)onderdelen. En wanneer de toren van Babel eenmaal afgebroken is, zijn de mogelijkheden eindeloos.
Intrigerend. Interessante redenering, maar ik ben het er niet helemaal mee eens.
Mijn beeld is dat de auteur suggereert dat we IoT / smart devices pas goed kunnen koppelen met klassieke transactie systemen door het gebruik van modelgedreven codegeneratie uit low code-platformen.
Volgens mij kunnen die deze koppeling wel eenvoudiger maken (en dus sneller economisch verantwoord), net zoals ze transactie systemen en apps sneller kunnen maken, maar is het geen noodzakelijke voorwaarde. Het feit dat deze koppelingen gewenst worden, hangt meer samen met verbeteringen in internet, de IoT sensoren, en de wens om steeds verdergaande dienstverleningen te realiseren. Ook vroeger zou het best gekund hebben : er is best een koppeling te maken tussen embedded software en transactie software : ‘gewoon’ een vertaling maken, een kwestie van goede afspraken maken. Het is alleen veel werk, en vanwege de vele verschillende omgevingen niet schaalbaar genoeg om economisch te zijn. Maar als het nodig is, worden er interfaces gebouwd, al heel lang. Een recente aanwinst zijn daarbij Webservices. Formeel bevat hun specificatie alleen de structuur, en niet de inhoud (semantiek), maar de structuur beschrijving (in WSDL) is wel een standaard, waarmee de vertaling vergemakkelijkt wordt, omdat de structuur al afgesproken is, en alleen nog over de inhoud afspraken gemaakt hoeven te worden.
Daarin ligt ook de kracht van low-code : de structuur is al afgesproken (binnen een platform), men kan zich concentreren op de inhoud. Transactie systemen en apps kunnen al met low-code gegenereerd worden. Als nu alle andere software, zoals embedded software en bv SAP ook nog met low-code gegenereerd kan worden, is integratie met die systemen een fluitje van een cent ;-). Alleen is dat een ideaal beeld (zie de robotstofzuiger) dat nog wel even op zich zal laten wachten, hoewel sommige ontwikkelingen misschien sneller komen dan men verwacht. Tot dan toe vereist integratie toch nog wel het handmatig bouwen van een koppeling.
Interessant, die toren van Babel vergelijking. Zou God slimme apparaten willen? En standup meetings, turnkey oplossingen, hyperconverged, burnout oriented architecture, zelfsturende teams of stofzuigers, ICT life cycle decommissioned 50 plussers?
Misschien houdt hij die onzin wel tegen. Spread the word. De kloof tussen business en ICT is God driven.
Natuurlijk kan er nu al gebouwd en gekoppeld worden, Paulus. Mijn punt is dat het nu te veel geknutsel is. Dat moet en kan beter, professioneler, bijvoorbeeld met modelgedreven software ontwikkeltools. Vergelijk de situatie nu maar met de beginjaren van het internet. Toen moest je ook zelf TCP/IP drivers op je computer installeren om verbinding te maken. Om over het krijsende inbelmodem maar te zwijgen. En kijk nu eens…
Met je reactie ben ik het weer grotendeels eens, Eric. Het modelmatig ‘bouwen’ gaat zeker beter dan alles handmatig doen.
Mijn bezwaar is dat ik vind dat de suggestie gewekt wordt dat het koppelen ook eenvoudig gaat als je maar low-code gebruikt. Dit staat vooral in de alinea ‘Om dit op te lossen is dus een model nodig dat ervoor zorgt dat de boodschap aankomt, ongeacht welke talen de devices en systemen spreken. (…) . Hierbij zijn functionaliteiten immers volgens een vast stramien vastgelegd zodat ze snel te herkennen zijn en eenvoudiger geautomatiseerd omgezet naar een andere taal.’
Dit zou mogelijk kunnen werken als het andere systeem met het zelfde low-code platform werkt, maar in de praktijk hebben andere systemen hun eigen toegangs-specificatie, waarvoor dan een connector moet worden gemaakt. Als het een veel gebruikt systeem is, wordt dat natuurlijk snel een keer gemaakt , en hopelijk gedeeld (bv in the Forge van OutSystems), maar het blijft een handmatig gemaakte connector, die ‘daarna’ ingebed kan worden in het model.
Dino, het is maar net hoe je God definieert.
Als je een boeiend relaas wilt lezen over ‘De lotgevallen van God en de ziel’, dan kan ik je het magnum opus van de Nederlandse filosoof Henk van der Waal: Denken op de plaats rust (2012) beslist aanbevelen.
https://www.groene.nl/artikel/waarheen-leidt-de-weg-die-wij-moeten-gaan
Oops ” low level coding in zowel php, Python, Javascript, Perl als Json”
daar sla ik stijl van achterover!
Dat dat al “low-level” genoemd wordt . . . . .
@Jan van Leeuwen : geen wonder dat je steil achter over slaat, als je “low-level” gelijk stelt aan “low-code”.
Het is nl zo dat “low-code” eerder “high-level” genoemd kan worden.
Het is ook NIET hetzelfde, gezien de volgende teksten vd auteur :
mn ” zolang de oplossing die ik zoek nog niet te genereren is” (met low-code dus) in “Persoonlijk kan ik niet wachten tot embedded systemen echt gemeengoed zijn en zolang de oplossing die ik zoek nog niet te genereren is, zet ik het gewoon zelf in elkaar.” (met low-level ipv low-code dus)