1 Introduction

Due to factors such as extreme (hyper) competition [18, 58, 72], increasing expectations from customers, regulatory changes, as well as technological advancements, the conditions in which enterprisesFootnote 1 need to thrive become increasingly turbulent. As a result, the ability to change, often referred to as ‘agility’ [85], becomes an important determinant for the success of enterprises [91, 118]. Indeed, keeping up with competition by reducing the time-to-market of new or changed products is still considered a dominant issue [125].

The notion of ‘agile enterprise’ is also referred to as the ‘run-time adaptive enterprise’ [89] or the ‘flexible enterprise’ [115]. One can, actually, identify different flavors of flexibility that can be considered as cornerstones in creating an agile enterprise, including strategic flexibility, organizational flexibility, financial flexibility, marketing flexibility, manufacturing flexibility and information systems flexibility [115, Fig. 1.4].

Since software makes up a large part of the information systems that are used in modern day enterprises, the enterprise and its supporting software are in fact intrinsically intertwined [27, p. 251]. As a consequence, enterprise agility and software adaptability are also highly intertwined and can not be viewed separately. Enterprises are almost continuously being redesigned [40], and as a consequence, enterprise and information systems engineering, including software development, is increasingly an ongoing activity that requires continuous alignment between the enterprise and its supporting software [51].

One of the issues in the alignment of an enterprise and its supporting software, is that design decisions that concern an enterprise’s implementation, including functionary types, organizational units, and the choice to apply the four-eyes principle, are often hard-coded into software [10, 47, 124]. The latter makes it harder to align changes on the enterprise level with changes in the software—something the authors recognize in their current practice quite frequently.Footnote 2 Moreover, the authors recognize that the software often does not support the required enterprise agility, but instead offers more flexibility than required on some aspects and less than required on (critical) other aspects. In order for software to provide the flexibility as required by the enterprise, it is necessary to make enterprise implementation design decisions explicit and to make transparent how they are implemented in software.

In order to prevent developers from introducing implicit design decisions in the process of software development, and to ensure that the software supports the level of flexibility as required by the enterprise, MDSD is suggested [30]. MDSD is a model-driven approach for the development of software that promises to bridge the gap between requirements of an enterprise and software implementation [12, 92, 113]. It uses models and model transformations to generate code or for real-time interpretation by running software [8, 12, 33, 48, 77, 106]. Metamodels play a crucial role in defining a model transformation or mapping function [2, 6, 8, 57] (see Fig. 1) and need to be precisely defined [12, 63, 77].

One of the earliest approaches toward MDSD is Computer-aided Software Engineering (CASE) [35, 71, 73] from the 1980s. A more recent approach is Model-driven Architecture (MDA),Footnote 3 that relies heavily on the use of Unified Modeling Language (UML) models [105]. However, mda comes with a lot of issues, including poor integration of different models, lack of efficiency, limited applicability, vendor lock-in, and its complexity [81, 110]. Other approaches include the automatic transformation of UML or Business Process Modeling and Notation (BPMN) models into BPEL [90, 126] specifications. While both modeling languages have a defined metamodel, it has also been shown that these lack proper semantics or [14, 29, 36, 64], even worse, completely seem to miss proper concepts for enterprise modeling [128].

In this research, the general hypothesis is that by taking an MDSD approach one can improve enterprise agility, at least to the point that software development is not the limiting factor for enterprise agility anymore. As a more specific hypothesis, we posit that DEMO ontological enterprise models—capturing the enterprise’s essence—, supplemented with explicit enterprise implementation design decisions, captured in Organization Implementation Variables (OIVs), provide a semantically rich starting point for MDSD.

In terms of Fig. 1, this means we will use DEMO as the source for MDSD. As a first step to, indeed, show the potential benefits to use DEMO ontological enterprise models as a base for MDSD, this research shows the design of a mapping from DEMO models to Mendix for the (automated) creation of a low-code application that also intrinsically accommodates run-time implementation design decisions. So, in terms of Fig. 1, we will use Mendix as the target for MDSD. In the next section, we will provide a further motivation for this source and target.

Fig. 1
figure 1

Model transformation and the role of metamodels, adapted from [7, 8, 12, 17]

Full size image

In line with this reasoning, the overall goal of the research reported on in this article is to create an (automated) transformation, a mapping, from the model of the enterprise essence and associated OIVs to a Mendix application in order to be able to generate low-code applications from enterprise models. As this mapping is a design(ed) artifact, the Design Science Research methodology [50, 76, 109, 123] has been applied. In terms of Design Science Research (DSR), the main focus of this article is on the design cycle, i.e., the construction and (initial) evaluation of the mapping. The resulting mapping has been evaluated (and further improved) multiple times, involving different input models, ranging from academic cases such as EU-Rent [83, 88] to real-world cases including Social Housing [66, 89]. While the mapping has evolved and improved over time, the latest version of the mapping is presented.

The remainder of this article is structured as follows. In Sect. 2 related work such as MDA is elaborated on and the rationale for the chosen source and target for the MDSD approach are provided. Given these choices, Sect. 3 outlines the theoretical background regarding Enterprise Ontology, Enterprise Implementation, and low-code technology. In Sect. 4 the mapping is shown, while Sect. 5 provides a summary of the evaluations conducted so-far and shows how the evaluation was done on the real-world Social Housing case. Before concluding, Sect. 6 discusses the limitations of the mapping. This article ends with conclusions and directions for future research in Sect. 7.

2 Related work and chosen solution direction

In this section, we discuss related work that is of direct relevance to the ambition to create an (automated) transformation from the DEMO model of the enterprise–its ‘essence’–and associated implementation design decisions to a working Mendix application in order to be able to generate low-code applications from enterprise models.

2.1 Enterprise engineering

