Design of blockchain-based applications using model-driven engineering and low-code/no-code platforms: a structured literature review

Abstract

The creation of blockchain-based software applications requires today considerable technical knowledge, particularly in software design and programming. This is regarded as a major barrier in adopting this technology in business and making it accessible to a wider audience. As a solution, low-code and no-code approaches have been proposed that require only little or no programming knowledge for creating full-fledged software applications. In this paper we extend a review of academic approaches from the discipline of model-driven engineering as well as industrial low-code and no-code development platforms for blockchains. This includes a content-based, computational analysis of relevant academic papers and the derivation of major topics. In addition, the topics were manually evaluated and refined. Based on these analyses we discuss the spectrum of approaches in this field and derive opportunities for further research.

1 Introduction

With the further maturing of blockchain technologies and the on-going transition to more energy-efficient and faster protocols with higher transaction volumes [86, 189], a more widespread adoption of these technologies seems within reach. However, one considerable barrier limiting the adoption is the technical and organizational complexity that users are confronted with when creating blockchain-based applications [131]. This complexity originates on the one hand from the underlying technical foundations, which build on distributed and decentralized systems, cryptography, and algorithmic processing [12]. Blockchains such as Ethereum [272] combine these properties for storing transactions in an append-only data structure, where each new block has a cryptographically verifiable link to its predecessor. Thus, users are part of a decentralized network that minimizes the degree of trust required towards other participants who continuously validate the information of the blockchain [92, 93]. In addition, organizational barriers such as the involvement of new regulatory requirements, the development of new skills and competencies, and the availability of financial and human resources may prevent adoption in practice [56].

From the perspective of software engineering, the lack of specialists for programming may today be partly compensated with so-called low-code platforms [36, 95, 245]. These development platforms are typically available as cloud services with visual, diagrammatic interfaces and declarative languages. In our view, they constitute the next step in the industry adoption of academic model-driven engineering (MDE) approaches and their predecessors.

The long-standing MDE discipline originated from the development of CASE (computer-aided software engineering) tools in the late 1980s [171], proposing the use of models as primary development artifacts for engineering [42, 76, 266]. MDE methods and tools address requirements, architectural components, and software artifacts with professional developers.

The term low-code development has been adopted by industry in recent years where various platforms are provided for the generation of software components or their cloud-based integration. While low-code approaches allow a user to produce results without having to understand source code and there may be an underlying model integrated with features of the platform [36], the model may not conform to an explicit formalization [76]. Further, we consider so-called no-code approaches as a subset of low-code approaches that operate at an abstraction level above code, not showing code to the user at all. Today, a large number of such platforms and tools are available that either support the development of complete software applications or focus on providing specific functionality, e.g., for entering data in a form and saving it to a database [213].

For easing the creation of blockchain-based applications it seems obvious to revert to MDE and low-code approaches. These carry the potential to abstract from the technical complexity and enable users to focus on usage scenarios and the organizational embedding [94].

In this paper we present an extension of a prior study [67] which investigated academic and industrial approaches for realizing blockchain-based applications using these methods and provide a comparative analysis of model-driven and low-code methods in this area. The extension encompasses the literature review, the review of industrial approaches, and their comparison. The literature review is extended in its scope and time frame as well as methodology, in particular through the addition of a computational literature analysis with formalized qualitative assessments. The review of low-code and no-code approaches incorporates platforms until October 2022 with an additional analysis step adding application characteristics and further platform descriptions. The review sections are concluded by discussing and comparing academic approaches in relation to low-code and no-code platforms.

We will do this along the following four research questions:

RQ1: Which academic modeling approaches have been developed until today for designing blockchain-based applications?

RQ2: Which low-code and no-code platforms permit the realization of blockchain-based applications?

RQ3: What are the predominant characteristics and areas of academic modeling approaches as well as low-code and no-code platforms?

RQ4: What are future research opportunities not realized today by academic approaches and low-code or no-code platforms?

In particular, we will regard approaches that are already available for creating blockchain-based software applications or offer interfaces to other platforms enabling this. This will permit to describe the state-of-the-art in this area and derive requirements for the development of future approaches. The remainder of the paper is structured as follows. Section 2 will outline foundations and related work in the form of previous studies and lead over to the description of our research methodology in Sect. 3. Subsequently, we will present in Sect. 4 our review of academic MDE approaches and in Sect. 5 the review of low-code and no-code development platforms offered by industry. Section 6 discusses the results and insights gained through our analysis and leads to our conclusion in Sect. 7.

2 Foundations and related work

Table 1 Selected surveys on (i) smart contract formalization, verification, engineering, and languages; (ii) blockchain-based business process management, and (iii) MDE techniques for the development of blockchain applications. These surveys have been considered in the review process as well.

In the following we briefly describe the main characteristics of blockchains and smart contracts as an introduction for readers who are not familiar with these technologies. Subsequently, we will outline the related surveys on model-driven approaches for the design of blockchain-based applications.

2.1 Blockchains and smart contracts

Blockchains are a family of technologies where transactions between authorized parties are stored in an electronic distributed ledger in a decentralized, distributed, immutable, and transparent way [93]. This is achieved through so-called consensus algorithms that guarantee the validity and integrity of transactions. The term “blockchain” stems from the form of the data structure of the ledger: a cryptographically linked chain of blocks containing records of transactions. The access to the ledger may either be restricted to certain parties (permissioned blockchain) or it may be openly accessible (public blockchain).

Blockchain-based applications then rely on this technology for its security and integrity properties, as financial channel, or to benefit from an established distributed infrastructure, e.g., by using a public blockchain. Furthermore, some blockchains allow applications to employ so-called smart contracts, pieces of code added to transactions for the decentralized execution of algorithms [12].

2.2 Related surveys

Developing blockchain-based applications requires a high level of expertise and understanding of the underlying technologies. Blockchain-based applications are empowered by smart contracts, i.e., programs executed on the blockchain. These smart contracts often involve financial transactions or deal with issues related to trust. As such, their correctness is of utmost importance. Due to the immutable nature of blockchains, mistakes in smart contract implementations are difficult to rectify. Many works from different fields in computer science investigate these issues and numerous surveys were conducted from different perspectives. Table 1 provides an overview of some related surveys, collected during the review process as elaborated in Sect. 4.1.

Most surveys focus on issues related to the development and analysis of smart contracts, while few regard blockchain applications as a broader topic. A general survey on various aspects of smart contract development and execution is presented in [133]. This includes a review of tools and techniques for the analysis and verification of smart contracts, e.g., to detect vulnerabilities, design patterns, smart contract languages, and execution schemes. While various issues related to software engineering are discussed, model-driven or low-code techniques to develop blockchain-based software are not regarded. The surveys [4, 81, 122, 257] review smart contract languages, including some of the work presented in this paper, but do not focus on MDE or low-code approaches specifically. While visual programming languages aim to reduce complexity and improve accessibility for the programmer, they do not correspond in general to low-code development approaches, which may involve visual programming but also deal with the generation and life-cycle management of software artifacts.

Blockchain-based approaches in the field of business process management have been reviewed in  [103] with a particular focus on collaborations. While approaches from this field are oftentimes not directly concerned with MDE, the model-based execution of business processes, workflows and choreographies is a central issue.

Formal specification and verification techniques for smart contracts is an actively researched field with numerous surveys [6, 108, 157, 202, 224]. This field is concerned with the detection or prevention of security vulnerabilities and faults, code optimization, formalization of semantics, and the correctness of smart contract implementations. Some approaches of this field employ MDE techniques, e.g., the generation of code from models.

A general survey on software engineering approaches for blockchain applications is presented in [85], including some that apply MDE techniques. However, a comprehensive overview of MDE is not in the scope of this former survey. The surveys [3, 152, 215, 254] review MDE approaches in particular. In [3] the authors discuss MDE specifically for Ethereum smart contracts, however, the review process is not elaborated. Sánchez-Gómez et al. [215] review model-based testing and development approaches and Udokuwu et al. [254] focus on the evaluation of software development processes. Since the publication of these surveys in 2020, newer approaches have emerged. A more recent review of MDE methods was conducted by Levasseur et al. [152] in 2021. In comparison to their work, we applied a broader search methodology and identified more approaches. None of these studies considers industrial approaches such as low-code platforms and they focus predominantly on blockchain-based application development.

In summary, while numerous studies on issues regarding smart contract development have been conducted, to the best of our knowledge, a comprehensive review of the state-of-the-art of MDE and low-code approaches from both academia and industry in this field is missing so far.

3 Research methodology

Fig. 1

Overall process for this study. Since the data sources for academic and industrial approaches differ significantly, two separate search protocols were formulated. The protocols were executed in parallel and isolated

For answering the four research questions we will employ the following research methodology. At first, we review existing academic MDE approaches for blockchain applications in the form of a structured literature review (SLR), followed by a content-based computational analysis of the resulting full text documents using topic modeling [54] and a review of state-of-the-art industrial low-code and no-code software platforms (Fig. 1).

Fig. 2

Systematic review process for the identification of academic MDE-related documents. A keyword search was performed on the portals ACM, IEEE Xplore, and Springer. This corpus was filtered by title and then subject to an assessment regarding the documents’ full-texts. Subsequently, a recursive backward-forward search was performed, resulting in a set of 200 relevant documents. Further, any surveys and preprints that have a published version were removed. This final set was then used for a content-based analysis using LDA

The review of MDE approaches is two-fold. Relevant papers were manually retrieved through the structured literature review at first, including the identification of categories and topics. In addition, topics were then identified using a content-based computational analysis for the resulting papers based on their full texts. Both results were finally combined in a manual rating and assessment process. In this way, the validation of the manually compiled and computational results is ensured. In particular, the SLR involved manual retrieval and paper screenings by the authors for identifying relevant papers and topics. Regarding the process, we follow the guidelines by Webster and Watson [264] and vom Brocke et al. [260]. The initial corpus of the SLR was generated by searching all keyword combinations from two groups, where group one included ‘blockchain, distributed ledger, smart contract’ and group two ’enterprise model, conceptual model, business model, model-driven, no-code, low-code’. These keywords were selected based on the domain understanding of the authors. We expected the relevant concepts to be dispersed, thus we chose a broad set of keywords.

