 So welcome to my talk titled morpher a single language for business and technology before I jump into the presentation itself Let me say a few words about myself So I spent almost two decades in software development. Most of that I spent working at Morgan Stanley 14 years For most of that I've been building trading systems And most recently I moved on to the financial and regulatory reporting areas But why that was my day job I Throughout this whole period I was really searching for the ultimate modeling language a language that allows me to express business problems in a In a very efficient way so that it can be solved using automation and along the The way I tried many languages, so I started as a Java developer And then moved on to Scala and then nowadays I'm doing a lot of Elm coding If you don't know Elm, it's a functional programming language So you can see the progression as I move from object oriented towards more and more functional Through Scala which supports both So as I was doing that I tried many others, but these were the main ones I Got into programming language design and you will see how that's relevant to the presentation as well And finally, I'm a co-creator of morpher. I'm responsible for most of the core coding So let me let me Like jump into what morpher is give you an overview of more what morpher is So it's it's developed and open source by Morgan Stanley and then It was contributed to Finos last year So the core of it is is a business-focused Intermediary representation and that's where it goes back to Programming languages programming language design an intermediate representation is It's something that All the programming languages have all the compilers have internally to basically capture the logic in a in a platform independent way and So what what we did with morpher is basically Created a simplified version of that that is That is easier to process during tooling and and exposed it Compilers usually don't expose that Intermediary representation. They treat it as an internal detail But as you will see we found that It's it's very useful to expose it as a as a standard Data format so the morpher IR is a is basically a data format That that is publicized and then on on top of that data format that that is the core but on top of that data format we We have various tools The on one side we have different ways of creating the business logic So while a normal programming language would have One syntax and you have to learn that syntax and then that's how you can code in that language Morpher has many syntaxes if you like many ways of creating the business logic. So our main one is elm Purely functional programming language. We have another one in the works Which is a Microsoft research language called baski We have a lot of other Domain specific languages within Morgan Stanley that That we translate from and we also are experimenting with GUI tools to to build The business logic. This is for like business users less less technical users And then once you have that business logic captured in that morpher IR then you can do various things with it That's where it becomes more interesting. So you can turn it into back into Programming languages like scala or typescript For for execution, but that's the least interesting part of it. The more interesting is that you can build visualizations that Explain the business logic to non-technical users and I'll get into how why that's interesting so Throughout my career I I Faced this challenge of building financial software. You basically have two groups of experts You have the the business and the technology experts Both of them are really good at their area. They are They know everything about it. They know their domain really well but they are together trying to build one thing financial software and The problem is that they are not speaking the same language, right? They are again experts in their area. They know everything about that, but they don't know much about each other's Domain and so because of that what what happens is that instead of having a proper dialogue The whole conversation turns into a series of monologues. So basically a business user will explain the business problem to solve in a long conversation or like a long monologue and then Somebody knows that down turns it into a specification. That could be a BA or someone even a developer And turns it into a specification, which is another monologue and then The developers go in and look at that specification and turn it into the longest monologue, which is the implementation and none of those Really are related to too much to each other. They They they they are pretty different. They will go through a phase of translation from one to the other. So Can can we turn that into a dialogue is the question and make it more efficient. So To basically the goal is to speak the same language, how can we get these different groups to speak the same language? So there's been previous attempts like UML is one of the big ones Where you create a language and and then get everyone to learn it I mean, that's obviously difficult getting getting different domain experts to learn the same thing It's one thing is that it's difficult, but because of the learning curve The other thing is that usually these languages are not not good at expressing business problems like they are basically a Subset of all the all the different domains And the the other big thing with it's specifically UML, but it's true for most of most of these attempts is that When when they talk about language, they they talk about a domain model. So that captures The basically the data structures. They don't talk about the business logic at all If I mean UML has some attempts at that but doesn't really have a good way to to capture the business logic itself Now the morpher approach is is different. So we we have one language, but that one language morphs into something that's already familiar for for the given Domain expert so for the business it turns into the diagrams that they can understand that they can relate to Such as like decision trees and decision tables And for the technologies it turns into code that they can actually integrate into their system And they are intimately familiar with and all this translation happens automatically. There's no manual interaction involved So that makes the whole thing Just magically work basically because the business user looks at the the diagrams that they are and they can understand And it does the exact same. It's guaranteed to do the exact same thing as the code that the technologist is looking at so So actually that let me jump into some demonstration of that so The the Example that I will use won't be very sophisticated. It won't be finance related It's surfboard rentals. Let's imagine that we have a business franting out surfboards and we are talking to our business user and the business user Gives us a simple Explanation of the business model. We basically want to make a decision about whether to When a customer comes in comes with a request to rent a number of surfboards We just want to decide if we can rent it out or we just have to reject the request So as you can imagine We get on a call the the developer goes in and uses Elm as I said, that's the model language we use and basically builds the the business logic and And so just and what you see on the on the left side Is the visualization of that so this is fully automated so if I make changes to the logic it immediately updates as you can see So it's a it's an interactive Dependency between the two so you can get on a call and do this together Now the next thing you might want to do is is actually go in and interact with that business logic That's usually one thing that you cannot immediately do maybe on a on a meaning you can draw up a decision tree Instead of writing code But you cannot interact with it which which is something that you probably need in order to figure out if it works as expected So let's say we have ten surfboards available and we want to get we We want to simulate if The client asks for five of those and what you can see is that we get the results highlighted the in this case, we would be basically allowing the rental what if we request more than Then what we have obviously we we reject that saying we don't have enough capacity Now a business user at this point might say This doesn't look right because I mean we had ten surfboards available and they just asked for eleven So we had one less and we rejected the whole thing So we are not renting out ten surfboards that we we could rent out So at that point They might go back and basically say okay. Let's look at this business logic and add a add a flag to To make it possible to do Partial rentals so I cheated a bit and I added this allow partial flag here Just to make it easier to add it to the business logic But I could be on the meeting doing this and basically say hello Partial so in the in the case where we normally reject we make it optional so we We make it depend on a piece of Another flag so if we if we would normally reject it and then we'll before we do that we will look at this flag and basically either allow the rental or not and And so again The What you see is like you can immediately start to test that of course you can you can capture that in In hard-coded test cases as well. So if I click on these scenarios, I I have the option to build up test scenarios Which basically uses the same same kind of tooling but as you can imagine I won't go through it, but as you can imagine it makes it very simple to To add Add test cases with all that help that you get one thing that you might immediately notice is that it Recognizes the fact that you have flags here with yes and no values. It does things like even checking for the validity of the values that you put in all of this comes out of the box So all you have to do is is implement the the Elm model the on business logic for that And then the rest of it is inferred through the tooling through going through the more for IR And of course, this is still a pretty simple business logic But you can imagine that it gets a bit more complex and we start taking into account The weather as well and because we might be closed when the weather is bad So you can you can see an example of that here where we made the logic a bit more Complex and then it allows you to drill into it a bit So if I click on is closed then then it opens up the an explanation on how that logic works And then I can immediately experiment with it again So let's see Let's select a few few things you can see that it highlights the Decision that it made and then it immediately started to highlight the the decision tree as well Of course here. I didn't specify all the the data that it needs But if I do then it immediately Reacts and as you can see so this this makes it very interactive and very easy to work with the business to figure out the right business logic and Going back to the presentation So what happened is we basically shortened the feedback loop Extremely because normally to get that kind of feedback on the business logic. It takes at least weeks Because I mean you need to put that business logic into an actual system deploy it and then the the business users can Interact with it and realize that you need changes to the business logic. So that got decreased from weeks to minutes So that's a significant Advantage and then it doesn't stop there The other thing that you get which I didn't demonstrate Is you get automated automated implementation? So basically we use co-generators to turn the more for IR into various different languages I have a scala and the JavaScript example here So the nice thing about code co-generators is that they automate a very error-prome manual process And they are very reliable testable and scalable. So what do I mean by reliable? They they Don't make one of mistakes like Like developers do They will make mistakes, of course, like they can have box like any code But they will make make it make the same mistake all the time So it's very easy to detect and very easy to fix and once you fix it. It's gone And that goes back to the test ability and scalable, of course These co-generators can produce hundreds of thousands of lines in in seconds while human developers can't do that But what's more interesting is that it Elevates you to a different abstraction level. So you can keep the Without changing the business logic without ever touching the business logic. You can try out different technology stacks So usually when when a new technology comes in or like the entire technology stack Is changing that happens in a couple of years in our industry We usually have this huge risk of moving the business logic from one technology to the other Now if it's in the more for IR, you don't have to do that You you can use the co-generators to translate into that whatever that new technology is and and the other thing Is that you can accumulate your technical expertise in the co-generators themselves So like as a junior developer turns into senior They accumulate a lot of knowledge and then when they leave they take all that knowledge Read co-generators that doesn't happen. It stays there and it accumulates over time So Pretty good. So with that, that's that's basically all I wanted to say The most important thing is you can get involved more for his open source Go the core technology is really stable the the IR itself and the tooling around it But there are a lot of interesting tasks. It's an integration technology So there's there's always a there's a lot of potential for For building more visualizations to build more co-generators We have a few of those in the works already And verification tools as well. So we are working on some of those already with Microsoft as well Which you will hear about in the in the New York version of this conference So I'll just like to Invite you to get involved in the in the project. It's We have discussions github discussions is the best way to reach out to us We already have a few discussions started and in there so just jump on there and and start a discussion and And with that, I open it up for questions Right now it has to go from the coding side, but we already started to work on an editor that a Decision three editor which basically allows you to edit the decision tree itself and and turns it into more for IR It's really a matter of like an adding these tools over time But the eventual goal is for Non-technical users to be able to to edit the business logic as well But it all has to tie back to the SDLC eventually, right? So but the more for IR gives you that data structure that you can Manipulate behind the scenes and gives you that abstraction layer that makes it possible Yep Yeah, yeah, I mean the that tool that testing tool is is pretty recent But I mean a few months old, but but yes, we are definitely using it As a kind of a BDD test is I wouldn't call it BDD because it's functional programming So there's like no like no timing aspect of things. So it's more about inputs and expected outputs But it's like very similar to that framework. Yeah So the biggest one biggest one that we did It's hard to measure the size really There's two big ones that we did in the in terms of training systems One of the first one that we did with the predecessor of this technology, which was not open source was pricing calculation for securities lending which is I mean, it's pretty big. I mean, it's a it's Yeah, I don't even know how to estimate the the size of it lines of code doesn't really matter in this aspect but I would say in terms of like individual Criteria classification rules, it's in the hundreds and We also built a trading system which makes trading decisions and manages the life cycle of the trades within the securities lending area as well, so Yeah, they could yeah, they could We we actually thought about that. I mean that would probably be I mean the only use of that would be to test the code generators really Yeah, because I mean if you if you're testing the model and hopefully the code generator generates Accuable and code. Yeah, I mean so you can definitely do it Yep Yeah, so these all these test cases turn into Jason, right? So with the inputs and the expected output So yeah, it would turn into a PR that adjacent changes basically new test case or the changed existing test case Yeah, it's just data. Thank you