Transforming digital transformations with Eclipse Theia and the Semantic Eye Framework

This talk explores the speaker's semantic AI framework designed to improve the effectiveness of digital transformations within organizations. The speaker identifies common challenges faced during such transformations, emphasizing that they often result in increased costs and extended timelines. He introduces a structured approach that focuses on three tiers: strategy, organization, and technology. The framework includes tools like the Eclipse Theia platform and a method called domain storytelling, which helps bridge communication gaps between stakeholders. By employing strong digital tools and modeling techniques, organizations can gain clarity on their processes and lead their own transformations instead of relying heavily on technology partners. This proactive approach aims to turn the complexities of digital transformation into manageable elements that foster both automation and innovation.

So, hi and welcome to my somewhat unusual topic in this tooling stream. I hope I can make it enlightening for you nonetheless. I have a lot to share, to leave you with a convincing story, let's dive right in. Many of you have maybe come to the same conclusion as I have that digital transformations generally are a mess. They often don't meet essential goals. They turn into existential

risks. They always take much longer and cost much more than anticipated. So, obviously, the current transformation approaches are not effective. This means we need a new game plan. Today, I'll show you how we can apply my semantic AI framework to achieve three things. First is to understand why those transformations fail. Second, to bring engineering and semantic models and digital tools to organizations and not just to development

teams. And to change several popular digital transformation narratives. I'll also show you um how the Eclipse Theia platform and the related open source frameworks can become those digital tools. I have Here's what I present before you today. I have worked in the software industry for more than 30 years in many roles. I have applied model-based software and requirements engineering for now over 20 years, but in the

last 10 years, I was working as a brand project manager on digital transformations, and I was irritated by the same recurring problems. So, I decided to do something about it, and that's what I'm going to present to I have three goals that I want to achieve. First, I want to raise awareness of just how bad the situation actually is. I want to give you a perspective for

a way out. And I want to point out the new market, if you will, for Eclipse tools. Scope, I'm not trying to solve digital transformation for every problem we can imagine. The Semantic High Framework focuses, at least at the moment, on organizations and their processes. This is not about um engineering processes or building construction or manufacturing and so on. It is really about organizations when they go

through the transformation. And even that transformation can be broken down into three, uh which I call the transformation tiers. We'll get into these in a second, and we're taking We're focusing on the middle one. Especially, that framework is not about the technology tier. That's important. I I'm a developer, but I've raised my level of abstraction or focus, so to speak. So, I've The Semantic High Framework is

my result of the last 3 years. I created it after a long a long and fruitless fruitless research of out-of-the-box solutions. I've been searching for almost 20 years. And that framework, the goal of that framework is to help organizations to sail through their digital transformations without the massive problems I hinted at on the first slide. Using it or not, that is a strategic decision for an organization.

So, what is it? It consists of five component components which build on one another. You see them here as a pyramid. At the top is your project. You can choose to um take any number of those components, but the combination of all five makes the most sense. Today, I'll have to concentrate on the bottom three, so we'll look into the conceptual foundations. There I'm going to present

you two instruments. That's the transformation tiers and the semantic compass, which guides, so to speak, the methodology. At the organization tier model, which we will get into also later, we'll have a look at what those models are or can be. And then specifically, we look at one diagram, the domain storytelling diagram, which you may know already. And then at the digital tools uh component, we have a

look at at the role of Thea of the Thea platform. But in order to reason about problems and solutions of digital um we need to make sure we're on the same page. So, let's do some alignment first. First of all, what is a digital transformation? Let's have a look at this extremely simple process of riding a train. In the old days, you would go to the train

station, look at the timetable, choose a correspondence, and then walk up to the ticket counter, buy a ticket right there, ask a few questions maybe, and then when the train arrived, you would step on that plane on that train, and that was of course was all analog. In today's world, you're much more likely to pull out your smartphone. You search your connection, and then you buy your

ticket right there, and you pay for it as well. And when that train comes, as before, you do your analog um boarding on that train. The organization here, of course, is the railway company. And one of the challenges we have to we're facing here is always the integration of digital and analog activities. We'll get into that a little bit later, too. Let me make two general comments.

