23: Low code: Thinkwise met Anne Buit

Hey en leuk dat je luistert naar een nieuwe aflevering van DevTalks. Wij zijn developers met een passie voor techniek. In deze podcast bespreken we de laatste trends op het gebied van software development. Vond je dit nou een leuke aflevering? Laat dan een like achter in je favoriete podcast app en heb je feedback, laat dan een reactie achter of stuur een mail naar podcast.cloudpublic.nl. Hallo en welkom bij deze 23ste aflevering van DevTalks. Vandaag zitten we met Anne buiten over Tinkwise. Welkom Anne. Hallo. En natuurlijk Florian Schaal. Hallo allemaal. We gaan het vandaag hebben over Tinkwise. Dit is onze tweede aflevering van de low-code serie. Zoals gezegd hebben we vandaag als gast Anne buiten. Anne is R&D manager bij Tinkwise Software, een bedrijf in Nederland, gevestigd in Apeldoorn. En as a matter of fact zijn wij oud collega's, Anne. Ja, dat klopt. Het is ondertussen zes jaar geleden volgens mij dat je ons verlaten hebt. Ja, het voelt als gisteren. Het voelt als gisteren. Nee, maar het is wel leuk om toch nu bij de low-code serie aan het opnemen zijn. Kunnen we Tinkwise zeker niet overslaan. Het is ook al echt een gevestigde naam in Nederland aan het worden. Is het al. Zeker. Dus dat is helemaal mooi. Hé, maar Anne, kun jij ons wat vertellen over Tinkwise? Yes. Tinkwise, zoals je zegt, is er al een tijdje. We bestaan zo'n 19 jaar, opgericht door Robert van der Linden en Victor Klara. En Robert van der Linden, de oprichter, die had in Amerika een SAP-bedrijf gehad, die heeft dat daar verkocht. Victor Klara heeft daarvoor gewerkt aan een groot enterprise systeem. En allebei vonden ze dat die softwareontwikkeling, dat was toch allemaal wel wat handwerk. Dat was een industrie eigenlijk die heel aanwachtelijk was. En ze hebben gezocht om dat te verbeteren, dat efficiënt te maken. En daar is Tinkwise eigenlijk uitgevoerd gebloeid. Om softwareontwikkeling toch naar een hoger niveau te trekken. En dan specifiek gericht op enterprise-applicaties. Zo ja. En dat is, als ik het goed heb, in 2002 opgericht. Als we het nu hebben over low-code, dan denk ik dat veel van onze luisteraars zullen denken van, hé, dat is toch wel echt een trend van de afgelopen, nou ja, pak een beet. Misschien vijf jaar geleden maximaal. Maar ze zijn het dus eigenlijk al bijna twintig jaar bezig. Ja, ik denk dat de naam low-code, die is natuurlijk wat recentelijker geïntroduceerd. Het is ook een goede beschrijving wat het is. Maar het is in zekere zin toch ergens ook wel model-driven in een nieuw jasje, of visueel programmeren in een nieuw jasje gestopt. Het is eigenlijk dat je niet zozeer met code applicaties bouwt. Dus meer decoratief applicaties bouwt. Dus meer beschrijft hoe een applicatie zou moeten werken en op basis daarvan de applicatie ontwikkeld. Oké. Als we dan even inzoomen op het Thinkwise-platform, want zo heet het volgens mij tegenwoordig. Wat eigenlijk een suite is van tools. Correct me if I'm wrong, want ik ga het nu een beetje uitleggen terwijl jij de experte bent natuurlijk. Maar dat is dus een suite van tools of development tooling waarmee je op een low-code manier applicaties kan bouwen. Kun jij ons even uitleggen wat voor onderdelen er in het platform zitten en hoe het in de hoofdlijn werkt en is opgezet? Het Thinkwise-platform is inderdaad een verzameling van tools en applicaties waarmee je op een modelgedreven manier, op een low-code manier, enterprise applicaties kan ontwikkelen. Dus echte ruggengraten van bedrijven, grote applicaties die ook decennia mee moeten gaan. Decennia. En misschien nog wel langer. En dat is niet zo triviaal. Als je tien jaar geleden zegt van nou, bouw maar een applicatie die de komende twintig jaar meegaat. Welke technologie gebruik je? En hoe zet je dat op? En dat dat ook in de architectuur van vandaag nog goed werkt. Dat is wat het Thinkwise-platform biedt. We bieden een IDE. Het is de Software Factory, heet dat. En daarin kun je de modellen maken. En een model is dan een applicatie die je daarin maakt. En daar beschrijf je alles van die applicatie. Je beschrijft hoe de datastructuur in elkaar zit. Je beschrijft hoe de processen in elkaar zitten. Je beschrijft hoe de user interface gevisualiseerd moet worden aan de gebruikers. Hoe de rechte inrichting zit. Er zit ook een specificatie- en workmanagementmodule daarin die je kan gebruiken als je niet je eigen specificatie- en workmanagement gebruikt. Maar dat is een model. Dat leeft nog niet. Om dat tot leven te wekken, hebben we bijvoorbeeld een runtime-componente. Die runtime-componente, dat is een bepaalde technologie. Want het model is helemaal los van technologie. Dat model, dat beschrijft het echt. Dat klopt over twintig jaar nog steeds, zeg maar. Maar ja, dat moet tot leven gewekt worden door technologie. Die functionaliteit moet... Nou, dat doen de runtime-componenten. En de runtime-componente, dat zijn servicetears. Dat zijn user interfaces. En die laden dat model en die vormen zichzelf naar dat model. Dus als er in het model staat dat er een entiteit verkoopfactuur is, dan maakt de servicelaar daar een API voor. Als er in het model staat dat er een menu-item voor die verkoopfactuur is, dan maakt de user interface at runtime dat menu-item daarvoor aan. Heel kort aan de hoogte. En die runtime-componenten, dat model is specifiek voor elke applicatie die ermee ontwikkeld wordt. En die applicaties zijn helemaal gericht op maat voor de oplossing. Dus je hebt niet dezelfde als de buurman. Het is echt een applicatie voor jou. Die runtime-componenten worden geleverd door Thinkwise. En worden onderhouden door Thinkwise. Dus je hoeft je niet meer als developer los druk te maken over je browserversies en iOS-versies en allerlei soorten zaken. Dus die technologische uitdaging ligt bij onze research en development afdeling. En dat zijn distributables, binaries, die om kunnen gaan met elk model. Dus wij leveren één desktop user interface uit, die laat het model en die kan vervolgens omgaan met elk model. Even daarop inzoomen. Want volgens mij in de low-code of in de model-driven wereld heb je daar twee soorten kampen of smaken. Je hebt de code generation, wat we toch ook bij systemen als OutSystems voorbij zien komen. Maar Thinkwise heeft echt gekozen voor runtime-interpretatie, als ik het goed heb. Dus waarom is die keuze voor runtime-interpretatie gemaakt? Wat voor logica zit erachter? Wat voor argumenten hebben jullie daarvoor? Ja, de runtime-interpretatie heeft een aantal interessante voordelen. Kijk, het eerste is natuurlijk dat je op het moment dat er wijzigingen komen, dat er updates komen, dat je niet opnieuw de hele user interface hoeft te genereren. Of niet opnieuw de hele servicelage hoeft te genereren. Dus je kan veel sneller updates aan die user interface zelf en de servicelage zelf veel sneller in productie krijgen. Het is gewoon die executable deployer. En die zijn ook van heel hoge kwaliteit, echt enorm hoge kwaliteit. Als er een issue in zou zitten, iedereen heeft dan die issue, dus dat kun je niet hebben. Daarnaast is het ook van, als je een generator gebruikt, dan kun je ook daarna nog even erin gaan sleutelen. En dat willen we eigenlijk niet, want dan kun je niet nog een keer genereren, zonder dat je je wijzigingen daarin weer overschrijft die je hebt gedaan. En daarnaast heeft het ook het voordeel dat je die user interfaces en ook die APIs enzo, dat die best wel klein blijven, beperkt blijven tot hetgene wat ze moeten bieden, wat ze moeten exposen. Dus stel je voor dat ik een afstandsbediening heb en die afstandsbediening wordt gericht op mijn tv, mijn tv heeft niet zoveel functies, ik heb ook geen smart tv, dan zou ik een heleboel knoppen van die afstandsbediening af moeten halen, omdat ik dat niet gebruik. In plaats daarvan, als ik bij een Thinkwise applicatie rechten uitdeel op het model, dan vallen gewoon delen van het model weg. Die user interface weet geen eens dat die delen van het model er zijn. Dus mijn client heeft helemaal niet die informatie en die APIs bestaan niet. Ik krijg niet een authorized terug, ik krijg een 404 terug, als ik een entity probeer te benaderen die toegankelijk is voor mij. En daarnaast ook wanneer ik gebruikersvoorkeur heb. Bijvoorbeeld als ik bepaalde schermen net iets anders wil hebben, dan kan ik dat nog als laagje bovenop het model doen. Hoef ik niet opnieuw uit te genereren voor mijn nieuwe user interface, uit te genereren waarin dat anders is. Nee, het is gewoon een extra laag bovenop dat model. Het is allemaal nog kneepbaar, zelfs in een productieomgeving. Dus dat zijn wel enorme voordelen wat betreft runtime interpretatie. En hoe zit dat dan met de performance als je daarnaar kijkt? Ja, dat is iets waar wij voor verantwoordelijk zijn. Dat dat snel gaat. En daar werken we continu aan om ervoor te zorgen dat dat snel blijft. Maar daardoor kunnen we ook best wel mooie technieken toepassen om ervoor te zorgen dat dat altijd goed gaat. Dus er wordt ook wel een stukje, als je dat model inlaadt, wordt dat model ook wel gecached door de user interface. Dan is het scherm opnieuw open, dat die niet weer het model gaat inladen om zichzelf te vormen naar dat model. Dus daar zitten echt wel mechanismes in. Maar daar hoef je als developer niet druk over te maken. Nee, precies. Dus dat wordt dan weer door de runtime geleverd. Ja. Maar dus even een stapje terug weer. Even het grote plaatje schilderen. Dus Thinkwise heeft een software factory gemaakt waarin je je applicatie modeleert van datamodel tot aan UI. Ik heb dingen gezien over processtromen. Allemaal dat soort zaken. En dat model, dat publiceer je een soort van. En de runtime componenten die jullie hebben, dus niet alleen UIs, maar ook de APIs, zeg maar, die lezen dat in. En die vormen zich dan gegeven dat model. Dat klopt, ja. En even dan voor developer herstel. Dus die runtime componenten die jullie ontwikkelen, dus de developers die bij Thinkwise werken, bij jou op de R&D afdeling volgens mij, die dan zo'n abstracte frontend of een abstracte API moeten bouwen. Hoe maak je zoiets, zeg maar? Ja, dat is niet zo makkelijk. Kijk, als je kijkt naar de meeste applicaties die je ontwikkelt, die maken gebruik van iets van een entity model. Maar ja, de applicaties die wij ontwikkelen, de runtime API, of een van de runtime clients, daar kun je niet een entity model in zetten. Want je weet van tevoren niet wat de entities zijn. Je weet van tevoren niet wat de schermen zijn. Dus die worden heel abstract opgezet. En dat is iets wat je niet zo veel ziet. En we moeten ook, als we daar componenten in zetten, heel specifiek selecteren dat die heel goed at runtime opgebouwd kunnen worden, in plaats van dat die van tevoren helemaal definitief ingericht moeten zijn. Want dat werkt gewoon voor ons niet. Dus ja, dat is een uitdaging. En dat vereist ook wel een bepaald abstractieniveau van onze developers, om dat te kunnen doen. Het onderdeel van het testen van zoiets, de applicatie is onderdeel van je testbasis, om het dan even zo te zeggen. Ja, en de variaties daar zijn een soort van oneindig. Want iedereen kan in de software factory zijn, een combinatie van formuliertjes of van lijsten maken, die dan, ja. Dus dat lijkt me wel dan, ik heb daar zelf natuurlijk zes jaar geleden dan ook aan gewerkt, waarin dat zo anders is dan dat je echt een applicatie gaat uitprogrammeren op basis van, wat je zegt, zo'n entity model. Ja, dat klopt. Maar als ik het ook goed heb, dus Tinkwise, het Tinkwise platform, dat maken jullie ook met Tinkwise. Ja, dat klopt. Hoe is dat mogelijk? Oké, we moeten nog even die één deel afmaken, wat betreft waar het platform uit bestaat. Wat hebben we gehad over de software factory? Wat is de idee waarin het model gemaakt wordt? In de beheeromgeving wordt een andere applicatie neergezet, want in de software factory is dat model aanpasbaar. In de beheeromgeving is dat model, in ieder geval datum model en logisch technisch, is het niet meer aanpasbaar. Op UI-gebied kan er nog een laagje overheen, om het echt specifiek in de user setting te tailoren, en de rechten kunnen daar nog overheen gaan. En in een productieomgeving wordt het beheerd vanuit, dat heet intelligent application manager. En we hadden die naam heel lang geleden, hadden we die al, en de afkorting daarvan is IAM, en daardoor clash dat in de begrippen nog wel eens met, identity and access management van verschillende cloud services en zo. Maar dat is een aparte tool, misschien moeten we hem hernoemen. Ik denk niet dat we dat gaan winnen. Het is een aparte tool. Daarin wordt dat model dus, of in ieder geval het model dat nodig is voor de runtime componenten, wordt daarin geplaatst, en kan vervolgens in de gebruikerscontext, kan dat worden geautoriseerd, en kan dat worden beschikbaar gesteld. Om er nog één kleine aanvulling over te maken, die runtime componenten, die komen en gaan. Dus we hebben al een, zeven of acht of zo runtime componenten gehad, dat zijn verschillende soorten user interfaces, in verschillende technologieën. Heb je daar voorbeelden van? Wat was nou bijvoorbeeld de eerste runtime UI, die er is gemaakt? Dat was een Visual Basic, Visual Basic 6 user interface, denk ik. Dus die laden ook dat model, en die vormen zichzelf naar het model, maar die technologie is al, daar hebben we op een gegeven moment afscheid van genomen. Dat hebben we vervangen met eigenlijk twee, ook desktop UIs, dat was een Java IoT desktop UI, en ook een .NET 2.0 WinForms UI. Nou die heeft zich, die .NET 2.0 WinForms UI, die heeft zich wel wat verder nog mee te evalueren, naar 3 en 4.5 en 4.7. De Java desktop UI, die bestaat al niet meer, en de Visual Basic UI, die bestaat ook al niet meer. We hebben nog een Java Web, dat was een JSF UI gehad, die op dezelfde manier werkte, dus die kon hetzelfde model inladen, en die vormde dan een web-applicatie, met hetzelfde model, die functioneel gezien dus precies hetzelfde deed. Dus die laat dan een, wat voor systeem dat dan ook is, een ordersysteem ofzo, en dan had je vervolgens je ordersysteem, door die UI in te zetten, had je hem ineens op desktop en op web. En voor de rest werkte het hetzelfde. We hebben een mobile UI, dat is een Cordova gebaseerde UI, die wel een beetje ondertussen, richting end-of-life aan het gaan. We hebben een ASP.net Web UI, die is ook nog actief, maar die technologie is ook al behoorlijk, end-of-life aan het gaan. En we hebben een React User Interface, en dat is een Progressive Web App, dat is de nieuwste UI. Dus op dit moment zijn er vier UIs, worden nog actief onderhouden, en een aantal is al afscheid van gedaan. Maar je moet dus nagaan, dat mensen die negentien jaar geleden begonnen, en die een Visual Basic User Interface hebben, hebben nu dezelfde applicatie, hebben ze nu op desktop, en op mobile, en op web, zonder dat ze daar zelf technologische uitdaging bij hadden, om dat te doen. Die Red Hat componenten zijn gewoon pluggable, die kunnen met elk model omgaan. Ja. Hoeveel effort gaat er wel niet in, om zo'n nieuwe UI dan te maken? Zeg maar die PWA, hoe lang hebben jullie het over gedaan, om die dan te bouwen? Ja, daar gaat echt vele man-jaren in zitten. Je moet nagaan, dat de software factory zelf, het platform zelf, wat je in het model kan beschrijven, dus dan hebben we ook de software factory, en ook deels de intelligent application manager, dat wordt ook continu uitgebreid. Dus daar komen nieuwe features, die je kan modelleren, worden eraan toegevoegd, en die moeten alle Runtime componenten ook begrijpen, en moeten dat ook toevoegen. Dat betreft groeit het ook in de breedte qua features. Als we een nieuwe UI ontwikkelen, moeten die al die features ook gaan ondersteunen. Dus de features die je nu in de PWA hebt, die zijn vele malen meer dan die in de VAB, die de VAB ondersteunen. Ja, vele malen meer, vele malen meer. En overigens, alle features die in de VAB groeien, die zitten er nog steeds in. Je kan nog steeds die hele traject afleggen, om naar de modernste versie te komen. Dat is simpelweg een upgrade. Maar dan kun je wel die nieuwe features ook allemaal gebruiken, inderdaad, in jouw applicatie. Dus inderdaad, er gaat echt veel tijd zitten in het ontwikkelen van een nieuwe UI. We kunnen dat wel heel attractief doen. Bij wijze van spreken feature per feature kunnen we dat toevoegen. De React User Interface heeft op dit moment ook nog niet alle features. Er zit bijvoorbeeld een feature in voor drag-drop, dat je iets van een bepaald onderwerp naar een ander onderwerp kan verslepen, dat er dan iets gebeurt. Dat zit er op dit moment nog niet in. Maar dat voegen we dan ook toe. En we kijken ook een beetje wat er op dit moment nodig is, voor mensen die die UI inzetten, om die projectering erin te bepalen. Maar dan denk ik ook, stel je hebt die drag-and-drop feature op een bepaald platform nodig, dan kun je denk ik die runtime ook gewoon switchen naar een runtime, die dat wel support bijvoorbeeld. Dat klopt. Die kun je gewoon naast elkaar draaien. Ja, dat is wel mooi ja. Zie je dat bij klanten dan ook vaak terug, dat ze bijvoorbeeld, noem maar wat de power users, de orderverwerkers, die zitten op Windows GUI ofzo, en de verkopers die werken met de PWA op een mobieltje? Ja, zeker. Dat is het verschil. En je kan daar ook als developer een beetje op voorstorteren. Je kan wel zeggen, nou, door richting een bepaald platform, wil ik toch wel wat andere delen van het model beschikbaar stellen, zodat je je hele enterprise systeem op je mobieltje, weet ik niet of dat altijd nuttig is, dus dan kun je daar, maar normaliter heb je overal alles, maar je kan dat inperken richting bepaalde platformen, als je dat wil. Ja, dus je ziet wel dat dat gebeurt. En het is ook een beetje wat je fijn vindt. Dat is een beetje non-functional, maar de ervaring in web, soms voelen dingen toch net wat anders, dan op een desktop applicatie. Dus ja, je ziet zeker meer dat de power users, die bij wijze van spreken geen eens kijken naar de applicatie, dat die misschien meer met een desktop client werken, dan met externe partijen. Even inzoomen het op het code gedeelte in low-code. Een van de side-effects van runtime interpretatie, lijkt me dat je minder code in de clients kan draaien. Bijvoorbeeld in de PWA, bij andere systemen, zoals bijvoorbeeld een out-system zien we nogal eens, dat mensen ja-verskips schrijven, om bepaalde, ik noem maar wat, mooie lodetjes of zo te laten zien in de front-end, als iemand wacht, of andere zaken, custom componentjes, dat soort dingen. Als je runtime interpretatie doet, is dat dan per definitie ook zo, dat de front-ends niet extensible zijn, qua eigen codeschrijven? Dat het toch allemaal op database of in de API afgehandeld wordt? Het klopt inderdaad dat je ingrijpen op de user interface, dat is dan wat minder makkelijk. Dus zelf wat JavaScript toevoegen, je moet nagaan, dat zit ook niet in de andere clients. En dan gaat het ook niet mee met technologische updates. Ik bedoel, we denken nu dat JavaScript de komende tijd nog wel even meegaat, maar is het er echt nog over twintig jaar? En wat dachten we twintig jaar geleden, dat het vandaag de dag nog allemaal zou zijn? Ik bedoel, Habbo Hotel, die moesten Flash-disciplines terugbrengen. Habbo Hotel, mooi voorbeeld. Ja, maar kijk ook naar Silverlight of zo, hoe rap dat weer ging voor HTML5. Dus het is een beetje gevaarlijk om heel erg in die front-end technologie te gaan zitten. Aan de andere kant, begrijp ik ook wel, dat er soms gewoon business case voor zijn. Soms is het gewoon het waard om het te doen, met inachtname van dat het dan niet naar nieuwe user interfaces, technologieën overgaat. Dus het is zeker wel extensible. Je kan daar gewoon je eigen component in de schermen embedden, en daarin doen wat je wil. Maar dan wordt het wel honderd procent jouw verantwoordelijkheid. En dan kunnen we als Thinkwise daar natuurlijk geen updates op leveren. Ja, precies. Dan wordt het, ik denk, stel je zit dan op zo'n VB en je hebt er heel veel custom components voor geschreven, dan wordt het natuurlijk ook een hele fractie lastiger om dan naar de nieuwste versie te gaan. En dan zul je dus dat allemaal die migratie zelf moeten doen waarschijnlijk. Ja. Misschien heb je het geluk dat het component dat jij had gebouwd, ondertussen een standaard onderdeel van de platform is geworden. Dat gebeurt op zich wel eens hoor. We hebben het bijvoorbeeld gehad met een Maps component, dat eerst als custom component begon, en dat nu een standaard component is geworden van een platform. Hetzelfde met schedulers, die eerst heel erg op maat specifiek voor scenario's werden gemaakt, en daar hebben we nog een abstracte versie van. Ja, dan kun je gewoon een scheduler declaratief definiëren. Maar je hebt er helemaal gelijk in. Je moet daar wel mee oppassen. Ja. Maar in een enterprise systeem kan ik me voor... Ja, tenminste, het lijkt me dat je met het modelleren van de applicatie, het datamodel, de UI, de processtromen, dat je daar niet mee wegkomt. Dus dat je op een gegeven moment wel echt logica moet gaan schrijven. En dan zien we dat bepaalde low-code systemen daar een eigen taaltje voor maken, waarmee ze, dat zien we bijvoorbeeld bij OutSystems, dat ze een taaltje eigenlijk creëren die niet vast zit aan hun techniek. Dus dat ze een eigen compilatieslag maken of iets dergelijks. Hoe gaat Thinkwise daarmee om? Ja, we zijn daar een beetje voorzichtig mee, met een eigen taaltje maken, want het is natuurlijk niet zo makkelijk. Je krijgt best wel een hoop drempel om dat te gebruiken. We hebben binnen het platform, eigenlijk proberen we zoveel mogelijk te modelleren. En eigenlijk, dat zijn al die gedragszaken en zo, die worden allemaal gemodelleerd, worden allemaal geboden ook door de UI. De UI lost ook daarin zelf een heleboel op, en de API. Dus bijvoorbeeld, al ga je naar een andere... Je selecteert een andere rij, je wilt de detailgegevens, die moeten dan ook bijwerken. Daar hoef je helemaal niks voor te doen, dat gebeurt gewoon automatisch. De UI pikt dat op. Maar ook zaken zoals dat je een toevoeger wilt verwijderen, een wijzer, dat soort zaken, om altijd voor weer en about te gaan. Dat wordt allemaal voor je gedaan, daar hoef je niks voor te doen. Je kan op het hoofd zeggen, dat wil ik niet aanzetten in dit geval, of dat wil ik wegautoriseren. Maar er zijn natuurlijk altijd zaken die je niet echt kan modelleren, of dat als je die zou modelleren, dat zo'n model complexer wordt dan dat je een paar regels code schrijft. En dat zijn over het algemeen specifieke businessregels, of constraints, een staffelbepaling, of een leverdatumbepaling, of zo'n soort zaken, waar toch wel wat logica aan te pas komt. En we plaatsen die logica zo diep mogelijk in de backend. Dus daar gebruiken we standaard het SQL-taal van de database. Meestal zijn dat ook dingen waar je gerelateerde data voor nodig hebt. Waar je toch een aggregatie moet doen over wat andere gegevens die eromheen zitten, of wat controllers moet doen over gegevens die eromheen zitten. Dus we hebben een aantal vaste logica-concepten, en de user interface en de API weet ook wanneer die een rol gaan spelen. En dan doen ze een call naar de backend om te kijken, oké, wat voor dynamisch gedrag kunnen we hier in werking laten treden. En op die manier kun je in principe die uitstapjes maken naar code waar dat nodig is. SQL is niet geschikt voor bepaalde zaken, zoals tekstaggregaties of machine learning, of zo'n soort zaken. Dus op zo'n soort punten koppelen we met externe services over het algemeen. Dus dan wrap je dat in een service, en dan zorg je ervoor dat die met die service op die manier communiceert, zodat dat ook geïsoleerd blijft. Oké, maar kun je ook logica meer op een API-niveau definiëren? Is dat dan C-sharp of Java, of dat is dan in ieder geval geen SQL, lijkt me? Nee, want op het moment dat we dat zouden doen op die manier, dan zouden we ook eigenlijk zeggen, die logica-laag moet van een bepaalde technologie blijven. Dus de logica-laag is op dit moment een .NET Core applicatie. Als we dan zouden switchen naar Node.js, ik denk niet dat dat gaat gebeuren, maar dan zou je die logica op die manier niet meer kunnen draaien. Dus daar zijn we wel een beetje voorzichtig mee, want dit zijn applicaties die enorm lang mee moeten gaan. En dan is het een beetje gevaarlijk om de technologie te winnen, en je ziet dat op database-niveau, zulke soort database-platformen zijn enorm stabiel. Die blijven echt gewoon goed werken. Je ziet dat met een Microsoft SQL Server, die databases die vroeger on-premise hadden staan, die kun je tegenwoordig ook prima als Azure-databases verder laten leven, zonder dat je die overhoop moet gooien of zo, qua logica. Dus wat dat betreft proberen we, als er dan ook wel code nodig is, om dat in de meest stabiele plek neer te zetten. Oké, dus als ik het goed begrijp, als ik dus bijvoorbeeld een aanpassing wil doen, je noemde net het voorbeeld al van de delivery date, en ik wil kijken wanneer bijvoorbeeld mijn pakketje verstuurd kan worden, dan moet ik dus een SQL-query aanpassen, waardoor eigenlijk de entity verrijkt wordt, en ik daardoor eigenlijk meer data uit de API terugkrijg, als ik het goed begrijp, toch? Ja, dat klopt. Dan zou je dat toevoegen aan Avery Entities. Dat hoeft op zich geen fysieke entity te zijn hoor. Het kan ook een virtuele entity zijn, waar je bij wordt gehaald. Maar ja, mits al die data die nodig is voor de bepaalding van de leefdatum, ook daadwerkelijk aanwezig is in die database, want als dat dan weer van andere plekken moet komen, bijvoorbeeld andere APIs ofzo, dan zou je die logica meer eerst in een processtroom, in een flow neerzetten, dat die eerst in die API gaat callen, zodat die dan wat logica toepast om die berekening te doen. Ja, want daarover gesproken, over die integraties, daar zat ik nog over na te denken. Kijk, als je die logica zoveel mogelijk in de back-end of in de database, hoe integreer je dan met andere systemen? Bijvoorbeeld, je moet ergens een ERP-systeem of de core-systemen die jullie maken, dat zijn toch veelal de spinnen in het web in een applicatielandschap, dus daar moet wat data vandaan komen, orderverwerkingssysteem ofzo, noem maar wat. Hoe werkt dat dan? Wat voor integratiemogelijkheden heb je? En hoe kun je dat dan toepassen in je applicaties? Ja, logica is een heel breed woord. Je hebt van allerlei logica die door de hele applicatie natuurlijk heen zit. De logica die we op de database plaatsen, dat zijn echt de businesslogica, de regeltjes en de constraints en zulke soort zaken. Als je het meer hebt over logica voor processing van externe APIs enzo, dan doen we dat meer in flows. Dus daarin zet je dan een aantal activiteiten achter elkaar. Dus eerst een bepaalde API, conferteer wat data, schrijf die data ergens weg, of zoek er weer een andere flow mee aan. Dus dat is meer de manier waarop zulke soort processen worden afgehandeld. Dat kan dan ook op basis van een useractie, dat je zegt, na een bepaalde useractie moet die bepaalde flow autonoom gaan doorlopen. Dat kan ook gescheduled worden of getriggerd worden door andere scenario's. Dus die soort logica wordt ook helemaal uitgevoerd op die servicelaag. Die logica is ook veel meer declaratief dan operatief. Dat is geen code, dat is meer een flow. En die entiteiten heb je dan ook gewoon tot je beschikking in je model, zeg maar. Stel, ik heb een API waarmee ik de pakkettendienst opdrachten geef, bewijzen van, en ik doe een get op die API van welke pakketjes heb je al rondgebracht, dat schedule ik ook weer bewijzen van. Dat zou je dan zeg maar in jouw applicatie dan weer kunnen geven, of hoe zit dat? Ja, in principe al die flows waar ik het over had, die hebben ook APIs. Dus die kun je op die manier ook invoken, gewoon, vanuit de, als je daartoe de rechten hebt. En de resultaten daarvan, ja, daarmee kun je doen wat je wil. En als jij die wilt dupliceren in jouw eigen database, ja prima, dan kun je dat daar neerzetten. En kun je dat ook in de UI naar voren toveren, op de manier waarop je dat wil. Oké. Zien jullie dan ook wel eens dat klanten bijvoorbeeld de user interface gebruiken voor de applicatie, maar ook de API gebruiken voor andere doeleinden, hè? Ja, zeker. En, oh ja, we hebben een vraag een beetje, die op een gegeven moment in het begin hadden we ook een beetje erin gemist, dat het platform gebouwd is met het platform. Ja. En daarin gebruiken we natuurlijk zelf ook veel de UI voor het bouwen van het platform, maar ook de API zelf van het platform voor het bouwen van het platform, en ook voor het, oké, we gaan een beetje van de hak op de tak, maar als ik daar weer even op terug ga, dan kan ik deze vraag beter beantwoorden. Ja. De Software Factory, dus de IDE, de Intelligent Application Manager, de beheeromgeving, dat zijn allebei producten van de Software Factory. Dus in een developmentomgeving waar een Software Factory staat, staat ook een Intelligent Application Manager voor het beheren van de Software Factory. En een Intelligent Application Manager is ook altijd de beheeromgeving van zichzelf. Daar staat hij zelf ook als model in, zodat daar rechten op kunnen worden uitgedeeld. Dus dat betekent ook dat we een nieuwe versie van het platform maken met de vorige versie van het platform. En op het moment dat we dat hebben gedaan, kunnen we ook de features gebruiken van de nieuwe versie van het platform, en maken daarbij zowel het ontwikkelen van het platform als bij het gebruik van de IDE, maken we dus ook meer gebruik van de runtime componenten, en het gebruik van de API. Dus het is bij ons ook echt eat your own dog food. We gebruiken zelf heel veel onze eigen platform voor de doorontwikkeling van ons platform. Kijk, de runtime componenten, die worden gewoon normaal gebouwd. Met de uitdagingen er wel bij van de runtime interpretatie, maar daar hebben we gewoon een keer trep over staan met Azure DevOps en de pipelines, om dat allemaal op die manier te ontwikkelen. Dat is gewoon normaal dan. Klassiek. Klassiek, ja. De Software Factory zelf en de Intelligent Application Manager worden op die manier ontwikkeld. Dus vrijwel alle acties die je kan doen in de Software Factory en ook in de Intelligent Application Manager, kan je ook met de API doen. Dus als ik bijvoorbeeld iemand in de Intelligent Application Manager rechten wil geven, of lid wil maken van een gebruikersgroep, of een gebruikersgroep een bepaalde rol wil geven aan een applicatie, dan kan ik de Intelligent Application Manager opstarten en kan ik dat via de UI doen. Maar ik kan ook direct tegen de API aanpraten om dat te doen. Dus op die manier kun je ook met de standaard FinCoast producten die worden uitgeleverd, kun je ook met de API praten. En je ziet inderdaad ook wel veel dat de API van eindproducten ook gewoon wordt ontsloten. Dat er een serviceaccount in de Intelligent Application Manager wordt gedefinieerd. Die mag een paar kleine dingetjes doen, een paar kleine APIs aanroepen en die wordt vervolgens naar een externe partij gegeven om op die manier gebruik te maken van de API om ervoor de orders in te schieten of iets dergelijks. Er zit niet echt onderscheid in als iemand rechten geeft of die dat dan via de UI wil doen of via een API. Je mag gedragen betreft ook gewoon een eigen UI bouwen als je dat heel graag wil. En direct tegen de API aanpraten. Als het een paar man jaar is, dan laat je dat wel. Nou ja, voor een volledige UI die dan ook echt alles kan wat onze UI kan, dan zou ik dat ook niet meteen aanraden. Maar als jij een heel klein en dan ook pixel perfect appje moet gaan bouwen met een paar functies, dan kun je die prima laten praten met een FinCoast backend. Ja, of bijvoorbeeld een webshop of zoiets dergelijks. Want de runtime UIs die jullie uitleveren, dat zijn dus echt voor core-systemen. Dus dat doet echt wel denken aan een business-applicatie als jij een of andere sexy webshop moet hebben die toch wel orders inschiet in het systeem. Dan kun je dat dus op die API-laag gaan doen, zeg maar. Ja, klopt. Kijk, de manier waarop we het doen is declaratief. Dus we hebben geen what you see is what you get-veldjes op een scherm slepen. Dat is heel anders dan andere low-code vendoren. Die horen toch vaak dat je op een scherm een soort van template of een soort scherm en daar sleep je dan componenten op en daar maak je dan veldjes zichtbaar, et cetera. Dat doen wij niet. En dat heeft ook te maken met dat is 10 keer leuk en dat is 20 keer leuk, maar dat is 2000 keer leuk is een beetje de lol ervan af om zo'n soort schermen te gaan maken. En dat zijn wel de orde grootte van systemen waar we in zitten. Dus wat wij doen, is wij maken een template die beschrijft de schermstructuur. Bijvoorbeeld die zegt, ik wil een bovenkantlijst, dan wil ik aan de onderkant een formulier en ik wil dat dat formulier ook aan de kant wordt geschoven en dan staan daar de detailgegevens of dan staat daar een kubus of een map. Dus je beschrijft in grote lijnen hoe dat scherm structureel opgebouwd is. Die structuur kun je bijvoorbeeld toepassen op entiteiten of op virtuele entiteiten. Dus je kunt zeggen, nou, deze 80 schermen maken gebruik van deze structuur. Vervolgens kun je bij de schermen zelf aangeven, oké, ik wil graag dat als hij als lijst gevisualiseerd wordt, dat ik deze drie velden in de lijst zie. Of dat dit veld vastgezet is en dan deze twee lijden zie. Of als het als formulier gevisualiseerd wordt, dan wil ik graag hier een paar groepjes hebben en dit wil ik dan zo even laten zien. Dan maakt het niet uit, op het moment dat ik op een mobile device zit, dat die hele schermstructuur anders wordt gedaan. Dus bijvoorbeeld dat twee dingen die normaal maar als mekaar stonden, worden onder mekaar gezet. Dat blijft hetzelfde. En daarmee zit je dus ook niet, de runtime componenten lossen dat allemaal op. Die zorgen ervoor dat wat goed wordt weergegeven. Afhankelijk van de ruimte die ze hebben. Of van de nestingniveau waar ze zitten. Dat als jij een klantadres direct opent, heb je veel meer ruimte dan als je klantadres ergens onder, ik zit onder een project en van het begin ben ik naar die klant gegaan, ik zit een beetje ingezoomd op dat adres, daar heb ik heel weinig ruimte voor. En dan lost de user interface dat op, die kan daar mee omgaan. Maar dat zorgt er dus inderdaad voor, dat je die schermen niet meer pixel perfect tekent. En dat je daarmee ook niet pixel perfect applicaties daarmee bouwt. En vandaar dat we echt op die core systemen zitten. En als jij echt een pixel perfect applicatie moet hebben, dan is Sphinx OS niet het juiste platform daarvoor. In ieder geval niet voor de frontend. Ja, dat is toch wel een belangrijk aspect. Dat je echt een andere positie hebt in de low-code-spectrum. Je hebt ook de hippe term citizen development. Ik noem het wel eens elke geks eigen app. Daar zijn jullie dus echt niet van. Het is echt gewoon de core systemen waar bedrijven tientallen jaren mee moeten doen. En je helpt ze eigenlijk steeds om die volgende adoptie te maken in die technologische push. Ja, en dan moet ik wel zeggen, ik vind de citizen development zaken en echt die frontend low-code, die zijn ook super gaaf. Daar kun je heel veel mee en je kunt heel ver komen zonder dat je ook maar regelcode hoeft te schrijven. Alleen, dat is niet het probleem dat wij proberen op te lossen. Want vaak zie ik dat die dingen die worden wel bovenop een schil gezet of bovenop een COBOL-systeem dat er al, weet ik veel, voor een jaar staat of een RPG-systeem waar ze al een ontsluiting voor hebben gedaan. En daardoor bouw je wel steeds meer dependencies op die legacy-systeem. Die legacy-systeem durft niet meer op de aard te komen. En dat is juist waar we van af willen. We willen juist flexibele kernsystemen willen hebben die niet legacy worden. Want je kan zelfs bij zo'n COBOL-systeem, dan kun je wel zeggen, we gaan heel erg opnieuw bouwen met de modernste technologie. Maar je bouwt wel de legacy van over tien jaar. Want die dingen moeten wel zo lang meegaan, minstens. Dus je lost het probleem niet op. En door echt een flexibele kern te hebben lossen we daarbij heel veel van die problemen op. Dat je die gewoon functioneel altijd kan aanpassen. Omdat het een model is, kun je heel snel en heel erg changes daarin aanbrengen. Dat propageert zich ook helemaal door. Ook aspectveranderingen. Dus bijvoorbeeld als je zegt, jongens, ik heb wat klachten gekregen, want als een persoonsscherm opent, en een ander persoonsscherm opent, dan zien ze andere data. Ik wil dat het gewoon altijd vast is, dat altijd de meeste procent ingevoerde data bovenaan staat. Over mijn hele applicatie heen, overal. Overal wil ik dat hebben. Als je dat systeem met de hand geprogrammeerd hebt, dan is het best wel een uitdaging om er al die schermen in te gaan om het aan te zetten. Maar als je een modelgedreven applicatie hebt, dan kun je gewoon in dat model gaan zoeken. Geef mij alle plekken, en stel die sorteringen in en je bent klaar. Dus zo'n aspectzaken door je systeem heen bouwen, dat gaat razendsnel op die manier. Overal logging toevoegen, of overal tracing toevoegen. Ja, precies. Ja, oké. We gaan even door, denk ik, naar de application lifecycle, om het zo maar te zeggen. Dus je werkt dan in de software factory IDE. Stel je werkt daar met, ja, als je uit core-systemen werkt, dan werk je vrijwel nooit alleen. Even een aanname. Maar dan denk ik wel, hoe kun je samenwerken in zo'n IDE? Hoe zorg je ervoor dat, ja, kan je met z'n tweeën aan hetzelfde entiteit werken? Hoe werkt dat? Ja. Allereerst hebben we een, zal ik wel, volgens mij ook, we hebben een specification and work management module zit in het platform. Gewoon requirements, eigenlijk toch? Ja, requirements for storage. Ja. Ja. En dat heeft op zich wel een voordeel, om dat op die manier te doen, want je krijgt dan een stukje traceability tussen je specificaties. En ook dat werkt met de implementatie in het model. Dus dan kun je ook echt reserven, oké, wat ik toen gedaan heb, of waarom heb ik het toen zo gedaan, of andersom, en wat heb ik toen aangepast? Daarnaast kun je zo'n model ook branchen. Zo'n model werkt sowieso versiegewijs. Dus je gaat, van bepaalde versies, die rol je uit. Het platform helpt je met deltas, tussen die versies, ook het identificeren, zodat je de uitrol echt op die delta kan doen. En dat je ook datamigraties kan doen, als dat nodig is. Want als je een verplicht veldje toevoegt, en je geeft daar niet iets van een waarde aan, ja, dan kan je niets van datamigratie goed doen, zonder dat je de uitspraak ook doet. Toevallig die error nog gehad, met de NTT Framework vandaag. Ja, dat zijn lastige dingen. Ja. Moet je wel wat mee doen. Ja. Ja. En daardoor ook, denk ik, support voor rollbacks. Ja, ik denk dat het, in de volle breedte, wil je gewoon versiegewijs, altijd bezig gaan. Je wil, terwijl je elke change als een versie ziet, en gewoon meteen weer terug gaat, naar de vorige scenario, op het moment dat het niet doorkomt. Ja, wil je eigenlijk, ja, altijd wel, ervoor zorgen dat jij kan kiezen, op een gegeven moment, van wanneer, dat er toch iemand op een knopje trukt, van oké, nu kan het niet live. Ja. Dat kun je ook doen, door te zeggen van, hé, ik heb gewoon een trunk, en alles als er een trunk komt, is dan goed. Er moet toch wel een moment zijn, en dat moment bepaalt eigenlijk, hoe je migratie er gaat uitzien. Hoe je delta er gaat uitzien. Ja. Ja. Die modellen, die zijn dus ook te branchen. Dus je kan ook zeggen, nou, we moeten aan twee grote modules, of zo, gaan werken. We willen elkaar niet te veel in de weg zitten. We willen onze eigen eindproducten, we willen onze eigen hele full stack daarvoor hebben. En die kun je vervolgens ook weer mergen. En bij zo'n merge laat je ook zien, waar eventueel conflicten ontstaan. Als je in een branch, een entiteit, helemaal weggooit, en in een trunk voegt het een veldje aan toe, of in een andere branch voegt het een veldje aan toe, ja, dan moet je daar een uitspraak over doen, hoe je daarmee omgaat. Ja. Dus op die manier kun je ook met teams, kun je daar samenwerken aan die modellen. Oké. En als je dan, zeg maar, oké, je hebt allebei aan de module gewerkt, je hebt op de merge knop gedrukt, bewijzen van. Dan wil je een nieuwe versie releasen. Uberhaupt, zeg maar, releasen met InQuest. Je ziet ook heel veel, bij heel veel low-code pakketten, dat het echt saas is. Dus dat je eigenlijk helemaal niet, iets te zeggen krijgt over waar het draait, op wat hardware, dat soort dingen. Volgens mij is het bij InQuest het geval, dat je zelf, zeg maar, je eigen infrastructuur moet draaien. Dat jullie niet het InQuest Cloud hebben, of iets dergelijks waar je het in kan draaien. Ja, we zijn op dit moment bezig, we hebben een demo-omgeving, die meer als paars werkt, per wijze van spreken. Maar het is niet zo, dat dat de facto standaard is. De facto standaard is, van hier, we zijn heel open, heel transparant, in hoe die architectuur en structuur in elkaar zit. Omdat het platform zelf ook een eindproduct is, van het platform, is die structuur hetzelfde. Dus, je kan gewoon de database, van de software factory, kun je plaatsen waar je wil. Als je dat, het maakt mij niet uit, waar je die neerzet, of je die nou in een container zet, of dat je die in een Azure database zet, of dat je die on-premise zet, op een server. Ja, het maakt mij niet uit. En hetzelfde met die runtime componenten, die kun je ook deployen waar je wil. Dus, ja, dus dat, dus dat is heel open, wat dat betreft. Voor de uitrol van een, van een upgrade, er bestaat eigenlijk uit een aantal delen. Dus, allereerst, als jij datummodel technische wijzigingen, hebt gedaan, worden er dus, en dat wordt wel gegenereerd, dus de backend, dus de database is wel gegenereerd, die moet ook persistent zijn. We hebben niet de runtime geïnterpreteerde database. Dus die wordt wel gegenereerd. Dus die moet ook worden ge-upgraded. En op basis van het versiebeheer, dus op basis van de visionering, van die versie naar die versie, doet hij een suggestie over de datum migratie. Daar kun je zo ook op ingrijpen. En daar genereert hij scripts voor. Om die, zowel die, die, de statements voor het alteren van de datastructuren, als voor het migreren van de data, dat wordt allemaal voor je gedaan dan. Daarnaast hebben we de, de businessregels en die logica, die worden op diezelfde manier, worden die ook op die database geplaatst. Dat hoef je niet in een volledig breder doen. Je kunt ook zeggen, nou, het deel is tussen die twee versies, alleen de geraakte logica, die ga ik op die database plaatsen. Dat is niet voldoende voor een, voor een deployment, want je hebt ook de nieuwe versie van het model nodig. Al zijn de Runtime componenten, hebben die een nieuwe versie van het model nodig. Dus die wordt dan gesynchroniseerd, naar de Intelligent Application Manager. En daar kan die vervolgens, live worden genomen. Dat kan ook blue-green worden gedaan, dat je user group voor user group, naar een andere versie haalt van, van de applicatie. Maar dat is de manier waarop dat wordt gedaan. Dus de database, de logica laag en de, en het model. De Runtime componenten, die hoeven niet geüpdatet te worden. Ja, want die pakken het nieuwe model op, en die vormen zichzelf naar het nieuwe model. Dus die hoeven niet te veranderen. Dus daar hoef je niks, je hoeft niet je app service te updaten ofzo. Maar hoe werkt dat dan vanuit een, stel je hebt een OTAP straat, en je werkt in de software factory, je hebt je nieuwe versie gereleased, en nu wil ik hem naar O, zeg maar releasen, doe je dat echt vanuit zeg maar de software factory, voer je de connection strings op van O, en dan druk je op vuur, of kun je dat vanuit een CICD tool, achtige tools als Azure DevOps, GitLab of iets anders, ook voor elkaar krijgen? In ontwikkeling, gebruiken we eigenlijk niet, de intelligent application manager, als host voor het model. Dat staat weer direct op de software factory. Dus de user interface laat dan zijn model, vanuit de software factory. Dus alles wat je erin doet, is instant. Dat is ook wel een handig prototype op die manier, want alles wat je doet, heeft gewoon direct effect op de hele stack. Wanneer je het naar acceptatie, of test of productie wil halen, dan kun je inderdaad rechtstreeks verbinden, met die omgeving, naar die omgeving toepushen. Wat je ook kan doen, is dat je zegt van, ik kan die omgeving helemaal niet bereiken, vanuit mijn omgeving. En dat je daar in plaats daarvan, een pakketje klaar zet, waar alles in zit dat nodig is, om dat te doen. Dus daar zitten instructies in, voor het plaatsen van het nieuwe model, daar zitten instructies in, voor het updaten van de backend, van de database, of de service laag. Dat pakketje, kan worden opgepakt, door een tool, dat heet onze deployer. En die deployer, die heeft eigenlijk twee varianten. Die kan dat gewoon met een wizard doen, next, next, next. Op die manier een nieuwe versie, uitrollen naar een omgeving. Maar die heeft ook een CLI. En met die CLI, kan je er dus voor zorgen, dat dat ook wordt opgenomen, dat dat ook wordt gedaan, vanuit een pipelines, of dat dat wordt gedaan, vanuit een octopus, of iets dergelijks. Dus het is niet dat wij, de CICD tooling meeleveren, maar we hebben wel de aanknopingspunten, om het te integreren, in CICD tooling. Oké. Dus dat werkt eigenlijk met, ja dus, als we het even vergelijken, met .NET, bij .NET, bulge iets, krijg je een artifact. Bully wordt wel de artifact, vanuit de software factory, dan gemaakt. Maar je zou dus, die artifact kun je, met een CLI, zeg maar, dan deployen, naar de verschillende, environments, die je hebt. Ja. En daarmee kun je bijvoorbeeld ook, secret management, connection string management, en dergelijke, in je CICD tool, afhandelen, zoals jij dat zo graag, zou willen. Ja. Ja, dat lijkt me inderdaad, een verstandig manier, om dat te doen. Ja. Dat je die ook niet allemaal, in de omgeving onderhoudt. En jullie leren je dan ook, echt niet aan, één bepaalde cloud, één bepaalde CICD tool, het is allemaal, zeg maar, open. Dus AWS is net zo goed ondersteund, als Azure, of? Ja, we hebben klanten, die op Azure draaien, en we hebben klanten, die op AWS draaien. Voor het initieel, neerzetten van de omgeving, want je hebt natuurlijk wel, die runtime componenten nodig, enzo. Daar hebben we wel, wat guidelines voor, hoe je nou, die cloud formation templates, ervoor kan maken, dat je dat één keer neerzet. Over het algemeen, is dat eenmalig, en vanaf dan, kun je die single-it gebruiken, om nieuwe versies, uit te rollen, zeg maar. Ja, oké. Dus echt, de infrastructure as code, om het zomaar te zeggen, dat is nog wel, gewoon zoals de cloud vendor, het voorschrijft. Ja. Oké, maar daar hebben jullie, een soort van best practices voor, hoe je dat zou moeten doen. Ja, we hebben, we hebben daar online, documentatie, handleidingen, die helemaal beschrijven, van hoe je die zaken, moet inrichten. Ja. En ook, hoe je daarin updates, moet vragen hebben. En weet je, daar zijn ook best wel veel wegen, naar women in. Dus, je moet nagaan, dat onze doelgroep, zijn vaak, dat zijn toch ook meer, de bedrijven, met echt wel grote, IT afdelingen, of independent software vendors, die al, ja, hun hele leven al, software development doen, die hebben al, voorkeuren erin, hoe ze dat willen doen. En die willen ook, de vrijheid geven, om gewoon, op hun eigen manier, hun straten, wat dat betreft, in te richten, in plaats van dat ze het, via de Thinkwise manier, moeten doen. Ja. En het is ook niet zo, dat, dat je applicaties landen, in een soort van, Thinkwise cluster, he. Dus elke applicatie, samen met een eigen IAM, is een soort van, of één IAM, voor meerdere applicaties. Dat is, zeg maar, je, ja, je application, je artifact, en, that's it. Zeg maar, je hebt niet iets anders nodig, om die applicatie te draaien. Nee, de, zowel de runtime componenten, als alle, ja, de database die je hebt, enzo, die zijn allemaal, heel, ja, open, wat dat betreft. Het is heel duidelijk, wat voor soort componenten je hebt, en hoe je die moet deployen. Het is niet dat je, een of andere magische runtime, eromheen nog weer nodig hebt, ofzo. Ja. Oké. Nou, best wel veel geleerd, eigenlijk. Ik heb er, wat meer kennis van. Ik ben hier niet zo in thuis. Want, ik werk toch eigenlijk, voornamelijk, met coden. Maar, ik vind het wel echt, ook interessant te horen, dat dit allemaal gegenereerd wordt, en dat je dan ook, bijvoorbeeld, de APIs, los kunt gebruiken. Dat levert toch heel veel mogelijkheden op, waar je bij low-code, niet zo snel aan denkt, eigenlijk. Ik denk dan, meer altijd, aan het voorbeeld, inderdaad, van, je hebt een UI'tje, textboxjes op, en dan, dan heb je een applicatie. Maar, ja, het is wel interessant, ja. Ja, ik denk dat, een grote deel van de low-code vendors, ook echt wel, meer in die kant zit, hoor. In de heart zit. En, ja, wij doen het iets anders. Wij differentiëren ons, echt specifiek, op het enterprise systeem. En hebben daardoor ook, echt met andere uitdagingen te maken. Ja. Ja, precies. Ja, nee, maar daardoor, juist, heb je ook, de producten, mee kunnen gaan. Omdat daar, gewoon, ja, het gegenereerde stuk, van de applicatie, dat is eigenlijk, de core. Ja, dat is echt, die backend, ja, die runtime component. Kijk, ik weet ook niet, hoe de wereld, er over 20 jaar uitziet. Maar, ik weet wel, dat de applicaties, die nu gebouwd worden, met platform, dan ook gewoon, prima, ook technologisch, up-to-date zijn, en functioneel up-to-date, gehouden kunnen worden. Dus, wat we nu bezig zijn, dat is een, een interface, maar niet zozeer een user interface, maar dat is een, een, een, een, een tekst gebaseerde, user interface, die op basis, die een natural language processing, gebruikt. Dus, Ah, oké. Die je, bij wijze van spreken, kan integreren met je, met je, Siri, of Alexa, of zo'n soort dingen. En dat je op die manier, wat, wat je, systeem kan doen, de intenties, de intenties, die je kan uitspreken, die zijn niet technologie gebonden. Nee, dus dat, dat in het model staat. Ja. Ja, dus als ik, even, dus nu gaan we denk ik, een blikje in de toekomst krijgen. Dus dan krijgen we zo meteen een, een runtime, zeg maar, Cortana, Alexa, van, van, Tinkwise, waar ze zeggen van, hé, wat is de laatste geprocesde order? En omdat, omdat die, ja, runtime, zeg maar, het model kent, weet die de order, weet die welke API je moet hebben, en wat daar dan de laatste, eh, versies van zijn. Ja, klopt. Ja, en, het, omdat die, dat model is, is niet, ook niet zozeer, er zitten natuurlijk wel UI aspecten in, maar die kun je gewoon aanhouden, en negeren voor dit gedeelte. Je kan nog hoogstens gebruiken van, om te kijken van, hé, wat is, wat is interessant voor gebruik, waar ligt de focus op? Ja. Om daar stellen, de aandacht naartoe te trekken. Dus, ik weet ook niet of, dat we op een gegeven moment, dat dit veel meer, de standaard, eh, gaat worden, dat we op deze manier, met onze applicaties, maar nu gewoon met onze enterprise applicaties, eh, Dus soms heeft die, neurolink van, Elon Musk, eh, jouw model, of het InQuest model, in zijn geheugen. Ja, nou ja, met de bandbreedte, die je daarmee hebt, met je enterprise systeem, kun je wel heel productief van worden. Dus, ja, ja, ja. Ja, maar het is toch wel echt, eh, heel al, ja, volgens mij, je was er echt mee bezig, toch? Ja, we hebben twee machine learning engineers, die daar nu actief, eh, mee bezig zijn ook. Ja. Ja, dat is wel, eh, ja, impressive. Ja, dat is ook super gaaf, want dat model bevat natuurlijk, zoveel metadata, die je ook weer kan gebruiken, om die modellen heel goed te trainen. Je weet hoe alles heet, je weet alle vertalingen, overal van, je weet wat je mag doen, eh, en, eh, ja, er zijn ook prototypes staan, en die prototypes zijn natuurlijk niet helemaal, op de juiste manier, eh, eh, tot stand gekomen, maar die werkte al. Dus, eh, dit, dit gaat echt wel, eh, van de grond komen, dat weet ik wel zeker. Het is meer de vraag van, in hoeverre dit in de wereld, van de grond gaat komen. Ja. Of dit echt de toekomst is. En dat is natuurlijk, of we die kijken. Ja. Ja. Maar stel, stel jullie releasen dit dadelijk, en het is klaar, en, eh, een, een kleine, eh, swappen, van de interface, eh, en dan, dan, dan kun je het meteen gebruiken eigenlijk, toch? Ja, klopt. Ja, je kunt gewoon... eh ja, er heet, om te gaan met elk model, dus, dus, in het modelbeschrijver bestaat, staat wat je moet kunnen, en wat, eh, wat mogelijk is. Dus, dus die user interfaces, zijn allemaal op die manier, of tenminste die interfaces zijn allemaal, bij die manier, eh, en dan, dan wil ik hem hierbij, eh, afronden. Eh, Anne Buit, hartstikke bedankt voor je inkijkje in de, in de keuken bij Tinkwise. Ja, bedankt. En, en, ja, graag eraan. Vond je dit nou een leuke aflevering? Volg ons dan zeker op Spotify, of geef ons een review op, eh, Apple Podcast. Eh, heb je feedback, stuur ons een mailtje op, eh, podcast at cloudrepublic.nl, of zoek ons op op LinkedIn of Instagram. En dan, zien we je de volgende aflevering. Ja, tot de volgende keer.