Innovatie & Strategie

Software-ontwikkeling
Jurgen Vinju

Superscience: Fintech vereist nieuw beheer backend banken

Met domeinspecifieke talen kun je geverifieerde, betrouwbare, complexe systemen bouwen en onderhouden.

23 juni 2020

Met domeinspecifieke talen kun je geverifieerde, betrouwbare, complexe systemen bouwen en onderhouden.

De financiële wereld verandert sterk. Een belangrijke drijfveer is de PSD2-wetgeving – die derden in staat stelt financiële diensten te ontwikkelen op basis van rekeninggegevens van de klanten van banken. Nieuwe kleine bedrijfjes springen op de nieuwe mogelijkheden om klanten service te bieden. Ook de al wat meer gevestigde betaalintermediairs als Adyen en PayPal ruiken nieuwe kansen, en zelfs grote partijen als Amazon en Google kunnen nu een bankinterface aanbieden. Om de backend van financiële instellingen toch robuust te houden, moet de complexiteit van het vakgebied worden gescheiden van de complexiteit van het code genereren, zegt Jurgen Vinju. Hij is hoofd van de groep Software Analysis & Transformation (SWAT) bij het Centrum Wiskunde & Informatica (CWI) en hoogleraar automated software analysis aan de TU Eindhoven.

Waar de software bij de grote banken jarenlang bestond uit één organisch geheel, ontstaat nu behoefte aan een duidelijke voor- en achterkant. Want zonder een robuuste en betrouwbare achterkant van de banken bestaan de nieuwe klantgerichte diensten niet. En die achterkant moet interfaces hebben voor het leveren van de benodigde data. Die achterkant van banksystemen bestaat uit een zeer complex samenspel van toepassingen die vaak al jarenlang in gebruik zijn. Vernieuwing en aanpassing daarvan is hogere wiskunde. Niet gek dat financiële instellingen daarvoor vaak de samenwerking opzoeken met kennisinstellingen en universiteiten.

Vinju legt uit dat er al jaren een beweging op gang is om dergelijke uiterst complexe software eigenlijk op een soort no-codemanier tot stand te brengen. Een methode die toch duidelijk verschilt van de nu populaire manier van low-code-/no-codesoftwareontwikkeling.