The field of Enterprise Engineering sees enterprises as complex sociotechnical systems [40] and therefore connects the fields of organizational science and software development. DEMO (Design and Engineering Methodology for Organizations) is a leading method within the discipline of enterprise engineering [26], with strong methodological and theoretical roots [3, 46, 104, 122] that sets communication as the primal notion for the design of enterprises and its supporting software systems [95]. At the same time, we observe there to be an increasing uptake of DEMO in practice, as, e.g., illustrated by the active community and certification instituteFootnote 4 as well as the reported cases concerning the use of DEMO [4, 10, 19, 20, 27, 32, 39, 54, 55, 60, 68, 79, 86, 87, 94, 107] and integration with other mainstream enterprise modeling approaches such as ArchiMate [31, 62] and BPMN [16, 42, 52, 78, 93, 120].

The theories behind DEMO distinguish between Enterprise Ontology and Enterprise Implementation [27]. Enterprise Ontology as defined by Dietz aims to capture the ‘essence’ of an enterprise in terms of products and services delivered. The Enterprise Implementation pertains to the organizational structure(s) and (sociotechnical) means, including the division of work between human actors and software solutions, as well as their assignment(s) to the organizational structures. Although changes to an enterprise’s ontology do occur, most of the time changes pertain to its implementation only [25, 27, 95]. As mentioned above, the authors have observed in practice how such enterprise implementation design decisions are often hard-coded into software.

2.2 Model-driven software development and MDA

Claimed advantages of MDSD over traditional software development approaches include: (a) a common and better understanding and reasoning about the required or created system [6, 12, 48], (b) the possibility to simulate before building the system [48, 63], (c) an increased productivity of the development team due to (partial) automation of the development process [6, 12, 48, 63], (d) a reduction of the number of bugs or defects, as they can be discovered early in the development process when they are less costly to fix [12, 48, 63], and (e) traceability between model and code [1, 102]. It is because of all of these advantages that in the research as reported on in this article, an MDSD approach is applied.

A specific implementation of MDSD is MDA, that, originally,Footnote 5 discerns three layers or kinds of models being used [82]Footnote 6:

  1. 1.

    The Computation Independent Model (CIM) describes the business domain without any computational aspect;

  2. 2.

    The Platform Independent Model (PIM) focuses on the software that supports the business but is technology independent;

  3. 3.

    The Platform Specific Model (PSM) is very closely related to the PIM but adds technological details so that working software can be created.

In terms of MDA this research thus needs an enterprise modeling language that can act as CIM and a target technology that can act as PSM ultimately. Considering the PIM and PSM are very closely related, in this research the distinction between the two is considered not very relevant at this stage.

2.3 Source model: enterprise modeling language

In order to be able to transform a model in the process of MDSD (see Fig. 1), the input model must a) be comprehensive, b) describe all business requirements, c) be consistent, and d) have its semantics fully specified. As the aim of this research is to create enterprise software, the chosen source models should at least comprise actor roles, products, process, information (items) and business rules. There are many enterprise modeling languages, including for example: 4EM [70, 101], ArchiMate [69, 117], ARIS [103], BPMN,Footnote 7 CogNIAM,Footnote 8 MEMO [37], SBVR,Footnote 9 SYSMLFootnote 10 and UML.Footnote 11 However, for each of these modeling languages it holds that either a) it describes only a part of the enterprise, e.g., it focuses on process or data or business rules; or b) it lacks formal semantics [65].

DEMO ontological enterprise models are posited as being coherent, comprehensive, consistent and concise models of the (essence of the) enterprise [27, p. 14]. Such a model is coherent of sub models describing both products, actor roles, processes, information and business rules. Moreover, the metamodel and semantics of DEMO is fully described [24]. As such, they seem to provide a good starting point for an MDSD approach. This is backed up by experiences from practice that indicate that DEMO ontological models provide a good basis to define requirements and design or generate software [19, 27, 32, 39, 54, 55, 60, 79].

Alternatively, a combination of several modeling languages could be chosen for the purpose of this research. However, given the lack of proper semantics for most existing modeling languages, combining languages is a tedious task that goes beyond the timelines of this research. As DEMO is readily available and seems to fit the goal of this research, DEMO models will be used as source for the MDSD approach as applied in this research.

2.4 DEMO-driven software development

While a literature study resulted in some partial mappings from DEMO to working software [53, 56, 61, 111], a complete mapping from the full DEMO metamodel to any software implementation model was not found. Furthermore, just as important, existing research seems to neglect enterprise implementation aspects. This results in a need for software developers to deal with these aspects themselves, thereby (possibly) causing a lack of transparency regarding the transformation of implementation design decision to software; and thus (possibly) hampering enterprise agility. For instance, Van Kervel et al. [60, 61, 111] report on a software engine that is able to generate working operational software, taking the DEMO ontological enterprise model of a domain as input. A deeper investigation, however, revealed that, in the process of creating this engine, several implicit implementation design decisions have been made that ended up being hard-coded in the software engine. Moreover, this engine only seems to support changes on the level of the DEMO ontological model of the enterprise, i.e., a new or changed product, service, or business rule, and not on the implementation level, i.e., a new functionary type or organizational unit.

A potential explanation for these issues is the fact that creating code to support a mapping of the complete metamodel of a modeling method such as DEMO is a highly complex and time consuming task. This is also why, in principle, the researchers suggest using a model-driven code generation strategy, since real-time interpreters can become even more complex. At the same time, such an approach makes it harder to make (controlled) customizations and extensions that are often needed in practice, and it is therefore the researchers suggest to turn to low-code technology.

2.5 Target model: low code

The idea of low-code technology is to add an(other) abstraction layer on top of (high) code such as Java and.Net. In terms of MDA [84], it is actually not clear if low code should be regarded as a PIM or as a PSM.

Low-code technology applies techniques from MDSD, while still allowing for (controlled) customizations and extensions [15]. While low-code technology improves enterprise agility, compared to traditional code [108], practical experience shows that these platforms mainly offer technical adaptability. For instance, changing the database management platform from MySQL to Postgres, and some flexibility on the (functional) requirements level, such as changing a specific workflow or screen lay-out. At the same time, however, changes in the enterprise, such as the organizational structures or its portfolio products and services, can still take quite some time to implement.

