2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)

2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C) | 978-1-6654-2484-4/21/$31.00 ©2021 IEEE | DOI: 10.1109/MODELS-C53483.2021.00016

In Search of the Essence of Low-Code: An

Exploratory Study of Seven Development Platforms
Alexander C. Bock Ulrich Frank
Research Group Enterprise Modeling and Information Research Group Enterprise Modeling and Information
Systems, University of Duisburg-Essen Systems, University of Duisburg-Essen
Essen, Germany Essen, Germany
[email protected] [email protected]

Abstract—Rapidly growing attention has been directed in nascent literature are not unlike those of IT vendors and market
recent years toward a type of software development and exe- research companies (see, e.g., [2] [3] [4]).
cution environment now passing under the name of ‘low-code Notwithstanding the ebullient rhetoric, there can be no doubt
development platforms.’ The fundamental claim is that limiting
traditional coding mechanisms in favor of a variety of alternative that the goals intended to be served by low-code development
means of design and specification yields substantial efficiency platforms are important. Indeed, these goals—among them,
gains in professional and private software development. But increasing productivity, reducing costs, promoting system
although much stir at present surrounds low-code development adaptability, and empowering users—are classical goals of
platforms, it is by no means clear what, if any, features are professional software development, and they have been at
distinctive of these systems, and whether any of these features
mark out a technology which can be considered original. This pa- the center of software engineering and information systems
per presents an exploratory study of seven low-code development research since the founding of the disciplines. Moreover,
platforms, with the aim of discovering their essence and assessing although vendors rarely state so in explicit terms, it would ap-
them critically in the light of research in information systems pear that low-code platforms substantially draw on principles
development. An analysis framework covering a number of from model-driven development, a topic which has occupied
criteria regarding professional information systems development
is used to characterize the selected platforms, and to point the attention of software engineering researchers for decades.
out features commonly, occasionally, and rarely possessed by But despite the stir over the low-code trend, there is a
them. The study reveals that hardly any features of low-code glaring scarcity of information and consensus regarding the
development are innovative in and of themselves, with novelty actual technical distinguishing features of low-code devel-
primarily consisting in their combination and integration. Still, opment platforms. As soon as one descends from the level
we argue in conclusion, a number of research opportunities can
be made out with an eye on the leitmotif of low-code development. of broad slogans to that of concrete technical capacities,
it is surprisingly difficult to find consistent and substantive
Index Terms—Low-Code, Information Systems Development, descriptions of what constitutes these systems. This paper is
Integration, Reuse, Abstraction. intended as a contribution to the search for the essence of
low-code development platforms.
I. I NTRODUCTION More precisely, this paper has two goals. The first is to
‘Low-code development platforms’ (LCDP) are said to present the results of an exploratory study of the features of
offer a number of advantages over classical approaches to seven low-code development platforms available on the current
software systems development. One dominant claim is that market. The aim of this study is provide an overview and
low-development platforms can contribute to the efficiency comparison of the technical capacities and functionalities of
of software development, indeed, that they hold the prospect these products now sold under the heading of ‘low-code.’ The
of undercutting the costs of traditional software development investigation is governed by an analysis framework covering
projects by a significant margin. Another recurring claim is several major segments of software development. The second
that low-code development platforms can be of utility both goal is to assess the revealed scope of low-code development
to professional software developers and lay users unfamiliar platforms in relation to research on software development
with information technologies (IT), with the latter often be- productivity and end-user computing. The findings reported
ing portrayed as ‘citizen developers.’ For example, Gartner here form part of a larger continuing study of ours on the
has, in characteristic tone, touted that “Enterprise low-code scope and limits of LCDPs [5]. Taken together, our work is
application platforms deliver high-productivity and multifunc- intended to furnish insights on the essence of low-code, and to
tion capabilities across central, departmental and citizen IT critically appreciate the trend in the larger context of software
functions” [1, p. 1]. For some years, the discussion of low- engineering and information systems development.
code systems has been limited largely to the practical sector, The paper proceeds as follows. In order to provide the
before it caught the attention of researchers. Notably, the appropriate context for our study, we begin, in section VI, with
tone and the unfettered optimism of some authors in this a brief overview of related research. In section III, we explain

978-1-6654-2484-4/21/$31.00 ©2021 IEEE 57

