Scalability with domain-specific modeling languages?

Domain Specific Languages
1

I’m looking for your insights on what can be considered industrial-scale modeling based on your experiences.

Background for this is that we wrote recently a paper addressing co-evolution of tools (ModelsConf 2023) and applied there Fowlers Gothic Security DSL to make things concrete. It is basically a small state machine language with a case of one diagram and one developer. Some reviewers pointed out that our focus was not on the industrial scale.

Valid point and I’m considering what would it be then?

  1. Large model like 10.000+ elements like 10.000 states? Or more?
  2. Large number of language users, like 10+?
  3. Large language (metamodel like SysML, UML, BPMN size)? Or even several languages that are still somehow connected?
  4. Multiple tools/tool versions?

Have you faced in projects other characteristics that could be considered industrial-scale? Please note that I focus on technology and leave social and organizational topics out.

2

Hello @juha-pekka,

I’m working on large scale modelling at PayFit, a payroll & HRIS SaaS Platform for SMBs (available in France, Spain & the UK).

We built from inception in 2016 an internal low-code platform, called JetLang, which started as some kind of BRMS (to define the payroll-specific rules) and evolved into a fully fledged LCP to let business experts build user interfaces, workflows, data models, all at the service of the payroll computation.
Today, 80+% of PayFit application is built on top of this platform, based on modelling approaches.

While we do not (unfortunately :sweat_smile:) follow MDE standards, and rely on our internal tooling, I believe we have what could be called an “industrial scale modelling approach”.

I find your criteria relevant in our context. At least, we match all of them:

  1. We have 20,000 variables modelled (half of them based on computation business rules) and 2,000 pages to display them :point_right: this is only for the French codebase (numbers are a bit smaller in other countries)
  2. 30 Product Builders in France (40 in total), so 30 users of our modelling tools (with problematic around collaboration, versioning, etc.)
  3. Several interconnected languages, as I believe this is the core of any low-code approach: rely on multiple languages to abstract different parts of a software application:
  • a DSL to express business rules / computations, mixed intertwined with a data modelling language
  • an UI modelling language, to describe the pages / form components to be rendered
  • a few “satellite” configurations, which could be seen as DSLs
  1. We have mostly one internal modelling tool (IDE), again an in-house one, but are dealing with language versioning and data migration at scale when releasing new version of the code (on our 10+k customer base).

Back to your article, and the industrial-scale criteria, you can probably find other examples in the low-code editor industry (if you’re willing to consider this approach as a fitting modelling approach for your study).
Otherwise, maybe folks at Obeo have industrial use cases that fit those criteria as well (and they rely on EMF, so closer to an academic approach :wink: ).

1 Like
3

Hi @tvillaren

Thank you for the reply and providing details. Great story and building own low-code platform is something I’ve seen others doing as well giving as an additional plus a full control on how things are modelled, what is generated and where the apps are run.

I interpret from your reply that a large model (x0.000 elements), many users (~30) and many languages (3+) are suitable criteria to state that development is industrial scale.

On tool level, and having multiple users and languages, how you deal with collaboration? On modelling side as well as on DSL development side? Are you migrating the data to match to new DSL version or are your users doing it?

All use cases are welcome.

4

From a DSL development perspective, we have mostly a backward-compatible approach with a few exceptions when it comes to refactoring some features.
In that case, we try to automate as much as possible the migration, but may rely on semi-automatic one (i.e. offer options to our DSL users) and of course we make sure test passes (or are updated manually) to cover those.

From a DSL user perspective, collaboration is not very supported by tooling, but as the codebase is large, it does not happen so often that our users try to modify the same models at the same time. And when it does, they’re usually in the same team (we try to apply a DDD approach to the way they develop with the low-code platform, so scopes are overall well defined), so they sync’ together.
We have a few collaboration features on our roadmap to improve on this :slight_smile:

5

Thanks again. Backward-compatibility is indeed desirable and as all changes can’t be fully automated giving users notifications and options sound great. The more these can be automatically handled the more happier users :wink: In our case, sometimes language engineer(s) can make the changes to models as they all are in a repository (or repositories); either manually refactoring models or using automation.