Subsequently, the topics were identified in a computational analysis in multiple iterations by applying Latent Dirichlet Allocation (LDA) [54]. The final synthesis of the resulting papers and their topics follows the processes applied by Casalaro et al. [49] for the synthesis and Torres et al.  [49, 248] regarding the rating and qualitative assessment through inter-rater reliability measures.

For discovering relevant industrial low-code and no-code software platforms, we reverted further to expert knowledge from industry in the field of low-code development combined with our own searches. On this basis, we conducted a survey of available platforms towards suitability for blockchain application development, and identified according characteristics, application areas, and categories. We discuss platforms in each category together with representative examples for assessing the state-of-the-art in implemented industry software solutions. This exploratory research approach is directed towards discovering requirements for future platforms that combine blockchain application development with the state-of-the-art from academia and industry.

4 Academic MDE approaches

In the following subsections, we review approaches of the academic discipline model-driven engineering in regard to development solutions for blockchains.

Model-driven engineering introduces models as primary artifact to the software development process in order to address numerous challenges of software engineering [42, 218]: First, the common understanding of software artifacts can be facilitated by domain-specific models, as such models are easier to interpret for humans than code. Second, model-based reasoning allows the verification of software, e.g., to determine the fulfillment of security properties. And third, well-defined models allow developers to create software artifacts in an automated fashion, which are correct-by-construction, with no or reduced coding effort. To identify existing MDE approaches that target specifically the development of blockchain applications, we conducted a systematic literature review as elaborated in the following.

4.1 Review process

The systematic review process as shown in Fig. 2 follows the guidelines by Webster and Watson [264] and vom Brocke et al. [260]. To obtain an initial corpus of documents, we performed keyword searches in step (S-1) on ACM, Springer, and IEEE Xplore with the search strings shown in Table 2. These publishers were chosen as starting point as we had access to the full-texts on their platforms. Moreover, established outlets of the modeling domain are mostly published on these platforms [123]. The steps (S-5.1) and (S-5.2) ensured that outlets from other publishers are considered as well. In total, the review covers 2173 outlets—a wide array of conferences, consortia, forums, journals, magazines, symposia, and workshops. The search strings are informed by previous studies in this area, namely [67, 123]. In the pre-study [67] we had found that restricting the search criteria on terms closely related to model-driven and low-code approaches does not cover fields we deem relevant nonetheless. This is oftentimes due to differences in the terminology used. Thus, we widened the search with the addition of terms related to models of a specific nature. The study in [123] had shown that the precise meaning assigned to the terms “modeling” or “model” is contextual and varies across fields of study. We thus restricted the search terms to account for the broad use of these keywords. Thereby, the term “business modeling” is largely motivated by approaches in the field of value and goal modeling, the term “conceptual modeling” by domain models and ontologies used during any stage of software development, and lastly the term “enterprise modeling” by the field of enterprise architectures.

Table 2 The five search strings (in a simplified form) used for retrieving the initial corpus, and the number of results found on ACM, IEEE Xplore, and Springer. The exact syntax of search strings varies for each search portal. The search period for academic approaches was restricted to publications between 2014 and July 2022

From this initial corpus of documents, duplicates were removed in step (S-2). Before the full-text analysis, the reduced corpus was then screened by titles in step (S-3). As basis for this third step we formulated loose keyword criteria, whereby the title should contain a term related to a model or the activity of modeling, and mention a blockchain-related word, such as “distributed”, “chain”, or “contract”. Non-exhaustive examples of satisfying the former criteria include the mentioning of modeling languages, model-driven practices, conceptualizations, structured knowledge representations, and domains known for applying MDE practices. Excluded were documents with titles indicating the discussion of a business model for a particular use case, since these occurred in abundance but do not in general relate to MDE. The title screening in step (S-3) was performed by all authors in isolation, whereby each author noted whether or not a publication seemed relevant and refined the assessment in a second pass. For documents without full agreement by all authors, consensus was established through a discussion.

In the next step, the documents were assessed by at least reading the abstract and reviewing tables and images (S-4), considering the inclusion criteria that (i) the documents should be related to distributed ledger technologies, and (ii) create, discuss, or present a modeling activity. Publications using models to only illustrate software, systems, or a use case, e.g., by means of a standard UML use case diagram, were excluded. For documents that passed the aforementioned assessment we then extracted dimensions for comparison by reading the full-texts. The dimensions are presented in 4.2.

For these 44 documents, we then performed a recursive backward-forward search (S-5), as proposed in [262]: references and citations were screened by title, relevant publications added to the set (S-5.1), and subsequently assessed (S-5.2). Step (S-5.2) was performed in the same manner as step (S-4). Surveys and versions of already captured documents, namely preprints or published versions thereof, were first considered as well. For all relevant new additions, a backward-forward search was again performed. Eventually, no new relevant documents could be found, and the backward-forward search was concluded. Of all thus collected documents, 200 fulfilled the assessment of being in the scope of the literature study by reading the full-texts of the papers (S-6). We further removed preprints for which a published version is contained in the corpus (S-7). The resulting corpus served as basis for a content-based analysis using LDA. Finally, surveys were removed in step (S-8), resulting in the set of documents presented in the following. This was done since these surveys were considered secondary studies and do not present an original approach, but rather focus on the synthesis of previous approaches.

4.2 Results of the literature review process

Through the SLR we identified 177 academic publications relevant in the context of MDE for blockchain-based applications. A discussion of the academic approaches is presented in Sect. 6. Each publication was subject to a classification based on three dimensions. The choice of these particular dimensions is informed by a pre-study [67].

Fig. 3

Treemap of the identified modeling languages, that have been employed by academic approaches—approaches may use or propose multiple languages, resulting in a total of 232 assignments. The area of a rectangle represents the number of approaches using this language: domain-specific language (dsl, 74), BPMN (51), UML (38), Petri Net (10), DEMO (9), OWL (8), ArchiMate (4), DMN (4), i* (4), REA (3), AOM (3), RDF (3), $e^{3}$ value (3) RuleML (3), ER (2), SCXML (2), SWRL (2), BPEL (1), CMMN (1), DatalogMTL (DMTL, 1), IFML (1), OCL (1), EER (1), SOM (1), TOVE (1), and USDL (1)

Base language: This dimension refers to the modeling language that was applied in the approach or used as foundation for an extension, for example, in the form of a profile or through an addition of domain-specific concepts. Some approaches do not revert to such a base language. Instead, they propose a tailor-made method for modeling some aspect of a blockchain system. We therefore refer to any such method as a domain-specific language (dsl). This domain-specificity is to be understood in the context of the development and modeling of blockchain-based applications. Furthermore, we did not distinguish between different versions of languages.

Blockchain technology: This dimension is defined as the base blockchain technology relevant for the approach. That is, the technology that the approach either applies, analyzes or, targets. For approaches of a conceptual nature that do not specify a technology, or for which considering such specifics is not relevant, we denote the blockchain technology to be unspecified. Some approaches target multiple blockchain systems, for which we assign the value multiple. The use of programming languages compiled to bytecode for Ethereum’s virtual machine [272] is regarded as using the Ethereum blockchain technology, regardless of the existence of other blockchains compatible with such bytecode. An implementation of non-established blockchain systems is denoted as custom. We did not distinguish between developments under an overarching umbrella, namely the various Hyperledger projects. Furthermore, the distinction between permissioned and permissionless networks is not considered, since this is generally an issue of system and network configuration.

Nature of realization: We distinguish between executable code generating and conceptual approaches. The former refers to an approach that automatically or partially automatically generates code artifacts from some model representation. These artifacts must be executable using a blockchain technology. Such artifacts include but are not limited to smart contracts, blockchain connectors, integration facilities, user-interface components for blockchain applications and process or workflow encodings.

We denote those approaches as conceptual that do not satisfy the code generation criterion, but instead focus on the conceptualization of the blockchain domain, resulting in a model representation, reasoning on blockchain systems based on models, conceptual language mappings or model-based methodologies for the design and development of blockchain applications. Conceptual artifacts produced by such approaches include but are not limited to ontologies, metamodels, methodologies, semantic models, and business models.

4.2.1 Employed modeling languages

The academic approaches at hand may use or propose one or several modeling languages. These have been identified according to the previously defined base language dimension. In this section we present the modeling languages ordered by the number of occurrences (totaling in $n=232$) in terms of the number of applications in academic approaches (c.f. Fig. 3). In total, we have identified 25 base languages, most of which are only sparingly used for the development of blockchain-based applications. In the following, the languages and their primary function in the context of DLT are briefly summarized, while a discussion of the approaches will follow in Sect. 6.

Domain-specific language (dsl): Papers proposing or applying a domain-specific language for the blockchain domain form the largest group with 74 representatives (out of 232). This group is notably heterogeneous, ranging from declarative (e.g., [125, 149, 207]) to graphical (e.g., [31, 39, 265]) modeling approaches with a varying degree of formalization. Some approaches combine a dsl with non-blockchain specific modeling languages, for example for the model-based generation of smart contract code (e.g., [128, 256]).

Business process model and notation (BPMN) [238]: With 51 occurrences BPMN is the most widely employed standard modeling language in the corpus of documents. In the context of blockchain-based applications, BPMN has been applied, for example, to execute business processes on-chain, based on smart contracts (e.g., [159]), or for the collaborative execution and enforcement of choreographies (e.g.,  [146]).

Unified modeling language (UML) [241]: UML is the second most prominent modeling language after BPMN with 38 representatives. This group accounts for all types of UML diagrams, although UML class diagrams are the most widely used by the approaches at hand. Approaches reverting to UML include development methodologies (e.g., [168]), conceptual modeling and ontology design (e.g., [70, 194]), as well as model-based code generation (e.g., [113]).