Fig. 2
figure 2

The standard transaction pattern shows the basic flow and discussion states. The complete transaction pattern includes 4 revocation patterns [27]

Full size image

For this research, the Mendix low-code platformFootnote 12 is chosen because it provides good documentation about its metamodelFootnote 13 and offers a Software Development Kit (SDK) to create Mendix applications using TypeScript.Footnote 14 Next to that, the researchers are experienced in using the Mendix platform in real-world situations.

3 Theoretical background

Before discussing the mapping from DEMO to Mendix, this section will briefly introduce the most important aspects of Enterprise Ontology and Enterprise Implementation, as well as the concept of low-code technology for the software support of enterprises.

Table 1 Transactor Product Table (TPT) for the Volley case
Full size table

3.1 Enterprise ontology

In general, an ontology is defined as a formal and explicit conceptual specification describing (shared) knowledge about some domain [11, 43, 45, 114]. In contrast to, e.g., ‘regular’ (data) models, an ontology specifies a shared view of the involved stakeholders [112] that can be expressed in a model containing the relevant concepts including their definition or semantics, and their relations [34, 44, 112].

Enterprise Ontology involves a specialization of the general concept of ontology, in that the goal of Enterprise Ontology is to share knowledge about an enterprise within and between enterprises [119]. Building upon the Language/Action Perspective [122], Fox [34] proposes actors, their roles and communication links between them as key concepts in Enterprise Ontology.

In his EE-theories for Enterprise Engineering and Enterprise Ontology, Dietz further builds upon these concepts by seeing an enterprise as a network of actors that enter into and comply with commitments [27]. Such commitments are raised by actors in acts, the atomic units of action, and follow a generic pattern called the Complete Transaction Pattern (CTP). This CTP (see Fig. 2) consists of 19 general step kinds and deals with the basic flow—request, promise, execute, declare and accept—as well as discussion states—decline, reject—and cancellations (or revocations). The general working principle is that actors constantly check whether there are acts they have to deal with or respond to; this is the so-called actor cycle. The total set of acts for an actor to deal with is called the actor’s agenda.

By abstracting actors to actor roles and commitments regarding a specific product kind to transaction kinds, the (DEMO) model becomes independent of the actors that are actually involved in the operation. Every elementary transaction kind has exactly one actor role as executor and one or more actor role(s) as initiator. This abstraction results in an enterprise model that only depends on an enterprise’s products and services, and that is fully independent of the way in which an enterprise is realized and implemented [22]. As a result, the DEMO ontological enterprise models are considered more stable than implementation dependent models [25]. In the next sections, the DEMO aspect or sub models, along with an example, and its metamodel, will be introduced.

3.1.1 Ontological aspect models

The DEMO ontological model of an enterprise consists of an integrated whole of four aspect models [27]. The Cooperation Model (CM) models the cooperation of the enterprise; it consists of transaction kinds, associated (initiating and executing) actor roles, fact banks, access links between actor roles and fact banks, and wait links between transaction kinds and actor roles. The CM is expressed in one or more Coordination Structure Diagrams (CSDs) and a TPT. The Process Model (PM) models the processes that take place as the effect of acts by actors, by detailing the coordination between actor roles; it makes explicit the causal and wait links between acts from the CTP. The PM is expressed in one or more Process Structure Diagrams (PSDs) and one or more Transaction Pattern Diagrams (TPDs). The Fact Model (FM) is the semantic model of products of the enterprise; it defines (declared or derived) fact types (entity types with their related product kinds, property types, attribute types and value types), existence laws and occurrence laws. The FM is expressed in an Object Fact Diagram (OFD) and zero or more Derived Fact Specifications (DFSs). The Action Model (AM) is the model of the operation of the enterprise, guiding actors in performing their acts. It specifies for every agendum kind with which the enterprise has to deal one or more Action Rule Specifications (ARSs). Each ARS fully supports the actor cycle and consists of an event part detailing the agendum kind to respond to, an assess part detailing the conditions to check and a response part that states how the actor should respond. Although these guidelines may look like rules, they offer the actors the possibility to autonomously–but responsibly–deviate from these guidelines.

3.1.2 Example: Volley

We use the Volley case [24, Ch. 12], which basically represents any (amateur) sports club, as an example to illustrate some of the key elements of DEMO.

In this case one can become member (TK01 for the first Transaction Kind) of the sports club by filling in a form with some personal details. After the information has been checked, the president of the club decides whether a membership is granted or not–the membership is, usually, granted when the (aspirant) member is 18 years old or more. When it is decided that the aspirant member can indeed become a member, a request for the payment of the first period (or part thereof) is done (TK02). As soon as the payment has been made, the membership card is printed and sent to the member so that he or she can start using the sports facilities. Needless to say, after becoming a member, a periodic process will make sure the periodic payments are being made. Moreover, there are ways to end a membership. However, in this example the focus is on becoming a member, and other parts are left out for simplicity.

Table 2 Transactor Product Table (TPT) for the Volley case
Full size table
Table 3 ARS01 (executed by TAR01) for the Volley case
Full size table

The TPT for the Volley case (Table 1) shows the (two) identified (elementary) transaction kinds and for each transaction kind its related product kind and the (elementary) actor role that is the executor of the transaction kind. For simplicity, PK01 only allows for a one-time payment per membership; in order to allow for periodic payments, it has to be changed to ‘[membership] for [period] has been paid’ with consequences for the FM. The CSD for the Volley case (Fig. 3) visualizes the TPT and shows the actor role(s) that can act as the initiator of a transaction kind; CTAR01 is a composite actor role (gray background with large border) and AR02 is out of focus (gray background), implying that only for TAR01 ARSs have to be created. It also shows there are two external fact banks (multiple transaction kinds) that contain facts about persons, e.g., their day of birth, and about the club, e.g., the minimum age. As shown earlier, each transaction kind follows the CTP, consisting of 19 general step kinds, resulting in 19 transaction kind step kinds for each transaction kind.

Fig. 3
figure 3

CSD for the Volley case