DOI 10.1109/MODELS-C53483.2021.00016

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
the method, the selection process, and the analysis framework Software development productivity is also promoted by a
informing the exploratory study. Section IV presents the variety of facilities for the automatic transformation of design
findings of the study, discussing the historical background, a artifacts into executable representations. Among such trans-
basic classification, and the functional features of the chosen formations are mappings of object models to code, mappings
platforms. In section V, we discuss the key findings and the of workflow models to schemata for workflow management
limitations of our study, and in section VI, we propose routes systems (WFMS), and mappings of data/object models to
for future research. The paper concludes in section VII. data base schemata. Research on model-driven development
has similar but wider aims, seeking to help generate entire
II. B RIEF OVERVIEW OF R ELATED R ESEARCH software systems from models [9] [10]. The objective is to
The search for the essence of low-code platforms is closely drastically reduce the need for coding. As another example,
linked to the question of their relation to prior research. Are domain-specific frameworks are similar to reference models
LCDPs designed on the basis of existing research on software in that they aim at enabling reuse in multiple specific cases
design and engineering? Are their components innovative in through adaptation. Different from conceptual models, how-
comparison with available methods, tools, and instruments? ever, a frameworks are incomplete software systems [11] [12].
The following overview is intended to provide a foundation Prominent examples of domain-specific frameworks include
for discussing these questions after the presentation our ex- skeleton enterprise systems for the financial industry [13], and
ploratory study. Of course, space forbids a comprehensive frameworks which can be tailored into individual webshops.
survey, so focus will be placed on a few salient approaches.
B. Focus on Empowerment
A. Focus on Productivity Enabling non-programmers to develop software requires
The essential driver of software development productivity is the provision of accessible representations which abstract
reuse. Artifacts that support reuse require abstractions, hence, away from the technical details of programming languages
models representing invariances among a range of systems. and other development facilities. Typical examples of such
In addition, reuse also requires concepts for cost-efficient and details are the dichotomy between types and instances, or
safe adaptation to individual requirements. Among the promi- graphical user interface (GUI) implementation patterns. Two
nent approaches addressing these aspects are the following. main approaches have evolved. The first seeks to provide users
Conceptual models are a pivotal means for the representa- with a general, but simplified model of computing and the
tion of domain knowledge in software development. However, accessible, often graphical description of individual programs.
the effort involved in constructing conceptual models from The field of ‘end-user computing’ or ‘end-user development’
scratch can be considerable. Two approaches are especially [14], which aims at “empowering end-users to develop and
suited to meet this challenge, both of which are based on adapt systems themselves” [15, p. 1], subsumes several lines
reuse. Reference models are supposed to describe the states of research following this strategy. Prominent among these are
of affairs in a larger domain, such that they can be adapted ‘programming by example’ [16], ‘model-based development,’
into models of a whole range of particular systems. The adapt- where the hope is that a user “just provides a conceptual
ability of reference models to situation-specific requirements description of the intended activity to be supported and the sys-
depends on the abstractions involved. In the case of data or tem generates the corresponding interactive application” [15,
object models, generalization is an attractive option, because p. 4], as well as various strategies relying on customization.
specialization, as a monotonic extension, does not compromise Visual programming, too, aims at abstracting away from the
the original reference models. Process models, however, bulk formalistic appearance of classical program code [17] [18].
against generalization [6]. For this reason, other approaches The second principal approach, which may be combined
have been proposed to express commonalities among process with the first, aims at providing users with concepts mir-
models, such as ‘behavioral profiles’ [7] and ‘families’ of roring their familiar technical terminology, as well as with
process variants [8]. Apart from controlled adaptation, any functionality tailored to the class of domain-specific tasks
modification is conceivable that can be expressed in the for which they are responsible (e.g., accounting, procurement,
underlying modeling language – at the risk of jeopardizing or sales). Apart from domain-specific application systems for
the integrity of a model. user-driven adaptation, the most important realization of this
Domain-specific modeling languages (DSMLs) are model- general strategy are the already mentioned DSMLs.
ing languages whose concepts are intended as reconstructions We return to some of the described approaches after the
of the technical terminologies used in certain domains. Thus, presentation of the main results of our study.
they free designers from defining domain concepts themselves.
In addition, they support the construction of consistent models, III. M ETHOD AND A NALYSIS F RAMEWORK
because they restrict the scope of possible models or systems The purpose of this section is to describe the research
in accordance with domain constraints integrated into the approach of the present study. We first describe, in general
DSML. It is possible to couple the use of reference models terms, the method, and the assumptions underpinning the
and DSMLs so as to yield an especially powerful foundation work reported here (subsection III-A). Afterwards, we present
for reuse and adaptation. the analysis framework by which we have characterized the

58

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
chosen LCDPs (subsection III-B), and we will explain the TABLE I
A NALYSIS F RAMEWORK
considerations which have guided our selection of platforms
for investigation (subsection III-C). Category Criterion

A. Method and Assumptions Static Pers- Mechanisms for data structure definitions
pective Data modeling component
The essential aim of the following exploratory study, as Internal databases and persistence mechanisms
stated in the introduction, is to obtain an overview of the Access to external data sources (APIs)
Data reference models
technical capacities and functionalities of a number of products Adaptation mechanisms for data (reference) models
marketed with reference to the label ‘low-code,’ and to reveal Dynamic Mechanisms for program flow specifications
the degree to which these features are common to the different Perspective Process modeling component
platforms. The principal method of investigation has been to Integration with static/functional components and artifacts
Process reference models
examine and assess the chosen LCDPs with regard to a set Adaptation mechanisms for process (reference) models
of technical criteria recorded in an analysis framework. The Functional Mechanisms for functional specifications
sources contributing to the design of the framework will be Perspective Functional modeling component
Generic functional reference specifications
explained in subsection III-B. Domain-specific functional reference specifications
As also stated at the outset, the findings reported in this Adaptation mech. for functional (reference) specifications
paper form part of a larger, ongoing study on the scope and GUI Design GUI design component
limitations of low-code environments in the current market [5]. Graphical GUI editor
Automatic generation of GUIs from data structures
In this paper, we present the results of an analysis of seven GUI reference models
LCDPs, whose selection will be explained in subsection III-C. Roles and Specification mechanisms for roles and users
Our complete project covers some additional platforms, and it Users Modeling component for roles and users
also involves a more detailed presentation of each of them Artificial Internal AI components
than is possible in the present paper. We are aware of only Intelligence Integrability of external AI services
one other published study of low-code platforms [19]. The
aims and results of that study, in part, coincide with ours. But
our concern is less with the comparison of individual LCDPs, with respect to the same aspects of a domain of interest. In the
and more with a critical appraisal of their main features and present study, the domain is that of the design, implementation,
their place in the context of software engineering research. deployment, and maintenance of software systems.
The technical review of all platforms has been conducted The specific analysis framework developed for, and used in,
by the authors of this paper. All platforms were assessed our study is shown in table I. As is apparent, the framework
in practical terms by accessing, and working in, the live contains 24 criteria in six categories. The design of the
development and execution environments, to which access was framework had two major kinds of sources, which might
obtained in the form of evaluation licenses. In no case, to be described as deductive and inductive in nature. First, one
the best of our knowledge, did the licenses impose significant part—indeed, the majority—of the categories and criteria of
restrictions on the availability of features relevant for our the framework were defined, deductively, in orientation to es-
study. Among the steps involved in the technical examination tablished perspectives and principles in software development.
were the open exploration of the environments, the search for For example, the first three categories of the framework—
specific types of functionality, the development of small-scale static perspective, dynamic perspective, and functional per-
example software solutions, as well as the consultation of the spective—are three well-known, traditional perspectives on
official documentations and additional educational materials systems design (see, e.g., [20, sect. 103.3]). As another ex-
provided by the platform vendors. It is our assumption that ample, the first four categories all include criteria concerning
it has been possible to ascertain the essential capacities and the availability of reference models, or of similar types of
characteristics of the studied platforms. However, no doubt reference specifications. These criteria have been defined in
some details of the platforms as well as some modalities of view of the striking importance of reference artifacts in soft-
their practical application must remain unconsidered due to ware productivity research, as explained in section II. Second,
our mode and scope of investigation. These limitations will some other categories and criteria were defined, inductively, on
be discussed in subsection V-B. Furthermore, some of our the basis of the actual features and components offered by the
analysis criteria do not lend themselves to easy assessment platforms. For example, the last category, artificial intelligence
using a simple n-ary evaluation scale. Cautionary remarks will (AI), was defined primarily because some of the products make
be given in the remainder of this section where relevant. it possible to use AI services of varying characters.
While most criteria of the framework are self-explanatory,
B. Analysis Framework some additional clarifying remarks are in order. As is seen
The investigation of the platforms has been governed by in table I, we have sometimes defined separate criteria for
an analysis framework defining a set of criteria in several the availability of ‘mechanisms’ and ‘modeling components’
categories. As is common practice, this was with the intention for the same purpose. By the former, we mean any kind of
of ensuring that all analysis objects are assessed consistently specification mechanism, including simple dialog forms or

