A Multiple Mini Case Study on the Adoption of Low Code Development Platforms in Work Systems

Although the adoption of Low Code Development Platforms (LCDPs) promises significant improvements in the efficiency and effectiveness of application development, their adoption requires further empirical research. This paper uses a combinatorial approach to research LCDP adoption and presents the results of a multiple mini case study with 36 cases on LCDP adoption. A combination of the Socio-Technical Systems theory and the Technology-Organisational-Environment model is used as a theoretical lens. In this paper, we show that LCDP adoption is a multifaceted phenomenon and identify three archetypes for LCDP adoption (i.e., Application Development Democratisers, Synergy Realisers, and IT Resource Shortage Mitigators) and one archetype for LCDP non-adoption (i.e., Intricacy Adversaries). Each archetype can be interpreted as an individual path to LCDP (non-)adoption. Based on these archetypes, we derive seven starting points for practitioners to adopt LCDPs in work systems. Furthermore, using the theoretical lenses, the paper shows that for LCDP adoption to occur, an optimisation of the social and technical sub-systems is required.


I. INTRODUCTION
Information Technology (IT) is a critical driver for organisations to create value and remain competitive [1].As a result, organisations need to increase the speed of application development within budget and time constraints.However, a significant gap in skilled developers for application development exists [2], e.g., with over 137,000 IT vacancies in 2022 in Germany [3].Traditionally, outsourcing has been a common strategy applied to address this shortage [4].However, recent developments suggest that this approach is becoming less attractive [4], [5].Low Code Development Platforms (LCDPs) are being promoted to address these challenges by increasing the efficiency and effectiveness of application development and by empowering end users to The associate editor coordinating the review of this manuscript and approving it for publication was Justin Zhang .
develop applications [6], [7], [8].For instance, Forrester Research claims that LCDPs ''have the potential to make software development as much as 10 times faster than traditional [development] methods'' [9].LCDPs are advertised to support professional software developers and so-called citizen developers with little to no programming experience [6], [7].Therefore, the global market size for LCDPs is expected to grow significantly, from USD 13.2 billion in 2020 to USD 45.5 billion by 2025, with a Compound Annual Growth Rate of 28 % [10].
Despite the widespread adoption of LCDPs by practitioners, academic research on LCDP adoption has only recently begun.However, a better understanding of LCDP adoption may help to explain the rapid growth in adoption and to address the factors that inhibit it.Therefore, we researched LCDP adoption in work systems and identified 12 drivers and 19 inhibitors as factors for LCDP adoption in [11].
We conducted a Delphi study, analysed the drivers' and inhibitors' importance, and found that experts agreed on the most and least important drivers and inhibitors for adoption [11].However, for the factors between the most and least important, the experts' ranking was context dependent [11].Our Delphi study only researched single factors and neglected the combinatorial effects between different factors.Another study investigated LCDP adoption at an organisational level with 18 semi-structured expert interviews, archival data, and user reviews [1].The authors identified ten aspects that support the adoption of LCDPs and six aspects that hinder it [1].Furthermore, in [1], it was argued that researching LCDP adoption just from a technology adoption perspective is insufficient, as Low Code Development (LCD) is an entirely new way of developing applications.Therefore, a combination of technical, organisational, and environmental factors need to be considered when researching LCDP adoption [1].In [12], we argued in the same direction and proposed a combination of technical, organisational, and environmental factors to research LCDP adoption in work systems.To represent the technical aspects, we considered results from previous research on cloud computing (CC) adoption.We justified this by the Platform as a Service (PaaS) cloud delivery model used by LCDPs [12], [13], [14].We included factors from agile software development methodology (SDM) adoption to account for the transformed application development approach [12].Furthermore, we showed that LCDP adoption is a multifaceted phenomenon that should be explored by combining different factors that influence each other [12].Consequently, we built a combinatorial research model with 13 factors in [12].Nevertheless, we could not yet empirically validate the model, which is the purpose of this paper.Therefore, the paper at hand addresses the following research questions (RQ): RQ1: What factors determine LCDP adoption in work systems?
RQ2: Which combinations of these factors lead to LCDP adoption in work systems?
The unit of analysis is the decision to adopt LCDPs in work systems, i.e., ''systems in which human participants and/or machines perform work [. . .] using information, technology, and other resources'' [15, p. 75].The focus is on work systems where professional and citizen developers adopt LCDPs as systems to develop applications.
The academic literature distinguishes between adoption and post-adoption phases [16].In the adoption phase, an organisational view is taken, i.e., the organisation has to decide on the adoption, select a provider, and enable the use within the organisation [16].In the post-adoption phase, the decision to adopt the LCDP for a specific project is made in a work system.Therefore, this paper investigates the postadoption phase.
To answer the research questions, we use a multiple case study, which allows us to explore the adoption in its real-world context.However, as we collect 36 cases to be able to investigate combinatorial effects and each case has a somewhat limited depth (i.e., one interview per case), we refer to the methodology as a multiple mini case study.A similar approach was taken by [17] in their study of Software as a Service adoption.
This paper has four contributions.First, we confirm ten of the 13 factors for LCDP adoption from our previous research published in [12].Furthermore, we find two additional factors (i.e., the sophistication of the application to be developed and the replacement of shadow IT) that are important for LCDP adoption.Second, we show that LCDP adoption results from a combination of different factors and is a multifaceted phenomenon.Based on this, we identify three archetypes for LCDP adoption (i.e., Application Development Democratisers, Synergy Realisers, and IT Resource Shortage Mitigators) and one archetype for LCDP non-adoption (i.e., Intricacy Adversaries).Third, based on the Socio-Technical Systems (STS) theory, we show that the technical and social subsystems must be jointly optimised for LCDP adoption to occur.Finally, based on the LCDP adoption archetypes, we derive practical implications and seven starting points for LCDP adoption that practitioners can use.
The paper is structured as follows: section two outlines the conceptual background, introduces the research model, and presents the current state of research on LCDP adoption.Section three presents the methodology of the multiple mini case study, and its results are presented in section four.Section five discusses the findings in the light of previous literature and derives practical implications.The study concludes with contributions, limitations and future research directions.

II. RESEARCH BACKGROUND A. LCDPs -CONCEPTUAL BACKGROUND
LCD offers a new approach to application development using interactive graphical interfaces instead of traditional programming [1], [6].For LCD, so-called LCDPs are used to foster application development through visual drag-anddrop techniques.Therefore, LCDPs are easy to start with for developers with and without prior knowledge [11], [18], [19].LCDPs operate as a PaaS cloud delivery model [12], [13], [14] and enable citizen developers to rapidly develop diverse applications [18].As such, LCDPs fit the broader trend of technology democratisation (i.e., traditionally required coding for application development can now be done by citizen developers) [18].In the academic literature, this trend towards democratising technology and giving business units a greater degree of responsibility for IT components and tasks is referred to as business-managed IT [20], [21], [22].Not surprisingly, several software vendors have added LCD functionality to their product portfolios in recent years, including ServiceNow [23], Salesforce [24], and Oracle [25].
LCDPs combine well-known concepts such as rapid application development, fourth-generation programming languages, model-driven development, and computer-aided software engineering [7], [26], [27], [28], [29].The academic literature, therefore, agrees that the trend towards LCDPs is not a completely new phenomenon [11].The term LCDP describes a list of heterogeneous development platforms with different functionalities, different usage scenarios, and different target groups [7], [11].We focus on LCDPs that are used by citizen developers and professional developers within an organisation to develop applications.Thus, these LCDPs enable full application development with a user interface, business logic, workflows, and connected data services [30].Gartner refers to this type of LCDP as Low Code Application Platform, and leading vendors in this market include Mendix, Microsoft, OutSystems, Salesforce, and ServiceNow [31].