Full size image
Fig. 4
figure 4

OFD for the Volley case

Full size image

The PSD for the Volley case (Fig. 4) shows the dependencies between the two transaction kinds. It tells that after a promise for TK01, (usually) a request for TK02 is performed (causal link), and that an execute for TK01 has to wait until the related TK02 has been accepted (wait link). The dependencies will be formalized in the AM.

The OFD for the Volley case (Fig. 5) shows the primary entity type ‘MEMBERSHIP’, its attribute type ‘starting day’ and its property types ‘member’ and ‘payer’. It also shows the entity type ‘PERSON’ with attribute type ‘day of birth’ and entity type ‘YEAR’ with attribute types ‘minimum age’ and ‘membership fee’, implying these club facts can be adjusted yearly. Both entity types PERSON and YEAR are out of focus (gray background). The DFS for the Volley case (Table 2) shows the derivation rule to calculate the age for a given person on a given day.

ARS01 (Table 3) for TAR01 in the Volley case shows the action rule to deal with a request of TK01:

  • The event part shows the event that is being dealt with (TK01 is requested), including the relevant information that must be part of the request in order to be able to deal with it.

  • The assess part shows the three clauses after Habermas [46]:

    • In the rightness division, it is ensured that both involved actors have the proper authority. In this case, the person performing the request should be the member of the (requested) membership.

    • In the sincerity division, it is checked whether both actors are trustworthy and sincere in their commitment. In this case, no specific condition has to be checked.

    • In the truth division, possible violation of existence and occurrence rules are checked. In this case, the age of the (aspirant) member is checked against the minimum age.

  • The response part shows that the actor can choose between promising and declining the request, based on the assessment. The first sentence of the response part allows the actor to responsibly (!) deviate from the rule. For example, if a young boy named Federer wants to join the club, but has not reached the minimum age yet, the actor can decide to allow the boy to become member. This underpins the idea that actors act autonomously and responsibly.

In total, there are 4 ARSs defined for TAR01. Together they constitute the AM for the Volley case.

Fig. 5
figure 5

PSD for the Volley case

Full size image
Fig. 6
figure 6

DEMO metamodel, adapted from [24, 80]. Legend is same as for FM, see Fig. 4

Full size image

3.1.3 DEMO metamodel

The DEMO Specification Language (DEMO-SL) specification [24] provides the formal specification of the DEMO metamodel, which has been extended and improved further in [80]. In Fig. 6, the DEMO metamodel derived from DEMO-SL is depicted. The general step kinds are defined by the CTP and thus are not defined in any of the aspect models. Product kinds are defined in both the CM and FM. A derived fact type can be expressed as a calculation, which can be an aggregation, specialization, or generalization. Both (elementary) actor roles and fact types can be in or out of focus—composite (trans)actor roles and multiple transaction kinds are by default out of focus, while the other concepts are by default in focus. Out (of) focus means the concept is shown in the higher-level models, such as the CM, PM, and FM, but no (detailed) action rules are created.

While there is an XML-based exchange model for DEMO available [80], in this research it was decided to create a more compact JSON (JavaScript Object Notation) format to represent the DEMO models as input for the automated model transformation, leaving out parts that are for representation only. The DEMO model for the Volley case expressed in JavaScript Object Notation (JSON) is shown in Fig. 7. The (metamodel) concepts of transactor role, elementary actor role, elementary transaction kind and product are compressed into one JSON object called transactor role, where an ID and names are added for readability. The composite actor roles and multiple transaction kinds can be found as such in the JSON representation, along with the initiates and has access links between an (elementary or composite) actor role and a (multiple) transaction kind. The concept of transaction kind step kind can be fully derived from the transaction kinds and the CTP, and thus do not need to be specified in the JSON input, just as causal links and wait links, which are (redundantly) specified in the ARSs as well. The different specializations of fact kind are represented with a type attribute (entity type, property type, value type, attribute type, derived), with a name and, if applicable, a range and domain. The ARSs are represented by an identifier, the actor role responsible for the rule, the event part (consisting of a when and while clause) and the assess part (consisting of a then and, optionally, else clause).

Fig. 7
figure 7

JSON file representing the DEMO model for the Volley case

Full size image

3.2 Enterprise implementation

In order for an enterprise to become and stay operational, it has to be implemented with appropriate technologies [27], including the assignment of work to human actors and/or IT-based actors. While the DEMO ontological enterprise model shows the (decided) products and services (as transaction kinds) as well as the collaboration network (of actor roles) for the production and delivery, many degrees of freedom exist on how to operationalize this network toward a ‘running’ implemented enterprise [27, p. 46].

Implementation design starts from an enterprise’s ontological model and ends with a fully detailed specification of the implementation of the enterprise—possibly within the design space constrained by an Enterprise Architecture [23]. The lowest level and most detailed model of an enterprise describes all implementation design decisions, including organizational structure(s), the decision to automate tasks, as well as the assignment of people and means to the organizational structures [67].

The notion of OIV expresses a category of design decision(s) for enterprise implementation [67]. It is a variable in the sense that its value can be different for different implementation alternatives. Some examples of the \(\sim \)30 of such OIVs [67] include:

  • Deciding on work locations and organizational units – e.g., which branches and departments exist;

  • Deciding upon functionary types and the authorization that describes which functionary type fulfills which actor role(s) or deals with which agendum kind(s), since it is common practice to authorize persons to fulfill functionary types and not actor roles directly—e.g., the functionary type ‘cook’ that fulfills both the actor roles ‘order baker’ and ‘stock controller’; or the functionary type ‘deliverer’ who is authorized for the acts ‘promise’ and ‘declare’ of the transaction kind ‘order delivery’ and also for the act of ‘accept’ for the ‘order payment’ transaction kind; and

  • Deciding on the order of working and logical units of work–e.g., should delivery only be done after receiving payment (as common in retail) or is it (also) possible to pay afterward (more common in B2B), and should receiving of payment and delivery be seen as a single unit of work that should be carried out by the same person without interruptions.