Petri Nets  [199, 200]: Petri Nets ($n=10$) allow for the description of concurrent processes in distributed systems. Thereby, system states and transitions between these are modeled with a formalized diagrammatic notation. Applications of Petri Nets in the context of blockchain technology include, for example, the formalization of ontologies (e.g., [78]), smart contract simulation and verification (e.g., [277]) and the encoding of business processes for execution engines (e.g., [102]).

Design and engineering methodology for organizations (DEMO) [74, 75]: DEMO ($n=9$) is a methodology with an ontological foundation for the design (and re-design) of organizations. A main concern of DEMO is the separation of the abstract representation of an organization’s operation from its realization [74]. These essential features are described by means of four diagrammatic models. The approaches at hand apply DEMO, or parts thereof, for various purposes. For example, the generation of code (e.g., [226]), and the use as ontological foundation (e.g., [70]). Of particular interest as well is the actor transaction diagram of DEMO (e.g., [223]).

Web ontology language (OWL) [261]: OWL ($n=8$) is an ontology language for the semantic web with formally defined semantics. An OWL ontology may be represented in various ways, for example, as an RDF graph (see description below), which is the main exchange syntax of an OWL document, or with an UML class diagram. Several academic approaches express DLT-related domain models in OWL (e.g., [26, 28]). The formalized semantics of OWL allow for the application of formal reasoning mechanisms in order to gain new insights, in particular in combination with query and rule languages (e.g., [29]).

ArchiMate [151, 244]: ArchiMate ($n=4$) is a multi-layered enterprise architecture modeling language. The layers represent various aspects of an enterprise, ranging from strategy and business concerns to the technical infrastructure. Academic approaches employ ArchiMate to model blockchain systems and the interrelations with business models (e.g.,  [66, 135]), for the creation of reference models (e.g., [82]), and as input for the generation of software artifacts based on a concept mapping (e.g., [19]). The application and technology layers of ArchiMate are considered, for example, in [66], while other approaches may regard mainly the top-level layers (e.g., strategy [135] or business layer [82]).

Decision model and notation (DMN) [243]: DMN ($n=4$) is a business decision modeling language, designed to be usable as complementary modeling method alongside BPMN, thereby allowing the decisions to be integrated in business processes. The combination of DMN and blockchain technologies was explored for example for the purpose of executing decision models on-chain, as seen in [115,116,117], or for supporting decision making as part of a development methodology [192].

i* strategic actor relationships modeling framework (i*) [274,275,276]: The i* framework ($n=4$) is a graphical modeling method where information systems are regarded as socio-technical systems in which actors are related to another in regards to goals, tasks and resources. This framework has been discussed, e.g., for requirements engineering and goal modeling for supporting the development of decentralized applications in an organizational setting [118, 258, 259], and for the policy compliant generation of smart contract code [252].

Agent-oriented Modeling (AOM) [230]: AOM ($n=3$) is a methodology for modeling socio-technical systems. Thereby, an information system is represented by interactions among autonomous agents. Several works regard AOM as integral part of some development methodology for decentralized applications, e.g., [153, 253, 255].

${\varvec{e}}^{\varvec{3}}$ value [107]: The $e^{3}$ value language ($n=3$) provides a notation to model value streams between actors. It is thus mostly used to explore business models and use cases with a focus on value exchanges. The usage in the context of blockchains is two-fold: either employed as part of a smart contract development methodology (e.g., [105]) or for use case modeling and analysis. In the latter case, the main concern is, e.g., the identification of DLT use cases [203] or the modeling thereof [198].

Resource–Event–Agent (REA) [175]: The REA model ($n=3$) provides a general business ontology and modeling notation for expressing economic resources, economic events, and economic agents and their relations. It has initially been proposed as an accounting framework for shared data environments with a data modeling notation resembling the Entity-Relationship model. The business ontology of REA is used in combination with DEMO, e.g., in [69, 70] for the development of blockchain domain ontologies.

Resource description framework (RDF) [124]: The RDF standard ($n=3$) provides a notation for the exchange and description of graph data. Thereby, a graph is represented as collection of triple statements. While RDF was originally intended as description language for metadata in the semantic web, it has found more general use since then, e.g., for modeling and exchanging ontologies. For example, blockchain-related ontologies have been expressed in RDF, as seen in  [10, 201, 220].

Rule markup and modeling language (RuleML) [212]: RuleML ($n=3$) is a standard for the semantic web based on RDF and XML for the specification of rules and constraints regarding the transformation and semantic interpretation of data. Several other markup languages have been developed based on RuleML, e.g., SWRL. Approaches at hand apply RuleML, for example, for the verification of DApps in regard to compliance rules [256]. An extended version of RuleML is proposed as a declarative smart contract language [71, 72].

Entity-relationship model (ER)  [52]: The ER model ($n=2$) has originally been proposed for the design of database models, but is commonly used for general data modeling tasks as well. It has been suggested to revert to ER for the design of the data domain model as part of the blockchain application development methods presented in [100, 208].

State chart extensible markup language (SCXML) [25]: SCXML ($n=2$) is a W3C standard for the declaration of state machines in an XML format. While numerous approaches at hand involve state machines, only two revert to this standard [185, 216]. In these works, SCXML is used as input format for a blockchain-based engine, with the purpose of executing smart contracts modeled as state machines.

Semantic web rule language (SWRL) [132]: The W3C standard SWRL ($n=2$) is a combination of OWL and RuleML, expanding the expressiveness of OWL with the capability of formulating constraints or rules on ontological concepts. Together with ontologies formalized in OWL, SWRL enables deductive reasoning and knowledge inference. This has been used, e.g., in [29] for gaining insights in DApps modeled according to an ontology. Another approach uses the combination of domain ontologies and SWRL expressions as a starting point for the generation of contract code [53].

Business process execution language (BPEL) [193]: The declarative XML-based Business Process Execution Language (BPEL or WS-BPEL, $n=1$) is a standard for the specification of executable processes. It relies upon the Web Service Description Standard for service specification and discovery, but adds capabilities for the description of interactions among business processes and web services. Thus, BPEL allows for the description of workflows orchestrating service invocations as seen, for example, in [48], where a BPEL process is translated into a smart contract which calls external web services.

Case management model and notation (CMMN) [242]: CMMN ($n=1$) is a business process modeling method designed to be complementary to BPMN. As opposed to BPMN, which describes a process as a predefined sequence of activities, CMMN regards a subject in a situation where actions to be taken may need to be chosen and ordered during run-time. CMMN is used, e.g., in [179] for the modeling of common blockchain application patterns, such as oracles and tokenization.

DatalogMTL (DMTL) [43]: Datalog is a logic programming language. Its applications include ontology representation and querying deductive systems. DatalogMTL ($n=1$) is an extension introducing concepts of metric temporal logic, allowing expression on temporal data. An example for the application of DatalogMTL is the work of Nissl et al. [190], where logic-based smart contracts modeled with DatalogMTL were translated into code executable by Ethereum’s virtual machine [272].

Extended entity-relationship model (EER) [104]: The EER model ($n=1$) includes all concepts of ER, but incorporates several extensions, such as inheritance concepts, clustering of entity types, and complex attributes. EER is used, e.g., in [129] for the representation of an OWL ontology of the block and transaction structure as present in Bitcoin, Ethereum, and Hyperleder Fabric.

Interaction flow modeling language (IFML) [240]: The IFML standard ($n=1$) offers notations to model interactions of users with front-end applications and the related behavior triggered by user actions or system events. In [100], the authors apply IFML as part of an MDD method for so-called hybrid applications, that involve a DLT system as well as a centralized database. The interactive system component is modeled with IFML. Furthermore, an extension of IFML is used to model workflows.

Object constraint language (OCL) [239] The formal and declarative Object Constraint Language ($n=1$) allows to specify expressions on UML models. This includes, for example, the definition of queries, invariants, and conditions on operations. The work of Syahputra et al. [235] presents a development method for smart contracts involving REA, UML and OCL. The UML models enriched with OCL expressions serve as input for the generation of code.

Semantic object model (SOM) [90]: The semantic object model ($n=1$) is an object- and process-oriented modeling method for enterprises. In SOM, a business system is represented on the levels of the enterprise plan, business processes, and resources, especially IT systems. In contrast to ArchiMate or BPMN, SOM describes processes and IT systems in a structural as well as a behavioral view and derives IT systems in their specification by a model-driven methodology. Härer [121] applied SOM in conjunction with BPMN for modeling decentralized organizations.

Toronto virtual enterprise ontology (TOVE) [96]: TOVE ($n=1$) is a formal ontology with a layered structure, containing sub-ontologies for the modeling of various parts of an enterprise, such as activities, products, or organizational structure [97]. Kim et al. [141] adapted TOVE for provenance tracking in supply chain applications. The extended ontology then serves as the foundation for the development of smart contracts.

Unified service description language (USDL) [47]: USDL ($n=1$) provides means for the description of web services and their relation to underlying business services. Thereby, USDL reverts to an XML-based syntax and includes an extension mechanism. This has been used, e.g., in [27] to adopt USDL for the description of smart contract functionality, aiming to increase the user’s trust in contracts for which the implementation is not public.

4.2.2 Employed blockchain technologies

We have identified seven blockchain technologies that have been regarded by academic approaches. In this work, we do not differentiate between the various Hyperleder projects, and instead group them together. An overview on the popularity of the employed blockchain technologies is shown in Fig. 4. By far the most popular technology is Ethereum ($n=99$), a general purpose blockchain with the capability of executing turing-complete smart contract in a decentralized virtual machine [272]. Numerous approaches did not specify a blockchain technology ($n=39$). This is exclusively the case for conceptual works that are technology independent. Further, we have found approaches that consider multiple blockchains ($n=16$). This includes some conceptual works, but more common are multi-chain approaches focusing on the technical level. The second most popular choice is then one of the infrastructure blockchain technologies developed under the umbrella of the Hyperledger project [134] ($n=15$). These are typically less focused on crypto-economic aspects than general-purpose blockchains, but instead are tailored towards consortial settings, where the cooperation of organizations is enabled through a collectively established blockchain as trust-basis. Hyperledger is followed by another two general purpose blockchain technologies in this ranking, namely Corda [127] ($n=4$) and Cardano [46] ($n=2$). Only one approach employs Bitcoin [184]. This low adoption may be explained by the limited smart contract capabilities of the Bitcoin technology.