59

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
table structures. By the latter, we mean graphical modeling TABLE II
S ELECTED LOW- CODE DEVELOPMENT PLATFORMS
components, based either on proprietary or common modeling
languages, for example, the Entity-Relation Model (ERM). Label Platform
This distinction is made because sometimes, platforms offer LC1 Microsoft PowerApps
the former, but not the latter. LC2 Mendix
It is also seen that we consider, in several categories, LC3 Appian
LC4 Wavemaker
the availability of adaptation mechanisms for self-defined or LC5 Pega
vendor-supplied (reference) artifacts and models. The point of LC6 Quickbase
this criterion is that adaptation mechanisms may be provided LC7 Bonita Platform
with different degrees of sophistication. For example, in a
simple case, it might only be possible to apply certain basic
modifications to an existing artifact (e.g., adding or deleting products of such large vendors as Microsoft, Mendix, Appian,
activities in an existing process model). In more sophisticated and Pega, but also the solutions of such smaller companies
cases, this process might governed and supported by a variety as Wavemaker, Quickbase, and Bonita. Another criterion was
of additional constraints and mechanism (e.g., domain-specific the intended user population. For example, the target groups
constraints which prevent the definition of nonsensical associ- of Microsoft PowerApps, Mendix, and Appian include, in
ations). Finally, it will be noticed that the category ‘dynamic large measure, semi-professional to professional developers,
perspective’ contains the criterion ‘integration with static and whereas Quickbase is mainly marketed towards lay persons,
functional components and artifacts,’ whereas no analogous or so-called ‘citizen developers.’ Another criterion was the
criterion appears in the other two main categories. The reason general purpose or character of the platform. Although exist-
is that the integration with other perspectives is of special ing low-code platforms vary considerably, it turned out that,
importance in the dynamic realm. Process models frequently within the subset considered, it was possible to roughly dis-
need to involve references to the data structures or functions tinguish four prototypical forms. The characteristics of these
used in the process modeled, whereas the converse is not true, prototypical forms will be outlined in subsection IV-B. For
for example, of data models. example, Microsoft, Mendix, Appian, and Pega are complex,
multi-use platforms, whereas Quickbase is essentially a basic
C. Platform Selection data management platform, and Bonita is, indeed, a classical
Depending on how one counts, there are now between WfMS. In the selection process, we made sure that at least
about twenty and several dozen vendors offering products and one example of each identified form was picked out. Lastly,
services in the rubric of ‘low-code.’ It is, of course, far beyond it deserves mention that in one case, we had to exclude a
our scope, both in the present paper and in our larger project, platform initially considered an appropriate candidate, namely
to undertake an exhaustive review of all these solutions. Our Google AppMaker. The reason is that Google recently decided
study must, therefore, of necessity remain exploratory, and a to discontinue that project, replacing it with another platform.
limited number of low-code environments have to be selected The replacement, in turn, falls in the category ‘no code,’ which
for study. In the present paper, as already anticipated, we is not the subject of this study.
present the analysis of seven such platforms. Furthermore, In the service of brevity, we will henceforth use uniform
it has to be underlined that in view of the extraordinary shorthands to refer to the seven platforms, taking the form LC1
heterogeneity of products and services sold today under the through LC7 . The assignment of labels is shown in table II.
name of ‘low-code,’ no claim to representativeness or gener-
alizability can be justified. What one vendor proffers as a low- IV. A N E XPLORATORY S TUDY OF S ELECTED L OW-C ODE
code solution need not bear any connection to what the next P LATFORMS
vendor has on offer. However, having noted these epistemic We now present the findings of our study. This will be
reservations, we can say that our selection of platforms has, done in three steps. First, in order to provide a general
of course, been guided by a coordinated procedure. context, we will make some observations about the historical
Table II shows the seven platforms selected for study. The background and product positioning of the seven studied
list has emerged as follows. First of all, at the beginning of platforms (subsection IV-A). Following this, in order to give
our project, we conducted a general survey of the market, and an initial characterization, we will explain four aforementioned
we also consulted some existing market reports (such as [1]). prototypical forms, into which the platforms may be grouped
This yielded a list of close to 40 environments and services. (subsection IV-B). The main part of this section, then, reports
All of them were explicitly branded as ‘low-code’ solutions, on the analysis of the platforms in relation to the established
although, as we will point out below, most products are simul- analysis framework (subsection IV-C).
taneously marketed under multiple other labels. Our primary
A. Historical Background and Product Positioning
intention in selecting for study platforms from this sizable list,
then, was to cover a spectrum as broad as possible with regard A striking fact about all considered low-code products is
to several criteria. One criterion was vendor size and market that they have existed, in one form or another, before the
influence. For example, as is easily seen, our selection contains label ‘low-code’ was invented. The companies offering the

