A proposal for a future tool platform

We may want those persons to be invited in the community also :smiley: In case you have any name that you want me to give access to please let me know

Anybody who has money :slight_smile:

2 Likes

I would be interested in collaborating on this project. I am running a very small company, so I may have not the possibility to contribute large funds, but I would happy to help on the engineering effort, if there are enough partners to make this viable.

From my point of view, given my limited energies compared to medium/large companies, I would tend to focus on finding the shortest path to get the core of this product used in a significative context. Perhaps integrated with some editor technology to be part of a usable language. Maybe to be used inside a tool that perform model analysis, I’m not sure.

Well it just so happens that I gave a demo an hour ago (not kidding) to a very potent company who is currently planning on building their own platform that checks pretty much all the checkboxes you describe, with the big ceveat that they operate within a specific domain. I cannot share any more details at that point other than that I demoed the benefits of projectional editing and language composition, and that the result basically was that they realized that this is what they were looking for.
Anyway, I would be happy to share your document and see what they say if you give it a go.

3 Likes

My perspective on this: the low/no-code vendors don’t do a better job of communicating about DSLs, since they don’t care about that at all. From their perspective, a DSL is “just” a way to “configure” their runtimes or generators. They might not even know the term DSL, or know much/anything about language engineering, and model-driven software development! And why should they?: they have a fixed domain that’s slowly expanding/evolving based on feedback on the semantics of their languages.

What these vendors (such as Mendix; disclaimer: I worked there for about 2 years) tend to have, and are able to sell (quite well, one might say), is a one-stop shop type solution: it’s not just a modelling environment but a true aPaaS, including runtimes, deployment, provisioning (in the Cloud™), project management (Jira-like systems), and other integrations.

I think that’s a large part of our communication problem: we’re trying to sell part of a solution, not the whole solution. That means we’re reliant on “regular” developers knowing what DSLs/MDS*/LE/LWBs are, but why should they want that: you’d only be taking away their job. (That you might replace it in-situ with a nicer one is often besides the point: you’re initially taking away their control of the situation.) Instead, it’s much easier to sell to “The Business”, but they’d like a full-spectrum solution, not just a tool and method to solve part of the problem, and leaving integration of that solution to devs who rarely have the skills to do that (well). This is something that we definitely should address, and make clear in the proposal, IMHO.

But, we certainly could invite people from low/no-code vendors to share how they sold their aPaaS’s. A name that springs to mind is Johan Den Haan from Mendix (johan.den.haan@mendix.com).

3 Likes

My bad here. What I meant is that do a better job at positioning themselves and explain the value they provide.

I read that you can understand you have a positioning problem when your clients are happy with the results you provide, but before becoming your clients they have an hard time understanding what you are selling. I think this is the case with DSLs and therefore we should explain better what we do. We may also need to package better what we do, and provide more integrated solutions could be part of the equation.

I would love to talk to persons from Mendix and invite Johan Den Haan in this community. Should I dare just write him an email, explaining you made his name?

1 Like

@ftomassetti: That’s actually exactly what I meant, so no bad done :wink:

Plus you’re right it’s two problems: 1. explaining what the added value of using a DSL-based approach is, and 2. being able to provide a (more) complete, or integrated solution.

I think he wouldn’t mind if you wrote him an email, mentioning me. I’m not sure he’d have time for it, though, but it doesn’t hurt to try.

Johan would show up occasionally I expect, although he’s a lot busier than 10 years ago.

I invited him. Let’s see :slight_smile:

Please share and let me know what they say.

1 Like

I also feel the positioning problem in my context trying to sell DSL approach in my company (Sioux Group, Eindhoven). I agree we should better explain the added value of what we do. I like the point @meinte.boersma is making that we should focus on the Business value proposition, find a way to leave the language engineering terms out of the story. It seems “full-spectrum solution” is a nice way to do that.

It is a topic very interesting to me because it’s one I’m struggling with for some time. Judging from the beyondparsing.com interviews I would expect it is something that more of us in this community are experiencing.

@ftomassetti I think the “positioning problem” might deserve a dedicated category in Strumenta Community. Maybe with a name like “Selling MDE.DSL solution”. Some members could share their (success) stories and/or lessons learned. What do you think?

1 Like