First of all, digitalization or digital transformation always means automation, and automation is hard in every area. Many areas, many fields have had decades or centuries to get there, but we are only just starting. One important point to keep in mind is that transformations are much larger than software. And the digital transformation is not a project. It starts with a project, but it is actually a perpetual activity,

which eventually transforms the organization itself, not just what it produces, but also what it is and how it does it. And it's not just the IT system. So, that scope is much bigger, and that's also a reason why organizations should not try to outsource most of it, because that's going to create a lifelong dependency, which is problematic. Next, maybe that's going to turn into a fun fact

for you, because I think you know how software is being created, but maybe I can show you something. So, what you see here, I call this the semantic compass, because it's about the semantics of things and how clear-cut that those semantics You have two axes. The vertical axis is abstraction, so very abstract, very high flight level at the top, and details, microscopic details at the bottom. And

the horizontal axis goes from very vague vague to very precise. And you can already see that program code is on that side, because it's the ultimate definition almost of precision and detail. It does just doesn't get more precise and more detailed than program language. So, when we want to create or have a a vague idea or a need for a product or service at the point A,

then what we what the general perception is what we do is we we add some detail to it, we add some precision, we do ask more people, and we slowly move to the point B where we deliver a software solution. We might have to backtrack at some point, and certainly at some point we developers expect some sort of a specification at the point S, and then from

there they're on their own. Does that sound plausible as a as a journey? The reality is that's not how we actually do it. The reality is that for the longest time we do natural language and text, and we go down this left axis where we have natural natural language and formal languages are on the right. So, to do that, we use things like Jira, um Confluence, Miro

board, and those imprecise sketches. You know them, the box and arrow diagrams on on whiteboards, which eventually have no defined semantics. You see here that I'm I'm using something like a waterfall here, but I'm I'm not hinting we should do that. I It just makes things easier to explain because ultimately uh Agile and um iterative goes through the same phases. I'm just leaving out the looping. there's

a problem with that is that at point S we throw over the fence what we throw over the a fence is Sorry. We throw what we have over the fence and hope that the developers will sort out the mess that we still have in our heads or on paper, and that they make it all work. That's what I call the precision gap. This is actually something they

cannot do because the specification is necessarily full of holes and ambigu- ambiguities, as you certainly know. And this is not easy to overcome because the domain experts can actually not help. They source code, they cannot read it, they cannot have a look at the software. So, they have to wait until it comes out on the other end. Hold that thought, we'll get back to it later. That

was the first instrument, the second are the transformation tiers um that we've already uh saw before. So, let's look beyond an IT system and give some structure to digital transformations. These are three areas of responsibility and concern: strategy, organization, and technology. And I'm not hinting a moment that that these have to be followed as sequential transformation activities. They actually depend on one another mutually. It doesn't make

sense to define a strategy for which technology does not exist, is too risky or too expensive. And I can give you examples for all other dependencies, too. So, the strategy tier um that provides direction to a transformation. The organization tier is a conceptual view. It defines what the organization does and how at a slightly abstract level. And then the technology tier, that's the resource view. That's the

tangible resources like actual people, offices, invoices, software licenses, electrical power, you name it. That all lives there. And it's this tier's uh responsibility to hire, procure, build, develop, whatever all the resources that the organization need needs to fulfill its goals. Who's responsible there? Of course, at the strategy, we have the board and the top management. The organization is the actual organization, people, domain experts, management workers, can

be customers, whatever. And at the technology tier, we typically have resource partners and technology partners, of which I consider human resources to be one. So, human resources are not at the organization level, but they are at the technology level. Next alignment, what is an organizational process? You see it here. We We'll get back to this diagram multiple times. At the top, we have actors. Those are active

resources. They can be people, groups. They can be IT systems or even robots. At the opposite end, we have the subject areas. This is like taking a train. There is a lot involved there, a lot of um different kinds of objects, if you will, a lot of lots of rules, uh lots of constraints, that lives there with its element. And between, we have the process. The process

defines how we work. Here, there's a certain element of repeatability in there, how we work here ensure the expected outcomes. And it's broken down, it gets to activities, and it might get down to tasks, but that's not relevant here. Organizational processes are different from manufacturing or food processing uh or energy transformation, in that these other processes, they have flows of objects or mass. So, they're subject to