60

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
chosen systems have all been active in the areas of software more than lip-service.
development, business information systems, and automation
for many years, if not decades. With the exception of LC1 , B. Initial Characterization: Prototypical Forms
the solutions now marketed as low-code environments have As already suggested by the foregoing observations, prod-
been the single or primary products of the company for most ucts sold as solutions for low-code development are remark-
of that time. ably heterogeneous. They therefore do not lend themselves to
An analysis of archived versions of the vendors’ homepages definite classification. Nonetheless, it is possible to identify
revealed that most products have been further developed and certain prototypical forms of environments. These are not
repositioned over the years, being portrayed with a changing without overlap, and some products realize features of more
variety of catchwords familiar in the IT industry. Sometimes, than one of them. But distinguishing between four prototypical
the term ‘low-code’ has, in fact, replaced earlier labels and forms of low-code solutions gives a serviceable indication of
become the dominant marketing metaphor. For example, LC2 the general character of the analyzed products.
and LC4 have been previously offered mainly as solutions 1) Basic Data Management Platform: One form of low-
for ‘Rapid Application Development’ (RAD), ‘Platform as code environment is a relatively simple hybrid between
a Service’ (PaaS), and, in the case of LC2 , as a ‘Model- database management system (DBMS), GUI designer, and
Driven Application Platform.’ LC3 has a history as a tool surrounding architecture into which individual solutions are
for ‘Business Process Management’ (BPM) in general, and deployed (exemplified by LC6 ). A product of this form
as a tool for ‘Mobile’ BPM and ‘Human-Centric’ BPM in allows users to configure simple application-like environments
particular. LC6 has previously been called an ‘Online Database where users can manage data for a limited area of concern,
Software,’ building on ‘Software as a Service’ (SaaS). Now without needing to understand the details of the underlying
these products are marketed chiefly as low-code environments. database technologies. It is sometimes implied that the prime
It must be noted, however, that the significance attached purpose of such products is to replace the use of spreadsheets.
to the label ‘low-code’ varies considerably. For example, For example, a user may generate a simple application-like
whereas the term figures prominently in the marketing of the environment to manage items in a warehouse. Platforms of this
products just mentioned, it is only of secondary importance kind can largely rely on drag-and-drop components, graphical
in that of LC1 , LC5 and LC7 . At any rate, the bottom- data models, and other user interface (UI)-based mechanisms,
line is that present-day low-code solutions are rarely new almost completely avoiding the need for traditional code. This
products developed from scratch. More often than not, they is the only identified form of LCDP which can reasonably be
either extend or rebrand previously existing products, some of expected to be readily accessible to the lay person.
which have a long history on the market. 2) Workflow Management Systems: Another prototypical
Another related observation is that many solutions are not form of low-code environment is, in effect, a classical compo-
marketed solely as platforms for low-code development. To the nent of information systems, namely a workflow management
contrary, they often said to be solutions for multiple primary system (exemplified by LC7 and, in part, LC3 ). A product
purposes, which are typically expressed in the form of various of this form allows users, in familiar fashion, to construct
well-known catchwords. For example, LC3 and LC5 are also conceptual workflow models, to define GUIs, data structures,
said to be solution for ‘Automation’ in general and ‘Robot connections to external systems, and user roles, and to execute
Process Automation’ (RPA) in particular, as well as for ‘Case instances of that workflow type in a local or online environ-
Management’ and ‘Business Process Management.’ Similarly, ment. As it has always been the case with systems of this kind,
LC7 is also, and indeed preeminently, offered as a solution most (but not all) specifications can be made in user dialogs
for ‘Business Process’ and ‘Workflow’ management. and graphical representations of models. For this reason, some
Besides being presented as solutions for ‘low-code devel- WfMS vendors may have conveniently taken up the label ‘low-
opment,’ LCDPs are routinely said to offer components for code’ to profit from an existing market trend.
a variety of secondary purposes, and to contribute to a host 3) Extended, GUI- and data-centric integrated development
of more general aims, all of which are explained in terms environments: A third prototypical form of low-code plat-
of still further catch-words. For example, many products are form is an extended type of integrated development envi-
advertised as bringing components for the use of ‘Artificial ronment (IDE) that combines components for GUI design,
Intelligence’ (e.g., LC1 , LC3 , and LC5 ) and ‘Microservices’ data modeling, data persistence management, process (ap-
(e.g., LC2 and LC4 ). Also, it is often asserted that products plication logic) modeling, external application programming
assist in achieving such general aims as empowering ‘Citizen interface (API) use, and deployment support (exemplified
Developers’ (e.g., LC2 , LC5 , LC6 , LC7 ), supporting ‘Agile’ by LC2 and LC4 ). A low-code environment of this form
development (e.g., LC2 and LC5 ), and following principles of allows users to build, within the confines of a generic and
‘DevOps’ and its varieties (e.g., LC2 , LC4 , and LC7 ). usually implicit application architecture, applications of low
Thus, low-code solutions are often supposed to contribute to moderate complexity. The focus is mainly on GUI-centric,
to a number of purposes of varying clarity and technical web or mobile applications to manage and present data. In
specificity. Some of them are reflected in distinct technical the simplest case, the components of such solutions can be
components mentioned below, whereas others are given no applied without the use of classical programming languages