Since blockchain technologies were not an area of active research prior to 2014, this review covers publications from 2014 onward. The research activity has risen considerably since then, as is evident by the increase of publications over the years, shown in Fig. 5.

Fig. 4

Employed blockchain technologies of the approaches in the final corpus. Ethereum is by far the most popular choice in this set. However, numerous conceptual approaches do not rely on a specific blockchain technology

Fig. 5

Number of documents in the final corpus grouped by year. This includes preprints but no surveys. Note that the review does not cover the entirety of 2022

Table 3 Publications proposing a conceptual method for the design of blockchain applications, or reasoning thereof. That is, the method does not automatically generate code artifacts executable in the context of a specific blockchain technology. Instead, such approaches may focus on the conceptualization of the blockchain domain, resulting in a model representation, reasoning on blockchain systems based on models, conceptual language mappings, or model-based methodologies for the design and development of blockchain applications. Conceptual artifacts include but are not limited to ontologies, metamodels, methodologies, semantic models, business models, and model-based verification and simulation without code generation

Table 4 Publications proposing an executable code generating method. That is, the method automatically or partially automatically generates code artifacts from some model representation, and the artifacts are executable in the context of a specific blockchain technology. Such artifacts include but are not limited to smart contracts, blockchain connectors, integration facilities, UI components for blockchain applications, and process or workflow encodings

4.2.3 Nature of realization

All documents in the final corpus have been grouped by their realization, that is, in conceptual and executable code generating.

Conceptual approaches: Documents presenting conceptual approaches are shown in Table 3. Most commonly, these conceptual approaches do not relate to a specific blockchain technology ($n=39$). This is not surprising, as conceptual works generally allow for a higher degree of abstraction. However, some approaches are technology-specific. In these cases, Ethereum is the most popular blockchain technology ($n=17$), followed by Hyperledger ($n=5$), Corda ($n=1$), and Bitcoin ($n=1$). UML is the most prominently employed modeling language in this group ($n=25$), e.g., as part of a methodology or for the design of metamodels. Some approaches propose or revert to domain-specific languages ($n=16$). This includes, for example, declarative legal languages, notations for state machines or automata, and non-standard specification languages. Semantic web languages, including OWL, RDF, SWRL, RuleM, and USDL ($n=13$) are used for example to author domain ontologies.

Executable code generating approaches: Documents presenting approaches with the capability of generating executable code are shown in Table 4. The most used blockchain technology in this group is by far Ethereum ($n=82$), followed by Hyperledger ($n=10$), Corda ($n=3$), and Cardano ($n=2$). Twelve ($n=12$) approaches support or target multiple blockchains. This is achieved either by directly implementing the necessary code translation and connectors or by targeting an intermediary language that is compatible with multiple blockchain technologies, for example, the DAML language (c.f. Table 6) as used in [119]. Most code generating approaches apply domain-specific languages for modeling ($n=58$), ranging from declarative textual to visual diagrammatic representations. In this group, BPMN is the most commonly used standard modeling language ($n=42$), followed by UML ($n=13$).

4.3 Content-based computational analysis

In addition to the manual literature review we conducted a content-based computational analysis of the derived set of relevant papers. For this purpose we reverted to Latent Dirichlet Allocation (LDA), an established topic modeling approach for text summarization in the field of information retrieval [50]. We follow the process of a computational analysis based on LDA as established and successfully applied before in [123, 182, 195].

Topic modeling techniques have been developed since the 1990s stemming from Latent Semantic Indexing and similar approaches, leading to research on LDA in the 2000s [34, 35]. LDA introduced the identification of topics from a document collection by training a model of topic-word distributions, resulting in the generation of k topics consisting of word occurrences. Today, LDA with optimizations such as Gibbs sampling is considered an online topic modeling with high performance characteristics [54], in addition to graph-based, biterm, and self-aggregating methods as well as further run-time optimizations such as GPU acceleration [50, 54].

Fig. 6

Final results of the computational analysis using LDA with a set of 10 topics based on five terms and the final weights assigned by the algorithm. The final set of topics displayed here was then subjected to a manual refinement (see Sect. 4.4) over three iterations. These iterations consisted of the identification of topics, their assignment to papers by three raters, the calculation of inter-rater reliability measurements, joint discussions of the results involving manual screening of the papers in unclear cases

In particular, LDA allows for the generation of k topics for a document collection such that each document is characterized by its own topic distribution $\theta _d$, representing multiple topics per document in the underlying model. The model of topic-word distributions is trained through expectation maximization, maximizing the likelihood that the topic distributions of each document $\theta _{d,k}$ form an overall topic-word distribution of k topics in the collection [34]. Furthermore, the model is characterized by the ratio of topics per document ($\alpha$) and the ratio of words per topic ($\beta$). As a result, each of the k topics is represented by the top n words according to the weight, corresponding to occurrences in the probabilistic model. In terms of software, the LDA implementation of MALLET (MAchine Learning for LanguagE Toolkit¹) was used in RapidMiner 9.5 with optimizations for Gibbs sampling [188] and concurrent processing [273].

We apply LDA as part of a data mining process, consisting of data selection, preprocessing, transformation, and data mining as suggested initially by the KDD model [89]. Data selection concluded with the full text PDF documents resulting from the literature review, including a small set of survey papers (c.f. Table 1) and few relevant papers only published as report or on ArXiv (c.f. Tables 3 and 4 marked with ‡) for generating an initial set of topics computationally through LDA. With this collection, preprocessing and transformation of the PDF documents to text documents followed. In preprocessing, data cleaning and related operations took place, in particular the tokenization of documents, minimal stemming, synonym replacement, cleaning for the removal of stop words, incomplete data, and irrelevant article fragments such as header texts or comments.

The LDA was carried out over multiple iterations. In particular, for determining the initial k topics, iterations for $k \in [6, 14]$ were calculated first, followed by defining domain-related stop words and synonyms. The results were evaluated manually by the authors with the criterion being to avoid overly generic or specific topics and words, concluding with the selection of $k=10$ topics. The topics that resulted from this initial application of LDA are shown in Fig. 6.

4.4 Manual topic refinement and synthesis by rating and qualitative assessment

In a next step we refined the topics proposed by LDA, screened and assigned papers to the resulting topics manually over multiple iterations with inter-rater reliability measurements, leading to a synthesis of computationally and manually determined topics.

The initial step consisted of identifying suitable labels for each topic in a joint discussion by the authors and the combination of similar topics. Given the topics, each subsequent iteration consisted of manually assigning papers to topics by three raters, the authors of this paper, the calculation of inter-rater reliability measurements, joint discussions of the results, and screenings of paper abstracts in unclear cases. The following inter-rater reliability indicator was measured as a qualitative assessment concerning the percentage agreement and Cohen’s Kappa [57, 176] over the assignments of ${n=177}$ papers in the collection. (1) The unanimous agreement where ${u_i \in [0,1]}$ is the agreement for the assignment of paper i with ${u_i = 1}$ if all raters made the same assignment and ${u_i = 0}$ if assignments differed. (2) The mean agreement where ${v_i \in [0,3]}$ is the number of raters in agreement for the topic assignment of paper i. (3) Cohen’s Kappa $\kappa$ was calculated according to the procedure described by Cohen and McHugh  [57, 176], accounting for agreements due to chance.

Table 5 Final set of topics resulting from computational analysis (Sect. 4.3) and three iterations of manual refinement (Sect. 4.4). For each topic, the number of papers that were assigned to the topic with unanimous agreement by all raters is given. The inter-rater reliability measurements of unanimous agreement ${A_U=72.3\%}$, mean agreement ${A_\mu =79.3\%}$, and Kappa $\kappa =0.71$ indicated very high agreement (see Sect. 4.4)

Fig. 7

Systematic review process for the identification of industrial low-code and no-code software platforms supporting blockchain application development. The data sources consist of (DS-1), an existing compilation by Invernizzi and Tossell (see Sect. 5.1), (DS-2), prior work [122], and (DS-3), additional research on the web. After (S-1), an initial filter step leaving reachable and sufficiently described platforms, (S-2) assessed blockchain support, concluding in (S-3) and (S-4), where platforms were tested with small example implementations for classifying in (S-3) their blockchain capabilities and for determining application attributes (S-4) such as open source availability

In the first of three iterations, the initial assignment resulted in ${A_U=62.1\%}$ of the papers assigned to the same categories by all raters with a mean agreement ${A_\mu =72.5\%}$, indicating moderate to high agreement below the threshold of ${A_\mu =75\%}$ that might be considered sufficient [191]. When accounting for chance with Cohen’s Kappa, $\kappa =0.60$ was reached, considered slightly below a substantial agreement at $\kappa =0.61$ or above, according to Cohen and Landis et al. [57, 150]. In the joint discussion, papers not assigned to categories by at least two reviewers were identified first for discussing the scope and suitability of topics. This concerned 8 papers that were determined out of scope for the existing topics and assigned to the newly added topics Reference Models and Business Modeling. Secondly, under-represented or unclear aspects for existing topics were discussed when raters had noted additional comments during the rating. This discussion revealed unclear assignments for papers on decision modeling, which were considered part of a process-centered topic Process, Workflow, Choreography, Decision Models as result of the discussion. Furthermore, formal verification papers were grouped with papers on further formal aspects, such as formal specification, in a topic Formal Aspects and Verification.

In the second iteration, unanimous agreement ${A_U=72.3\%}$, mean agreement ${A_\mu =79.3\%}$, and Kappa $\kappa =0.71$ were reached, indicating relatively high agreement on the assignment of topics and substantial agreement regarding $\kappa$. The joint discussion did not reveal topics unclear in scope or suitability, with all papers being assigned by at least two raters. Based on the rater’s comments, unclear aspects during the assignment led to marking related papers for an additional abstract screening as input for the last iteration.

