Towards the interoperability of low-code tools

The adoption of low-code platforms (LCPs) is growing. Many big tech companies are using or building their own low-code platforms. And there is also a rich ecosystem of open source low-code tools. All helping companies improve their software development productivity by (semi)automating the implementation of their software systems from a (reduced and pragmatic) set of models.

However, there are still barriers hindering their adoption. Among them, vendor lock-in is a major concern, especially considering the lack of interoperability between these platforms. Typically, after modeling an application in one LCP, migrating to another requires starting from scratch remodeling everything (the data model, the graphical user interface, workflows, etc.), in the new platform.

In our paper titled Towards the interoperability of low-code platforms, co-authored by Iván Alfonso, Aaron Conrardy, and Jordi Cabot, we study the interoperability between the emergent market of low-code tools as it will have a significant impact in the adoption and long-term success of this new model-based style of software development.

We specially focus on the most important ones, according to Gartner. Indeed, Gartner periodically provides its Magic Quadrant for enterprise low-code platforms, which assesses and positions LCPs based on various criteria, such as their industry leadership, features, vision, etc. In its most recent version from 2024, we see LCPs like Mendix, OutSystems, and PowerApps being positioned as market leaders, given their popularity across different industries in areas such as process automation, financial services, public sector industries, and others.

In our work, we first analyze the current import/export options offered by major players in this market. Based on the identified limitations, we propose a model-based migration approach to enable interoperability among the leading LCPs. In an attempt to overcome strong exporting limitations, the approach is enhanced with capabilities of visual large language models (LLMs) when needed.

Evaluation of the interoperability situation in low-code tools

We explore whether the model created in one LCP can be imported in another LCP, e.g. to enable the generation of the application using the second LCP (who may have a better support for our target tech stack) without starting from scratch.

For each tool, we have evaluated the import and export capabilities for the three major types of models provided by each low-code platform (Data, GUI, and Behaviour). The collected data is summarized in Table 1, and some conclusions are discussed below, particularly in relation to vendor lock-in.

Discussion points:

• While some tools use the same format for storing their models (e.g. JSON) their internal schema is completely different therefore requiring a migration phase before they can be used in another tool
• Support for data models is (with limitations) common but there are many more limitations when it comes to the other types of models. In terms of options and in terms of diversity and quality of the import/export.
• Some tools do not offer a real model import. There is no option to pass them a model. But they offer the feature to initialize a project based on an existing data source ( a database, a CSV or Excel file,…). So a pseudo path to import a model in those tools is to create a, for instance, Excel file that somehow represents the model we want to import. Obviously, there is an information loss (e.g. ambiguity in the definition of the data types, absence of explicit relationships among classes, no validation rules…) as the model is not directly imported but has to be inferred from the CSV.

 

Model-based migration approach

Based on the previous analysis, it’s clear that we need a solution to help companies migrate from one low-code tool to another. Our model-driven solution for migrating models from an LCP A to an LCP B is summarized in Figure 1.

The input file stores the application model/s. If the tool offers a formal model export feature, this file will contain the model expressed in a textual concrete syntax conforming to the tool language (e.g. a JSON file conforming to a JSON schema mapping the language concepts). Otherwise, we use as an alternative an image file capturing the graphical model (i.e. a screenshot of the model displayed in the tool). This dual input format accommodates LCPs that lack complete export support.

In both cases, the file is parsed and transformed into an intermediate model. In the first scenario (a formal textual description is available) a text-to-model transformation is used to create the model. This type of model transformation uses a grammar to parse the file and produces a model conforming to the language metamodel used as pivot representation between the two platforms. In the second scenario, an LLM is used to create the intermediate model directly from the provided image.

These intermediate models conform to the B-UML metamodel, the modeling language we used as pivot language. B-UML, part of the BESSER modeling framework, leverages and adapts well-known modeling standards, including UML for defining data models and IFML for UI models.Once the Model is created, it can be refined or completed, if needed.

Finally, a template-based generator creates a textual representation of the model but now in terms of the concrete syntax expected by the target platform (LCP B). When such platform does not offer a model import feature, we rely on other available imports such as importing from Excel or CSV files which is common in most tools. Note that in this case we may lose some information as LCP B is not directly importing the model but inferring it from the CSV structure.

Running Example

As proof of concept, we have implemented some migration paths on top of the BESSER platform. Our prototype is open-source and available in the project repository. Our current tool support is restricted to data models and support for the interoperability of UI and behavioural models would follow the directives explained so far but it’s left as future work.

As an example, we show the transformation of a simple library data model. This model is originally defined in Mendix. Let’s assume we want to first export it from Mendix and import it into PowerApps. First, the Mendix data model is exported as a JSON file using the formal method provided by Mendix. Then, a T2M transformation for Mendix takes the Mendix model and transforms it into a B-UML compliant version. To be imported into PowerApps, the B-UML model is given as input to the generator for Excel files that will produce a spreadsheet that PowerApps will be able to import and use to recreate the model. We see the result in Figure 3. Although the generated Excel file includes associations through columns linking different sheets, due to limitations on PowerApps’ side, the model is not complete as it is missing its relationships so this part needs to be manually completed.

As a second example, assume that now we want to move from PowerApps to Oracle Apex. In this case, we use a screenshot of the PowerApps data model and the CSV files that PowerApps is able to export representing the classes (but not the associations) and we fed both to the LLM combined with a PowerApps specific prompt. As before, this process produces a B-UML model. This model is then used to generate a semantically equivalent Oracle SQL database structure (using a code generator we developed as part of BESSER), which is then read by Oracle Apex. We see the result in Figure 3.

Summary

Interoperability continues to be a block in the adoption of LCPs. We propose an approach to improve the interoperability of LCPs by (semi-)automatically migrating models from one platform to another. Depending on the capabilities of the LCP to import and export models, we propose different interoperability pipelines. Reach out to us if you need more details or are interested in specific migration paths suitable for your own industrial scenario.