B. LCDP ADOPTION 1) LCDP ADOPTION RESEARCH
Technology adoption is the diffusion and initial use of technology within a work system [32].Research on technology adoption distinguishes different levels of adoption, from organisational to individual adoption [33].The academic literature further distinguishes between the initial adoption phase and the subsequent post-adoption phase [16].During the adoption phase, organisations decide to adopt, select a vendor, and facilitate implementation within the organisation [16].In the post-adoption phase, individuals or work systems decide to adopt the LCDP, e.g., for a specific project.In this paper, we take a work system view for three reasons.First, LCDPs promote collaborative application development with multiple developers, i.e., an application is developed by more than one individual.Therefore, adoption usually occurs at a higher level than the individual level.Second, the goal of LCDP adoption is to develop many applications within a department.Therefore, many post-adoption decisions occur at the work-system level (whereas organisational adoption occurs only once -when the organisation decides to adopt the LCDP).Therefore, the work system view helps to explore the majority of LCDP adoptions.Third, LCDP adoption differs from traditional technology adoption in that LCDP adoption is ''a technology and method of software development where both elements [technology and method] are intertwined'' [1, p. 1].Therefore, the relationship between the technology and the human participants needs to be analysed.Taking a work system view helps to analyse this relationship in detail.
From an academic perspective, a few papers research LCDP adoption from different perspectives.In a recent literature review [34] summarise the academic literature on drivers and inhibitors for LCDP adoption.The authors find that improved software development efficiency and reduced entry barriers for application development are the most frequently discussed drivers for LCDP adoption [34].In addition, in [35], posts from LCDP online forums are analysed to explore LCDP adoption on an individual level.The authors conclude that faster development (i.e., higher efficiency) and lower development complexity are the most often discussed drivers for LCDP adoption.The authors of [36] explore LCDP adoption at an organisational level by surveying IT professionals and find that accelerated digital transformation and reduced dependency on IT developers are the main drivers for LCDP adoption.Another paper that examines LCDP adoption at an organisational level is [1].The authors argue that LCDP adoption is a technology adoption that also transforms the application development process [1].Therefore, a combination of technical, organisational, and environmental aspects need to be explored to research LCDP adoption [1].In summary, the authors identify ten factors that support the adoption of LCDPs and six that hinder it and structure them along the Technology-Organisation-Environment (TOE) model [1].However, none of the empirical research discussed so far takes a work system view for analysis.
To the best of our knowledge, the only empirical research applying a work system view to LCDP adoption is our recent Delphi study [11].We conducted a ranking-type Delphi study with 17 experts and identified 12 drivers and 19 inhibitors for LCDP adoption in work systems [11].The experts in our study agreed that the most important drivers are the improved efficiency of software development, reduced entry barriers for application development, and reduced knowledge requirements for application development [11].The experts also agreed that the most important inhibitors are the lack of LCD culture and reluctance to change.In addition, the experts emphasised that the drivers and inhibitors influence each other and that a single factor is not sufficient to explain LCDP adoption [11].Therefore, LCDP adoption in work systems should be explored with a combinatorial approach [11], which cannot be done in a Delphi study.Consequently, we decided to build a combinatorial research model, which we published in [12].In this paper, we test this research model for LCDP adoption using a multiple mini case study approach.This multiple mini case study approach allows us to study a contemporary phenomenon (i.e., LCDP adoption) in its real-world context [37].

2) RESEARCH MODEL a: THEORETICAL LENSES FOR LCDP ADOPTION
Most of the previous research on LCDP adoption is practiceoriented and does not apply a theoretical lens [12].To further advance the rigour of LCDP adoption research, we use for this study the research model and theoretical lenses developed in our previous research in [12].To construct the research model, we derived 13 empirically testable factors from existing CC and agile SDM adoption research.We describe the core components and relationships of the research model in the following section.The complete model is published in [12].
Several technology acceptance theories have been used to study CC adoption [33].One research direction that examines the adoption at the individual level uses the Technology Acceptance Model or its extensions [33].However, this paper focuses on the adoption within work systems (i.e., at a higher level).Therefore, the models proposed by a second research direction, namely the TOE model [33], are more appropriate.The TOE model suggests that the adoption of an innovation is influenced by a combination of technology, organisation, and environment factors [38], [39].The TOE model has been widely used to investigate why organisations adopt new technologies [1], e.g., CC [40], Enterprise Resource Planning (ERP) systems [41], and organisational adoption of LCDPs [1].
In the TOE model, the technology includes all technologies (e.g., equipment and processes) that are relevant to the organisation [38], [42].The organisation describes several characteristics, such as the management structure and support, culture, technical competence, availability of resources, organisational readiness, technical competence, or organisational size [42].Several studies suggest that the characteristics of an organisation are crucial when studying technology adoption [1].The environment consists of all external factors that influence technology adoption [38], [39], [43].The environment usually includes factors such as the structure of the industry, the regulatory environment, and pressure from technology providers that influence the adoption decision [42].
Due to its simplicity, the TOE model is often criticised for its generic nature [44].Therefore, we propose to use it Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
as a guiding framework, but to extend the technology and organisation components with elements from the STS theory for further analysis [12].The STS theory has already been used by [45] to study the adoption of computer-aided software engineering systems, which have conceptual similarities to LCDPs [27], [29].The STS theory analyses the interaction between the social sub-system and technical sub-system, both of which a work system comprises [46], [47], [48].According to [46], the social sub-system consists of a structure subsystem and a people sub-system.In contrast, the technical sub-system comprises a technology sub-system and a task sub-system.
In the context of LCDPs, these sub-systems are already defined by [14]: the structure sub-system is the way an organisation communicates, has authority, and is set up; the people sub-system includes all stakeholder-specific factors; the task sub-system includes all application developmentspecific factors; while the technology sub-system includes all platform-specific issues [14].Based on the STS theory, we can assume that for work systems to achieve their goals (i.e., to adopt a technology), the social and technical subsystems must be balanced and jointly optimised [12], [54].In addition, the sub-systems must be open and responsive to their environment [12], [54].
In summary, we derive three tentative propositions from the theoretical lenses for our combinatorial research model.First, a combination of technical, organisational, and environmental factors must be considered when researching LCDP adoption (as indicated by the TOE model and STS theory) [12].Second, multiple sub-systems need to be balanced and jointly optimised for LCDP adoption (as indicated by the STS theory).Third, environmental factors are essential for LCDP adoption (as indicated by the TOE model and STS theory) [12].