In the third iteration, after screening abstracts in 23 unclear cases, the final measurements indicate unanimous agreement ${A_U=76.3\%}$, mean agreement ${A_\mu =83.1\%}$, and Kappa $\kappa =0.75$. At this point, agreement on topics among the raters was considered very high, even when accounting for agreement by chance through $\kappa$.

Table 5 shows the final set of topics with the number of papers assigned through unanimous agreement. The details of these topics will be discussed in Sect. 6 by highlighting the core papers found for each topic.

5 Industrial low-code and no-code software platforms

In the following, we continue in our research methodology by reviewing state-of-the-art low-code and no-code software platforms towards their suitability for blockchain application development. The review process is described in Fig. 7.

Low-code and no-code software platforms are increasingly available for practitioners to develop applications using abstractions beyond source code [36, 76]. While low-code platforms are in their representation still close to the source code and often suited for technical users and developers, no-code platforms go one step further by providing representations on an abstraction level above source code that are accessible to non-technical domain experts and even citizen developers [209]. For example, low-code approaches might provide an interactive drag-and-drop environment for arranging blocks of statements in a procedural manner, while no-code approaches often guide users through dialogs and allow arranging pre-configured user interface (UI) components. Since many platforms are today web-based, their ease of use also stems from integrations, by connecting to existing cloud-services or websites and integrating their functionality [213].

5.1 Review process

Relying on expert knowledge, the review considers as a starting point an informal compilation by Invernizzi and Tossell² that identified 145 web-based platforms such as website and app builders, e-commerce services, and data dashboards. The identified solutions differ substantially in the scope and applications they target. We review solutions of the compilation, extended with approaches from prior research and additional investigations of state-of-the-art platforms in October 2022. Therefore, the data sources for this review are (DS-1): the compilation by Invernizzi and Tossell, (DS-2): practical approaches from prior research [122], and (DS-3): additional research on blockchain-specific low-code and no-code solutions available on the web.

We applied a four-step process, consisting of an initial filtering step (S-1), the evaluation of scope and applicability for blockchains in step (S-2), the classification of solutions applicable to blockchains (S-3), and the characterization through representation and application attributes (S-4). Initially, 179 solutions were identified. In (S-1), we manually retrieved descriptions from the vendor websites in addition to information provided by (DS-1), followed by filtering out duplicate entries, those that could not be reached on the web, or did not provide sufficient information on their websites (e.g. closed beta software). The remaining 150 solutions were evaluated in (S-2) regarding their scope of blockchain integration. Finally, 47 solutions were identified as applicable for blockchains. For these platforms, further evaluations for assigning (S-3) categories and (S-4) the type of the predominant representation and application attributes were carried out.

5.2 Results

For discussing available platforms and their blockchain integration, we distinguish between 1st degree and 2nd degree integration. A platform supports 1st degree integration if it interacts directly with blockchains through its software or services. 2nd degree integration is supported if an external service could be integrated that offers 1st degree integration. The criteria for the selected platforms (S-3) listed in Table 6 are that they (a) offer blockchain integration of 1st or 2nd degree and (b) were considered a low-code or no-code approach. For (S-4), the table outlines the 9 categories identified in this step along with a description of application attributes, 1st and 2nd degree blockchain integration (columns d$_{1}$ and d$_{2}$), open source (column s) availability of the implementation, and the representation (column r) primarily used to abstract from source code.

Table 6 Industrial low- and no-code approaches with 1st or 2nd degree blockchain integration

5.2.1 Platforms with 1st degree integration

1st degree blockchain integration has been found in 18 solutions intended for building mobile apps, web apps and websites, workflow integration and automation, and smart contract development.

Fig. 8

Outsystems studio, a low-code application builder for web and mobile applications showing an integrated development environment using visual flows (right-hand side), here specifying the user interactions and processing steps in a supply chain tracking application, along with an android emulator executing the app (left-hand side) with retrieval of blockchain data

App builders: The primary integration features in the categories for app builders, concerning platforms primarily for mobile applications (AM) or web applications (AW), are the creation of decentralized apps (DApps) and the integration of cryptocurrency-related data, e.g., price information. Platforms such as Outsystems (AW-6) and Bubble (AW-1) support DApps, where components of a mobile, desktop, or web app can send blockchain transactions and call smart contract functions, e.g., through web3 plugins such as the MetaMask browser extension.³ In the case of Outsystems, web3 functionality through MetaMask is available in pre-defined components provided as part of the platform’s integrated development environment (IDE). Following the web3 concept [45], apps or websites are created using decentralized platforms and infrastructures that depend less on large, centralized, and potentially influential entities such as cloud providers which could represent potential single points of failure. This might be achieved by blockchain transactions made through MetaMask or by decentralized data retrieved from Ethereum.

An example for the development of a blockchain-based app for supply chain tracking is shown in Fig. 8 as demonstrated before by the authors in [67]. In this category, representations abstract from source code (column r) and often use flow-based editors. Elements connected by flow relationships specify, e.g., the navigation through user interfaces, computational steps, or other actions carried out sequentially or non-sequentially using conditional branches or events. In the example, a list of goods or so-called commodities is retrieved from the Ethereum blockchain, stored in a local list, and—for each supplier—processed regarding shipment and product data.

Website builders: For website builders, blockchain integration has only been found for integrating cryptocurrency-related data, with the exception of ICME (WB-2). ICME is a website builder for creating websites on the Dfinity blockchain. The app and the resulting websites are hosted on Dfinity, such that the creation of the website as well as the hosting do not rely on traditional client–server-architectures and instead retrieve and process data on nodes of the decentralized blockchain network.

Workflow integration and automation tools: Tools in this area automate and execute user-defined workflows and allow for integration. This concerns on the one hand cloud providers such as Amazon Web Services (AWS) (WA-2) integrating services for cloud computing. On the other hand, there exist platforms focused on the integration of web apps and web services. For instance, n8n (WA-7), and Zapier (WA-14)⁴ realize this approach.

Fig. 9

Simba Chain, a no-code smart contract development platform showing a data model consisting of assets (rectangles) and transactions (ellipses) that result in the generation of a smart contract with corresponding data structures. On the right-hand side, attributes of the Commodity asset are specified with data types and names

AWS (WA-2) and Microsoft Azure (WA-3) are cloud providers offering low-code solutions in combination with their cloud services, where AWS offers 1st degree integration in supporting service calls to the Amazon Quantum Ledger Database (QLDB) and Amazon Managed Blockchain. For AWS and Azure, flow-based representations are used for specifying calls to services and lambda functions. Similar to the flows shown in Fig. 8, they visualize the subsequent invocation of steps for execution along with execution logic. Using cloud services, steps are specified, possibly depending on conditions or events, for invoking programs of platform-as-a-service offerings with corresponding computation and data storage steps of infrastructure-as-a-service components. Lambda functions allow for specifying functions abstract from concrete servers or services offering scalability and distribution advantages not tied to the implemented source code or the servers. AWS relies on a state machine representation called step functions for this purpose that follows the serverless compute paradigm.

Azure allows for lambda functions through Azure Logic Apps that describe application logic in a flow-based manner. Furthermore, Azure allows the connection and integration with user-facing apps, branded power apps, developed in a no-code environment through the composition of UI elements.

Apart from cloud providers, platforms focused on the integration of web apps and web services realize applications on the principle of so-called integrations, by connecting existing apps and services in an automated workflow. In this area, simple workflows might be specified with platforms such as If-This-Then-That (IFTTT) (WA-4) that conditionally call services based on the output of other platforms, e.g. reading a temperature value from a weather app and activating an internet of things (IoT) device through an IoT online platform in case of extreme conditions. In this category, the representation abstract from source code (column r) is either dialog-guided or flow-based. For example, IFTTT (WA-4) will present users with a series of dialogs prompting the involved web apps along with their actions and specific conditions.

An example offering more complex workflows in this area is n8n (WA-7), where a flow-based editor connects different services based on advanced application logic. Here, an application might retrieve documents from a spreadsheet web app and decide based on complex branching logic the processing with data operators; for instance, transformations of data columns and the calculation of formulas. Then, the processing in further apps might be triggered, e.g., adding entries to an SQL database or e-mailing the results with a mail application in case specified criteria are met.

Integration with blockchain transactions and smart contracts is supported in the surveyed approaches for the Ethereum blockchain in Zapier (WA-14) and Aurachain (WA-1), for the Amazon Managed Blockchain and Amazon Quantum Ledger Database in AWS, and for the Hyperledger Fabric blockchain in NodeRed (WA-8) and Aurachain (WA-1). Further blockchain integrations concern the support of crypto-currency data.

Smart contract development is supported primarily for Ethereum, Hyperledger Fabric, Hyperledger Sawtooth, Amazon Quantum Ledger Database in DAML (SC-1), Dappbuilder (SC-2), and Simba Chain (SC-3). In particular, Simba Chain supports smart contract design based on templates and a visual editor for Ethereum, Hyperledger Fabric, and others.

As an example, smart contract development in Simba Chain is shown in Fig. 9. In the editor, a data model consisting of assets and transactions is defined for a smart contract to be generated with data structures accordingly persisting data on the blockchain. In the example, the smart contract of the supply chain tracking application demonstrated before in Fig. 8 is defined in its data structures. From the app, it will store shipments with a certificate of origin and the commodities contained in it, specified with the displayed attributes such as global trade item number (GTIN), quantity, and weight data. Generated data structures allow for efficient data storage and will provide basic reading and writing functionality through setter and getter functions.

In comparison, DAML (SC-1) uses a text-based representation in the form of a domain-specific language that can specify complex smart contract functionality. The language uses textual descriptions with a notation that is mostly based on natural language elements, interpreted and deployed to a blockchain. The language encompasses primarily the specification of contract logic, e.g., triggering transactions based on contractual conditions, the handling of tokens, e.g., sending out tokens if contractual conditions are met, and the definition of assets as abstract concepts represented by tokens. While this approach offers complex features due to the expressivity of the language, it is geared towards technical domain experts and developers as a low-code approach.