mass preservation. What goes in must come out. This is not true for organizational processes, I claim. We can easily create 1,000 objects that just didn't exist They might not even go out again. So, it's the wrong abstraction. And that's to me, that's one of the reasons why all the organizations struggle when they use BPMN, because it has this first kind of mindset. I think that organizational processes

are better modeled with contracts and that we consider them as transactions. So, they have clear start conditions and they have different goals that they can reach and it's easy to formalize those conditions at the beginning and at the end. And then we can apply tooling to it. All of this Sorry, stepped too far. Um This diagram is important, so keep it in mind. Um all of what

you see here is part of the organization tier. So, there's no technology here yet. Organizations can do that by themselves. And I did not mention it earlier, but every organization, every every company, every administration, everyone has organizational processes. That's why they matter. Now, what is actually going wrong? On the first slide I called digital transformation a mess and here's why. I have written down the prototypical transformation

project again in five stages. You may claim this is waterfall, but it works just the same for iterative ways. So, first there's a strategic decision by the board like a go for launch. Then there's a business concept phase. The goal of that is actually to create clarity, to to define the business goals, processes, responsibilities, etc. Next, they will elect or choose a partner for technical end. They

will choose a platform and eventually those people set to work. A specification is created and then they customize the platform or develop something new. It's tested. Change management is put underway and the solution is rolled out. The effects on the transformation tiers that that has are quite predictable, but we can already see here that it's starting to get technology heavy. Now, what happens in my humble experience,

and it's it's always the same. I've seen it so many times, but well, maybe it's just me who caused it. At the strategic decision level, it's all but rainbows and butterflies. It's all good. They know they're aware of the the gravity of the situation, and they expect some problems and high costs. So, say they put up a budget of 1 million euros. Next, the business concept phase.

That's where the confusion sets in because those people often do not know what's expected. Um they're lost. Of course, usually there are external consultants, but eventually, let's say they come up with 200 user stories. Then, they select a partner. They come in. They say, "Sure, no problem. We can do that." They start to have a closer look, and they find some holes, and eventually, you have 300

user stories, and it costs 2 million euros. Then, when they start to set to work, chaos and frustration sets in. Suddenly, there are 1,000 user stories, and it costs 5 million euros. Eventually, it's rolled out anyway, the users go like, "This is worse than before. We There's so much missing in this new system. We need another 500 user stories, and it now costs 10 million." Not sure

whether you share this kind of experience. I've I've put it a bit to the point, I know, but that's the experience that I took in from about 15 projects or so. The root causes of this, there are many, and today I just want to focus at two. One at the organization tier, one at the technology tier, which I call feature negotiation, which is just a poor methodol-

methodological resort. Also, something important, I'm not going to this, but maybe you've already noticed, there are no tools of no tools worth mentioning being used at the organization level. All they do is text and some sketchy diagrams. So, let's talk about organizational complexity first. Organizational processes are instantly complex and complicated. You can talk to any expert and you will be surprised and amazed at just how complex

even a simple process is is. Because they need to um cater for all the edge cases, like someone loses their ticket, now what happens? New situations arise every day and these processes actually only work because we have those skilled humans with years of experience who will just find some way out um of that pinch. The main problem here is that there is actually no established methodical way

to deal with that. And the comp- the organizations are left alone in dealing with that complexity. So, we I think it's fair to say that a transformation is an exercise in massive complexity and I'll prove it to you. Organizations do not master their own complexity at levels that would be required for automation and innovation because there are so many aspects. First of all, they have to digest

the strategy that comes from above, they have to master the subject areas and have to formalize those somehow. There are processes like the ones that they have now, the ones that should be there tomorrow. There are new requirements. They should do business innovation, which by the way is extremely hard and a huge challenge for those people. Technology innovation, that's usually the responsibility of the tech partner. And

they should do change management, which also is a big problem. what they do typically is they try uh to find someone that they can delegate to, and that's the technology partner. That's your IT company who does transformation projects, who does web applications, stuff like that. The problem there is that these technology partners can only deal with technology-related complexity. They use very powerful tools to do this and