b: RESULTING RESEARCH MODEL
Based on the theoretical lenses and findings from previous CC and agile SDM adoption research, we constructed a research model (cf.Table 1) that forms the basis of our empirical research in [12].A visualisation of the key concepts and relationships in the research model can be found in Appendix A. We used the analogy between CC and agile SDM adoption to derive the factors for the research model published in [12].We argue that because LCDPs are cloud services using a PaaS delivery model [14], all of the factors found to influence CC adoption in general must also influence LCDP adoption [12].In addition, the adoption of LCDPs significantly changes application development [1]: from a process with traditional programming to one with visual drag-anddrop capabilities [1], [6], [55].To account for these changes, we included previous findings from the literature on SDM adoption [12].
Previous research is ambiguous about the effect of individual factors.Therefore, we propose to use a combinatorial approach, where combinations of multiple factors cause the outcome (adoption or non-adoption) [12].Existing literature on CC adoption finds asymmetric effects of factors [12], e.g., high security concerns lead to lower CC adoption [56], while other studies show the opposite [57].In addition, for IT innovation adoption in general, factors are found to interact as a form of conjunctural causation [58].
Table 1 summarises the research model we developed in [12] and provides an overview of the proposed subsystems, the factors to capture LCDP adoption, the descriptions of the factors, and the effect on adoption found in previous research.Where both positive and negative effects have been found in previous research, the term ''mixed'' is used in Table 1 in addition to the terms ''positive'' and ''negative''.However, as previous studies on the adoption of CC and agile SDM lack a combinatorial approach, we suggest in [12] to limit ourselves to considering these factors as essential for explaining LCDP adoption without specifying their combined effect on LCDP adoption.

III. METHODOLOGY A. OVERVIEW
For this paper, we followed a multiple case study approach to answer our research questions.This approach allows us to explore the contemporary phenomenon of LCDP adoption in its real-world context [37].As our research has a relatively high number of cases (i.e., a high breadth), with each case having only one semi-structured interview as a source of evidence, we refer to it as a multiple mini case study.The rationale for choosing a multiple mini case study is the complex research model (13 factors), which requires many cases to investigate combinatorial effects.An advantage of this large number of cases is that it allows us to identify archetypes of cases with similar characteristics, across which we can triangulate findings.To answer the research questions, we followed a four-step approach to conducting this case study, namely (1) designing the research, (2) collecting the data, (3) analysing the data, and (4) writing the case study report, as suggested by [37].In the following sections, we explain our methodological choices and the measures taken to ensure the validity of the results.

B. DESIGNING THE RESEARCH
As a first step, we formulated the research questions (i.e., RQ1 and RQ2) and clarified the unit of analysis (i.e., the decision to adopt LCDPs in work systems) [37].The work systems perspective allows us to explore adoption at a level where it typically occurs -between the individual developer and an organisational level.We used our research model [12] as an a-priori theoretical framework to guide the research design, data collection, and data analysis.
As case study research builds on analytical generalisation from cases, the case replication logic is crucial to define the underlying rationale for selecting cases [37], [59].We combined literal and theoretical replication to select our cases and strengthen the robustness and generalisability of our 118766 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
research [37], [59].Literal replication allows us to predict similar results for cases with similar characteristics [37].Theoretical replication allows us to identify cases with different outcomes for theoretically predictable reasons [59].Literal replication was ensured by selecting homogeneous work systems from large organisations.For theoretical replication, we selected informants with backgrounds from business and IT units, as we found in our previous work (i.e., [11]), that informants from the business and IT units have different views on LCDP adoption.In addition, all informants had to be decision-makers when deciding on LCDP adoption within a work system (e.g., an LCDP owner) or actively consulting in these decision situations (e.g., a consultant).We identified the informants through our personal professional network and the social network LinkedIn.For LinkedIn, we searched for informants from German Dax, MDax or SDax companies in combination with the search term ''Low Code''.These indices include the shares of the 40 largest German companies (Dax), as well as also 50 mid-cap (MDax) and 70 small-cap (SDax) companies.
For all informants identified, we assessed whether the informants were decision-makers or consultants in the decision situations described.We found 23 informants, of which nine had a consulting background, and 14 were line managers.An overview of the informant characteristics can be found in Appendix B. All informants agreed to the publication of the data collected in this research article.

C. DATA COLLECTION
First, we sent each informant an online questionnaire with context questions (based on the contexts found in [11]).This approach allows us to obtain standardised context information to increase comparability.We then invited the informants to participate in semi-structured interviews [37] as our primary data collection method to gather in-depth information about LCDP adoption.The interview guide was derived from the research questions and the theoretical framework in [12] to ensure a full chain of evidence from the research questions to the findings.All interviews were structured in six parts: (1) introduction, (2) the current state of LCDP adoption at the organisational level, (3) process for adopting LCDPs in work systems, (4) factors for LCDP adoption in work systems, ( 5) key learnings for LCDP adoption in work systems, and (6) concluding remarks.The semi-structured questionnaire can be found in Appendix C. Data collection took place via videoconferencing between February and April 2023.The interviews lasted, on average, 45 minutes and were recorded, transcribed, anonymised, and analysed.We recorded 36 cases, with 26 adoption cases and ten nonadoption cases.A description of the cases and their contextual variables can be found in Appendix D and E. In addition, to increase the reliability of the case studies, we used a case study protocol and a case study database (MAXQDA) [37], [59].MAXQDA is a software solution for storing, categorising, and analysing qualitative data [60].

D. DATA ANALYSIS
We analysed the data collected from the context questionnaire and interviews (i.e., using multiple sources of evidence [37]) in several iterations.We first conducted a within-case analysis and then a cross-case analysis, following the methodological guidance of [37].
For the within-case analysis, we first coded our data according to the 13 factors of the a-priori analytical framework, which we developed in a previous paper [12].In the second iteration, we used open coding to identify potential new factors from the case data and aggregated them into axial codes [61].The coding of the interviews was carried out by the first author and then discussed with the other authors.For each case, we extracted the outcome (adoption or nonadoption decision), the factors that led to the outcome, the value of the factors, and the effects of the factors.Based on these results, we analysed whether a factor was relevant to the LCDP (non-)adoption decision and based on the frequency of the factors and the interpretation of the underlying cases, the archetypes were created, discussed, and refined in several iterations among the authors.In refining the archetypes, we went back and forth between the empirical case data and the characteristics of the archetypes.In addition, in order to increase the robustness of our findings, a pattern matching was carried out, i.e., the factors and their effects from the empirical data were matched with the theoretically predicted effects [37].We conducted the cross-case analysis based on our identified archetypes with the aim of better understanding the underlying effects of LCDP adoption and the situations in which these archetypes emerge.

E. COMPOSITION
We only reported results found in at least two cases to ensure robustness and reduce the risk of reporting spurious results [37], [59].We also followed recommendations for persuasive writing, such as clear transferability of results, appropriate rhetoric, and empowerment of readers [59].

F. VALIDITY
A crucial part of multiple case study research is ensuring its rigour.Four criteria are used for this purpose: construct validity, internal validity, external validity, and reliability [37], [62], [63].Because multiple mini case studies have fewer sources of evidence per case, and because of the general criticism that many case study papers do not show how rigour is ensured [62], [63], we elaborate on our methodological steps to ensure rigour in the following section.
Construct validity is about ensuring the development of correct operational measures for the researched concepts [37].To ensure construct validity, we triangulated across multiple sources of evidence (interviews and the context questionnaire), and established a chain of evidence from the a-priori framework to the results [37].Internal validity is about establishing a causal relationship [37].We, therefore, applied pattern matching [37] and created archetypes of cases between which results can be triangulated and we iteratively discussed the findings among the authors to reduce subjective results.External validity defines the domain to which the results of a study can be generalised [37].To ensure external validity, we used a multiple case design (36 cases) with a combination of theoretical and literal replication to allow for the generalisability of the findings [37].In addition, we clearly defined the unit of analysis (i.e., LCDP adoption in work systems).The aim of reliability is to ensure that the steps of a study can be repeated and produce the same results [37].To ensure reliability, we followed the methodological guidelines of [37], created a case study database (MAXQDA) and a case study protocol to enable the replication of our research.