On the other side of the complexity spectrum, Dappbuilder (SC-2) offers smart contract creations through the instantiation of pre-defined templates for Ethereum, Polygon, and other blockchains. The approach is limited in applicability to the foreseen application areas that utilize standardized contracts modified according to the specification of the user, e.g., for issuing user-defined tokens on the Ethereum blockchain. For this purpose, a smart contract of the site is used based on the standardized Ethereum ERC-20 token implementation.

5.2.2 Platforms With 2nd degree integration

2nd degree blockchain integration has been found in 37 solutions intended for building websites, mobile or web apps, or forms, for workflow integration and automation, internal tools for companies, for data processing, and spreadsheet-based applications. Eight solutions also offer 1st degree blockchain integration. The integration features across the categories rely on another service supplying a direct integration for blockchain applications. Among the no-code or low-code applications, it is typical to integrate other services in the fashion of a composition, for example, creating an application in an app builder with data provided by an external service. Blockchain integration features, due to this capability, rely on other services for integration. Based on the integration paradigm, existing web services might be combined or access blockchain data.

Workflow integration and automation tools offer 2nd degree integration in this way. For example, workflows specified with cloud services such as with Amazon Web Services (AWS) (WA-2), or with Microsoft Azure (Azure) (WA-3) can define API calls in their flow-based editors to a platform with 1st degree integration, e.g., calling Zapier (WA-14) for the retrieval of Ethereum transactions. Similarly, workflow tools focused on integrating web apps and web services (WA-4 to WA-14) such as Pipefy (WA-9) might utilize Zapier and similar services in web-based workflows. In this way, most 2nd degree integration platforms offer the possibility of interacting with Ethereum smart contracts and transactions.

App builders and website builders provide further integration possibilities for mobile and web applications as well as websites. For instance, in Glide (AM-4), which can embed dialogs for smart contracts and transactions, in addition to integrating cryptocurrency data. In this way, applications composed of these components might be realized with workflow automation. Websites might also integrate dialogs from Glide (AM-4), e.g., e-commerce payments using cryptocurrencies or for enhancing websites with web3 functionality. Websites following the web3 concept [45] depend less on large, centralized, and potentially influential entities such as websites of well-known social networks. Instead, decentralized platforms and infrastructures host components of websites, e.g., using blockchain transactions made in a browser through the MetaMask extension or by decentralized data retrieved from Ethereum through services such as Zapier (WA-14). The integration paradigm can be applied and used in combination with platforms in the other categories concerning data, form builders, internal tools, and spreadsheets. For example, a transaction may be sent after the workflow has been started by another action such as entering data in a spreadsheet.

Spreadsheet tools may be used for building small applications with platforms such as Actiondesk (SP-1), AirTable (SP-2), or Rows (SP-3) by pre-defined components and multiple views that allow defining input fields and the processing of submitted data, e.g., calculating statistical measures of sales transactions on Ethereum retrieved through Zapier.

Form builders typically provide input fields for entering data with user-defined UI elements such as labels and buttons with the possibility of triggering external actions. For instance, retrieving corresponding transactions from Ethereum, and sending out results through notifications or e-mails. For example, Arengu might be used in this way (F-1).

Internal tools focus on company-internal tasks, encompassing enterprise tools for the automation of enterprise resource planning (ERP) or operational tasks. For example, by handling customer data and sales orders, managing human resources (HR), customer relationship management (CRM), creating dashboards or admin panels.For instance, using data from the Ethereum blockchain, tools such as Jet Admin (IN-2) might present a tabular structure and trigger an approval workflow for a back-office team.

Data processing tools permit the analysis of data with formulas or measures, e.g., of statistical nature, and offer predictive analytics features such as found in Levity (D-1) and Obviously AI (D-2). In this way, smart contract function calls might for example be evaluated regarding their frequency or sales volume. By permitting the integration of further data sources and the integration of other web applications, data analysis might involve the processing of newly appearing blockchain transactions. Such processing may include, for example, the storage of transaction data in spreadsheets, or the triggering of workflows. Integrations in this context can extend to enterprise-focused business process management when combined with platforms such as Process Street (WA-10), offering advanced functionality in combination with workflow engines.

Overall, the results show that the integration possibilities for the creation of websites or apps rely on few services such as Zapier (WA-14), predominantly found in the workflow automation category. Typical integration features consist of access to blockchain transactions or cryptocurrency data. Further integration possibilities with APIs on a technical level are very common, however, they were not considered no-code or low-code when using Webhooks, Rest, other forms of HTTP requests, or API access based on technical parameters. For the development of smart contracts, few no-code platforms could be found in practice, with most solutions being low-code approaches using representations closer to source code where technical knowledge is required for development and blockchains.

6 Discussion

For discussing the results of our study we will first elaborate on the academic papers as shown in Tables 3 and 4. We characterize each topic with relevant papers found in the literature search. The topics were derived via the topic modeling technique of LDA and the subsequent manual refinement as has been described in Sects. 4.3 and 4.4. The selection of papers included in the discussion is based on all papers assigned to a particular topic with unanimous agreement by all raters (see Sect. 4.4 and Table  5) and discusses further papers from the literature search 4.3 that characterize each topic to illustrate the scope of approaches. This will permit us to give detailed insights into each of the proposed topics. Subsequently, we will draw the relations between the topics of the academic papers and the tools found in the analysis of low-code approaches. As a synthesis, we will be able to derive commonalities and differences in academic model-driven as well as industrial low- and no-code approaches for blockchain design and point to further research and development opportunities.

Process, workflow, choreography, and decision models: Model-driven design and implementation aspects of processes, workflows, choreographies, and decisions are supported in various approaches utilizing the blockchain at design-time or run-time. Concerning especially publications on process modeling and related subjects, the topic captures a substantial part of the overall literature on modeling and blockchains.

Centered on process and workflow models, most publications apply BPMN on the Ethereum blockchain and concern run-time aspects. Especially monitoring and execution are addressed by Weber et al. [263], following optimizations [102], and systems implementing execution such as Caterpillar [41, 159, 160] and further approaches focused on workflows, e.g., by Sturm et al. [231, 232] or based on annotations by Bagozi et al. [20]. For these execution approaches, BPMN is transformed to representations used for execution with a smart contract. Oftentimes, BPMN is transformed into an intermediate model closer to execution and then used as input for a generator program resulting in one or more smart contracts. The intermediate model has the role of specifying well-defined execution semantics, often relying on Petri Nets such as in  [102, 163].

Business process management and workflow systems implementing execution consist of additional process or workflow engine components, listening to events emitted by the blockchain mostly through smart contracts as in Caterpillar and subsequent works [20, 160], usually with further blockchain-external components such as model repositories; only in some cases using decentralized repositories, e.g., based on distributed file systems as suggested by Bagozi et al. [20].

In few systems related to processes and workflows, approaches not relying on smart contract generation can be found. Here, processes and workflows are interpreted such as suggested by López-Pintado et al. [162], using workflow engines as also proposed by Falazi et al. [87, 88] and Sturm et al. [232]. Primarily static smart contracts, not changing over time, are used for the interpretation of process and workflow definitions. Also, combinations of static smart contracts and generated contracts could be found, e.g., proposed by Bagozi et al. [20] using smart contract templates, Härer suggesting a combination with multiple object- and participant-specific contracts [121] for business systems, and Klinger et al. also proposing partial generation of the contracts [142, 217].

While the approaches discussed so far rely primarily on BPMN and Ethereum with smart contracts, few process and workflow approaches also exist for other modeling languages and blockchain platforms. Not relying on smart contracts at all, Evermann and Kim [84] propose a workflow system based on blockchain transactions, where Petri Net representations of workflows are used to create transactions that trigger the execution on a workflow engine using a blockchain connector, possibly applicable also for bitcoin or other blockchains. Relying on statecharts, few works such as Nakamura et al.  [185] can be found, where statecharts specified in SCXML are reduced and transformed to contracts on the Hyperledger Fabric blockchain for workflow execution with distributed node.js applications. SOM and BPMN are applied by Härer [121] for describing business systems consisting of structural views for distributed organizations in SOM and process behavior specified by BPMN collaboration diagrams, also concerning design-time aspects for collaborative modeling based on voting mechanisms together with the generic tracking of instances at run-time for monitoring.

DEMO is applied in few instances, e.g., by Loukil et al. suggesting a non-generative approach [164], where smart contracts are interpreted in a three-layered architecture and evaluated on Ethereum, and by Silva et al. [223] proposing DEMO for its actor transaction diagrams with further diagrams of transactions and UML classes as part of a comprehensive transformation method involving execution on the Hyperledger Fabric blockchain. Guerreiro et al. [114] apply BPMN initially and suggest also DEMO for actor transaction diagrams that represent business transactions with a transformation implemented in Hyperledger Fabric smart contracts.

Concerning declarative modeling approaches, few works investigate decision models using DMN and case management by CMMN. For DMN, execution is proposed by Haarmann et al. [115, 117], where DMN provides decision rules based on formulas or decision tables that are encoded in smart contract logic for execution and demonstrated on the Ethereum blockchain. Concerning CMMN, Milani et al. [179] provide a comparison of BPMN with CMMN and point out their limitations regarding execution characteristics such as missing expressivity for completed tasks in CMMN.

Related to process choreographies, most works concern BPMN choreography diagrams with few approaches describing other modeling languages such as DCR graphs. Works in this area address the collaborative execution of process choreographies, where choreography tasks are executed by multiple participants exchanging messages. Based on BPMN and execution aspects, this is investigated by Ladleif et al. [146] and following approaches such as by Corradini et al. [61, 65], Sturm et al. [233], Corneli et al. [59], and Spalazzi et al. [229]. In BPMN choreographies, the control flow is restricted according to the choreography structure that is established by the tasks, relationships, and specialized gateways and events, effectively defining permitted patterns of message exchanges. Most approaches generate smart contracts such as Corradini et al. [61], possibly with the non-generative use of static components such as by Ladleif et al. [146]. In addition to the Ethereum-based approaches, also a multi-chain implementation has been proposed by Ladleif et al. [145].