are successful at it, like formal languages, compilers, integrated development environments, and for example, Git. Um hold that thought, too. the misery starts because there are technology partners who suit see this as a challenge. They deliberately ignore to see that it's a mission impossible, but since they usually leave the crime scene without financial harm, they still The main problem is that these companies they have they know nothing

about the organization, about subject areas, processes, markets, customers, and so I've always heard the same story. Ah, we have smart people. They learn so quickly. You will be amazed. The problem The knowledge transfer eventually will not work. And that's because the domain experts who are so supposed to transfer the knowledge, they cannot provide um this conceptual clarity at the organization tier. That would have been the result

from the conception, from that business concept phase that we saw earlier. So, the focus necessarily shifts to uh software and software features because that's where the technology partner is really apt at. The organization tier is essentially skipped. Work is not done there, and the organization drives passive role and is driven around by the technology The only way out they have is they settle on something I call

feature negotiation. So, they do it the the the iterative way. They take one requirement at a time or a bunch of them like 2 weeks worth of it. Think user story. They implement it. They create some software features and then they validate it and then they start to turn in circles. The problem with this is that complexity is not mastered up front. So, they will in a

piecemeal style, they will slowly discover what everything that is involved and then they will find that it doesn't match up. This implies also that um there is no coherent big picture in the end like a domain big picture like the the the processes, what does this organization do? Because it it's just left in the dust. They never do it and there is no alignment on the business

stakeholders either. There is someday or are all in in involved at some point, but it's not what could be. So, that's the situation we are faced with at that point and I was somewhat glad to discover that this is for me this is the problem, but then how to solve it and I turned to look what other industries do that are more successful with digital in their

projects and projects and with their products and there is a strong recurring pattern All those industries they create conceptual solution models at their organization tier, which might be called different at that. Um usually what they do, they have some shared language with defined semantics and they do a very strong and rigid stakeholder alignment before they actually build the product. Take building construction for example of which you

see a blueprint on the They have very defined syntax and semantics on each of those elements and they are highly standardized. Draftsmen have make it do an apprenticeship of 4 years to learn to draw these. Note the arrow on the staircase. That's There's no two ways about it. There's no room for interpretation. But you have to know whether that arrow points up or down the stairs. So,

that's what I call non-ambiguous. It's the same for music. An orchestra just couldn't perform a Beethoven concert without the musical scores, which are which are a conceptual model of the music they're going to play. If we put that back into these transformation tiers, then we see that they do a lot of work at this middle tier, which they call architecture. They create their their solution model or

conceptual model are the blueprints that they do. And the blueprints have the role of a specification and of a contract. There's also a strategy aspect um to it and there's a central role that's the architect. He is the designer or she is the designer and mediator between the future building owner and the craftsman often he's also the draftsman. In Agile development, for example, we still don't do

that. The architect draft doesn't Well, we have architects, too, but um in the building construction, the architect draw talks to the the um craftsman, not the future building owner. Whereas, in Agile, we do exactly the opposite. The future users, they talk to the people who dig the hole. And building construction has been doing that or has been abandoned that practice 500 years ago. So, we need a

new game plan. And the basic idea behind this is that we shift the organizations focus to that organization tier, that we create explicit solution models for them also with defined semantics. And that's why I told you to hold that thought about that process diagram, because that's what we turn into models. And we use those solution models as specifications, just like building construction and many other industries do.

So, next question is how will we create those models because they will not just fall out of the sky. We'll come back to the semantic compass to guide us. what we should actually do is we should formalize all artifacts early, much much earlier in the process. So, we should go down first the red route and then the green one and then we get into what I call

the digital automation territory. That's where we can use digital tools to create, validate, and generate artifacts. We still have the problem to solve with that precision gap. So, the new strategy is we formalize artifacts early, and then we build, align, and optimize semantic solution models until everyone is happy. This alignment aspect is really important. We don't need to build software to find out that we've misunderstood the

domain. We should have something which gives us a much quicker response and a much cheaper uh validation of our ideas and And only then will we onboard technology partners. So, we create a big picture first and then we go out. If we get that 80% right, we are five or 10 times better than we are today. There is a lot of negotiation going on later, but if

we don't have that big picture, we're lost from the start. So, in detail, that means we bring engineering to the We make the organizational process the unit of digital transformation and we change around those narratives that are so ingrained today. And we change them to that the organization first creates a shared view of its future and then leads its own transformation rather than being driven around by