61

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
and similar technical specification mechanisms, largely relying to be consulted together with the following explanations and
on conceptual models and UI-based configuration. But a basic the discussion of limitations in subsection V-B.
understanding of static, functional, and dynamic abstractions 1) Common Features: Several features are offered by all or
in software development is required in any case. Also, as soon almost all of the seven analyzed solutions.
as advanced requirements need to be implemented, familiarity To begin with, the static perspective is usually addressed
with conventional technologies, or proprietary look-alikes, is quite extensively. Every considered product features a compo-
usually required, for example, Java, JavaScript, SQL, HTML, nent for the definition of data structures. In the vast majority
CSS, SOAP, and a variety of common APIs. of cases, this component is offered in the form of a conceptual
Overall, products of this form are directed at an intermediate modeling tool, implementing either a variant of the ERM or
to (semi )professional audience. They are intended to reduce some proprietary language. Sometimes, data structures can
the efforts of routine tasks in the development of web or only be defined in UI-based configuration dialogs or lists.
business applications, such as designing GUIs, implementing Another common feature falling into the static category is
the model-view-controller (MVC) pattern, defining object- the capacity to access external data sources using a variety of
relational (O-R) mappings, managing dependencies, and de- APIs. For example, the platforms all permit to access relational
ploying the solutions in different target environments. database and other persistence technologies using standard
4) Multi-use platforms for business application configura- APIs like JDBC; and each platform contains an individual list
tion, integration, and development: The fourth prototypical of so-called connectors to other types of files and systems,
form of low-code platform is the most varied and eclectic one. such as CSV files, ordinary office document types, Google
It is a multi-use platform where applications (or application- documents, and the like. The platforms are generally designed
like environments) can be configured and developed, using so that data may be stored either in an internal database
any of a variety of components, building blocks, and existing system, or in existing external systems, where the import and
systems, within the framework of an integration-oriented, export is accomplished according to user-defined patterns.
business-centric system architecture (exemplified by LC1 , Another feature possessed by every studied low-code plat-
LC3 , and LC5 ). These are invariably the solutions of large form is a GUI designer. Without exception, the platforms
vendors. Platforms of this kind involve all or most components incorporate a component to develop graphical user interfaces
of the previous prototypical forms and expand on them in two and to couple them, in various ways, with other implementa-
ways. First, they have, at their core, some integration-oriented, tion artifacts defined elsewhere. All GUI designers support the
business-centric system architecture. For example, LC3 and interactive design of GUIs, building on a palette of pre-defined
LC5 have an architectural core akin to that of classical widgets. The vast majority of platforms provide drag-and-drop
Workflow Management systems or Case Management systems, mechanisms for that purpose. The scope of the provided wid-
whereas LC1 is built as a more general business application gets varies, with some products only covering basic elements
integration suite. Second, the platforms are designed so that a like buttons and text boxes, and others supplying a long list
variety of customizable, building block-like application units of interactive and representational means, including diagrams
can be inserted into different places in an individual solution. and pre-structured item galleries.
These units are intended to address aspects of such areas The coupling of GUIs and data structures is fairly con-
as artificial intelligence, business intelligence, and advanced venient in most environments. The user does not have to
means for static and dynamic integration. implement the MVC pattern on their own, relying instead on a
In effect, platforms of this type can be applied in widely pre-implemented version of it. Furthermore, all systems, with
divergent ways. In some cases, they may be used like platforms the partial exception of LC6 and LC7 , provide distinct support
of simpler forms. In more complex cases, they may be used to in adapting the GUI to different target environments (e.g., per-
build solutions for the operations of complete business units, sonal computers, tablets, and smartphones). The exact scope
integrating a range of existing systems and data sources. of such functionalities varies, but, as a rule, the developer is
largely freed from implementing GUI adaptation routines.
C. Technical Features The above features are among the most prominent ones in
We now turn to the central part of our study, the analysis of all systems. A couple of other features are equally common,
the seven low-code developments platforms on the basis of the although they are sometimes not as readily apparent. This
analysis framework explained in subsection III-B. Since the is particularly true of features falling into the functional
primary aim of this paper is to contribute to the clarification perspective, which are often much less obvious and less
of the essence of LCDPs, we will divide the presentation sophisticated than those in the static perspective. One common
according to the prevalence of the identified features. We will functional capacity is the ability to make basic functional
discuss, in turn, features found to be commonly, occasionally, specifications. Usual approaches include simple expression
and rarely exhibited by the studied platforms. Table III gives languages for decision rules or business rules, dialog-based
a condensed summary of the results. As already cautioned ways of specifying conditions, and even simple drag-and-drop
in subsection III-B, no single ordinal scale can adequately systems (as in LC6 ). Besides this, each solution provides a
represent the many shades and nuances of capacities present— library of standard operations for general purposes, such as
or absent—in the different platforms. The table is, therefore, mathematical functions. Moreover, all solutions enable, albeit

62

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
 TABLE III
F EATURES OF THE STUDIED LOW- CODE DEVELOPMENT PLATFORMS

Criterion LC1 LC2 LC3 LC4 LC5 LC6 LC7 Overall

Static Perspective
Mechanisms for data structure definitions ••• ••• ••• ••• ••• ••• ••• •••
Data modeling component ••• ••• ••• ••• ••• ••◦ ◦◦◦ ••◦
Internal databases and persistence mechanisms ••• ••• ••• ••• ••• ••• ◦◦◦ •••
Access to external data sources (APIs) ••• ••• ••• ••• ••• ••• ••• •••
Data reference models ••◦ •◦◦ •◦◦ ◦◦◦ •◦◦ •◦◦ ◦◦◦ •◦◦
Adaptation mechanisms for data (reference) models •◦◦ •◦◦ •◦◦ ◦◦◦ •◦◦ •◦◦ ◦◦◦ •◦◦
Dynamic Perspective
Mechanisms for program flow specifications ••◦ ••◦ ••◦ ••◦ ••◦ •◦◦ ••• ••◦
Process modeling component ••◦ ••◦ ••◦ ◦◦◦ ••◦ •◦◦ ••• ••◦
Integration with static and functional components and artifacts ••• •◦◦ ••◦ ••◦ ••◦ ◦◦◦ ••• ◦◦◦
Process reference models •◦◦ •◦◦ ◦◦◦ ◦◦◦ •◦◦ ◦◦◦ ◦◦◦ •◦◦
Adaptation mechanisms for process (reference) models •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦
Functional Perspective
Mechanisms for functional specifications ••◦ ••◦ ••◦ ••◦ ••◦ ◦◦◦ ••◦ ••◦
Functional modeling component ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦
Generic functional reference specifications ••• ••• ••• ••◦ ••• •◦◦ ••◦ ••◦
Domain-specific functional reference specifications ••◦ •◦◦ •◦◦ ◦◦◦ •◦◦ ◦◦◦ ◦◦◦ •◦◦
Adaptation mechanisms for functional (reference) specifications •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦
GUI Design
GUI design component ••• ••• ••• ••• ••• •◦◦ ••• •••
Graphical GUI editor ••• ••• ••• ••• ••• •◦◦ ••• •••
Automatic generation of GUIs from data structures ◦◦◦ •◦◦ ••◦ ◦◦◦ ••• •◦◦ ••◦ ••◦
GUI reference models ••◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦ •◦◦
Roles and Users
Specification mechanisms for roles and users ••• ••• ••• •◦◦ ••• ••◦ ••◦ ••◦
Modeling component for roles and users ◦◦◦ •◦◦ ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦ ◦◦◦
Artificial Intelligence
Internal artificial intelligence components ••◦ •◦◦ ••◦ ◦◦◦ ••◦ ◦◦◦ ◦◦◦ •◦◦
Integrability of external artificial intelligence services ••◦ •◦◦ ••◦ ◦◦◦ •◦◦ ◦◦◦ ◦◦◦ •◦◦
Explanation: ◦ ◦ ◦ = not or weakly addressed; • ◦ ◦ = partly addressed; • • ◦ = well addressed; • • • = extensively addressed.