The implementation of an enterprise, and therefore the specific value chosen for the OIVs, will change far more often than the products and services it delivers. For example, the actor roles ‘order completer’ and ‘order baker’ are stable notions in a pizzeria, just as the act ‘accept order payment’; what might change often is the authority of a functionary type—answering questions such as ‘should we combine the actor roles of order completer and order baker into one functionary type in the first months of opening our new pizzeria branch, while later we might distribute these responsibilities over the functionary types ‘sales’ and ‘baker’?’ or ‘should we take the responsibility for accepting order payments away from our functionary type deliverer and move it to an automated web agent under the (outsourced) responsibility of a payment service provider?’.

For an agile enterprise it is priority that frequently occurring changes, typically implementation design decisions, are not on its critical path. Ideally it should be possible to make such changes with no or only little impact in the supporting software. This may show the need for an implementation to be easily adaptable in some variables, while for other variables it is not necessary to change its value easily. For instance, departments may be rearranged yearly, while work locations may be more stable. OIVs offer the possibility to make explicit the enterprise’s implementation design decisions that need to get a place in software and/or to make an explicit requirement that (some) values should be (easily) changeable in the software.

At the same time, the variability can be quite high, making it difficult to gain overview and impossible to support all implementation possibilities. With the simplistic assumption that each of the 14 (out of the 30) OIVs that can be changed independently can have three different values each, the total number of possible implementation alternatives is already \(3^{14}\approx 4.8*10^{6}\) for each transaction kind—a problem for both human understanding and automation. It is thus necessary to make conscious choices on what changes should be supported by the supporting software systems and to what extent.

3.3 Low-code technology

The term ‘low code’ was first coined by Forrester in 2014 [96]. Although some say it is neither clear what low code exactly is, nor that its features are very new [9, 15], low-code development platforms claim to enable creation of software with less effort compared to traditionalFootnote 15 programming [121]. It builds upon existing concepts including MDSD, code generation and visual programming [21]. Claimed benefits of low-code technology include [49, 74, 98, 100, 108] a) less hand-coding, faster development, and, as a result, cost reduction in both development and maintenance, as well as a shorter time-to-market; b) complexity reduction by using pre-built components; c) the ability for non-technical people to create applications, thus opening up the possible population for application development as well as improving business and IT collaboration while increasing IT productivity, and d) enabling digital transformation and increasing IT and business agility.

While low-code platforms support technical flexibility such as changing from one database to another, they do not prevent developers from hard coding (implicit) implementation design decisions [10]. Other mentioned disadvantages of low-code technology include poor scalability, performance, vendor lock-in and limited creativity and customizability [108]. There is however also research that argues against these disadvantages or that shows that the practical implications of these disadvantages is non-existent [38, 49, 97, 127].

Fig. 8
figure 8

Low-code metamodel

Full size image

Low-code platforms, including Mendix, rely on three central concepts (see Fig. 8): a) data, b) logic (also called action or (micro)service), and c) and interface (Application Programming Interface (API) and screen) as well as their interrelations and permission (or access control) rules for user roles to allow users with certain roles to use these parts of the application.

Compared to traditional programming languages like Java and.Net, that mainly rely on the concepts of class and method, the set of low-code concepts is richer and closer to the business, making it easier to, e.g., connect the information need of a user to an interface to retrieve and show the corresponding data. The Mendix metamodel is a specialization of the generic low-code concepts (see Table 4).

Table 4 Mendix (metamodel) units as specialization of the generic low-code concepts
Full size table
Table 5 Mapping from DEMO metamodel (concept) to Mendix metamodel (unit)
Full size table

4 Mapping

The mapping is based on the DEMO metamodel as provided, extended with the concept of Organization Implementation Variable, and can be found in Table 5. The result of applying the mapping function to a DEMO model is a full-functional Mendix app containing a data model (and database), (basic) CRUD (Create, Read, Update, and Delete) screens, a security model so that users can only access the parts they are authorized for, several workflows to support the DEMO CTP, and (business) rules for the evaluation of DFSs and truth parts of the ARSs. It is fairly easy to add APIs on top of the data model and/or logic to expose data or function to other applications. In the process of creating the mapping, several design decisions have been made that are reported below.

  1. D1

    Transaction Kinds are not mapped. Instead, their associated Product Kinds are mapped to an Entity in order to be able to capture the state of a transaction, see D4.

  2. D2

    For Multiple Transaction Kinds (MTKs) it is usually not needed to capture the coordination acts around these facts, so no mapping is needed. The production facts in the MTK are present in the FM and mapped accordingly to a Mendix unit, see D5.

  3. D3

    As the page for showing the agenda for an actor is a very generic functionality, it was decided not to generate it but to built it in Mendix as a reusable component (module). The logic to support the state machine representing the Complete Transaction Pattern is also built as a generic module. The details of this module are not part of this article as they merely build upon earlier research [41, 60, 61, 111]. The development of this module has started before Mendix launched its native workflow capabilities, that has the potential to reduce complexity of this module.

  4. D4

    Transaction.Proposition is an Entity that is part of the generic module handling the CTP. By extending it, the generic state machine can be used, but it can also be related to the specific entity or entities the Product Kind is about, i.e., the variables in the Product Kind.

  5. D5

    For out of focus Entity Types in the FM, the decision has to be made whether the data is stored within the generated application, or used from another source, typically through an API. For the latter, in Mendix an external entity can be created, but it requires the API to be available in ‘Mendix Connect’.Footnote 16 As this functionality does not seem available (yet) through the Mendix SDK, it was decided to not use that it. Instead, some basic CRUD pages were created in order to view and modify the data. It is fairly easy in the generated application to change this later.

  6. D6

    There were not enough example DEMO models to provide a mapping for the generalization and specialization Entity Types.

  7. D7

    DEMO Attribute Types can have different kinds of Value Types. If the scale sort of a Value Type is categorical, the Value Type can either be mapped to a Mendix Enumeration or Entity. The DEMO Attribute Type using the Value Type will then either be a Mendix EnumerationTypeAttribute or Association. If the scale sort of the Value Type is of some other type, e.g., day, money, etc., the DEMO Attribute Type will be mapped to some specific Mendix (primitive) AttributeType, e.g., DateTime, Decimal, etc. As this mapping is purely a matter of (software) implementation, it is put into a separate descriptor file.

  8. D8

    Calculated Attribute Types need to be calculated, for which currently a so-called Microflow is created. The (mathematical) definition of the calculation (as defined in a Derived Fact Specification) needs to be implemented in that Microflow, of which the mapping is too extensive and detailed for the scope of this article. A decision that goes along with this choice is that from a performance perspective one would like to be able to decide whether this calculation is performed on read or on save. The low-code approach applied in this research makes it easy to make such a decision in the platform, as it currently seems too difficult to include this aspect into the mapping.

  9. D9

    For the handling of Action Rules, a Mendix Action Button for the User Role that has to deal with the agendum (kind), a Mendix Page to see all the relevant information to decide on a response, as well as one or more Mendix Action Buttons for the different choices are generated. In this way, the autonomy of the actor(s) involved is respected, and only the parts for retrieving, and possibly calculating, all the information are automated. The mapping of the assess part is similar to that of a Calculated Attribute Type and thus a similar reasoning holds as described in D8.

  10. D10

    In this research the principle is adopted that OIVs should be adaptable at run-time, and therefore this concept is mapped to a Mendix Entity, including basic CRUD pages to edit the value, i.e., design decision, of a certain OIV in the running application. The different values of such an OIV can have impact on authorization, redirecting and handling of a (C-act), and much more. This is considered to be part of the logic and state machine and supports the choice for low-code technology as target platform because it easier to build this into the state machine than into the mapping. At the same time, in Sect. 3.2 it has been shown that the possible number of configurations grows exponentially with the number of OIVs and, as a result, incorporating OIVs into the state machine might turn out to be a \(\mathcal {N\!P}\)-hard problem.