A. OVERARCHING
In the following sections, we first outline the overarching results from the context questions, second identify factors for the LCDP (non-)adoption based on the research model and open coding, and third introduce archetypes of LCDP (non-)adoption.In the context of this paper, archetypes are typical examples of LCDP (non-)adoption cases and are defined by the occurrence of a set of factors.All results of the context questions can be found in Appendix E.
We recorded 36 cases, of which 26 are adoption cases and ten are non-adoption cases.The organisations to which the work systems belong come from a variety of industries, with industrial manufacturing (22%), financial services (17%), healthcare and life sciences (17%), and conglomerates (11%) being the most frequent.All can be considered large organisations with a global presence.This is confirmed by the results of the context questionnaire, where in only 21% of cases, the IT unit provides IT services to only one continent.In addition, respondents tend to see their IT units as centralised, whereas the business units tend to be decentralised.In most cases, the LCDP is Mendix (39%), Microsoft Power Platform (25%), or OutSystems (14%).There are also fewer cases where the LCDP is Appian, Oracle APEX, or RCP.Many case organisations claim to be at an early stage of LCDP adoption as they have few low code applications (i.e., only 26% have more than 100 low code applications).When analysing who is developing on the LCDP, in the majority of cases (32%), the IT unit and external developers are developing on the LCDP, followed by the IT unit only (16%), business and IT units (16%), business unit only (11%), and IT unit, business unit and external developers (11%).Therefore, in most cases, the IT unit is involved in the (non-)adoption decision.The informants explain the lower use of pure citizen development with a lack of governance concepts, the fear of building up insular application landscape, and security concerns from citizen development.As I-09 put it:'' We do not push the topic citizen development [. . .] as we as IT unit or organisation, in general, do not have a concept on how we want to deal with it.''However, a wider roll-out of citizen development is being piloted or planned in several organisations.
The process for adopting an LCDP in a work system is primarily project-specific (i.e., the business unit wants to develop an application, approaches the IT unit, a joint evaluation is made as to whether an LCDP is the right solution, and then the adoption decision is made).Therefore, in the following, each case represents the adoption decision for an application to be developed in a work system.

B. EMPIRICALLY FOUND FACTORS FOR LCDP ADOPTION
In the following section, we present the empirically identified factors for LCDP post-adoption.As shown in Table 2, we were able to identify ten of the 13 factors from the research model (cf.Table 1) and two additional factors from open coding during the within-case analysis.In the adoption cases, the most frequently found factors are expected efficiency improvements(26 out of 26), sophistication of the application to be developed(15 out of 26), compatibility (14 out of 26), and internal IT capabilities (12 out of 26).For the nonadoption, the most frequently identified factors are the same, with the sophistication of the application to be developed(ten out of ten), expected efficiency improvements(seven out of ten), compatibility(six out of ten), and internal IT capabilities(six out of ten).The two newly identified factors are the sophistication of the application to be developed and the replacement of shadow IT.The factor of sophistication of the application to be developed refers to the fact that the LCDPs are better suited to developing small, simple applications rather than large, complex ones.Multiple informants highlighted the importance of this factor, e.g., ''[The evaluation] also contains soft factors, like low complexity [of the application to be developed]'' (I-15) or ''[The] reporting functionality ended up not being at the same level as [in specialised software] and there would simply have been no advantage to using [an LCDP] in these use cases.Another point is performance, especially when you must process large amount of data'' (I-21).As this factor relates to the sophistication of the application to be developed in LCDPs, and all developmentrelated factors are in the task sub-system, we propose to assign this factor to the task sub-system.The factor replacement of shadow IT is the adoption of an LCDP to provide a platform for (citizen) developers to develop applications in a way that complies with organisational policies, as illustrated by I-03: ''There is this issue of shadow IT.Many applications are not apps, but it is still an application because people work with them daily.[. . .] And we lift it out of the shadows and into the official path that conforms to corporate guidelines.The person in charge of something like this can be sure: okay, I am compliant.''Since the underlying goal of this factor is to comply with the organisation's policies (i.e., authority), we suggest that this factor be assigned to the structure sub-system.
The factors of vendor lock-in, previous experience, and training opportunities from the research model could not be found in our cases.The non-occurrence of the factor vendor lock-in can be explained by the work system (i.e., postadoption) view taken for this paper.The informants explained 118768 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.that vendor lock-in is a factor to be taken into account during the adoption decision at the organisational level.However, for adoption at the work system level (post-adoption), ''this does not play any role'' (I-03).

C. ARCHETYPES FOR LCDP (NON-)ADOPTION 1) GENERAL
A combination of factors from the previous section leads to the (non-)adoption of LCDPs.Each factor has a value (e.g., low or high) and an effect (negative or positive) on the (non-)adoption of LCDPs.The same combination of factors, values, and effects always leads to the same outcome.The coding table for all cases can be found in Appendix F. In the next sections, we present three archetypes of LCDP adoption and one archetype of LCDP non-adoption.The archetypes were created based on the frequency of occurrence of the factors and the interpretation of these cases.

2) ADOPTION
In all adoption cases, the factor expected efficiency improvements occurs with the value high and a positive effect.Furthermore, in all adoption cases, the majority of factors have a positive effect on LCDP adoption, and two to six factors occur in the adoption cases we analysed.As shown in Table 3, we identified three archetypes for LCDP adoption based on the interpretation of the cases: (1) Application Development Democratisers, (2) Synergy Realisers, and (3) IT Resource Shortage Mitigators.The following sections present the archetypes and the factors that define them.
The first archetype is Application Development Democratisers, which aims to broaden the developer base for less sophisticated applications through LCDPs.The archetype is defined by the factors expected efficiency improvements with the value high and a positive effect and low sophistication of the application to be developed with a positive effect.In this archetype, expected efficiency improvements are a key decision criterion, e.g., ''cost efficiency and speed -those are the two things that really matter'' (I-04).Interestingly, for the expected efficiency improvements, not only the initial development cost is considered but also the cost to operate and maintain the application.Here, LCDPs were seen as having an advantage as non-experts can support operations: ''This is a topic, where also student workers can support'' (I-16).Moreover, when deciding to adopt an LCDP, the development and subsequent operations and maintenance must be considered.A crucial factor mentioned by several informants is the lower sophistication of the application to be developed.They argued that a lower sophistication of the application to be developed had a positive effect on LCDP adoption.