to varying degrees, to invoke and integrate external functions of a work-flow modeling component and a workflow engine.
via APIs. For example, almost every system allows to use It may either be the case that a system, plainly, is a classical
standards such as web services and RESTful services; many WfMS to begin with (LC7 ) or that it is a more complex multi-
systems make it possible to use a long list of APIs of individual use platform which incorporates a WfMS at its architectural
providers, such as Google APIs and Salesforce APIs; and some core (LC1 , LC3 , LC5 ). The functionalities offered in this
systems, like LC1 and LC3 , also permit to use specialized connection are familiar. The workflow modeling component
APIs for Artificial Intelligence services. is usually based on a conceptual modeling language, such
Moving on to a different area, another common feature is as Business Process Model and Notation (BPMN) (LC3 and
that all solutions, with the partial exception of LC4 , come with LC7 ), or it is a simplified proprietary representational structure
a component to define roles and user rights. The roles and user (LC1 , LC2 , and LC5 ). In platforms incorporating workflow
system is usually contained in the governing architecture of components, the workflow engine usually governs a large part
the low-code platform itself, which will be deployed together (but not necessarily all) of the interaction between users and
with the custom application. the system at runtime.
Finally, almost all considered solutions offer advanced A somewhat different approach to dynamic specifications
support in the deployment of the applications, although this is taken by LC2 , LC4 , and LC6 . Here, the perspective is
takes quite different forms. For example, LC3 , LC5 , and LC6 less business-centric, and more generic and technical. These
require to install the environment of the low-code platform on platforms mainly provide components to define the interaction
a web server, and then individual applications are deployed with, and transition between, user-defined UI forms (see
into that environment. LC4 , in contrast, allows to deploy the above). For example, LC2 , features a proprietary process mod-
developed solutions as self-contained applications for various eling component to define the transitions between UI pages.
devices and machines. LC4 and LC6 , in turn, do not offer modeling components for
2) Occasional Features: Certain features are found only state transitions of the application, instead using basic menus
in some of the reviewed systems. Many of them fall into the and, sometimes, event-catching scripts.
dynamic perspective, where quite different strategies are taken. Another feature we detected occasionally is the availability
One occasional feature, as already suggested, is the availability of advanced or traditional coding components. Some sys-

63

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
tems, such as LC3 , LC4 , and LC7 , involve one or several is characterized by a more or less extensive range of individual
explicit components where procedural specifications can be features, which cannot be enumerated here. For example, LC2
made using traditional programming languages and related provides an AI-based component to predict and recommend
technologies. Most frequently, the systems use Java and next steps in the modeling process (a feature whose utility is
JavaScript; other languages are integrated depending on the relatively limited). All such features vary drastically in scope
focus of the systems. For example, LC4 , which is directed and maturity and would need to be assessed individually.
at web development, permits to use CSS. It must be said,
however, that at some level of the architecture, almost all V. D ISCUSSION
low-code platforms grant recourse to traditional programming The foregoing study permits a number of observations to be
code, either by providing quasi-hidden coding components made. We will now discuss, in turn, the key findings (subsec-
accessible only to advanced developers, or by allowing to tion V-A) and the limitations of our study (subsection V-B).
invoke self-programmed applications or libraries using APIs.
A more extensive category of features is largely exclusive A. Key Findings
to the large-scope multi-use platforms of major vendors (LC1 , No new technology. We may begin by highlighting what
LC3 , and LC5 ). These environments usually offer a variety of is, depending on one’s expectations, either the most surpris-
configurable, building block-like application units which can ing or the least surprising fact about the studied low-code
be integrated at different places in an individual solution. For development platforms. In and of themselves, the different
example, these units cover the area of business intelligence individual tools and components of which these environments
(such as components for data analysis and reporting), the area are comprised are neither radically new nor innovative in any
of artificial intelligence (such as pre-built components for text way. To the contrary, most of these tools and components
recognition and sentiment analysis), and the area of static and are well-known and have been used in professional software
dynamic integration, such as components for data extraction, development for many decades. For example, data modeling
transformation, and loading (ETL), and components for what components, process modeling components, database manage-
is now called robotic process automation. There is consider- ment systems, data source APIs, and graphical GUI editors all
able variance in the functional scope and the maturity of all belong to the standard arsenal of presumably the largest share
these pre-developed application units. of professional software developments projects.
3) Rare Features: Finally, there are several features which Low-code platforms integrate various classical development
are present only in a few systems on the market, and often components in one environment. Notwithstanding the previous
only to a limited degree. Interestingly, among these are key point, one of the respects in which low-code platforms deviate
capacities which would be expected given earlier research on from classical development infrastructures is that they incor-
software development productivity, namely, domain-specific porate all or most tools and components required for a limited
reference models or other reusable implementation artifacts class of software development projects in one environment.
(see section II). When it comes to domain-specific reference When using a classical infrastructure in professional software
data models, only the large-scale platform LC1 provided a development, one routinely has to deal with a sizeable array
sophisticated library of reusable data structures, addressing pri- of separate tools, such as IDEs, modeling tools, DBMS,
marily common business and communication concepts, such O-R mapping frameworks, GUI libraries and editors, external
as ‘customer,’ ‘address,’ and ‘email.’ Some other systems, like libraries, dependency managers, deployment and compilation
LC2 and LC6 , offered some smaller data reference structures assistants, and so on. In low-code platforms, these tools are
for the general domain of software development (involving integrated in one environment, so that there is less need to
concepts like ‘user’ and ‘session’), or for certain application switch between different systems and, more importantly, less
domains, like facility management or customer services. need to maintain and integrate the implementation artifacts
Turning to domain-specific reference functions or functional produced by these separate technologies.
implementations, still fewer artifacts are provided. LC1 does Productivity gains mainly ensue from reducing the efforts
make it possible to reuse a considerable number of functions of routine tasks. As is implied by several of the foregoing
implemented in various business applications of the same findings, low-code platforms produce productivity gains pri-
vendor. Most other systems, like LC2 , LC3 , and LC5 , offer marily by reducing the efforts of routine tasks in software
catalogs of reusable functions, but these are mostly generic development projects of low to moderate complexity. This
in nature, and they do not take on a dominant role in the applies in several ways. One is that through the provision
intended use of the systems. Lastly, as far as reusable artifacts of a pre-defined, integrated environment, there is less effort
of a dynamic nature, such as reference process models, are in synchronizing the artifacts produced by previously separate
concerned, we did not identify any noteworthy deliverables development components. Productivity is also promoted by
in the studied platforms. There are a couple of examples supplying reusable reference implementations for such generic
including pre-defined process models here and there, but these tasks as GUI design, O-R mapping, MVC implementation,
were very limited in scope and depth. and deployment in different environments. As a result, these
Finally, of course, it needs to be noted that besides the standard parts of an application need not be implemented
various features discussed above, every solution on the market manually in each and every project.

