A proposal for a future tool platform

As the size and complexity of systems and business engineering projects grows, the tools to build the underlying models have to become more powerful. While adequate ALM, PDM and SCM tools exist, the core modeling infrastructures fall short of what is needed. These tools have to support a wide range of expressive languages to describe the models, must enable a diverse range of analyses, scale out in terms of model size and user community, support various forms of collaboration and, finally, play well with today’s web and cloud infrastructure. Here is a paper that outlines a platform for such tools.

I’d like to get your feedback, and then hopefully assemble a community of stakeholders who might develop, finance and ultimately use such a tool.

6 Likes

You’re making me read again… I’ll let you know soon.

Is it an idea to also present this during the LangDev meeting?

If I go there I will submit.

Just read through it, albeit gave some parts more of a glance over than a thorough read - mainly because I know your ambitions already. I like the idea very much - there was a reason that a short while ago I posted on LinkedIn or Twitter that having some proper (modeling) languages to work on cloud solutions would be useful. It’s a hotchpotch of command line tools and scripting languages that any new engineer gets lost in if not very careful. That’s the engineering half or your problem statement, on the business modeling side, where I did a lot of work the past 3 years, the same problem exists also, indeed.

I like the idea lot, I’d be happy to be part of it also.

The only weak spot I see right now is the sexiness that’s required to get that commercial organisation involved to develop the tool. It requires an investment, and one of the things I learned recently is that investors follow hypes. Right now, software engineering tools are not very interesting for tech investors, at least not in Europe, unless you can include a magic word like AI in your story, or address the issue of converting legacy code into models.

1 Like

Unfortunately, you might be right. “Microservices”, and “AI/ML” are also a good buzzwords. Maybe we could have a more “marketing-focused” version of this document which weaves those buzzwords in in a way that would still make sense.

In any case, it’d be good to be a bit more explicit on how to migrate from a(ny) current situation to one using the tool platform.

@voelter: is this paper inteded for the closed audience of this community only, or is it okay to share it with 3rd parties atm?

One thing that I would love to discuss in this community is how to communicate better about DSLs. We have clearly a positioning issue, which the low-code/no-code approaches seem to tackle better than we do.

Being involved in an AI startup I confirm that it helps getting investments :slight_smile: (we do explainability AI).

That said, I think that here investments could come under a bit of a different logic. Investments could come either by organizations which would typically pay a consulting company to build a DSL, or from such consulting companies.

Of course a key element of discussion is who would own this thing and another one is what kind of investment is needed.

Also, we are talking about a cloud solution so would it make sense to have some commercial offering just about the hosting/provisioning part? Some companies may want that to not have to take care of that themselves, while others may want to have the possibility to host their repository on their own servers.

1 Like

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.