As I-15 put it: ''[The evaluation] also contains soft factors, like low complexity [of the application to be developed].''
The same argument was relevant in case eight: ''Because I can build an app, but I cannot offer support for a big app, right?[. . .] That is the main factor when deciding to use low code'' (I-04).The overall goal of this archetype is to broaden the developer base with citizen developers from the business units.In addition, the IT unit and external developers support the citizen developers, e.g., by providing Q&A sessions to answer open questions.Therefore, the Application Development Democratisers archetype emerges when the applications to be developed are less sophisticated, when there are multiple citizen developers in the organisation, or when applications need to be customised to meet departmental requirements.
The second archetype is the Synergy Realiser, which aims to achieve efficiencies by leveraging licences for LCDPs from existing enterprise systems or pre-developed components (e.g., authentication modules).Therefore, this archetype is defined by expected efficiency improvements with the value high and a positive effect and high compatibility with a positive effect.As with the previous archetype, the expected efficiency improvements are a key reason for LCDP adoption, e.g., ''this was cost-driven'' (I-14), or ''the key reason was the budget'' (I-22).In addition, high compatibility with existing enterprise systems of the work system and their licences is a key decision factor.For example, in case 34 the informant pointed out: ''The licences environment -it [the LCDP] was already part of the licence environment'' (I-22).Furthermore, in this archetype, because the licences are included in existing enterprise systems, the LCDPs are usually well integrated into these systems, making development even easier.Efficiency in application development is, therefore, achieved by realising synergies through the use of LCDP licences from existing enterprise systems or pre-configured components from organisational marketplaces.Therefore, the Synergy Realiser archetype typically arises in situations where citizen developers and LCDP licences are available as part of existing large enterprise systems.
The third archetype is IT Resource Shortage Mitigators with the underlying goal of building applications efficiently with limited traditional IT resources.Therefore, this archetype includes the factors expected efficiency improvements, with the value high having a positive effect, and internal IT capabilities, with a positive effect.In case three, the informant pointed out that expected efficiency improvements were one of the main reasons for adopting an LCDP: ''The expectation is, in any case, that this [the development] is done very, very fast'' (I-02).Furthermore, in this case, there was a lack of IT resources (i.e., low internal IT capabilities), which encouraged the adoption of an LCDP to develop the application (''It is key that we have this application'' I-02).Another informant elaborated that when using an LCDP, the development of ''the application [could be done] in a tenth of the time'' (I-20) and also ''external resources'' (I-20) could be used for the development (i.e., solving the problem of low internal IT capabilities).In addition, the factor of internal IT capabilities can have the value high with a positive effect, i.e., ''the people know a lot'' (I-14) about LCDPs.Interestingly, in these cases, the development is typically done by the IT units and external developers.Therefore, a typical situation in which the IT Resource Shortage Mitigators archetype emerges is to fill the internal IT resource gap in the IT unit.In addition, the sophistication of the applications to be developed may be higher than in the other two archetypes, as IT staff are more experienced in application development than citizen developers.
Figure 1 shows a Venn diagram of the archetypes, where each circle represents the occurrence of a factor (e.g., compatibility), the archetype is shown in parentheses and 118770 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
the numbers show the case IDs.Based on this visualisation, we can highlight two results.First, all LCDP adoption cases can be classified into these three archetypes.This indicates that for an LCDP adoption to occur, at least the factor expected efficiency improvements and one archetypedefining factor (compatibility, internal IT capabilities, or sophistication of the application to be developed) must occur.
In addition to the factors that define the archetypes, other factors (e.g., top management support) may occur.However, we see these cases as a more specific version of the archetypes, as adoption already occurs based on the factors that define the archetypes.Second, several cases (e.g., case 35) combine two archetypes (Synergy Realisers and Application Development Democratisers).Therefore, we conclude that archetypes can occur combined.
With the exception of high external pressure (cases seven and 26), high security and privacy concerns (case 21), and a closed organisational culture (cases two, four and 33), all factors have a positive effect on LCDP adoption.Since the outcome for these cases is still LCDP adoption, we argue that the positive effect of the other factors must have equalised or even dominated the negative effects.This argument is also supported by our empirical data, e.g., case four, where there ''were a few colleagues from the IT, that were against it [the LCDP]'' (closed organisational culture), but none of them was a ''decision-maker, who could push against it'' (I-02).In this case, however, the decision-makers were ''fascinated by the speed'' and the ''integration [of the LCDP] in the [software name]'' (I-02).The decision to adopt the LCDP was therefore taken.The same pattern occurred in case two, where the ''IT has not really shown that much interest in engaging with [the LCDP]'' (I-02) due to a closed organisational culture.However, the high compatibility with existing systems, the high expected efficiency improvements, the lack of IT resources (low internal IT capabilities), and the support from top management led to the adoption of the LCDP.
In summary, firstly, the overarching goal of all LCDP adoption cases is to realise efficiencies (i.e., expected efficiency improvements).Secondly, there are three archetypes for LCDP adoption (Application Development Democratisers, Synergy Realisers, and IT Resource Shortage Mitigators).Thirdly, all LCDP adoption cases can be assigned to these archetypes.Fourthly, most of the factors have a positive effect on LCDP adoption; however, negative effects (e.g., from a closed organisational culture) can be compensated by positive effects of other factors.

3) NON-ADOPTION
In addition to the 26 adoption cases, we also identified ten non-adoption cases.Among the non-adoption cases, high privacy and data security concerns, low compatibility, high sophistication of the application to be developed, high complexity, closed organisational culture, low usefulness, low internal IT capabilities and high external pressure have a negative effect on LCDP adoption.On the other hand, high compatibility, high expected efficiency improvements, low internal IT capabilities, and high top management support have a positive effect.A full coding table can be found in Appendix F.
When analysing the underlying reason for the nonadoption of an LCDP, we found one archetype across all non-adoption cases.The archetype is defined by a too high sophistication of the application to be developed, which has a negative effect on LCDP adoption.We call this archetype Intricacy Adversaries and describe it in Table 4. Several informants illustrated that the sophistication of the application to be developed was too high, leading to non-adoption.For example, in case 15, it was decided not to develop a new front-end for an existing application because of the ''large amount of data'' (I-15) to be processed (i.e., high sophistication of the application to be developed).In case 29, the too high sophistication of the application to be developed was also the reason for non-adoption, i.e., ''[the] reporting functionality ended up not being at the same level as [in specialised software], and there would simply have been no advantage to using [an LCDP] in these use cases'' (I-21).As several LCDPs (Appian, Mendix, Microsoft Power Platform, and Oracle APEX) are found for this archetype, we argue that it is independent of the specific LCDP.It is also independent of the type of developer, as cases were found with developers from business units, IT units, and external developers.The Intricacy Adversaries archetype can be further specified by adding additional factors.For example, in case 15, the key decision criterion for non-adoption was that the sophistication of the application to be developed was too high.However, the informant further added that the internal IT capabilities were too low to develop an application outside the LCDP standard, which he emphasised by stating, ''because we have this skillset to work in the standard [

. . . ] So that means what does the [LCDP] framework offer me? I am not just going to use some plugin or JavaScript library'' (I-15
).Therefore, due to the too high (non-standard) sophistication of the application to be developed and the low internal IT capabilities it was decided not to adopt the LCDP.
As outlined above, the factors of high compatibility, high expected efficiency improvements, low internal IT capabilities, and high top management support positively influence the LCDP adoption.However, when combined with a high sophistication of the application to be developed, the result is non-adoption.In the following sections, we present two cases where the positive factors occurred, but the decision was taken not to adopt the LCDP (i.e., cases ten and 24).
In case ten, expected efficiency improvements and top management support were high and had a positive effect on LCDP adoption.In addition, internal IT capabilities were low, which also had a positive effect on the LCDP adoption.However, the sophistication of the application to be developed was high and the usefulness was seen as low, both of which had a negative effect, resulting in the LCDP non-adoption.In this case, the adoption of an LCDP to develop a specialised insurance application was evaluated.There was high top management support, as ''low code is modern, and [the LCDP] was the strategic low code tool'' (I-12).Furthermore, in this case, the aim was to realise the expected efficiency improvements for an internal project, as ''custom development is done in profit centres and not in cost centres'' (I-12).However, the sophistication of the application to be developed was too high for the LCDPs, i.e., ''there was no fit between the platform and the requirements in the end'' (I-12).This resulted in the LCDP not being adopted.
In case 24, compatibility and expected efficiency improvements were high and had a positive effect on LCDP adoption.However, the sophistication of the application to be developed (internal IT capabilities) were high (low), and both had a negative effect on LCDP adoption, which ultimately led to LCDP non-adoption.In this case, the goal was to develop a project management tool, but ''from the beginning, the demand was fuzzy.It was just the main topic that we want to manage our projects better'' (I-16).At the beginning of the evaluation, the aim was to get ''as fast as possible, a cheap solution [an application]'' (I-16), and as there was a ''strong organisational drive'' (I-16) to adopt LCDPs, and therefore, an LCDP was the first choice.However, upon further evaluation of the sophistication of the application to be developed, ''that made no sense at all in the end because it would be extremely difficult to maintain, and these functionalities would in any case not be as easy to reproduce as they are implemented in these professional tools'' (I-16).Moreover, the internal IT capabilities were low, i.e., ''I think this was also a skill problem'' (I-16).Therefore, the decision was not to adopt an LCDP for this application development project.
To summarise the previous sections, firstly, a too high sophistication of the application to be developed is the core factor hindering an LCDP adoption.Secondly, this factor is applicable across platforms and types of developers.Thirdly, even if other factors have a positive effect on LCDP adoption (e.g., expected efficiency improvements or top management support), the effect of the high sophistication of the application to be developed is still stronger (cf.case ten).