64

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
 Conceptual modeling is at the core of the platforms, but have pointed out that almost all studied tools offer support in
not at the core of marketing. Another key finding concerns deployment, it was beyond our means to assess the rolling-out
the way in low-code platforms are sold. As our analysis has and operation of solutions in realistic organizational settings.
indicated, conceptual modeling components, whether for data Closely related to this point are means for supporting col-
models or for workflow models, are among the most important laboration and project management. We have concentrated on
components of LCDPs, and one of the principled ways in the technical features essential to software development, rather
which they are able to decrease the need for traditional coding. than on the management of surrounding activities. Some, but
This is the case although the modeling languages provided not all, LCDPs are also claimed to offer support for the latter.
tend to be rather simplistic, lagging behind the state of the art A different criterion whose evaluation could not be un-
in research on conceptual modeling. To a degree, modeling dertaken here is the usability or accessibility to lay persons
components also involve ideas from Visual Programming (cf. (‘citizen developers’). In order to properly evaluate low-code
section VI). Interestingly, however, conceptual modeling is environments on this criterion, it would be necessary to
not highlighted in the marketing of low-code products. Few conduct a study with subjects who are truly non-proficient
vendors present themselves as offering solutions for model- in software development. As both authors of this paper have a
driven software engineering; rather, a variety of more recent background in computer science, it was not possible to judge
catchwords are employed. This is another indication that what how the platforms are perceived by non-IT experts.
has changed are often labels, not technologies. A completely different class of criteria with respect to which
Reuse is addressed at a generic architectural level, not our analysis is limited are economic criteria. It was beyond our
at a domain-specific level. As our analysis has demon- scope to compare, for example, price/performance measures of
strated, present-day low-code platforms rarely intend to offer any kind. As an aside, however, it may be mentioned that the
reusable artifacts at a domain-specific levels. They neither price models for most services are not made public anyway.
offer domain-specific reference models of noteworthy sophis- Moreover, it was our impression that some of the vendors,
tication, nor do they provide DSMLs. Rather, what is reused for example, LC5 , closely tie their price models to additional
by these platforms are fairly generic, and often implicit, consulting and educational services.
architectural frameworks for specific classes of application Finally, another limitation pertains to the analysis which
systems. This involves reference implementations for such we have, in fact, undertaken. Despite our best efforts, no
areas as GUI design, OR mappings, MVC operations, access guarantee can be made that we have not overlooked one
to external data sources, and so on. Within these frameworks, feature or another in the systems. One reason is that most,
individual solutions can be configured and developed. For though not all, of the investigated platforms are complex and
example, some systems hold generic frameworks for certain extensive environments. Exploring each and every component
types of web or mobile application, whereas others build on within them would be a project whose scope far exceeds our
architectural frameworks akin to those of WfMS. capacities. Another reason is that despite—and, sometimes,
because of—the orientation toward lay users, it is often
B. Limitations surprisingly difficult to find the places where even some of
A number of limitations apply to our study. One princi- the most basic configurations can be made. For example, it
pal limitation has already been stressed in subsection III-C. is often opaque where, if at all, functional specifications can
Because we have only investigated a small sample of low- be made. All the same, while certain details may or may not
code development platforms, no pretense can be made of have escaped our attention, we are confident that we have
representativeness or generalizability of results. Although we adequately captured the general character of the examined
have intended to cover a spectrum as broad as possible, it development platforms.
is by no means possible to assert that we have revealed all
significant capacities of products found on the current market, VI. O PPORTUNITIES FOR F UTURE R ESEARCH
or, conversely, that the capacities which we have identified are Although our conclusions substantially deflate the claims
really characteristic of most low-code environments. Because popularly expressed about low-code development, it is not
of the free use of the label ‘low-code,’ it is entirely possible advisable to ignore this trend. Instead, we agree with Cabot
that products and services on offer under that label, now or in [21] that the generated momentum may (re-)kindle interest in
the future, possess or will possess features altogether different a number of research themes of great theoretical and practical
from what has been shown above. importance. Striking examples, we think, include these:
Several other limitations of this study have to do with Domain-specific abstractions, like reference models and
criteria not taken into consideration. Two such criteria are DSMLs, promise to contribute both to reuse in software devel-
scalability and performance. Our uses and tests of the plat- opment and to the support of non-programmers. As we saw,
forms were invariably restricted to the design of simple, small- however, existing LCDPs rarely offer domain-level implemen-
scale software systems. We can make no statement about the tation artifacts. One route for future research may, therefore,
behavior of the systems in larger and more complex projects. consist in reviving research on domain-specific abstractions,
Another cluster of criteria ignored here concerns the area of and to study how these can be effectively integrated with other
live deployment, operations, and maintenance. Although we components of current development suites, including, but not