Choreographies based on languages beside BPMN appear in comparatively few works based on DCR as addressed by Madsen et al. [166] and Henry et al. [130] in methods allowing for execution on the Ethereum blockchain. Provided an external execution engine exists, control flows between collaborative tasks of multiple participants are restricted to the edges defined by the DCR graphs in these approaches.

Further domain-specific notations exist in few works, not applying standardized modeling languages. For workflows, JSON is used by Bore et al. [38] for execution in a workflow system connected to Hyperledger Fabric. Another domain-specific notation using transaction concepts derived from Ethereum for business processes is suggested by Boychenko and Gavrikov [40] by a UI prototype without implementation.

Further specializations for the body of literature discussed for process and workflow approaches exist in addition, primarily concerning run-time aspects and optimizations. For example, on traceability and monitoring by Di Ciccio et al. [55], confidential execution such as in Carminati et al. [48], trust, e.g., Bagozi et al. [21], and flexibility aspects for instance in López-Pintado et al. [163], as well as BPMN-specific concepts, e.g., with focus on time and events by Abid et al. [2] and Naha et al. [247].

Application development: The development of blockchain-based applications using models and model-driven engineering has been the subject of many retrieved publications. Thus, the range of methods found for this topic comprises both conceptual and executable, code-generating approaches and spans from base languages such as AOM, e.g., [153], BPMN and DMN, e.g., [192], DEMO, e.g., [14], ER, e.g., [100], OCL, e.g., [235], OWL [28] to RuleML, e.g., [256], and UML, e.g., [101, 139, 168, 237], as well as a large number of blockchain domain-specific languages, e.g., [39, 99, 120, 158, 210, 236, 271], and visual programming paradigms such as Blockly, e.g., [167, 178, 265]. In terms of the targeted blockchain platforms for application development approaches, we could find a strong preference for focusing on the Ethereum platform, some also directed towards Hyperledger as a permissioned platform, e.g., [100, 139, 178], and only few with an explicit support of multiple platforms, e.g., [119, 120, 128, 206, 235]. Of particular interest from the perspective of modeling are approaches that extend existing languages with blockchain-specific concepts, e.g., by using stereotypes or profiles, as they may permit a gradual evolution of existing models towards blockchain-specific ones. This has been applied for example to UML, e.g., [128, 168, 170] or NodeRed [210]. Further approaches proposing UML profiles explicitly will be discussed below under the topic of UML Modeling.

Formal aspects and verification: The use of formal methods in the context of blockchain-based applications and especially for smart contracts is a strongly researched topic [246]. In particular, the formal verification of smart contracts can ensure their correctness and thus avoid errors that cannot be corrected afterwards due to the immutable nature of blockchains [183]. The approaches we found in our study mostly revert to some custom notation, which is the reason why we classified them under domain-specific language. They are often based on a custom-developed variant of state machines/diagrams, automata, or tool-specific extensions such as stateflows in Matlab/Simulink—e.g., [11, 172, 177]—but mostly do not adhere to the UML statechart specification. The exception being [216] where statecharts expressed in SCXML are generated during formal model checking and used as a basis for the generation of smart contract code on the Hyperledger platform. Further languages that have been used for formal verifications include for example Petri Nets for the visual modeling, simulation, and verification of smart contracts as a basis for code generation [277] and RDF as a foundation for representing knowledge about smart contract vulnerabilities and verification rules that are checked prior to code generation [201]. Although not directed to formal verification per se, also approaches based on logic-based languages such as DatalogMTL are considered here, which can be used for formal modeling of smart contracts and according code generation [190]. In addition, approaches can be found that revert to UML profiles for blockchain applications with explicit verification rules described in programming code [109], thus providing a link to the application development topic.

Legal aspects, rules, and languages: Due to the slightly misleading term “smart contract”, it is frequently assumed that this concept corresponds fully to a legal contract. However, as has recently been elaborated, four types of relations between smart contracts and legal agreements need to be distinguished [83, p.25]: (1) the smart contract stands for mere code without a legal agreement, (2) the smart contract acts as a tool to execute a legal agreement, whereby the latter is maintained off-chain, (3) the smart contract constitutes a legal agreement by itself, e.g., to express an offer or acceptance, or (4) the smart contract and a legal agreement are merged and they both exist simultaneously on-chain and off-chain, whereby it needs to be stated whether the agreement is to be treated on-chain or off-chain. These preliminaries need to be considered when regarding papers that treat legal aspects in the context of blockchains. In particular, approaches of the first type (1) are discussed under the topic Application Development. Further, also the terms rules and languages were identified as part of this topic in the course of the content-based analysis using LDA. We thus group here together papers that incorporate rule-based approaches or that aim for the development of new languages in the context of blockchains, thereby reverting also to modeling or model-driven engineering.

In terms of legal aspects, we thus identified papers that develop, for example, a smart legal contract markup language, dedicated new languages, or transformations from existing legal or financial contract languages into blockchain-based smart contract languages thus arriving at legally-binding smart contracts, i.e., where the smart contract constitutes a legal agreement [51, 80, 148, 267]. Another direction is to use smart contracts for partially automating the execution of legal contracts as done in the MDE-based Beagle approach where the legal agreement is kept off-chain [251]. Furthermore, declarative approaches have been proposed for representing contractual terms for deriving smart contracts on blockchain platforms, e.g., using RuleML as base language [71, 72]. In terms of dedicated languages for smart contract development there is some overlap with the topic of Application Development discussed above. Thus, approaches such as Das Contract [226], SmaCoNat [207], SPESC [125], or CML [270] also mention their relation to paper-based legal contracts and may be used for legal purposes but focus more on the development of blockchain applications. We also found papers on the conceptual level, e.g., for unifying the notion of legal smart contracts from a conceptual modeling perspective [144] or for the description of legal concepts in smart contracts using formal ontologies based on Petri Nets [78].

Ontology: Various forms of ontologies in different languages and formats are used for designing blockchain-based applications, as seen, for example, in the above topic where ontologies mainly take on a supportive role. Under this topic we thus classify those approaches that put the focus on ontologies for blockchain applications and which regard ontologies not only as an additional means of representation. This includes for example the use of ontologies in a way similar to reference models, i.e., for achieving a common understanding of the contained concepts as proposed in [70] for explaining the nature of blockchain transactions and for providing a taxonomy of the blockchain ecosystem by using UML or in [69] with the focus on smart contracts. This direction can be further extended by reverting to ontology languages such as OWL and SWRL which permit to formalize blockchain-related concepts such as NFTs (Non-Fungible Tokens), DAOs (Decentralized Autonomous Organizations), or oracles from different perspectives and reason about them using rules or queries [26, 29]. Apart from general reasoning about blockchain concepts, ontologies have been used to reason about specific blockchain technologies, e.g., the Solidity language for Ethereum smart contracts, which permits, for example, to derive statistics about particular concepts used in deployed contracts [44].

UML modeling: Based on the topics suggested by the LDA, we decided to establish a separate topic for approaches that put an explicit focus on UML. Similar to what we noted for the topic of ontologies, UML has already been covered in several approaches as a means of representation and a basis for execution. Here we thus focus on approaches that put UML at the center. This includes, for example, approaches that revert to UML use case and UML sequence diagrams in combination with i* for understanding the goals and design of blockchain-based software applications [258, 259]. As had already been mentioned above, the extension of UML through blockchain-specific profiles or stereotypes has been proposed in several papers. Górski and Bednarski thus suggest a UML profile for smart contracts by providing stereotypes for states, contracts, verification rules in smart contracts, and flows for representing the communication of nodes and show how this can be translated into an implementation on the Corda platform [110]. The same authors further proposed a UML profile for the deployment of distributed ledger applications. For that purpose they added stereotypes to UML deployment diagrams for distinguishing, for example, between DLT nodes, oracle nodes and nodes specific to the targeted Corda platform [111,112,113]. Standard UML models such as statecharts may also be used for engaging in application development via model-driven engineering. Jurgelaitis et al. have shown for example, how UML class diagrams and statecharts may be used for representing platform-independent and platform-specific models for generating code in the Solidity language for the Ethereum platform [137].

Business modeling: Under the topic of business modeling we identified only approaches that are positioned on the conceptual level. Although the generation of artifacts from models in this area has been demonstrated—e.g., for generating business plans from business model canvas models [268]—we have not found approaches in our study that apply such techniques for the design of blockchain-based applications so far. Of particular interest in this context are approaches for identifying new business opportunities through the use of modeling approaches, e.g., by using languages such as $e^{3}$ value [198, 203], $e^{3}$ value in combination with BPMN [105], or ArchiMate [135]. Thereby, the latter may also be integrated with technical aspects of the underlying enterprise architecture such as shown in [66]. Further, it has been shown how multi-agent organizational modeling can be applied for studying and simulating blockchain-based systems [211], whereby UML has been chosen to describe the approach.

Reference models: The creation and application of reference models has been widely studied in multiple domains. Reference models can be characterized as conceptual models that serve as model blueprints in a certain domain [269] and especially for the development of information systems [91]. For the field of blockchains, reference models have been proposed for describing the underlying technologies and their procedures as such, e.g., using a combination of ArchiMate, BPMN, and UML [82], using custom notations for specific blockchain platforms such as Hyperledger [37], or using UML for describing the conceptual schema of Ethereum [194].

Supply chain: The application of blockchain technologies for tracing products over large logistic networks and across different cooperating parties has gained considerable interest both in academic research as well as in practice [106]. Thereby, the digitalization of the physical workflow of documents and transactions between the actors in a supply chain such as shipment companies, ports, airports, etc. has the potential to reduce transaction costs and enable even new types of business services based on the availability of additional data. This is especially due to the use of blockchains in practice for this area as recently exemplified through the TradeLens platform [136]. In this context, we found approaches that focus specifically on the area of supply chains and that provide model-based approaches. This includes the use of established modeling approaches such as i* and BPMN, e.g., for representing the interaction of business actors in the realm of supply chains [118], or the development of domain-specific modeling languages and profiles as well as dedicated blockchains for supply chain applications, as e.g., in [15, 31, 32, 222].