A. OVERVIEW
We empirically explored combinations of factors leading to LCDP adoption in work systems with 36 cases.We captured 26 adoption cases and ten non-adoption cases.From these cases, we found three archetypes for LCDP adoption (i.e., Application Development Democratisers, Synergy Realisers, and IT Resource Shortage Mitigators) and one archetype for LCDP non-adoption (i.e., Intricacy Adversaries).In the following sections, we first discuss the theoretical implications of our results and, second, the practical implications.

B. THEORETICAL IMPLICATION 1) COMPARISON OF EFFECTS TO LITERATURE
First, we compare the effects found in our cases with the effects discussed in the literature on CC and SDM adoption, based on our research model published in [12].As shown in Table 5, we found the same effect as discussed in the literature for seven factors.We did not find three factors discussed in the literature in our cases, and for two factors, we found the effect partially (i.e., the literature found mixed effects, but we found only positive or negative effects).We also found two additional factors, and for one factor, we were able to extend the effects found in the literature.The remainder of this section focuses on situations where the empirical effects differ from those found in the literature.
We did not find three factors which are found to be relevant in CC and SDM adoption literature in our cases: first, vendor lock-in is not relevant to the adoption of LCDPs in work systems.I-03 pointed out that it is essential to consider vendor lock-in on an organisational level, but in a post-adoption situation in a work system, ''this does not play any role'' (I-03) anymore.The next factor found in the academic literature, but not in our cases, is training opportunities [12].The informants argued that there are extensive training materials available (''Training materials are openly available'' and ''we try to link to [LCDP vendors'] resources, so to offer [LCDP vendor] learning courses'' (I-14)).Therefore, they did not see it as an important factor in their decision to (not) adopt LCDPs.Another reason why this factor was not found could be that the decision to adopt or not adopt an LCDP is made by people who are already trained.Therefore, 118772 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.they did not consider this factor to be important.Moreover, we could not find the factor previous experience in the cases we analysed.As the informants did not mention these factors, the factors might have no effect on the decision to adopt an LCDP.
There are two factors (security and data privacy concerns and expected working mode improvements) for which we found only some of the effects previously discussed in the literature.The factor of security and data privacy concerns was found in only two cases, indicating a lower importance of the factor.In these cases, the effect is also in line with the majority of the literature (i.e., higher concerns have a negative effect on the adoption) [12].Compared to the literature, only one paper reports a different effect (i.e., high concerns have a positive effect on the adoption [57]).We argue that the result of this paper is not transferable to our findings due to the different research contexts.
In addition, we are in line with most papers that report a positive influence of expected working mode improvements on technology adoption.For LCDPs, this refers to the quick, tangible results outlined by I-21: ''You could really give them something tangible, [. . .] within one or two weeks, that you could really test.[. . . ].And that simply helped enormously to accelerate this [. . .] [development] process.''Our finding is not surprising, as LCDPs are promoted to increase alignment and understanding between business and IT units during application development [11].
We found two new factors: replacement of shadow IT and the sophistication of the application to be developed.The factor replacement of shadow IT is not yet discussed in the academic literature on CC and SDM adoption.We argue that it is not discussed in this literature because these research streams do not focus on replacing shadow IT.
Moreover, some practitioners see the adoption of CC as a mechanism to promote shadow IT and not as a way to reduce it, e.g., [64].However, it is not surprising that we found this factor in our cases, as practitioners, e.g., [65], and academic research have recently discussed this factor, e.g., [11] for LCDPs.The literature on shadow IT also considers LCDPs as a technology to help organisations transform shadow IT development into a positive or legitimate way of developing applications, also referred to as business-managed IT [20], [21], [22], [66].
Finally, we found the additional factor of sophistication of the application to be developed, which is not discussed in the literature on CC and SDM adoption.However, previous research on the challenges of LCDPs highlights the limited functionality, flexibility, and customisation potential [34] of LCDPs, especially for more experienced developers.We argue that these challenges lead to LCDPs being adopted only for less sophisticated applications.
We extended the literature for the factor of internal IT capabilities, as we found a new effect, i.e., both high and low internal IT capabilities positively influence LCDP adoption.High internal IT capabilities with a positive effect on the adoption are already well discussed in the literature [51], [67].
However, for LCDPs, we also found that low internal IT capabilities positively influence LCDP adoption.I-02 argued that as they did ''not have the resources'' to develop an application using traditional development methods (i.e., low internal IT capabilities), the decision was made to adopt an LCDP and develop the application without traditional IT resources.This result is specific to LCDPs, as they are promoted to reduce the barriers and knowledge required for application development, thereby empowering citizen developers to develop applications [11] and closing the internal IT capabilities gap.

2) ADOPTION AND NON-ADOPTION ARCHETYPES
In general, we see that combinations of factors lead to the decision to adopt LCDPs.There are three LCDP adoption archetypes and one LCDP non-adoption archetype.All adoption archetypes have high expected efficiency improvements with a positive effect in common.Therefore, we consider this factor to be necessary for LCDP adoption.Both our informants (e.g., ''good IT groups have always tried to adopt the most productive tool sets they can, and a lot of them are very willing to adopt'' I-08) and LCDP vendors (e.g., ''accelerate all phases of the app development'' [68]) see the expected efficiency improvements as a key factor for LCDP adoption.However, as the same factor, with the same value and effect, is also present in the nonadoption cases, it is not sufficient to explain LCDP adoption.In contrast, in our non-adoption cases, a high sophistication of the application to be developed with a negative effect only occurs in all non-adoption cases.Therefore, we propose to consider this factor as sufficient for LCDP non-adoption.
For the LCDP adoption cases, we found that cases can be part of multiple archetypes (e.g., case two is part of the IT Resource Shortage Mitigators and Synergy Realisers, cf. Figure 1).Furthermore, a negative effect of one factor (e.g., a closed organisational culture, case 33) may be equalised by the positive effect of the other factors.In the following sections, we link our archetypes and their adoption goals to previously discussed reasons why LCDPs are adopted.
First, adoption cases belonging to the Application Development Democratisers archetype aim to broaden the developer base for less sophisticated applications.For this archetype, the concept of citizen developers (i.e., people from the business units with little programming experience) is essential, as they can now develop less sophisticated applications using the LCDP [4].The main advantage of citizen developers is that they have a much deeper understanding of the overall business process [69] that the application to be developed should support.Therefore, this archetype is consistent with the marketing claim of LCDPs to enable citizen developers to develop less sophisticated applications [34].It is also consistent with the literature on business-managed IT, which promotes the democratisation of IT [20], [21], [22], [66].However, governance, compliance, and security policies need to be in place when allowing citizen development to avoid security breaches [4], [21].
Second, adoption cases belonging to the Synergy Realisers archetype aim to efficiently develop applications using already included licenses for LCDPs from existing enterprise systems.In the case of Microsoft's Power Platform, informants emphasised that the LCDP was already part of existing licences and was well integrated into Microsoft's overall ecosystem.As I-18 explained, ''Microsoft did a good job, faded in all these [low code] components everywhere and so that you could not get around it.''As a result, citizen developers could easily use the Microsoft Power Platform to develop applications.Looking at the broader enterprise software vendor space, several other companies have announced low code capabilities in their products in recent years (e.g., ServiceNow [23], Salesforce [24], and Oracle [25]).
Third, adoption cases belonging to the IT Resource Shortage Mitigators archetype aim to develop applications efficiently with limited traditional IT resources.These results are consistent with previous research, e.g., [1] and [11], which found that LCDPs are often used to fill the gap of skilled application developers.Practitioners also emphasise that LCDPs are an option to enable less skilled developers (e.g., student workers) to develop applications [4].Therefore, LCDPs need to be easy to use and should require little training time.
Finally, the main reason for the non-adoption archetype is the high sophistication of the application to be developed.From a research perspective, this result can be explained by the lack of functionality, flexibility, and customisation of the LCDPs [34].Practitioners have the same perception, as they emphasise that LCDPs should only be used for simpler applications.They even emphasise that for more sophisticated applications, development may be impossible or require a significant amount of traditional coding [4].However, the large amount of traditional development contradicts the core idea of LCD.

3) LINK TO THEORY
As discussed in section two, we used a combination of the TOE model and the STS theory as the theoretical lenses for this paper.Based on these theoretical lenses, we derived three tentative propositions, which we will elaborate on in the following sections.
The first tentative proposition was that a combination of factors must be considered when researching LCDP adoption in work systems.Our research confirms this proposition, as all our adoption cases required at least two different factors being present.This finding is also consistent with previous research on combinatorial technology adoption, which claims that only a combination of factors leads to adoption, for 118774 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
The second tentative proposition was that the social sub-system (i.e., structure and people sub-systems) and the technical sub-system (i.e., technology and task sub-systems) must be balanced and jointly optimised [46] for LCDP adoption [12].For this paper, the proposition can be interpreted as follows: first, in each adoption case, at least one factor from the social sub-system and at least one factor from the technical sub-system must occur (to allow the sub-systems to be balanced).Second, in order to optimise the sub-systems, the majority of the factors should have a positive effect.When analysing the three archetypes for LCDP adoption, we see that only the IT Resource Shortage Mitigators archetype had at least one factor from the social sub-system and one from the technical sub-system.For the other two archetypes, only factors from the technical sub-system occurred.This finding suggests that balancing the sub-systems is less relevant when deciding on LCDP adoption.Moreover, the technical subsystem seems to be more important, as illustrated by I-15: ''You are right -this list is rather technical.''The optimisation of sub-systems, however, is core to all LCDP adoption cases, as we found negative effects only in a few cases.However, for these cases, the positive effect of the other factors of the respective sub-system outweighed and equalised the negative effect.When applying this theoretical lens to the non-adoption cases, we see unbalanced sub-systems, as only factors from one sub-system were present in the many nonadoption cases.Moreover, since most factors had a negative effect, the sub-systems are not optimised.As a summary of the previous section, we can see that balancing of subsystems is less important in explaining LCDP adoption (as adoption also occurs with only technical factors).However, optimising sub-systems (i.e., factors that have a positive effect on the sub-systems) is more important for LCDP adoption.
Based on the TOE model, the third proposition was that the environment is important for LCDP adoption [12].We found a few cases (i.e., cases six, seven, 11, 26, and 29) where external pressure (i.e., an environmental factor) was required for the (non-)adoption decision.However, as this is not the case for all archetypes, we can only partially confirm this tentative proposition.We explain this finding by the postadoption focus of our research, i.e., the LCDP had already been introduced at an organisational level, and as the primary decision is to adopt the LCDP for a specific project, the environment may be less important.This finding is also in line with the results of [11], who found that environmental inhibitors are less important for the decision to adopt an LCDP in work systems.
In summary, the adoption of LCDPs can be explained by a combination of different factors.As we have found cases where an LCDP is adopted without balancing the technical and social sub-systems, this does not seem to be necessary.However, in all adoption cases, the sub-systems are optimised, and we conclude that optimisation is important for the decision to adopt the LCDP.Finally, the environmental factors are less important for the LCDP adoption decision, as they are present in only a few cases.