technology partners and making themselves dependent on it. That they understand the world through semantic models and that they drive automation with information and not just blunt data. And we make transformation manageable by using strong digital tools that help us to create those aligned futures, models of the future. And as a platform I think uh Thea and the related open source frameworks are great basis to be just

those tools. Now you've probably asked yourself what those models are like. I'm sorry, but today I've just not have enough time to take you there and you'll have to come to my presentation next year. But we'll focus on just one and that is domain storytelling. Can I just have a show of hands? Who has ever heard of domain storytelling? One. Okay, so I'm glad to maybe show

you Domain storytelling has existed for a number of years. I once took a a course. These are guys from Kiel who have developed the notation. There's even a book about it. Um and it's it's a great um knowledge capturing and stakeholder alignment tool. I'm time and time I am amazed at how quickly I get feedback from those users on from those domain experts. They always claim to

speak one voice, but you start drawing and 2 minutes later they start to disagree and that's a great What those diagrams do is they are semi-formal. They have some formality, so they do here I'm not sure whether you can read it. Yes, you can. Um it says "Landowner submits building permit application via cloud upload to building authority." So, we have a sentence that we can print, but

we have already identified two actors and two different work objects or it's more of a channel with a cloud upload. The second one is "Building authority confirms reception within 2 days." That's an informal kind of thing of building permit application via email to landowner. And you'd be amazed how far you get with just this. And from these I can later easily derive more formal documents. So, I'm

using domain storytelling as a halfway house to break down that huge precision gap. We make a stop in the middle and rather than we go from like informal text, word documents, whatever, sketches, we do domain stories and we start to focus on that process, but with a strong notation of work objects and agents and actions. We need a to this to do this we need a a

language that is somewhat precise, but not too much and that can span some range um of detail. And domain storytelling does just that. So, you see here on the diagram after DST domain storytelling bubble, we use that as a basis and we no longer rely on text. We do still rely on text somehow, but we can fix that later. Here's a little example of a case study

um that I've done for the Swiss blood stem cell organization. You don't need to read any of this, but this is just an overview of part one of five of their process. And the detailed view of this part one of five is 28 diagrams. Over 900 activities, whereas they started with the tendering and when they selected their partner at the platform, they had 270 user stories between

four to two eight lines for the whole process. So, they really had to wake up and awakening here. So, you just see how the massive complexity in those in those processes. Let's get to the tools, the role of the The vision I have presented is very ambitious. I'm well aware of that and what the organizations are expected to do is really really difficult and we have a

long way to go there, but I think it's it's inevitable. It's like the delivery of a birthday cake to the other side of a wide river when there is no bridge. So, we should ask Jesus to the rescue. So, you ask, but why Jesus? Because, well, Jesus can walk on water. Now, organizations cannot walk on water without proper support, but we can certainly work on that. So,

that's where I see the the semantic AI tooling. It has to be there under the water surface and it has to help It has to be there whenever the user wants to make a step to get to the other side. This analogy analogy is attributed to Alan Kay or Steve Wozniak. I didn't invent it, but I could not confirm it either. So, the role of the tooling

that we have, organizations are facing really immense complexity and we we had a look at that at these many dimensions. In addition, there is one more and that's configuration management. They are not used to having multiple versions of the same thing at the same time. Git has not arrived at those organizations yet. So, they all do it by prefixing document names with dates and adding version comments

at the end. So, to me it's compulsory that we store our models as human-mergeable text. But, then on the other side tools must make complexity palatable. They must make it accessible to them. So, we need intuitive structures, we need intuitive diagrams. We need automation to help them. We need guidance and support where AI can help us. But, for the longest time or as far as I can

remember, diagrams are always stored as XML, JSON, or in binary format. And that's just not compatible with Git and merging multiple diagram versions into So, how can we store diagrams in human-readable language? the cross model does just that. The cross model was presented at TheiaCon last autumn and it's a Theia-based open-source application that you can study. And it elegantly unites text, graphical, and form editors by using