Industrial low-code and no-code approaches: The review of industrial low-code and no-code approaches concluded with 47 software platforms. In this discussion, the platforms described in Sect. 5.2 and Table 6 are summarized for their main characteristics and limitations, leading to a concluding discussion in comparison to academic approaches for model-driven engineering. In comparison to academic approaches, a broad comparison is given in Table 7.

The reviewed platforms are available as online platforms following the software-as-a-service paradigm, partially with additional offline components. They can provide technical solutions for practitioners ranging from the automation of business tasks to workflow integration and software engineering.

From the review, platform tests, and implementations for evaluation (c.f. Sect. 5.2), a general finding is the high maturity of industrial platforms in the form of products. In particular, the high usability and the availability of a broad range of interfaces for cloud-based and blockchain integrations, and the possibility of cross-platform development. 18 platforms allowed for 1st degree integration with blockchains, primarily with Ethereum, Hyperledger Fabric and Amazon Quantum Ledger Database, while 37 platforms provided 2nd degree integration by relying on other platforms or services. This result is similar to the blockchain platforms identified for the academic approaches in Table 3.

For blockchain application development, 1st degree integrations allow reading of blockchain data as well as submitting transactions to major blockchain networks in addition to specific functionality regarding templates for decentralized applications and cryptocurrency-related data integrations. Using the principle of composition, blockchain applications can utilize applications and web services as well as platform-as-a-service and infrastructure-as-a-service offerings from cloud providers, possibly followed by data processing and analytics. Blockchain integration is therefore applicable primarily with categories related to smart contracts, workflow integration and automation, and data (Table 6). Furthermore, data transfers, triggering of events, or presentation in application UIs or dashboards may be realized. Despite these features, however, limitations related to the abstraction from source code, implementation trade-offs, and technical knowledge remain.

The representations abstract from source code such as flow-based editors (c.f. Fig. 8) or graph-based data model editors (c.f. Fig. 9) provide meaningful abstraction, ease-of-use, and, at the same time, hide implementation complexity. The insight into the execution behavior is limited in most platforms, where few platforms allow for limited source code access, e.g., Outsystems and Mendix. This results in limitations primarily of auditability, transparency, portability, and migration. For instance, in cases where execution behavior requires inspections due to audits, bugs or other unintended behavior, access to source code is required.

Also related to abstractions is the technical knowledge required for users. Low-code development environments such as in Outsystems or Mendix provide representations close to source code and tend to be better suited for developers or technical domain experts, possibly engaging in application development or supporting it. No-code environments might be used by non-technical experts or end users, sometimes called citizen developers, for their abstractions beyond the level of source code, e.g., guiding the user through dialogues. Here, business tasks involving multiple web applications might be automated, however, the development of complex applications involving blockchains can at most be supported, e.g., in discussing implementations with technical experts and domain experts. For both low-code and no-code platforms, visualization and potentially better understanding of domain knowledge are general benefits, limited by technical knowledge required for developing with the platforms, the understanding of execution behavior, especially in case of unintended behavior, and the possibility of evaluating implementation trade-offs.

Table 7 Primary characteristics of academic and industrial approaches for blockchain application development

Comparison of academic and industrial approaches: When comparing the results of the analysis of academic approaches and those of industrial low-code and no-code approaches we can identify the following commonalities and differences. Although industrial approaches typically do not position their platforms under the terms model-driven or model-based, the representations used in some of them directly correspond to these terms as used in the academic publications—see for example the illustrations of the Outsystems and the Simba chain platforms in Figs. 8 and 9.

While academic approaches have discussed the design of blockchain-based applications from a multitude of perspectives, including for example business, legal, organizational, deployment, and coding aspects, the industrial low-code and no-code platforms seem rather limited in terms of their scope. For example, none of the found low-code or no-code approaches provide representations to elaborate on business aspects, the definition of goals or the consideration of legal and compliance aspects. In these areas industrial approaches could consider in the future the methods and tools proposed by academia. This concerns in particular also the integration of different methods as has been broadly discussed in enterprise modeling in academia.

On the other hand, the industrial platforms all have a high technical maturity, especially regarding ease of use, integration, and, in some platforms, features for scalability. These features are not directly comparable to aspects of academic approaches which often are only partially implemented, focus on feasibility demonstrations, and generally do not offer features found in industrial software products.

Since most platforms are web-based, they tend to integrate also the hosting of cloud-based application components or services that can be scaled by the platform or through integrated services from cloud providers. Especially when using serverless architectures from cloud providers such as AWS, scaling can extend to further infrastructure resources without requiring changes on the application level. This is of course something that cannot be reached by academic platforms which can typically only provide a prototypical implementation, which is ideally made accessible as open-source.

A further interesting aspect where academic and industrial approaches differ at this point in time are proposals for domain- or task-specific solutions. As could be found in the academic discussions on blockchain design approaches in the area of supply chains, first approaches dedicated to this specialized field exist. In contrast, industrial approaches so far seem to rest on the general level, at least when it comes to 1st degree integration platforms. However, platforms such as Budibase (IN-1) or Jet Admin (IN-2) would offer at least the possibility of 2nd degree integration here.

Limitations of the study: Despite the extensive review of literature sources across many different outlets and the inspection of a large number of low-code and no-code platforms our study is of course not without limitations. These concern both the retrieval of literature, the selection of relevant sources, as well as their interpretation. Regarding the retrieval of sources we may have missed publications that could only be found using multiple recursions. Here, we set a cut-off in the backward and forward search due to our limited manual processing capacities. Bigger author teams with additional resources may thus contribute additional results. The same applies for the retrieval of industrial low-code and no-code platforms and tools. Concerning the determination of the relevance of publications for the investigated topic and the derived research questions, a certain subjectivity cannot be avoided. We aimed to mitigate this as much as possible by going through multiple iterations and in-depth discussions between the authors. Finally, the content-based analysis of the literature sources also has a subjective component. As a mitigation we reverted to a computational approach for a more objective proposal of potential topics and a later manual refinement. However, as has already been mentioned in Sect. 4.3, also the used LDA approach requires a subjective selection of parameters and could easily lead to different results in case of variations. We are however confident that the provision of all used datasets and analysis parameters makes the used methods and processes transparent and replicable—see “Appendix A”.

7 Conclusion and research opportunities

In this paper we reviewed academic model-driven engineering approaches and industrial low-code and no-code platforms for supporting the development of blockchain-based applications. We have done this along four research questions, restated in the following:

RQ1: Which academic modeling approaches have been developed until today for designing blockchain-based applications? We have identified 177 academic publications (excluding preprint versions that have been published) from various fields regarding model-driven engineering and development of blockchain-based applications. Further we identified the modeling methods used, as well as the blockchain technologies of interest in academia.

RQ2: Which low-code and no-code platforms permit the realization of blockchain-based applications?

Following a rigorous review process, 47 low-code and no-code platforms have been identified. We have found that these realize blockchain support either directly, as feature implemented in the product, or indirectly via integration facilities.

RQ3: What are the predominant characteristics and areas of academic modeling approaches as well as low-code and no-code platforms?

Academic approaches display an effort towards a strong conceptualization of the blockchain-domain with a focus on various types of models as central artifact. In contrast, low-code and no-code platforms typically are less concerned with model-representations, or hide these from the user. Instead, these platforms focus on software products, oftentimes as part of a cloud-based solution. In terms of technical maturity, most academic approaches do not go beyond a prototypical realization and instead place more weight on conceptual aspects. In this regard, industry solutions typically feature a higher maturity and offer greater flexibility for an integration with other products. RQ4: What are future research opportunities not realized today by academic approaches and low-code or no-code platforms?

Based on the insights we gained through our study we can derive the following opportunities for further research in the design of blockchain-based applications in a. model-driven engineering, b. industrial low-code and no-code platforms, and c. combinations and interfaces between academic and industrial approaches.

Despite the large number of approaches proposed in the academic papers and the multitude of different languages used for supporting the design of blockchain-based applications we noticed a shortage of holistic approaches covering both business as well as technical aspects. For example, the implementation of blockchain solutions not only requires a sound and sustainable business model but also ways for translating this into technical architectures and possibly even to the level of code generation. At the moment this could only be achieved using a combination of several approaches, similar to the 2nd degree integration found in the review of industrial tools and platforms. Further, only few approaches exist so far that target explicitly the design of blockchain-oriented business models. Though existing languages such as $e^{3}$ value or parts of ArchiMate can and have been shown to be used for this purpose, languages with explicit stereotypes for this purpose have not yet been proposed. Also for other modeling aspects such as enterprise architecture, business processes and workflows, and the technical realization, further profiles and stereotypes could be proposed to ease the usage of model-based approaches.

The review of industrial low-code and no-code platforms showed the advanced state of these platforms today compared to their counterparts found in early endeavors in the 1990–ies. As has already been mentioned in the comparison above, these platforms however lack methods for adding more conceptual aspects and relations to the business side. In this respect, they could learn from the academic approaches and possibly even academia could contribute here in the form of plugins or extensions of existing industrial platforms. Further development opportunities for the industrial platforms could be identified in regard to better support for debugging and error handling, where still considerable technical knowledge is required by users.

Finally, we can derive opportunities for joining academic and industrial approaches. Apart from the mentioned extensions of platforms on either side, it may be worthwhile establishing interfaces between academic and industrial platforms. For example, academic platforms could provide interfaces to profit from advances in formal verification of smart contracts in industrial platforms and low-code and no-code platforms could provide APIs for enabling interaction with academic platforms, e.g., on the business and conceptual level.

8 Appendix A: Datasets of the review process

The bibliographies of the document corpora at various stages of the review process corresponding to Fig. 2 are available online [68]. In particular, we provide reference lists for all documents collected after the steps (S-2), (S-4), (S-7) and (S-8).