Domain specific languages (DSL's) zijn het gereedschap dat het SWAT-team van Vinju ontwikkelt voor de financiële sector, maar ook voor het KNMI, en grote techbedrijven als Philips en ASML. De bedrijfsprocessen van die organisaties zijn ingewikkeld. De uiteindelijke code die wordt geïmplementeerd, is op zich ook weer ingewikkeld om te maken.

Complexiteit domein x complexiteit coderen = spaghetti

"Als je dat met elkaar vermenigvuldigt, komt het in de sourcecode terecht en dan krijg je spaghetti", stelt Vinju. "Een DSL is bedoeld om het ingewikkelde van het domein te scheiden van het ingewikkelde van een implementatie." Eerst worden de kennis van het domein en het doel van nieuw te maken software in een model gegoten. Vervolgens kun je die modellen op allerlei manieren testen en met formele methoden correct bewijzen. Je kunt er ook allerlei verschillende wat-alsscenario's mee simuleren. Uiteindelijk kan er 'met een druk op de knop' code mee worden gegenereerd die automatisch aan de correctheidsgarantie voldoet en bijvoorbeeld als cloudapplicatie kan worden geïmplementeerd.

Er is dus niemand die normale programmacode intikt. Sterker nog, niemand mag er met zijn vingers aanzitten om onderhoud te doen. Vinju: "Ik heb al zelfs wel geëxperimenteerd met het toevoegen van een checksum, waardoor als iemand maar iets aan de code verandert, het systeem gelijk niets meer doet." Het devies is: bij onderhoud en aanpassingen ga je terug naar de DSL, je draait aan wat knoppen voor de verandering en laat de codegenerator een nieuwe versie van de software maken die de oude versie vervangt.

Dat concept lijkt veel op de nu populaire no-codesoftwareontwikkeling. "Toch is er een duidelijk verschil", zegt Vinju. "Low code en no code richten zich op een domein – neem bijvoorbeeld franchiseorganisaties – waarbinnen veel verschillende partijen er gebruik van kunnen maken voor het maken van generieke software. Een DSL wordt daarentegen specifiek op de behoeften van één grote organisatie gemaakt en die wordt dan ook vaak eigenaar van de DSL."

Verleden

DSL's zijn niet nieuw. Paul Klint en Arie van Deursen – destijds beiden verbonden aan het CWI – bouwden halverwege de jaren 90 al voor Nederland de eerste DSL in samenwerking met Mees Pierson (nu ABN AMRO). Dat gereedschap – genaamd Risla –stelde verzekeringsexperts in staat zonder tussenkomst van engineers nieuwe producten te bedenken, in COBOL te maken en te installeren op het mainframe. "Dat heeft 25 jaar heel succesvol gewerkt."

Je leert altijd wat

Maar ook in de regio Eindhoven, bij bedrijven als Philips en ASML, is het gebruik van DSL's niet ongebruikelijk. Door zijn posities in Amsterdam en Eindhoven komt Vinju met beide werelden in aanraking. "In Amsterdam zijn de wetenschappers vooral bezig met de financiële wereld en in Eindhoven met machines. Er zit veel overlap tussen het soort problemen dat ze willen oplossen, maar niet in de onderliggende kennis. Het is eigenlijk heel verfrissend. De ervaring die je bij de een opdoet, is een soort spiegel bij de ander. Daardoor kun je heel goede vragen stellen. Soms kan een oplossing die bij de een werkt, echt niet bij de ander –bijvoorbeeld doordat regelgeving dat verbiedt. Maar het komt ook voor dat de ander zegt: 'Oh, zo keek ik er nog niet eerder naar.' Je leert dus altijd wat."

Heden

Inmiddels maakte het CWI een nieuwe DSL voor financiële producten, genaamd Rebel; dit keer in samenwerking met ING. Nieuw daarin is onder meer het auditingperspectief. "Vragen als: wat is de rechtvaardiging van zo'n product of bedrijfsproces? En kunnen we de mensen die de auditing doen, ondersteunen met behulp van computationele middelen?"

Bovendien maakt Rebel het mogelijk al voordat het product daadwerkelijk wordt gebouwd, te onderzoeken wat voor effecten daardoor mogelijk kunnen ontstaan. Dan gaat het over bijvoorbeeld: wat gebeurt er als de bank negatieve rente op creditcards zou toestaan? Wat gebeurt er als de rente per week wordt afgerekend in plaats van per jaar?"
Een van de promovendi uit de groep van Vinju – Jouke Stoel – richt zich helemaal op het gedeelte van de specificaties testen en modelchecken, terwijl een andere promovendus – Tim Soethout, die aan de kant van ING werkt – zijn promotieonderzoek doet aan de codegeneratieaspecten daarvan. "Bij het ontwerp van een nieuw bankproduct denk je niet zo gauw na over de efficiency van de code. Je bent enthousiast over wat je ermee kunt verdienen. Maar er moet wel een correct bevonden implementatie van de software komen. Die is dan makkelijk traag in het gebruik. Dus kijkt Tim naar hoe je zo goed mogelijk parallelle gedistribueerde systemen uit het model kunt genereren die toch voldoen aan de correctheidsgarantie."

Dat is echt een toepassing die niet zonder blockchain zou kunnen.

Alle banken werken wel met universiteiten samen, maar nooit verschillende banken tegelijk aan één project. Vinju wijst op de strenge mededingingsregels. "Er is één uitzondering en dat is in het Digital Finance-onderdeel van EIT Digital, een Europees instituut voor innovatie en ondernemerschap." Daar werd onder andere gewerkt aan een identity-chainmodel voor het beheer en delen van klantgegevens waarover de klant zelf de regie houdt.

"Daarvoor is nu een DSL in ontwikkeling – waaraan onder meer Tijs van der Storm uit mijn onderzoeksgroep werkte – die smart policy's kan genereren. Dat zijn zeg maar een soort contracten waarmee de consument vastlegt welke data hij deelt, met wie, voor hoe lang en onder welke voorwaarden. In het project zorgt een blockchaintoepassing ervoor dat niet iemand ongezien van zo'n smart policy kan afwijken. Dat is echt een toepassing die niet zonder blockchain zou kunnen."

Toekomst

Het maken van een DSL is nu nog een forse investering in tijd en geld. Het streven is die investering omlaag te brengen. Het onderzoek richt zich daarom op de mogelijkheden tot hergebruik van onderdelen van DSL's zodat niet elke keer helemaal opnieuw hoeft te worden begonnen. Een van de denkrichtingen is een DSL voor DSL's, vanuit een soort metaprogrammeerperspectief. Een voorbeeld daarvan is de meta-DSL genaamd Rascal, ontwikkeld door de SWAT-groep, waarmee efficiënt en effectief DSL's ontwikkeld kunnen worden. Bovendien kan het traject worden verkort door niet alleen met interviews de kennis over het domein te verzamelen, maar ook op een geautomatiseerde manier domeinkennis uit legacy systemen te abstraheren.

 

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (juni-julinummer 2020). Wil je alle artikelen uit dit nummer lezen, klik dan hier voor de inhoudsopgave.

Lees meer over Innovatie & Strategie OP AG Intelligence
2
Reacties
aschwin.tenfelde 26 juni 2020 12:36

Bedankt voor je antwoord! Er is een hoop veranderd, maar een hoop is ook nog hetzelfde. Ik heb als student en promovendus nog een graantje kunnen meepikken met MERODE en First Result en de RISLA DSL bij Mees Pierson, met ASF+SDF.

Wat er veranderd is, is dat de focus van het "hoe" met meta technologie nu naar het "wat" is gegaan. We kunnen met de pragmatischere taal Rascal snel experimenteren met allerlei domeinspecieke talen en hun bijbehorende generatoren en checkers. Er is vrijwel onmiddelijke een moderne IDE beschikbaar voor elke experimentele taal.

De vraag is nu meer "wat": wat voor taal is dan de beste? wat is dan goede input in zo'n DSL? En wat moet er uit gegenereerd worden? Al deze aspecten zijn een kwestie van ten eerste hele goede samenwerking met domeinexpers en ten tweede tools die daarbij ondersteunen zodat de kosten van de DSL ontwikkeling en onderhoud niet de baten overstijgen. Dat gebeurt tegenwoordig niet meer, IMHO.

(a) wat is nou de goede taal? Snel kunnen experimenteren met allerlei prototype talen en daarvoor goede ondersteuning afleiden zonder alteveel werk en ballast. Dit zijn voornamelijk resultaten uit de jaren 80 en 90 die nu vorm hebben gekregen. Alleen het analyse aspect is nog onder ontwikkeling. Daar zijn meta-tools en tussen-talen nog vol in ontwikkeling.

(b) wat zijn goede expressies in die taal? Hier is het analyse aspect echt interessant. We onderzoeken hoe we snel en interactief kunnen simuleren, checken, controleren, testen. Zo kunnen de domein-experts experimenteren met de mogelijke gevolgen van "what if" scenarios zonder dat er code hoeft te worden gegenereerd en uitgerold. We hebben hier mooie voorbeelden van bij banken maar ook in de spelletjes wereld zijn sprekende voorbeelden: wat als we deze spelregel veranderen, is het spel dan nog speelbaar en leuk? etc.

(c) wat is nou de beste code om te genereren? Hier kun je eindeloos domeinkennis inzetten en verspreiden over de uiteindelijke gegenereerde code, zonder de straf dat die code onderhouden zou moeten worden. Prachtige voorbeelden in de bankwereld waar we nu aan werken is het voorkomen van het "locken" van records in massief parallele implementaties: door de financiele effecten van een mogelijke race te analyseren op basis van de domeinkennis (wellicht heeft deze race geen financieel effect?) kan sneller gecommiteerd worden aan parallel geiniteerde acties. Het gevolg is hogere throughput bij piekbelasting en lagere gemiddelde kosten. Ook bij het NFI was een leuk voorbeeld een paar jaar geleden: op basis van specifieke kennis van de JPG output van een in beslag genomen camera een gespecialiseerd zoek-algorithme genereren dat wél op tijd het gewiste bewijsmateriaal kan terugvinden.

Kortom: meer "wat" dan "hoe", veel samenwerking, focus op analyse en interactieve simulatie en toepassing van domeinkennis voor betere code. De basis van "generative reuse" is gebleven, maar de baten van DSLs zijn omhoog gegaan door meer te oogsten van de domeinkennis en de kosten zijn omlaag gegaan door te oogsten van de experimenten uit de jaren 80 en 90. Er is nog veel onderzoek te doen, maar je vindt toch links en rechts allerlei industriele toepassingen in Nederland. Bijv. http://www.swat.engineering is een CWI spin-off die met DSLs zijn geld verdient. Nederland is goed in "talige informatica"; er zijn veel mensen bij CWI, TU Eindhoven, TU Delft, UTwente, TNO, etc. geinteresseerd en actief met DSLs aan de slag.

Als je zin hebt om een keer bij te praten over deze onderwerpen, de deur staat open bij CWI (virtueel of in het echt). Groetjes, Jurgen Vinju

Eric-Jan Hoogendijk 24 juni 2020 20:41

Zoals DSL hier wordt gepresenteerd is het niet veel anders dan een gezonde modulaire, herbruikbare en parameteriseerbare opbouw van de software; en dan ook nog voor één bedrijf. Hoe dit de samenwerking tussen organisaties op gebieden zoals PSD2 moet vergemakkelijken is mij niet duidelijk. Een enkel bedrijf een domein noemen staat dat ten ene male in de weg. Het domein banking definiëren dat consistente externe interfaces genereert lijkt mij een bedrijven overstijgende aangelegenheid dat waarschijnlijk niet eens tot stand kan komen zonder door de overheid opgelegde regels. Maar dat dit moeilijk is bewijst wel dat zo'n interface ook bij zoiets als het GBR ook van tijd tot tijd weer op de schop moet.

Hoe die generatoren moeten werken met elementen zoals YACC en lexicografie kan het beste aan wetenschappelijke instituten zoals het CWI overgelaten worden.

Dat het CWI in de jaren 80 en negentig daarin al heel ver waren heb ik van nabij kunnen zien. Hierbij kwam ook de bewijsbaarheid van software duidelijk in beeld. In die tijd was er bij IBM ook een groot project aan de gang waarin ons bedrijf en het CWI ook participeerden. Het streven was daar om een domein overstijgende generator te bouwen en te onderzoeken of die vanuit bestaande software de taal en parameters voor deze generator zou kunnen kunnen genereren. Ik geloof niet dat dat uiteindelijk tot een resultaat heeft geleid, maar er is toen wel veel kennis opgedaan. De kosten stegen IBM geloof ik op een gegeven moment "een beetje" boven het hoofd. terwijl geenszins duidelijk was of zij daar ook de vruchten van zouden plukken.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.