Fig. 9
figure 9

CSD for social housing

Full size image
Table 6 TPT for Social Housing
Full size table
Fig. 10
figure 10

OFD for Social Housing

Full size image

5 Implementation and evaluation

As part of the design cycle of DSR, the mapping has been evaluated on three cases: a) the academic cases EU-Rent [83, 88] and Volley [27], and b) the real-world case Social Housing [66, 89]. At first, this mapping was executed manually, while later a TypeScript reference implementation (automated converter) of the mappingFootnote 17 was created to allow for easy validation with several DEMO models. Every transformation that was performed with the mapping provided feedback on the correctness and completeness of the mapping. This resulted in several iterations that evolved, improved and enhanced the mapping and its reference implementation so in order to able to deal with all the required concepts as outlined in Sect. 4. The reference implementation eased the process of code generation and evaluation of the mapping; a major redesign of the mapping or its reference implementation was never needed.

Currently the mapping and its reference implementation are being evaluated with two other real-world cases from two other organizations. Up until this moment, no changes had to be made to the mapping nor its reference implementation. As an illustration, in the next sections the input and output for the Social Housing case that was part of the evaluation is shown.

Table 7 DFSs for Social Housing
Full size table
Table 8 ARS01 (executed by TAR01) for Social Housing
Full size table

5.1 Social housing

Social Housing is the domain where houses with low(er) rents are provided to people with little or no income. It is of particular interest of ICTUFootnote 18, as it’s being reorganized every few years and many parties are involved. It is desirable to have an application, for the support of relevant processes within this domain, that can easily be changed to accommodate changes in the responsibilities of the parties involved. In the Social Housing domain two main areas can be discerned: a) the registration of a home-seeker as a member, and b) assigning a house to the member. The focus for the evaluation was on the first.

5.1.1 DEMO models

The CSD (Fig. 9) and TPT (Table 6) reveal the starting, periodic renewal and ending of a registration. Starting the registration is initiated by the (aspirant) member and executed after the registration fee has been paid. Every year the registration is renewed against payment of a renewal fee. Ending a registration can be initiated by the member–e.g., when moving to another area–or by the Social Housing organization–e.g., in case of (repeated) non-payment of the renewal fee. The model shows that actors in this domain need access to facts about costs and terms, and about persons and (their) living, abstracted from how access to these facts is arranged.

The OFD (Fig. 10) shows the registration as core entity type, and the starting and ending of a registration as product kinds. Additionally, the entity type person is shown –gray-colored and thus out of focus, as persons are not created within this domain–including the property type that a person is the member and/or payer of a registration. The value type {year} is included to express a) the product kind of annual registration payment, b) the definition of the (aggregated) entity type registration \(\times \) {year} for the product kind ‘annual registration payment’, and c) several decisions taken yearly – modeled as attribute type of {year}—such as the standard registration fee. In deciding upon starting a registration, (derived) facts about the existence of one or more active registration(s) for and the age of a person are needed; Table 7 shows the DFSs to calculate those.

Action rules guide actors in their decisions. Table 8 shows the ARS for the registration starter (AR01) to settle the agendum kind registration starting is requested (TK01/rq). This action rule says to assess that the participants are authorized to play their (performer and addressee) role in this request, that the (aspirant) member is at least 18 years old and Dutch, that the (aspirant) member doesn’t have an active registration at the starting day of the new registration, and that the starting day is in the current year or later—the latter implies one can start a registration retrospectively, but limited to the current year. If the assessment yields a positive result, normally the registration starter can proceed to request the (aspirant) member to promise that the registration will be started; otherwise the registration starter normally should decline to do so. As an action rule is not fully deterministic, the registration starter remains free to—responsibly!—deviate from this rule. For the chosen focus within the Social Housing domain, 11 ARSs have been defined.

Fig. 11
figure 11

Chosen OIVs for social housing

Full size image
Fig. 12
figure 12

Project outline of the generated Mendix application for Social Housing

Full size image

5.1.2 Organization implementation