Langium, GLSP, and React forms. It also runs either on Electron as a standalone application or as a browser. The code is there. One can study that. The architecture that they propose is like this. They have Langium server at the bottom, which is responsible for parsing language text and for storing it in text format. And it's also the server from which the GLSP, the diagram server, then derives

its graphical model, which it sends to the client for display and editing. And we also have a text editor, a syntax editor in VS Code, for example, or in Theia, that presents that language text to us. So, we come to the to the the demo part of my presentation. I've started uh I've decided to start the Semantic AI tools with two editors for domain storytelling. domain storytelling

has a great role as a halfway house, as I have just explained. This is always the way when I get to a new client and they I I have to find out about their processes, I do domain stories for several weeks with them until it comes out of their ears. The other thing is that this free editor that you can use, it's great, it does the job,

but it has certain shortcomings, and the biggest of which is that it's each diagram is an island. So, when you want to change the name of an actor, you have to open to upload into the browser seven diagrams, change that name, store it again. It's just um Firstly, it's it's uh takes a lot of time, and it's just lacking consistency. I want the tool to do this

for me. Also, Egon is persisted as JSON, which is not gettable. So, what I've done is I've created a Langium text editor for this, and yeah, I added two features that I was missing. First was I added the storybook, which contains many stories, and you can share actors and work objects across stories through that storybook. And I've added an icon library, which lets you store similar icons

uh across lets you reuse multiple of the icons across many of your diagrams. So, you change it in one place, you change it everywhere. And I've used um Google Material icons for this because there's a thousand of them. Actually, the guys from domain storytelling the the Egon.io, they do the same thing. I copied I copied them as much as I could because I think they've done a

great Secondly, I've created a graphical uh GLSP editor that picks up this uh icon palette and shows it to you, and with that you can then um edit your diagrams or have them layouted in whatever form you want. So, this demo that I'm going to show you, I'm not I didn't get quite as far as I wanted which I had in mind at the point where I

um handed in my application for this presentation, but I'm still like you said, as a proof use it as a proof of work. So, I'm going out of my presentation here and into mirroring mode. Let me just switch that. Now, where is it? Can you already No, that's the wrong one. Right. here we are in VS Code. What I have is are just two separate VS Code

extensions. I have not married them yet, but I I think about doing it with the help of this cross-model approach. Here um first I'm I need to switch. I'm going to show you the language first that what I um sent with Langium. Here's again the story that I mapped. I'm going to close that. We have several files here. We have the Permitted Book. Uh we have the

library and then we have just one story. Let's close that to have more space. And this is what it looks like. It's a nice uh an editor which um can do for example, it can do renaming for you uh and it will be renamed everywhere. So, if we go to the book now, this this was the story. Let's go to the book. Now, the book has changed

its name. So, you have all the language features and I can I think I can even do that an undo on You introduce your work objects. You um link them up with an icon. The icon library, I can do command-click and I takes me to this the definition of that. This is the icon. This is the URL um where that icon lives. I can even um associate

a color to it. and then this is the actual story here. Excuse me. I have to do it with the trackpad and I'm not used to that. Um so, land owner submits building building authority and then it all comes back. We can even do the notes. So, there's the little footnote here. It says within 2 days and we have some um consistency checking. For example, here's a

warning that says, "Well, this annotation here has no reference to it." So, there's a lot of comfort and we can have a really rigid model with quite little effort. Now, that's one part and that's how you do that and it's easy this way to do 50, 100, 200 stories because they will always be uh consistent and it makes it easy for you to edit. But, we also

need diagrams because that's what users expect and that makes it much easier to work with them. So, here I've created an empty file for it and when I open it, it's empty. And here is the palette with all those um icons that we have shared. I faked this, I must admit, but the icons they are there. They're pulled up. They're material icons that are pulled up this

this palette and now we can do uh we can take a land owner, set it here, set him here, put in permit application, uh add a verb, rename it, and so on. And I'm not going into the full thing, but that's how it works and what I want to achieve is that when I save this, I get language test text, language text, and it's stored at that.

So, going back to my presentation, I have, of course, a road map and it has two streams. One is the concept that I've developed over the last 3 and with my presentation you can see it right there. That's the combination of that for the moment. And then I have a tooling stream. I will call that tool the semantic lens. I cannot explain why so far I've done