C. PRACTICAL IMPLICATIONS
Based on the characteristics of three archetypes of LCDP adoption and one archetype of LCDP non-adoption, we can derive three practical implications and seven practical starting points for promoting LCDP adoption in work systems.Practitioners can use them to ensure effective and efficient LCDP adoption and reduce risks associated with the adoption.
The first implication for practitioners is that the adoption of LCDPs is not just about citizen development, as the adoption often takes place in the IT unit (cf.IT Resource Shortage Mitigators) and requires the support of the IT unit to be successful.Therefore, the IT unit needs to be involved in the adoption of LCDPs (cf.starting point #2).Moreover, IT managers -sometimes influenced by experienced LCDPaverse developers -may miss the opportunity to make their IT unit significantly more efficient.
Since a high sophistication of the applications to be developed prevents LCDP adoption (cf.Intricacy Adversaries), the second practical implication is that LCDPs should only be used for less sophisticated applications.This implies that practitioners should have clear guidelines and processes about what should and could be developed on the LCDP and where other application development approaches might be a better choice.
The third implication for practitioners is that LCDPs are adopted to increase the efficiency of application development (as indicated by all adoption archetypes).Moreover, our cases also suggest that LCDPs can deliver on this promised increase in application development efficiency.
Based on the practical implications and the adoption goals outlined above, we identified seven practical starting points for LCDP adoption, as shown in Figure 2. The starting points are ordered from more general ones (e.g., creating top management support for LCDP adoption) that apply to all three adoption archetypes to more specific ones that apply only to selected archetypes.
First, work systems should be supported by top management to encourage LCDP adoption.Top management can help allocate resources for LCDP development, overcome resistance, and positively influence organisational culture, which is necessary for all three LCDP adoption archetypes.
Second, because LCDPs change the application development process, the LCDP adoption must be jointly done by business and IT units, as otherwise developers in the IT unit could feel ''threatened.If someone comes along now, like me, and I tell them: guys, I can do exactly what you're doing, but I do it ten times faster than you.They automatically felt threatened'' (I-20).Research on critical success factors for business-managed IT comes to a similar conclusion, suggesting a mutual approach (with people from business and IT units) for the adoption of businessmanaged IT [21].Furthermore, several informants pointed out that this fear stems from a lack of clarity about the LCDP capabilities and scenarios of use.I-01 highlighted that by stating that ''The traditional software developers often have an aversion to [the LCDP] [. . .].However, there are also some colleagues, really traditional software developers, who at some point slip into low-code development with us or work with us once, and then after, let's say, a few beginnings, they appreciate it or actually enjoy working with it.''Organisations should, therefore, educate professional and citizen developers about the capabilities and use cases of LCDPs.
Third, organisations should strive for an open organisational culture with LCDP champions.This point is closely related to #2, as an open organisational culture also promotes alignment between business and IT units on the use of LCDP.In addition, LCDP champions (i.e., people who have already successfully developed LCDP applications) can be the first point of contact for citizen developers to answer potential questions enable them to use LCDPs.I-16 highlighted the benefits of this model: ''I organised a lot of them [Q&A sessions] to really enable the use case owner, with the real problems and app ideas.''This idea of creating LCDP champions who can be easily approached with questions significantly reduces the barriers to entry for LCDPs.
Fourth, as indicated by the Application Development Democratisers and the Intricacy Adversaries archetypes, practitioners need to assess whether the application being developed is of low sophistication.This assessment requires a thorough analysis of the application's requirements.It is crucial to start with this evaluation; otherwise, the decision to adopt an LCDP could be made, but the development is stopped due to unsatisfactory results.For example, I-12 illustrated this by stating: ''There was a project that was stopped [. . .], it was stopped because the implementation has to be done as in custom development.Large data models were built; things were made persistent, which didn't have to be persistent, both from the requirements and the low code solutions.''In this case, the problem was that the sophistication of the application being developed was too high for the LCDP, and therefore, the development had to be stopped.
Fifth, the complexity of the adopted LCDPs should be low, especially if the focus is on citizen development.This factor should be taken into account when selecting the LCDP, as the complexity and capabilities of different LCDPs vary considerably.I-03 pointed out that: ''The [Microsoft] Power Platform is just a bit different.In my opinion, much more easy to use.''Sixth, marketplaces should be created where organisationspecific low code components (e.g., authentication modules or user interfaces) can be found and re-used.I-01 pointed out that they have a marketplace with ''pre-configured interfaces, modules for the authentication, all in all, that you can use instantly for the low code development.This is a key benefit for LCDPs, that [. . .] you can use these modules directly.''A component review process must be in place, to ensure compliance with security guidelines and a high quality of the marketplace components.
Seventh, if organisations already have LCDP licences embedded in existing enterprise systems, they should make them available to a wider developer base (as indicated by the Synergy Realisers archetype).In particular, the Power Platform seems to be well integrated into the Microsoft (licensing) environment, making it easy for professional and citizen developers to start developing applications.However, when offering the existing LCDP licences to a broader developer base, organisations need to have strong governance of the LCDPs to avoid the development of shadow IT [11], [21].

VI. CONCLUSION
In this paper, we captured 36 cases (26 adoption and ten non-adoption cases) and identified three archetypes for LCDP adoption and one for non-adoption.The paper has four main contributions that are useful for researchers and practitioners.
First, based on our research model published in [12], we empirically confirmed ten out of 13 factors leading to LCDP adoption.In addition to the research model, we found two additional factors (i.e., the sophistication of the application to be developed and the replacement of shadow IT).We showed that a high sophistication of the application to be developed is a sufficient factor for LCDP non-adoption.This finding contributes to a better understanding of LCDP adoption and explicitly addresses calls for empirical research on LCDPs [14] and their adoption [34].Practitioners evaluating LCDP adoption can use these results to develop decision criteria for the adoption.
Second, we showed that the decision to adopt LCDPs results from a combination of multiple factors and is a multifaceted phenomenon.Based on these combinations, we derived three archetypes for LCDP adoption (i.e., IT Resource Shortage Mitigators, Application Development Democratisers, and Synergy Realises) and one archetype for LCDP non-adoption (i.e., Intricacy Adversaries).Each archetype can be described with a distinct set of factors.Since combinations of these factors are most important for LCDP adoption, researchers and practitioners should focus on these aspects when analysing LCDP adoption in order to save resources.Furthermore, with this paper, we have confirmed the potential to further explore this topic with other methodologies (e.g., Qualitative Comparative Analysis).
Third, by combining the TOE model and STS theory, this paper is the first to apply a theoretical lens to LCDP adoption in work systems.By applying these theoretical lenses, we have shown that social and technical aspects should be jointly optimised for LCDP adoption.
Fourth, based on the identified LCDP adoption archetypes, we derived seven starting points for LCDP adoption.These starting points and the theoretical lenses also highlight that LCDP adoption is not a traditional technology adoption, as it completely changes the approach to application development.Therefore, technical and social aspects need to be considered when making the decision to adopt LCDP.
Like all research, this paper has limitations.First, we were only able to identify ten cases of non-adoption, which are relatively few.It is much more difficult to identify cases of non-adoption of LCDPs for a variety of reasons.As several informants explained, work systems are still in the early stages of adopting LCDPs and, therefore, started with simple, clear cases of adoption (i.e., there are significantly fewer non-adoption decisions than adoption decisions).In addition, informants may be biased towards talking about ''positive'' outcomes (i.e., adoption) and were, therefore, reluctant to talk about non-adoption.Second, we did not triangulate our findings within cases (e.g., through source triangulation); instead, we identified archetypes of cases across which we triangulated our findings.The rationale for this is that we wanted to have a greater breadth of cases and explore combinatorial effects while still keeping the research project operationally manageable.Third, because we have explored LCDP adoption qualitatively through mini cases, we cannot quantify the strength of the effects (e.g., the strength of the positive effect of low sophistication of the application to be developed on LCDP adoption).Therefore, we cannot determine to what extent the positive and negative effects balance each other out.Fourth, the qualitative mini case study approach has the limitation that it depends on the researcher's ability to capture relevant aspects from the interviews and thus has the risk of being subjective.We mitigated this problem by following methodological guidelines for case study research (e.g., [37]) to ensure rigour (cf.section III-F) and by iteratively discussing the findings in the group of authors.Fifth, most of our cases came from large German organisations, which may limit the generalisability of our findings beyond Germany or to smaller organisations.Therefore, the findings may have limited generalisability beyond our research context.
Based on our findings, we can derive several areas for further research.First, since we found that a high sophistication of the application to be developed is a sufficient factor for LCDP non-adoption, one could explore what drives the sophistication of the application to be developed for LCDPs.In this sense, one could also apply a task-technology fit theory; as in the non-adoption cases, there seems to be a misfit between the task (i.e., developing a sophisticated application) and the technology (i.e., the LCDP).Second, researchers could also focus on small and medium-sized organisations (SMEs), as this study focused on large organisations.SMEs may be more interested in adopting LCDPs as they tend to have fewer development resources than large organisations.Third, we explicitly decided not to conduct a Qualitative Comparative Analysis in this study as we wanted to use an exploratory approach and be open to further factors besides the model of [12].Furthermore, using our research model in [12] with 13 factors would have required more than 8,000 cases for validation, which is not feasible from a resource perspective.However, as we were able to significantly reduce the number of factors relevant to LCDP adoption, a Qualitative Comparative Analysis could be an interesting research avenue to pursue.An example of business-managed IT and Qualitative Comparative Analysis is the publication of [22].Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

FIGURE 2 .
FIGURE 2. Practical starting points for LCDP adoption in work systems.

FIGURE 4 .
FIGURE 4. Overall context information of the cases.

TABLE 2 .
Occurrence of factors in analysed cases; (x) indicates source of factor.

TABLE 5 .
Comparison of effect found in literature with case results; ( * ) additional factor found through open coding.

TABLE 7 .
Semi-structured interview guideline.Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
D. CASE DESCRIPTION