@al.darmonski Well put. So the challenge is: how can we explain what this is, in terms of what it means for the business buying into it. Selling DSLs and related tools to engineers is relatively easy, selling it to business modelers is a lot harder. I spent two years trying that at BMW Alphabet, and it literally took some fights to get even a single step further.

Very nice writeup! I’d love to see this happening, and to find a way to contribute.

I do not think offline work (and later, deferred synchronization) is required; networks are becoming more and more ubiquituous.

I disagree on this point. There are, and will be, lots of situations without network connection, e.g.:

  • Deliberately separated networks inside companies
  • Specific Domains: Construction, Infrastructure, everything outdoor-y, WiFi-free (medical, research)
  • Travelling (airplane or Deutsche Bahn)
  • Every time $MY_OS or $MY_NETWORK_PROVIDER decides to do strange network things

Do you have some ideas how to build this incrementally and collaboratively?
I doubt we’d manage to pull this off if we aimed for “the whole nine yards” at once.
And we won’t get all of it right the first time.

2 Likes

I am not against off-line work. Excluding it was simply an exercise in descoping, to make it not even more complicated.

1 Like

Hi all… thanks Markus for putting forward this proposal. That kind of “cloud-scale” modeling infrastructure is something that I have been thinking about for some time as well.

Since there seems there are many complex technical issues to build something like that, I’d propose we start by focusing on interfaces based on the initial requirements we know about, and back them up with naive/cheap but functional implementations, that even if they cannot operate at scale, they complied with the contract correctly (if we ignore the more demanding non-functional requirements). Maybe even a hackathon would be enough to take us to an initial toy-like implementation that addresses the first few critical use cases adequately and displays a sensible architecture.

That would allow us to start implementing clients for this repository, and allow us to find time/resources to replace the naive implementations with much improved ones that can actually provide the latency/reliability/throughput characteristics that would be really required for this kind of infrastructure later.

Another upside of this interface-centric approach is that it promotes a model that makes it easier to combine open-source and proprietary/commercial components.

Finally, of course, such interfaces will need to be revisited as time goes by, and we discover technical requirements that challenge the choices made so far, or even require things that used to be separated to be implemented together, or vice-versa.

2 Likes

I would agree with @rafael, however from the discussion of today I had the impression that @voelter has much more experience than most with incremental transformation engines. My understanding was that he was saying that it is a difficult problem to tackle and that in order to have decent performance one has to couple the way tranformations are executed with the way data is stored. So this would leak into the design of the API, if I understood correctly. I personally feel that I do not know enough about these incremental transformations, so it is difficult for me to comment.

I wonder if there is something I can read to learn more about these incremental transformations

1 Like

For sure, @ftomassetti, the more the persons defining the interfaces understand the basic requirements, the closer they will match what would be needed for the final interface.

But we don’t need to get things totally right at first, if we are prepared to evolve as required. Also, we should only define interfaces where it is clear they are needed, and not separate things “just because”, in order not to make it harder for implementations to benefit from coupling. At a minimum, there must be at least one interface for clients to put/find/take things from the repository.

2 Likes

How would the platform manage derived models?

Example: User edits model, change notification is sent to the typesystem service.
The typesystem does its thing. Now the editor service wants to update its error markers.

How does this work? I can imagine different approaches:

  1. There is a separate channel between typesystem and editor, the active repository doesn’t care.
  2. The active repository only offers event propagation, without any incrementality.
  3. The typesystem delivers a derived model to the active repository. The derived model is processed the same way as the “real” model, but not persisted.
  4. The typesystem delivers amendments to the real model, which are not conceptually different from the “real” model. The active repository treats them the same way as any other model change (including persistence).

My gut feeling says 3), but I cannot overlook the consequences.

Shared a document with considerations and design alternatives for the Active Repository.
We can use it as a wiki to organize and explore ideas.

I started adding:

  • Use cases (we need to dimension the cases, sizes, etc)
  • Then can start choosing technologies to ensure scalability reqs.
  • Minimal API
  • Alternatives for model format
  • Pros & cons of languages
  • Techs to consider

Feel free to contribute.
Just request access for write access and I will provide.

All the best!
Pedro J.

2 Likes

Something that is somewhat related to what is being proposed here:

1 Like