a language prototype and a GLSP prototype and I've also done prototype on marrying them but I decided not to show that today. So over the next months or years I will first evaluate whether that cross model works for me and then I will start implementing the domain storytelling editor because that's what I need for my daily work and then I'll add type system on it, entity relationship

diagrams, state machines, expression languages and so on. I've already built this with Xtext about 7 years ago but that's that's the plan. So conclusion or proposal, what we should do is we should we should shift the organization's focus from a passive involvement to an active leading role. We should introduce explicit software supported solution models with strong domain semantics and we have to introduce strong theory based organization

level tooling as a key enabler. For more, see my website. I'm happy to take questions for you. There's one. So thanks. I would be interested in knowing a bit more about what you mean when the JSON files are not gettable. I understand the other cons of of the first solution that you You mentioning. I don't understand the JSON files are not getable. the problem is usually I've

I think this is also that was the demise of many UML tools. They always stored their their diagrams in either XML or with JSON or so on. And references are bad with JSON, for example. And when when you modify a diagram and then just persist it as XML, for example, sometimes orders change and you have it's impossible to to merge two versions of that diagram which were

stored independently in in XML to get them into a consistent form again. Sometimes that diagram is lost in my experience. That's what I mean by getable. And here we have a language and we have a compiler or a parser that tells us whether that thing is correct or not. But it's easy to to corrupt an XML or JSON file if you do the wrong thing. Um about

the solution you are developing and it is now as far as I understand a prototype. Right? Yes. I can imagine that for big organizations you you you will be also um required to store part of the domain in some kind of external repositories that are being that that need to be then managed independently. I for instance, I don't know, um big databases of actors or um things

that leaves that leave an independent life and can be used then by instances of the of the story telling. Is this also foreseen in your project? Well, I I I plan to to store everything as text and then you have your a get repository and you put that on GitHub on your own or your company get and you can refer it from other sides. You can share

it. That's that's the plan. So, I want to use developer tooling that we have to develop software today. I want to leverage that and push it into the organization later. Yeah. Very nice. Very interesting. It's I I imagine it uh I mean uh also in my I mean we we write software and we have sometimes some kind of um I would say yeah, communication gap between the

product owners and and us. It could help a lot. Yeah. I mean this is this could also help at a higher level like the upper management, you know, but also at lower level like with stakeholders which are technicians, but maybe they they define the requirements, but maybe they do not really talk our own language of technician of a very specific technology and this could also help a

lot. >> That's why I call it the semantic models. They These are models which use the terminology of the domain specialist. You can also The domain can do also could also be software development and then you have a different set of of terminology. It works with whatever field you have. But you need to make it formal. You need to have the help of tools to manage that.

A last question if you if you allow. Um how does this solution compare with SysML for instance to describe systems I see SysML is has a very technical focus, I think. It's something at the technology tier. It's not a tool at at the organization. Whatever I I showed you how in architecture well, the tier is called architecture and not organization, but it's it's something that lives at

this lower level and which it's just hard to get out of there. Okay, it's not really filling the gap between languages and >> Yes, I think I think that's my Yeah, I agree. Thank you. Right, so do we have time for one more? No. So, we have to we can um Oh, right. Because he waved back there. So, Sebastian, please. Uh I have to ask a provocative

question. Please do. Um yes, I will. So, you mentioned the example with the blood stem project where they had like 500 or 200 user stories and uh, each user story was basically a single line in a spreadsheet. How's that line in the spreadsheet different from a line in your domain specific language? Well, that's exactly that the precision a kind of thing. So, that line is only text

and it can be misunderstood in so many ways and it doesn't have real context. Whereas, if you have proper models, each object or each class or type lives in a context by the references it has to other things. So, objects are always defined, their semantics are defined in a context and a user story is just one morsel that's written usually by people who are often not even

trained requirements engineers. Okay, so we have a so to say a glossary that and we ensure that the vocabulary is used consistently domain specific language. But, how does it help with the completeness of the user stories It doesn't. Okay, it doesn't. So, you still have to have to manage your domain and you you have to know when you're done. Thanks a lot for giving me those um,

two more minutes. This is the next speaker and thanks for coming here. Thanks for the interesting questions and see you.