65

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.
limited to, LCDPs. Research on this matter is likely to profit R EFERENCES
from collaboration with the disciplines dealing with the fields [1] P. Vincent, Y. Natis, and et al., “Magic Quadrant for Enterprise Low-
in question, for example, business and organization studies. Code Application Platforms,” Gartner, Gartner Report Sep. 2020, 2020.
Mitigating the conflict between range and productivity of [2] F. Ihirwe, D. Di Ruscio, S. Mazzini, P. Pierini, and A. Pierantonio,
“Low-code engineering for internet of things,” in Proc. of the 23rd
reuse: A fundamental design conflict concerning reuse is that ACM/IEEE International Conference on Model Driven Eng. Lang. and
the more specific a reusable artifact is (e.g., a data model), the Syst.: Companion Proc., E. Guerra and L. Iovino, Eds. New York:
better is its contribution to reuse, but the lower is the range ACM, 2020, pp. 522–529.
[3] R. Sanchis, Ó. Garcı́a-Perales, F. Fraile, and R. Poler, “Low-Code as
of cases covered, and, hence, the possible economies of scale. Enabler of Digital Transformation in Manufacturing Industry,” Applied
Various approaches exist to reduce this conflict, such as gener- Sciences, vol. 10, no. 1, p. 12, 2020.
alization/specialization and multi-level language architectures. [4] R. Waszkowski, “Low-code platform for automating business processes
in manufacturing,” IFAC-PapersOnLine, vol. 52, no. 10, pp. 376–381,
But more research is needed for the further reduction of the 2019.
conflict under all perspectives on software development and [5] U. Frank, P. Maier, and A. Bock, “Low Code Platforms: Promises, Con-
in the context of larger integrated development environments, cepts and Prospects. A Comparative Study of Ten Systems,” University
of Duisburg-Essen, Essen, ICB Research Report 70, 2021.
including, but not limited to, LCDPs. [6] U. Frank, “Specialisation in Business Process Modelling: Motivation,
Synchronization of models and code. To support the model- Approaches and Limitations,” University of Duisburg-Essen, Essen, ICB
driven construction and adaption of software systems, it is Research Report 51, 2012.
[7] S. Smirnov, M. Weidlich, and J. Mendling, “Business Process Model Ab-
essential to keep models and code synchronized. Especially straction Based on Behavioral Profiles,” in Service-Oriented Computing
promising, though challenging, are approaches featuring a - ICSOC 2007, ser. LNCS, B. J. Krämer, K.-J. Lin, and P. Narasimhan,
common representation of models and programs (e.g., [22]). Eds. Berlin: Springer, 2007, vol. 4749, pp. 1–16.
[8] F. Milani, M. Dumas, N. Ahmed, and R. Matulevičius, “Modelling
Adaptable software architectures: In large and complex families of business process variants: A decomposition driven method,”
projects, the adaptation of an existing system can be more Information Systems, vol. 56, pp. 55–72, 2016.
efficient than building a new system from reusable artifacts. [9] S. W. Liddle, “Model-Driven Software Development,” in Handbook of
Conceptual Modeling, D. W. Embley and B. Thalheim, Eds. Berlin
This strategy requires architectures based on powerful abstrac- and Heidelberg: Springer, 2011, pp. 17–54.
tions. Enriching the idea of frameworks with DSMLs and [10] M. Brambilla, J. Cabot, M. Wimmer, and L. Baresi, Model-Driven Soft-
the integration of predefined artifacts such as components or ware Engineering in Practice: Second Edition, ser. Synthesis Lectures
on Software Engineering. San Rafael: Morgan & Claypool, 2017.
services may be a promising approach. [11] W. Codenie, K. de Hondt, P. Steyaert, and A. Vercammen, “From custom
applications to domain-specific frameworks,” Communications of the
VII. C ONCLUSIONS ACM, vol. 40, no. 10, pp. 70–77, 1997.
[12] M. E. Fayad and R. E. Johnson, Eds., Domain-specific application
Our investigation of seven low-code development platforms frameworks: Frameworks experience by industry. NY: Wiley, 2000.
does not lend support to the hypothesis that the systems [13] K. A. Bohrer, “Architecture of the San Francisco frameworks,” IBM
sold under that heading substantially advance the state of Systems Journal, vol. 37, no. 2, pp. 156–169, 1998.
[14] B. A. Nardi, A small matter of programming: Perspectives on end user
the art. In many ways, they lag behind the frontiers of re- computing, 2nd ed. Cambridge, Mass.: MIT Press, 1995.
search on software design, implementation, and maintenance. [15] H. Lieberman, F. Paternò, M. Klann, and V. Wulf, “End-User Develop-
What distinguishes these platforms is that they integrate, in ment: An Emerging Paradigm,” in End User Development, ser. Human-
Computer Interaction Series, H. Lieberman, F. Paternò, and V. Wulf,
one environment, multiple well-known and traditional system Eds. Dordrecht: Springer, 2006, vol. 9, pp. 1–8.
design components so as to reduce the efforts of routine tasks [16] R. St. Amant, H. Lieberman, R. Potter, and L. Zettlemoyer, “Program-
in implementing business applications within the confines of ming by example: visual generalization in programming by example,”
Commun. ACM, vol. 43, no. 3, pp. 107–114, 2000.
certain, more or less restrictive frameworks. [17] G. Costagliola, V. Deufemia, and G. Polese, “A framework for modeling
Nevertheless, LCDPs deserve the attention of researchers. and implementing visual notations with applications to software engi-
These platforms are intended to address goals of great social neering,” ACM Transactions of Software Engineering Methodologies,
vol. 13, no. 4, pp. 431–487, 2004.
and economic importance in a world permeated more and [18] D. Ingalls, S. Wallace, Y.-Y. Chow, F. Ludolph, and K. Doyle, “Fabrik:
more by software. Also, because existing LCDPs in large mea- a visual programming environment,” in Conference Proceedings on
sure build on modeling components, they may help increase Object-oriented Programming Systems, Languages and Applications,
N. Meyrowitz, Ed. New York: ACM, 1988, pp. 176–190.
the public awareness of conceptual modeling, and (re-)spark [19] A. Sahay, A. Indamutsa, D. Di Ruscio, and A. Pierantonio, “Supporting
research on advanced modeling languages and architectures, the understanding and comparison of low-code development platforms,”
among other themes in software design and implementation. in 2020 46th Euromicro Conference on Software Engineering and
Advanced Applications (SEAA), 2020, pp. 171–178.
But at the same time, the low-code trend, having its source [20] S. A. Demurjian, Sr., “Traditional Software Design,” in Computer
primarily in marketing, gives occasion for critical reflection on Science Handbook, A. B. Tucker, Ed. Boca Raton: Chapman &
the terminology in professional software development. As our Hall/CRC and ACM and Taylor & Francis, 2004, chapter 103.
[21] J. Cabot, “Positioning of the low-code movement within the field of
study has demonstrated, platforms sold under the label ‘low- model-driven engineering,” in Proc. of the 23rd ACM/IEEE International
code’ do not make up a well-defined class of technological Conference on Model Driven Eng. Lang. and Syst.: Companion Proc.,
environments with a uniform set of features. While we, as E. Guerra and L. Iovino, Eds. New York: ACM, 2020, pp. 535–538.
[22] T. Clark, P. Sammut, and J. Willans, “Super-Languages: Developing
academics, are not in a position to prescribe to any practitioner Languages and Applications with XMF (2nd Edition),” ArXiv e-prints
what terms to use, we believe that maintaining a consistent 1506.03363, 2015. [Online]. Available: https://arxiv.org/abs/1506.03363
terminology is among our core responsibilities. At present, it
is questionable to consider ‘low-code’ a proper scientific term.

66

Authorized licensed use limited to: ULAKBIM UASL - Izmir Ekonomi Univ. Downloaded on March 14,2022 at 11:14:40 UTC from IEEE Xplore. Restrictions apply.