Having explored the (stable and implementation independent) DEMO model for the registration part of the Social Housing domain, the enterprise implementation and its desired flexibility has been elaborated. As mentioned earlier, within the domain of Social Housing, it is important to be able to easily shift responsibilities between organizational units and functionary types. In terms of organization units, actor roles can shift from one social housing association to an umbrella of social housing associations, or to a municipality, or may be in the future as a collaboration of municipalities. The authorization of a functionary type to fulfill one or more actor role(s) shifts regularly, due to changes in required education and competence level, compliance requirements and labor market opportunities or constraints. Finally, as it is common practice to install persons to fulfill functionary types (and not actor roles directly), it was decided to choose the following OIVs from the collection of OIVs [67] as the OIVs that should be easily changeable in the supporting software.

  • Organizational Unit, e.g., ‘City of Amsterdam’ and ‘Woningnet’;

  • Functionary type, e.g., ‘Civil Servant Social Housing’ and ‘Customer Contact Manager’;

  • Authorization, e.g., functionary type ‘Civil Servant Social Housing’ in organizational unit ‘City of Amsterdam’ is authorized to settle agendum kind ‘TK01/rq (registration starting is requested)’ and ‘Customer Contact Manager’ in organizational unit ‘Woningnet’ is authorized to settle agendum kind ‘TK01/rq (registration starting is requested)’; and

  • Installation, e.g., person ‘George’ is installed as functionary type ‘Civil Servant Social Housing’ in organizational unit ‘City of Amsterdam’ and person ‘George’ is installed as functionary type ‘Customer Contact Manager’ in organizational unit ‘Woningnet’.

This is summarized in Fig. 11 that shows the FM of the implementation. This model can be extended with product kinds (and related transactor roles) to show the process of creating an implementation (design), as suggested in [28].

5.1.3 Generated low-code application

Figures 13 and  14 show the input JSON files for the automated converter that uses these files to generate a Mendix application. Figure 12 shows the project folder of the generated Mendix application, containing pages with buttons, microflows and enumerations. Figure 15 shows the generated domain (data) model consisting of entities, attributes and associations. It also shows the generic (computed but not persisted, therefore orange-colored) entity AssessmentResult that will be used in the microflows (see below). Additionally, the needed user roles are created and all Mendix units have the proper access rules so that only authorized users can see and/or mutate the data and/or use the functionality provided through screens. Figure 16 shows how the truth part of ARS01 (Table 8) was implemented in a Mendix microflow and Fig. 17 shows a screenshot of the running application where an actor with the right authorization can deal with a C-act of kind TK01/rq.

Fig. 13
figure 13

DEMO model for social housing in JSON format

Full size image
Table 9 Limitations of the DEMO to Mendix mapping, structured according to [5] (part 1)
Full size table
Fig. 14
figure 14

The app descriptor file for the DEMO model for Social Housing in JSON format, containing the name of the application to be generated, the mapping from value types to software primitives, and the OIVs to be taken into consideration

Full size image
Fig. 15
figure 15

Domain (data) model of the generated Mendix application for Social Housing

Full size image
Fig. 16
figure 16

Mendix implementation of the ‘truth part’ of ARS01

Full size image
Fig. 17
figure 17

Screen for AR01 to deal with TK01/rq

Full size image

5.1.4 Achieved flexibility

As the software is easily regenerated from a changed DEMO model, the approach as suggested in this article supports changes in the enterprise’s ontology. One could, e.g., easily add the transaction kinds for the assignment of a house, or change the (business) rules of ARS01.

Moreover, by generating a run-time configurable item for each chosen OIV, the resulting application is intrinsically adaptable with regard to implementation design decisions for a given enterprise’s ontological model. Specifically for the Social Housing case, it made it possible for the enterprise designer or HR-employee to ‘configure’ their (implementation) design decisions about “which actor roles are fulfilled by this functionary type” and “which person is fulfilling which functionary type (and at what moment)” directly in the (running) application, without needing to specify it for a developer or translate it to more technical terms such as ‘user role’ or ‘permission rule’, and without the need to rebuild or redeploy the application. The approach as suggested in this research thus supports both changes in the enterprise’s ontology and its implementation.

6 Limitations

In this section we briefly reflect on the limitations of the research as reported on in this article. As we have followed a DSR approach, we use the typology of DSR limitations as suggested in [5] as a way to structure these reflections. The authors of [5] have based this typology on a structured literature review into “self-reported” limitations on design science artifacts. The resulting typology identifies 19 types of limitations which the authors of [5] have grouped into four categories based on [13].

It is also important to note that (self-reported) limitations do not necessarily have an immediate relation to the quality of the designed artifact. Described limitations also clarify and document the limitations one should be aware of when using the artifact in practice, or as a base for further development of a similar artifact; just like the Medication Guides that come with medicines. Using this typology as a base, Tables 9, 10 and 11 summarize the limitations of the created mapping from DEMO to Mendix.

Table 10 Limitations of the DEMO to Mendix mapping, structured according to [5] (part 2)
Full size table
Table 11 Limitations of the DEMO to Mendix mapping, structured according to [5] (part 3)
Full size table

7 Conclusion and further research

In this paper, we investigated the potential benefits of using DEMO ontological enterprise models, supplemented with explicit enterprise implementation design decisions, captured in OIVs, as a semantically rich base for MDSD. As a first step to show this benefit, we focused on the design of a mapping from DEMO models to Mendix for the (automated) creation of a low-code application that also intrinsically accommodates run-time implementation design decisions.

By introducing the concept of Organization Implementation Variable into the MDSD (code generation) process, the mapping from enterprise implementation design decision to software implementation is made transparent, thereby not leaving it up to developers to make the (right) choice. Moreover, by generating a run-time configurable item for each chosen OIV, the resulting application is intrinsically adaptable at run-time with regard to implementation design decisions for a given enterprise’s ontological model. This run-time configurability of implementation decisions has shown to support, or even improve, enterprise agility [89]. Moreover, for new products and services, the resulting (Mendix) application can easily be (re)generated from its changed DEMO model. The approach as suggested in this research thus supports both changes in the enterprise’s ontology and in its implementation. In this section the conclusions and future research are further detailed.

7.1 Conclusions

Given the choice for Mendix as low-code target platform, a mapping from the complete DEMO metamodel, including enterprise implementation, to the Mendix metamodel has been designed. This mapping is implemented in TypeScript, using the Mendix SDK, in order to generate a readily deployable low-code application from the DEMO ontological model of an enterprise, including the support for run-time configurable OIVs. In doing so, a reusable component in Mendix is created to support the CTP as well as for showing relevant agenda to the actors that have to deal with them.

One advantage of the proposed approach follows from the use of the DEMO ontological enterprise model as the starting point. Since these models are claimed to be of high quality, i.e., coherent, comprehensive, consistent and concise, the generated software is of high quality and only contains the necessary constructs to support the enterprise end users.

As (parts of) the software are simply (re)generated when new transaction kinds arise, the proposed approach supports some level of enterprise agility. By adding OIVs to the MDSD approach, it becomes possible to change a predefined set of implementation design decisions at run-time, therefore allowing for even more agility for the enterprise as software development is not a limiting factor anymore in changing the enterprise.

Another advantage of this approach is that the generated application model can be adapted easily through the low-code visual paradigm. This allows for changes in the user interface,, to make use of APIs, or to implement the execution of the action rules or calculations in a more efficient way. A warning should be given that changes in the generated output model can become a source of hidden design decisions.

Reflecting on the MDSD approach as applied in this research, by making explicit the required enterprise implementation flexibility and giving it a specific place in the generated application model, the notions of software adaptability and enterprise agility have been connected, thereby at least improving the latter. As the application can be regenerated easily, changing the software is not the limiting factor anymore in changing the enterprises service and product portfolio or its implementation.

7.2 Future research

As already hinted at in the discussion of the limitations (Sect. 6), further work is called for. With regards to the limitations of type L13 (Limited performance), we, respectively, foresee:

  1. a)

    There is a need to better detail the generic DEMO metamodel, containing only the true DEMO concepts and separating the core of DEMO from the purpose-specific information such as visualization or code generation.

  2. b)

    To arrive at (low-)code that remains readable and understandable by humans, it is important to generate meaningful application names and other mappings to relevant software primitives. More work is needed to understand what exactly is needed on top of the DEMO model to generate a working and meaningful application.

  3. c)

    The mapping does not include mapping rules for generalization and specialization Entity Types from the DEMO Fact Model. More cases are needed to be able to define such a mapping.

  4. d)

    The mapping from Derived Fact Specifications and Action Rule Specifications to a Mendix microflow is not straightforward. It is suggested to further detail that mapping for all possible DEMO constructs. Possibly, it turns out to be easier to manually perform such a mapping case-by-case than to generalize it to an automatable mapping.

  5. e)

    More work is needed regarding the implementation of OIVs in Mendix, and software in general. It is not clear whether all OIVs can be implemented completely independent of others, as suggested by Normalized Systems theory [75]. More case studies are needed, involving more OIVs, to fully understand the complexity of this problem.

  6. f)

    Currently, one Mendix application is created for a given DEMO model. For bigger enterprise models, i.e., larger cases, it might be desired that a portfolio of several separate, but connected, applications is generated. One solution is of course to split up the DEMO models and generate an application for each separate model (part). Another solution is to create a sort of microservice landscape with small applications, perhaps on the level of a single transaction kind, as suggested by several authors [66, 86, 116]. It is worthwhile to find out what level of granularity would be optimal and how to introduce the splitting of an enterprise model into different applications.

As stated for limitation type L16, it is hard to compare the MDSD approach as applied in this research to ones that use a different kind of input, such as BPMN or UML. There does not seem to be a generic framework to do these kind of comparisons, especially when both input and output is different. It could, therefore, be interesting to research ways to compare different approaches toward MDSD.

The current mapping is clearly specifically targeted toward the Mendix platform (see L19). Although other low-code platforms rely on similar concepts, the question arises whether the mapping can be abstracted to facilitate other low-code platforms, or even high code. This conforms to the need to (better) distinguish between the PIM and PSM as defined by MDA. Further research is needed to get a perspective on the feasibility and usability of such an abstraction.

Next to that, new features of the Mendix platform also provide opportunities for future improvements of the mapping:

  1. a)

    Mendix has recently launched native workflow capability in the platform. As the majority of the current mapping and its implementation was set up before that time, it does not use this feature. It could be interesting to look into these possibilities and see how it can support the CTP. As this component is created as a generic component, it is easy to rebuild without impacting the model converter.

  2. b)

    Mendix has recently also introduced ‘Mendix Connect’, that eases integration with (existing) external (data) sources through APIs. As it does not seem to be available in the SDK, it is not incorporated in the TypeScript implementation of the mapping. It could be interesting to see how this feature can be used to accommodate integration of external data.

Finally, the use of Large Language Models (LLMs) and (generative) Artificial Intelligence (AI) in software development is growing fast [99]. And while there are several potential advantages of such an approach, including increased efficiency and accuracy,Footnote 19 it is unlikely that it will fully replace software developers in the near future, thus still allowing for implicit hard-coded implementation decisions. Moreover, these techniques are black-box, i.e., it is unknown how exactly input is transformed into software. This is a great issue in situations where traceability is needed, e.g., when executing laws, something that is easily achieved with MDSD in general, and the MDSD-based approach as applied in this research. Use cases where LLMs and AI could be able to add value to the outlined approach:

  1. a)

    Enhance modeling tools so that similar advantages as for software development can be achieved, but on the level of enterprise modeling;

  2. b)

    Transform text (prompts) into an enterprise model to allow users to create an enterprise model without having to learn the specific modeling language;

  3. c)

    Support the making of implementation optimization decisions.

These use cases are on the level of creating the input model (CIM; in our case: DEMO) and it would be interesting to see how such approaches can be integrated into the approach as outlined in this research to create a wider-scoped approach for enterprise (model-driven) software development.