Finds documents with both search terms in any word order, permitting "n" words as a maximum distance between them. Best choose between 15 and 30 (e.g. NEAR(recruit, professionals, 20)).
Finds documents with the search term in word versions or composites. The asterisk * marks whether you wish them BEFORE, BEHIND, or BEFORE and BEHIND the search term (e.g. lightweight*, *lightweight, *lightweight*).
Die Fähigkeit, benötigte Softwareapplikationen effizient bereitstellen zu können, ist für Unternehmen heute ein kritischer Erfolgsfaktor. Gefragt sind signifikante Produktivitätsfortschritte für die professionelle Applikationsentwicklung; einen Lösungsansatz hierzu versprechen sog. Low-Code-Plattformen. Die vorliegende Fallstudie vergleicht zwei mit Low Code durchgeführte Softwareentwicklungsprojekte. Ausgehend von den Low-Code-getriebenen erwartbaren Optimierungspotenzialen wird analysiert, welche Einflussfaktoren eine gelungene Realisierung dieser Potenziale in den Projekten sicherstellen. Eruierte Einflussfaktoren sind: die adäquate Verwendung plattformseitig angebotener Abstraktionsebenen, die Nutzung Low-Code-spezifischer Zusammenarbeitsformen, eine strategische Plattformpositionierung, die Vermeidung statischer Anwendungsszenarien, ein internes Citizen Development auf Anbietendenseite und die richtige Plattformwahl.
Der Verlag bleibt in Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutsadressen neutral.
1 Einführung
Mit zunehmender Digitalisierung müssen Unternehmen immer schneller und flexibler auf sich verändernde Marktanforderungen reagieren. Die Fähigkeit, die steigende Nachfrage nach Informationssystemen schnell und bedarfsgerecht befriedigen zu können, wird für immer mehr Unternehmen zu einem kritischen Erfolgsfaktor. Low-Code-Applikationsplattformen1(Low Code Application Platforms, LCAP) versprechen einen Lösungsansatz: Sie erlauben, Anwendungen durch visuelles Zusammenfügen vorgefertigter Software-Bausteine zu erstellen und individuell anzupassen. Verglichen mit der „herkömmlichen“ Softwareentwicklung heben sie damit die Softwareerstellung auf eine nächste Abstraktionsstufe. Diese weitere Abstrahierung ermöglicht eine beschleunigte Entwicklung und Bereitstellung von Businessapplikationen durch einen breiteren Personenkreis als bis anhin – nicht nur ausgebildete Informatikerinnen und Informatiker können mit Hilfe von LCAPs Applikationen entwickeln, sondern auch Citizen Developer, d. h. Anwendende ohne formale Programmierkenntnisse (Di Ruscio et al. 2022).
Für die professionelle Applikationsentwicklung, also die methodisch-systematische Erstellung von Softwareanwendungen durch Unternehmen für den Eigenbedarf oder als Dienstleistung, ergeben sich damit interessante Perspektiven. So postulieren z. B. Richardson und Rymer (2016), dass LCAPs sowohl Entwicklung als auch Bereitstellung von Applikationen bis zu einem Faktor 10 beschleunigen könnten. Unklar ist jedoch, ob und unter welchen Umständen sich solche Produktivitätssteigerungen in der Praxis erreichen lassen. Berichte zur Verwendung von Low Code zeigen kein einheitliches Bild: während z. B. Aveiro et al. (2023) derartige Potenziale bestätigen, berichten andere von gemischten bis problematischen Erfahrungen in der LCAP-Anwendung, wie z. B. Luo et al. (2021), Martinez und Pfister (2023), Cusch (2023) oder Al Alamin et al. (2021).
Advertisement
Um mit dem Low-Code-Ansatz assoziierte Effekte wie z. B. besagte Produktivitätssteigerungen zu validieren, untersucht die vorliegende Arbeit zwei Projekte zur Entwicklung von Geschäftsanwendungen, die auf Low-Code-Basis von einem weltweit tätigen Schweizer Innovationsdienstleister (nachfolgend als DL bezeichnet) im kundenseitigen Auftrag umgesetzt wurden. Beiden Projekten lag ein agil-iteratives Entwicklungsvorgehen zugrunde; in beiden Projekten wurden Informatikfachkräfte sowie die LCAP von Mendix (mendix.com2) eingesetzt. Die Verwendung einer LCAP für die Modellierung, Implementation, Validierung und Inbetriebnahme von Anwendungen kann als eine den Entwicklungsprozess optimierende Massnahme interpretiert werden. Die Wirkung dieser Optimierung lässt sich dabei in den Dimensionen Zeit-Kosten-Qualität-Flexibilität des u. a. aus dem Prozessmanagement bekannten „magischen Vierecks“3 beschreiben (Dumas et al. 2021). D. h., der Optimierungsschritt kann eine bessere (oder schlechtere) Zeiteffizienz des Entwicklungsprozesses zur Folge haben, weniger (oder mehr) Ressourcen pro Prozessinstanz benötigen, den qualitativen Output des Entwicklungsprozesses verbessern (oder verschlechtern) oder auch die Fähigkeit zur Adaption an Gegebenheiten und Veränderungen erhöhen (oder beschränken): Denkbar ist z. B. eine Beschleunigung der Entwicklungsarbeiten durch den Einsatz von Low Code Technologien (Zeit), aber auch die Generierung neuer Lizenzierungs- und Ausbildungsaufwände (Kosten) sowie veränderte Umsetzungsmöglichkeiten (Qualität, Flexibilität).
Diese neue Sichtweise auf die Low-Code-gestützte professionelle Applikationsentwicklung bildet also den Rahmen für die vergleichende Fallstudie zu den beiden vom DL durchgeführten Projekten: Über semistrukturierte Interviews werden die Ausprägungen der Projekte bzgl. der Dimensionen Zeit-Kosten-Qualität-Flexibilität ermittelt und zum über die Analyse vorhandener Studien ermittelten erwartbaren Optimierungspotenzial einer LCAP in Relation gesetzt. Ein besonderes Augenmerk wird dabei auf Einflussfaktoren gelegt, die sich aus der Fallstudie ableiten und die in der Praxis für eine Absicherung und Stärkung des Optimierungspotenzials von Low Code für die professionelle Anwendungsentwicklung sorgen. Insgesamt ergibt sich damit für die vorliegende Arbeit ein Vorgehen, das sich an folgenden drei Forschungsfragen orientiert:
FF1
Literaturbasierte Analyse der Auswirkungen des Einsatzes einer LCAP auf die professionelle Applikationsentwicklung – welche zeit-, kosten-, qualitäts- und flexibilitätsbezogenen Auswirkungen hat der Einsatz einer LCAP laut bestehender Literatur auf die professionelle Applikationsentwicklung?
FF2
Vergleichende Überprüfung des erwartbaren Optimierungspotenzials von LCAP in zwei exemplarischen Projekten – wie bestätigt sich das theoretisch erwartbare Optimierungspotenzial von LCAP in Bezug auf Zeit, Kosten, Qualität und Flexibilität in spezifischen Anwendungsfällen?
Advertisement
FF3
Identifikation und Extraktion von Einflussfaktoren zur Sicherung des Optimierungspotenzials in der Praxis – welche Einflussfaktoren aus den untersuchten Anwendungsfällen sichern und stärken das Optimierungspotenzial von LCAP in der Praxis?
Im Vorgehen zur Beantwortung dieser Forschungsfragen werden zwei Zielsetzungen verfolgt:
Z1
Analyse der Implementierung der Low-Code-basierten Softwareentwicklung in einem Dienstleistungsunternehmen anhand zweier Projekte; dabei Fokussierung auf den Vergleich beider Projekte mittels Bewertung hinsichtlich der vier Dimensionen Zeit-Kosten-Qualität-Flexibilität des „magischen Vierecks“.
Z2
Extraktion von Faktoren, die die Realisierung Low-Code-getriebener Optimierungspotenziale beeinflussen.
Die abgeleiteten Einflussfaktoren dienen als Beitrag für das bessere Verständnis der Voraussetzungen für den erfolgreichen Einsatz von Low-Code-Plattformen in der professionellen Softwareentwicklung.
2 Auswirkungen des Einsatzes einer LCAP auf den Applikationsentwicklungsprozess – Stand der Forschung
Im Folgenden werden die Ergebnisse einer systematischen Literaturanalyse nach Webster und Watson (2002) zusammengefasst. Diese fokussiert auf empirische Arbeiten, welche auf Basis genügender Grundgesamtheiten Praxiserfahrungen mit Low-Code-Ansätzen in der professionellen Softwareentwicklung auswerten4 (FF1). Damit lassen sich die Erfahrungen ausreichend verlässlich als Auswirkungen auf die Dimensionen Zeit-Kosten-Qualität-Flexibilität abbilden.
Durchgeführt wird die Recherche auf der Web of Science Core Collection und dem Web of Science Preprint Citation Index (webofscience.com). Dabei wird eine Einschränkung auf solche Quellen vorgenommen, die einen Bezug zum Thema Low Code haben und zudem ab 2021 publiziert wurden, um Betrachtungen auf Basis genügend aktueller Low-Code-Technologien sicherzustellen. Ein manuelles Filtern nach umfragebasierten oder quantitativ-empirischen Analysen zu Praxiserfahrungen in der Verwendung von Low Code liefert acht im Detail zu analysierende Quellen, wobei zwei Quellenpaare von gleicher Autorenschaft zusammengefasst betrachtet werden: In Luo et al. (2021) werden Low-Code-bezogene Foren-Diskussionen klassifiziert. Alsaadi et al. (2021) fragen nach den Gründen, warum LCAP eingesetzt werden. Käss et al. (2023a) gehen Treibern und Bremsfaktoren einer LCAP-Einführung nach, die sie in technologie-, organisations- und umgebungsbezogene Faktoren weiterentwickeln (Käss et al. 2023b). Al Alamin et al. (2021, 2023) fokussieren auf technische Herausforderungen einer LCAP-basierten Applikationsentwicklung, während Rafi et al. (2022) das Potenzial von Low Code aus der DevOps Perspektive beleuchten. Martinez und Pfister (2023) schliesslich befragen LCAP-Anwendende, Citizen Developer wie IT-Experten, eines grossen Bauunternehmens.
In die Betrachtungen zudem einbezogen wird ein DZone Trend-Report, der die Perspektive von Software Professionals auf den Low-Code-Ansatz analysiert (Esposito 2021).
Die erwähnten Quellen werden nach Hinweisen zu praktischen Auswirkungen der Verwendung von Low-Code-Plattformen durchsucht. Jede identifizierte Praxiserfahrung wird einer Dimension zugeordnet und sorgt für einen Impuls „+1“ auf die Dimension, wenn die Praxiserfahrung als Verbesserung zur „herkömmlichen“ Softwareentwicklung und -bereitstellung interpretiert werden kann, „−1“ im entgegengesetzten Fall und „0“ im neutralen oder widersprüchlichen Fall. Normalisiert5 ergeben sich damit für die Dimensionen Zeit-Kosten-Qualität-Flexibilität folgende Auswirkungen, die in Abb. 1 und Tab. 1 illustriert werden:
Abb. 1
Optimierter Applikationsentwicklungsprozess – die Wirkung einer LCAP auf die Dimensionen Zeit-Kosten-Qualität-Flexibilität im Überblick (vgl. Tab. 1)
Optimierter Applikationsentwicklungsprozess – die Wirkung einer LCAP auf die Dimensionen Zeit-Kosten-Qualität-Flexibilität gem. analysierter empirischer Quellen (vgl. Abb. 1)
Der Einsatz einer LCAP sorgt für eine beschleunigte Applikationsentwicklung – das geht aus der Analyse der betrachteten Quellen insgesamt klar hervor. Die Beschleunigung drückt sich in kürzeren Projektlaufzeiten bzw. kürzeren Iterationszyklen aus. Für die Kundinnen und Kunden eines Unternehmens bereitgestellte Low-Code-Anwendungen reduzieren damit ihre Time to Market, was den Ansatz insbesondere auch für das Erstellen von Minimum Viable Products, zum Austesten neuer Geschäftsideen interessant macht.
Dimension Kosten:
Die LCAP-bedingte Beschleunigung der Applikationsentwicklung sorgt auch für eine Reduktion der einzusetzenden Ressourcen. Zudem lässt sich durch Übertragung ausgewählter Entwicklungsarbeiten auf Citizen Developer der Einsatz teurer Informatikkompetenz reduzieren. Der Einsatz einer zentral überwachten LCAP kann auch helfen, Folgekosten einer unkontrollierte „Schatten-IT“ einzufangen bzw. zu vermeiden. Diese Einsparungen werden gedämpft durch neue Kostenpositionen für die Integration, Lizenzen und den Betrieb einer zusätzlichen Plattform, für die Governance eines allfälligen Citizen-Developments sowie – trotz des seitens Plattformhersteller mitunter gerne postulierten Einfachheit des Ansatzes – für den notwendigen Knowhow-Aufbau. Insgesamt präsentiert sich die Kostendimension also ausgeglichen.
Dimension Qualität:
Die Qualitätsentwicklung gilt es bei Einführung einer LCAP im Blick zu behalten. Den Opportunitäten aus plattformgetriebener hochagiler6 Zusammenarbeit zwischen anforderungsgebender und umsetzender Seite stehen Einschränkungen in den Möglichkeiten zum Customizing der durch die Plattform bereitgestellten Softwarebausteine gegenüber. Als herausfordernd werden auch die Themen Plattformperformance und -skalierbarkeit eingeschätzt. Weitere Aspekte wie Integrationsfähigkeiten von LCAP, die generierbare Softwarequalität und damit verbundenen Vorkehrungen zur Fehlervermeidung, die mit LCAP einhergehenden Sicherheits- und Compliance-Risiken sowie die Unterstützung in Fehlersuche (Debugging) und Wartung zeigen sich uneinheitlich bewertet. Das Thema Wartung schliesslich könnte sich problematisch entwickeln, wenn die von einer LCAP vorgegebenen Nutzungspfade verlassen werden.
Dimension Flexibilität:
In der Dimension Flexibilität zeigen sich tendenziell Vorteile, wenn ein Citizen Development das knappe Gut vorhandener Informatikkompetenz entlastet, denn Umsetzungen können auf mehr Ressourcen verteilt werden. Insbesondere reduzieren sich fachseitig die Abhängigkeiten von IT-Abteilungen bzw. eingekauften IT-Dienstleistenden. Als einschränkend hingegen werden der mit dem Beizug einer LCAP einhergehende Vendor Lock-in sowie der oft fehlende Zugang zu generiertem Code bzw. die fehlenden Übertragungsmöglichkeiten von Lösungen auf alternative Plattformen eingeschätzt. Neutral fällt schliesslich die Bewertung der von Plattformen angebotenen Möglichkeiten zur Wiederverwendbarkeit entwickelter Lösungsbestandteile aus.
Der Mehrwert eines LCAP-Einsatzes im Rahmen einer professionellen Softwareentwicklung ist also durchaus gegeben, allerdings in erster Linie für die Dimension Zeit. Um Hinweise abzuleiten, wie sich das Wertpotenzial in den Dimensionen Zeit-Kosten-Qualität-Flexibilität sichern und stärken liesse, wird im Folgenden eine Fallstudie über zwei Low-Code-basierte Projekte durchgeführt. Bei den untersuchten Anwendungsfällen handelt es sich um von einem grösseren, weltweit tätigen Schweizer Innovationsdienstleister (nachfolgend als DL bezeichnet) auf Basis der Mendix LCAP durchgeführte Applikationsentwicklungen, die im Auftrag zweier mittelständischer Organisationen umgesetzt wurden. Die erarbeitete komparative Fallstudie beschreibt beide Projekte im Detail und setzt sie bzgl. inhaltsbezogener (Auftraggebende, Entwicklungsziele, Zielgruppen) sowie managementbezogener und damit auf die LCAP-getriebenen Optimierungsdimensionen abbildbare Projektmerkmale (Projektlaufzeit – Zeit, eingesetzte Ressourcen – Kosten, Vorgehensweise – Qualität/Flexibilität) in Relation (FF2).
Die beiden untersuchten Projekte unterscheiden sich deutlich in Laufzeit, Ressourcenumfang und Vorgehen. Damit können Einflussfaktoren erwartet werden, die in einem Projekt vorhanden sind – und dort entsprechend distinktive Wirkung zeigen – und im anderen nicht. Die Fallstudienerhebung basiert auf drei ca. einstündigen aufgezeichneten semistrukturierte Interviews mit Mitarbeitenden des DL. Bei den Mitarbeitenden handelt es sich um einen direkt in die Umsetzungsarbeiten beider Projekte involvierten Seniorentwickler, einen Seniorentwickler in beratender sowie ein Linienmanager in steuernder Funktion. Alle drei Mitarbeitende weisen mehrjährige praktische Erfahrung in der Verwendung unterschiedlicher Low-Code-Technologien auf. Die Interviewrunden sind offen konzipiert, die Gespräche beinhalten neben inhaltsbezogenen Fragen zu den beiden Entwicklungsprojekten folgende managementbezogene Leitfragen: Welche Potenziale konnten dank des Einsatzes einer LCAP in den Projekten realisiert werden; welche Low-Code-Plattformeigenschaften waren dafür relevant? Welche Herausforderungen waren im Hinblick auf den Einsatz der LCAP in den Projekten zu bewältigen; welche Low-Code-Plattformeigenschaften standen im Weg, waren unzureichend? Welchen Veränderungen haben sich aufgrund der Low-Code-Entwicklung im Softwareentwicklungsprozess ergeben?
Auf Basis der Gesprächstranskripte erfolgt neben einer Zusammenfassung eine induktive Kategorienbildung, aus denen inhalts- und managementbezogene Projektmerkmale sowie Einflussfaktoren auf das mit einem LCAP-Einsatz einhergehende Optimierungspotenzial abgeleitet werden.
Nachfolgend werden die beiden Projekte kurz dargestellt.
3.1 Offertprozess für Unternehmenskunden bei einer Schweizer Krankenversicherung (Projekt 1)
Die Schweizer Krankenversicherung beschäftigt rund 2000 Mitarbeitende und zählt mehr als 1,5 Mio. Versicherte zu ihren Kundinnen und Kunden, darunter etwa 30.000 Unternehmen, die eine Unfall- oder Krankentaggeld-Versicherung (KTGV) abgeschlossen haben.7
Die Offertstellung und die Berechnung der Prämien ist für Krankenversicherer eine grosse Herausforderung. So haben nicht nur jeder Kanton und jeder Branchenverband eigene Regeln (Gryps 2024), auch berechnet sich die Prämienhöhe abhängig von unterschiedlichen Parametern, z. B. Alter, Geschlecht und Gesundheitszustand der Mitarbeitenden, dem bisherigen Schadensverlauf und der vereinbarten Wartefrist.
Aufgrund dieser Komplexität, der geringen Standardisierung und wegen des geringen Marktvolumens nur partiell vorhandener Standardsoftware wird der Offertprozess für das KTGV bei vielen Versicherungen ungenügend mit Software unterstützt. Auch bei diesem Versicherungsunternehmen war dieser Prozess stark durch mehrere Excel-Dateien in oft unterschiedlichen Versionen bestimmt. Die Kommunikation zwischen den Prozessbeteiligten erfolgte per Mail oder Telefon, im Prozessverlauf getroffene Entscheidungen waren im Nachhinein nicht mehr oder nur mit grossem Aufwand nachvollziehbar. Der Offertprozess wurde als umständlich, langwierig, intransparent und fehleranfällig empfunden. Da viele Mitbewerbende vergleichbare Probleme haben, kann eine signifikante Verbesserung des Prozesses bezüglich Zeit und Qualität für eine Versicherung daher zu einem relevanten Erfolgsfaktor werden. Diese Chance wollte die Krankenversicherung nutzen, entsprechend verfolgte sie einen ambitionierten Zeitplan: In möglichst kurzer Zeit sollte eine Leading-Edge-Lösung zur Unterstützung des Offertprozesses entwickelt werden mit dem Ziel, eine standardisierte, transparente und gesetzeskonforme Offertstellung für Krankentaggeld-Versicherungen zu ermöglichen. Die Applikation soll den Mitarbeitenden die notwendigen Arbeitsschritte und deren Abhängigkeiten transparent machen, sie schrittweise durch den Prozess führen und auf mögliche Fehler oder in der Offerte noch fehlende Elemente hinweisen. Die einfache Integration in bestehende Umsysteme war ebenfalls eine wichtige Anforderung.
Gemeinsam mit der auftraggebenden Versicherung wurde beschlossen, die Applikation auf Basis der Low-Code-Plattform Mendix zu realisieren, dies aufgrund folgender Überlegungen bzw. Erwartungen:
a.
Der Offertprozess durchläuft viele In‑/Output-intensive Aktivitäten und entwickelt sich beständig weiter. Die Erwartung war, dass mit Mendix die Benutzeroberflächen aufgrund der vorgefertigten Programmbausteine einfach und schnell konfiguriert werden können.
b.
Anwenderinnen und Anwender können in der Gestaltung der Benutzeroberflächen und im Prototyping früh eingesetzt werden, so dass kürzere Sprints möglich werden. Die Verwendung der in der Plattform „eingebauten“ Kollaborationsfunktionen sollten zudem die Zusammenarbeit zwischen den Projektmitarbeitenden unterstützen.
c.
Die Mendix-Umgebung lässt sich relativ einfach in die bestehende Systemlandschaft integrieren.
d.
Es gelingt ein Einstieg in die „Low-Code-Welt“ mit dem Ziel, die Mendix-Plattform auch für weitere neue Applikationen und für das Citizen Development zu nutzen.
Von o. a. Zieldefinition und einem grob umrissenen Anforderungskatalog ausgehend wurden iterativ die Berechnungslogiken, die Benutzeroberfläche sowie die notwendigen Teilprozesse konzipiert und umgesetzt. Realisiert wurde das Projekt durch ein interdisziplinäres Team, das sich aus kunden- und DL-seitigen Spezialisten in den Bereichen Projektleitung, Software-Architektur, Business-Analyse, User Experience und Entwicklung zusammensetzte. Die tatsächliche Projektlaufzeit betrug schlussendlich 24 Monate.
3.2 Entsorgungsinformationen für die Bewohnenden einer Schweizer Stadt (Projekt 2)
Das zweite beschriebene Projekt startete aus einer anderen Ausgangslage. Eine Schweizer Stadt mit rund 40.000 Einwohnern wollte den Bürgerinnen und Bürger zuverlässig und immer aktuell Informationen rund um die Entsorgung und über Entsorgungstermine bereitstellen. Dazu sollte eine mobile Applikation mit folgenden Funktionalitäten entwickelt werden: Bereitstellung aktueller Entsorgungstermine und Routen; standortbasierte Informationen zum Auffinden nächstgelegener Entsorgungsstellen, deren Angebot und Öffnungszeiten; Push-Benachrichtigungen über z. B. wichtige Neuigkeiten oder Änderungen im Zusammenhang mit der Abfallentsorgung; Hilfestellungen und Empfehlungen für die Entsorgung unterschiedlicher Abfallarten. Neben der mobilen Applikation wurde eine webbasierte Applikation für das zentrale Stammdatenmanagement und für Administrationsaufgaben entwickelt. Die mobile App sollte von den App Stores geladen und registrierungsfrei genutzt werden können.
Anders als in Projekt 1 war die Mendix Plattform für dieses Projekt durch den Auftraggebenden gesetzt, der damit das technische Fundament für eine schnelle Applikationsentwicklung auf gleicher Plattform legen wollte. Weil der DL bereits über Mendix-Expertise verfügte, entschied sich die Stadt für den DL als Implementierungspartner.
Die Applikation wurde als „native App“ bereitgestellt. Das Projekt bestand im Kern aus zwei Personen, dem Auftraggebenden und dem Entwickler seitens DL. Ausgehend von der Zieldefinition wurden die wesentlichen Anforderungen als Epics formuliert (vgl. z. B. Pohl und Rupp 2021). Die Epics wurden iterativ abgearbeitet: Der Entwickler erarbeitete direkt auf Mendix Vorschläge zur Implementierung der Epics, diese wurden im zweitägigen Rhythmus mit dem Auftraggebenden evaluiert, angepasst, getestet und freigegeben. Auf diese Weise konnte das Projekt innerhalb von 20 Arbeitstagen nach Projektstart realisiert werden.
Tab. 2 setzt inhaltsbezogene (Auftraggebende, Entwicklungsziele, Zielgruppen) und managementbezogene Projektmerkmale (Projektlaufzeit, eingesetzte Ressourcen, Vorgehensweise) der beschriebenen Projekte in Relation. Die managementbezogenen Projektmerkmale korrespondieren mit den entwicklungsprozessbezogenen Dimensionen Zeit, Kosten und Qualität bzw. Flexibilität, die durch den Einsatz der Mendix-LCAP beeinflusst werden.
Tab. 2
Vergleich der untersuchten Projekte anhand verschiedener Projektmerkmale
Projektmerkmale
Projekt 1
Projekt 2
Inhaltsbezogene Projektmerkmale
Auftraggebende
Ein Krankenversicherungsunternehmen
Eine Stadtverwaltung
Entwicklungsziele
Aufbau einer Plattform zur Digitalisierung des Krankentaggeld-Offertprozesses
Aufbau einer Native Mobile App mit Informationen und Erinnerungs‑, Feedback- und Bestellfunktionen zum Thema Entsorgung, Aufbau einer Oberfläche für die App Administration inkl. Datenmanagement
Zielgruppen
Interne Mitarbeitende des Krankenversicherungsunternehmens
Mobile App: Stadtbewohnerinnen und Stadtbewohner
Administrations-App für das Datenmanagement: Interne Mitarbeitende der Stadtverwaltung
Managementbezogene Projektmerkmale
Korrespondierende Dimensionen des zugrundeliegenden Entwicklungsprozesses
Projektlaufzeit
Zeit
2 Jahre
4 Wochen
Eingesetzte Ressourcen (FTE)
Kosten
5,5 FTE Entwicklung inkl. Architektur
0,5 FTE UI Expertise
0,3 FTE formelles Projektmanagement
1 FTE
Vorgehensweise
Qualität/Flexibilität
Agil nach SCRUM:
– Alle 2 Wochen Review Meeting mit den Auftraggebenden
– Kontakt Auftraggebende/Entwicklung unter der Woche nach Bedarf
– Jede Woche Backlog Refinement
Requirements/User-Experience-Design:
– Vision → Epics → Stories
– User-Experience-Design mit Figma, dann Übernahme, Anpassung und Implementierung in Mendix
Qualitätssicherung:
– Coding Guidelines
– Automatisierte Unit Tests
– Automatisierte funktionale End-to-End Tests
Wartbarkeit:
– Coding Guidelines
– Lösungsdokumentation
Einfaches agil-iteratives Vorgehen:
– Auftraggebender definiert Vision und Epics
– Entwickler implementiert ersten Vorschlag in Mendix, Verfeinerung und Implementierung im zweitägigen Rhythmus gemeinsam mit dem Auftraggebenden
Requirements/User-Experience-Design:
– Feature Entscheide direkt am aktuellen Produktinkrement
– Kein explizites Backlog
– Keine vorgängiges explizites User-Interface-Design
Qualitätssicherung:
– Automatisierte Unit Tests
– Keine automatisierten funktionalen End-to-End Tests
Besonderheiten
– Hohe Komplexität in den zu verwendenden Berechnungslogiken
– Dynamisches (zustandsabhängiges) User Interface
– Keine Authentifizierung für Endbenutzende notwendig
– Authentifizierung nur für Applikationsverantwortliche
– Keine Integration von Datenquellen aus Umsystemen
FTE Full Time Equivalent
Es fällt auf, dass die mit dem Einsatz einer LCAP erwartbare positive Wirkung auf die Zeit- und Kostendimension (vgl. Abb. 1) im Projekt 1 wenig, im Projekt 2 hingegen klar beobachtbar ist. Diese Differenzen sind nur teilweise durch inhaltsbedingte Unterschiede in den Projekten erklärbar und ein Beispiel, warum sich die in Kap. 4 vorgenommene Suche nach konkreten Einflussfaktoren lohnt, welche die Realisierung des LCAP-getriebenen Optimierungspotenzials ermöglicht haben bzw. hätten.
4 Das Optimierungspotenzial von Low Code ausschöpfen – abgeleitete Einflussfaktoren
Die beschriebenen Projekte sind Beispiele für den Einsatz einer Low-Code-Plattform in Projekten des DL. Welche Einflussfaktoren E lassen sich nun aus den Projekten ableiten, die das mit einem LCAP-Einsatz einhergehende Optimierungspotenzial sichern bzw. stärken (FF3)?
Tab. 3 bietet einen Überblick über die abgeleiteten Einflussfaktoren und zeigt auf, welche der Dimensionen Zeit-Kosten-Qualität-Flexibilität jeweils gestützt werden.
Tab. 3
Eruierte Einflussfaktoren, die das LCAP-getriebene Optimierungspotenzial in den Dimensionen Zeit-Kosten-Qualität-Flexibilität sichern bzw. stärken
Einflussfaktor
Stärkung Potenzial in Dimension
Abgeleitet aus
Z
K
Q
F
Projekt 1
Projekt 2
E1
Passende Wahl und adäquate Verwendung der angebotenen Abstraktionsebenen
Vermeidung „Over-Customizing“: eine Abstraktionsebene adäquat verwenden, auf andere Abstraktionsebene wechseln, wenn nötig
×
×
·
·
• Zeit- und kostenintensives „Over-Customizing“ verwendeter Frontend-Bausteine („klassisches“ Vorgehen im UI-Design; Anforderungen sind exakt umzusetzen)
• Komplexe Businesslogik effizient umgesetzt (Sinnvolles Ausweichen auf tiefere Abstraktionsebene)
• Applikation aufwandseffizient umgesetzt (Framework in vorgesehener Funktionslogik verwendet)
E2
Engere Zusammenarbeit mit Auftraggebenden
Low-Code-getriebene, agil-iterative Möglichkeiten zur Synchronisierung von Auftraggebenden- und Umsetzendenseite forciert nutzen
·
·
×
·
• LCAP-getriebene Möglichkeiten wenig genutzt (Anforderungsfestlegungen anhand separater UI-Designs)
• LCAP-getriebene Möglichkeiten gut genutzt (unmittelbare Umsetzung und sofortiges Ausprobieren von Anforderungen auf der LCAP, unmittelbares Ableiten von Anpassungs- und Weiterentwicklungsvorschlägen)
E3
Strategische LCAP-Positionierung
LCAP als strategische Plattform positionieren, damit mehrere Applikationen auf LCAP realisieren und Plattform auslasten
·
×
·
·
• Mittelfristig verbesserte Kosteneffizienz durch geplante Mehrfachnutzung der LCAP (auftraggebende Organisation positioniert LCAP strategisch)
E4
Die richtigen Projekte auf LCAP realisieren
Projekte mit begrenztem Potenzial: Applikationen, die statische Prozesse unterstützen
Projekte mit erhöhtem Potenzial: Applikationen, die dynamische Prozesse unterstützen; die benötigte Parametrisierung erfolgt vorallem auf hoher Abstraktionsebene
×
×
·
×
• Hat Entscheid ‚pro Low Code‘ im Projekt beeinflusst (zugrundeliegende Prozesse werden als nicht statisch eingeschätzt)
• LCAP-getrieben flexibles und aufwandseffizientes Anpassen der Applikation, mit Einschränkungen (Änderungseingriffe teilweise auf tiefer Abstraktionsebene)
• LCAP-getrieben flexibles und aufwandseffizientes Anpassen der Applikation (Änderungseingriffe nur auf hoher Abstraktionsebene)
E5
Als Lösungsanbietender internes Citizen Development etablieren
·
·
×
×
• Optionen zur Ressourcenflexibilisierung und zum verbesserten Anforderungs-Fit (Erkenntnis: Als Lösungsanbietender könnte man stärker auf internes Citizen Development setzen)
– Customizability auf angebotenen Abstraktionsebenen
·
·
×
·
– Integration Umsysteme
·
·
×
·
– Performance Tuning
·
·
×
·
– Testing/Debugging
·
·
×
·
– Unterstützung Kollaboration
·
·
×
·
– Versionierung Artefakte
·
·
×
·
– Integration Softwareentwicklungswerkzeuge
·
·
×
·
– Wiederverwendbarkeit Komponenten
·
·
·
×
4.1 E1: Zeit- und kostenbezogene Optimierungspotenziale durch passende Wahl der Abstraktionsebene sichern
Nach Einschätzung des DL kann heute grundsätzlich jede Problemstellung Low-Code-basiert umgesetzt werden – bei entsprechender Plattformwahl (siehe dazu auch E6): die Wahl der LCAP definiert, inwieweit sich eine Anforderungslage mit Hilfe dieser Plattform umsetzen lässt, in welchen Anwendungsaspekten also die Plattform welchen Grad an Customizability bereitstellt. Je feingranularer und flexibler die Customizing-Möglichkeiten, desto geringer ist jedoch der erreichte Abstraktionsgrad. Tatsächlich setzen Plattformen hier unterschiedliche Akzente; am flexibelsten zeigen sich solche Plattformen, die bei Bedarf ein „Aufbrechen“ des standardmässig bereitgestellten Abstraktionsgrads ermöglichen – z. B. durch Anpassen oder Hinzufügen von in einer „klassischen“ Programmiersprache formulierten Code-Fragmenten. Um das Effizienzpotenzial einer solchen LCAP in den Dimensionen Zeit und Kosten voll auszuschöpfen, ist die richtige Wahl und adäquate Verwendung der angebotenen Abstraktionsebenen entscheidend:
Wenn z. B. versucht wird, die plattformseitig bereitgestellten Programmbausteine spezifisch zu adaptieren, kann erheblicher Overhead generiert werden. Ein solches „Over-Customizing“ zeigt sich häufig auch bei der Einführung betrieblicher Standardsoftware: Um spezifische Anforderungen mittels einer nur bedingt passenden Standardsoftware zu erfüllen, wird diese mit grossem Aufwand so umkonfiguriert oder durch Hilfsprogramme ergänzt, dass die mit der Verwendung einer Standardsoftware verbundenen Vorteile aufgewogen oder sogar überkompensiert werden (Schwarz 2022).
Auf der anderen Seite können sich die auf höherer Abstraktionsebene angebotenen Bausteine für das Umsetzen gegebener Anforderungen als unhandlich oder nicht sinnvoll erweisen – ein Wechsel auf die tiefere Abstraktionsebene sorgt dann für schlankere Lösungen.
Beide Phänomene lassen sich im Projekt 1 beobachten: Statt die von der Mendix-Plattform angebotenen Frontend-Bausteine in ihrer vorgesehenen Funktionslogik zu verwenden, wurden sie auf einer tieferen Abstraktionsebene erheblich modifiziert. Diese Anpassungen im plattformseitigen User Interface (UI) Framework führten zu einem signifikanten Anstieg des Entwicklungsaufwandes. Interessant ist der Grund für das „Over-Customizing“ der Mendix-Frontend-Bausteine: Das UI-Design wurde zunächst gemeinsam mit Hilfe der Designplattform Figma (figma.com) erstellt. Dabei wurde keine Rücksicht auf die der Mendix-Plattform zugrundeliegende UI-Philosophie genommen – in der Annahme, dass der Transfer auf Mendix problemlos wäre. Die Erwartungen erfüllten sich nicht, die Umsetzung des Figma-Designs in die Mendix-Umgebung erwies sich als aufwändig. Eine Rückkehr auf Mendix’ UI-Philosophie kam aber nicht mehr in Frage: Die Auftraggebenden hatten bereits erhebliche Aufwände in das UI-Design unter Figma investiert und wollte dieses nun auch in der Applikation umgesetzt sehen. Hingegen wurde im Projekt 1 schnell erkannt, dass die hohe Komplexität in den zu berücksichtigenden Berechnungslogiken auf oberster Abstraktionsebene der Mendix-Plattform nur über eine grosse Zahl an visuell modellierbarer Mendix-Microflows hätte implementiert werden können. Dieser Teil wurde daher tieferer Abstraktionsebene „klassisch“ in der Programmiersprache Java implementiert. Dieser Entscheid wurde von den Projektbeteiligten auch im Rückblick als ressourcenschonender eingeschätzt.
Im untersuchten Projekt 2 wurden Frontends und Anwendungslogik ausschliesslich unter Verwendung der vom Mendix-Framework bereitgestellten Software-Bausteine gemäss ihrer vorgesehenen Funktionslogik aufgebaut. Auf eine vollständige Anforderungsanalyse wurde verzichtet, der Auftraggebende entwickelte und konkretisierte seine Vorstellungen im engen Austausch mit dem Entwickler, ohne die Standardfunktionsweise der Bausteine grundsätzlich infrage zu stellen.
Insgesamt gilt also, die Einschränkungen in den Customizing-Möglichkeiten auf bestimmter Abstraktionsebene, also plattformbedingte Einschränkungen in der Dimension Qualität, zu akzeptieren, um Potenziale in den Dimensionen Zeit und Kosten zu realisieren. Nicht „gegen“ das vom LCAP bereitgestellte Framework implementieren, stattdessen das Framework im vorgedachten Sinne einsetzen – so sollte die Devise lauten.
4.2 E2: Qualitätsbezogene Optimierungspotenziale durch engere Zusammenarbeit mit Auftraggebenden stärken
Die LCAP-getriebenen Möglichkeiten einer engen agil-iterativen Synchronisierung von Auftraggebenden- und Umsetzendenseite wurden in Projekt 2 besser genutzt, entsprechendes Potenzial in der Dimension Qualität also besser realisiert als in Projekt 1:
In Projekt 1 wurde agil nach SCRUM entwickelt (scrum.org), wobei die anforderungsbezogene Alignierung zwischen Auftraggebenden- und Umsetzendenseite vor allem anhand von den Entwicklungsarbeiten entkoppelt erstellter User Stories und UI-Designs vorgenommen wurde – in der Erhebung der Fallstudie bezeichnete einer der Interviewpartner dieses Vorgehen als „theoretisch“. Trotzdem unterstützte der LCAP-Einsatz die Auftraggebenden-Umsetzenden-Alignierung: Für die Erläuterung erarbeiteter Zwischenergebnisse kamen regelmässig auf der Plattform erzeugte visuelle Logik-Festlegungen zum Einsatz.
In Projekt 2 wurde auf eine vollständige Anforderungsanalyse verzichtet; der Auftraggebende entwickelte und konkretisierte seine Vorstellungen im engen Austausch mit dem Entwickler. Hier kam eine neue Form der Zusammenarbeit zwischen Auftraggebendem und Softwarelieferant zum Zug, die durch den Low-Code-Ansatz begünstigt wird: die vom Auftraggebenden nur grob festgelegten Anforderungen werden unmittelbar in der Plattform umgesetzt, das Ergebnis kann sofort ausprobiert, Anpassungs- und Weiterentwicklungsvorschläge abgeleitet werden. Damit wurde ein klareres und besser validiertes Verständnis über zu Erreichendes und damit verbundenen Lösungsvarianten inklusive ihrer Vor- und Nachteile erreicht.
Trotzdem verblieb nach rückblickender Einschätzung des DL auch in Projekt 2 noch ungenutzter Spielraum: Der Einsatz einer LCAP impliziert ein Zusammenwachsen und Verschränken der Entwicklungsdisziplinen Anforderungserhebung, Design, Implementation und Validierung – Anforderungen werden im engen Dialog zwischen dem Auftraggebenden und dem Entwickler unmittelbar auf der LCAP implementiert und validiert.
4.3 E3: Kostenbezogene Optimierungspotenziale durch strategische LCAP-Positionierung sichern
Ausgangspunkt beider Projekte waren singuläre Problemstellungen. Ein Low-Code-basierter Lösungsansatz wirft damit aber auch eine strategische Fragestellung auf, die in beiden Fällen geführt wurde: Gibt es auf Seiten Auftraggebender mittelfristig weitere Problemstellungen, die mit Hilfe von Low Code angegangen werden können? Denn die mit der Integration einer neuen Plattform verbundenen Aufwände rechnen sich normalerweise nur, wenn auf ihr mehr als nur eine Anwendung realisiert wird. Beispielsweise gehen LCAP-Lizenzmodelle typischerweise von einer Mehrfachnutzung der Low-Code-Plattform aus. Kostenentlastend und damit die Dimension Kosten stärkend wirkt also ein strategischer Plattformentscheid, der mit der Einführung der Plattform getroffen wird und regelt, welche Anwendungen künftig auf der LCAP realisiert werden, so dass sich Lizenzkosten bzw. Betriebsaufwände mittelfristig auf mehrere Applikationsprojekte aufteilen.
4.4 E4: Zeit-, kosten- und flexibilitätsbezogene Optimierungspotenziale durch die richtigen Projekte stärken
Nach Einschätzung des DL lassen sich die mit dem Low-Code-Ansatz einhergehenden Vorteile im Bereich Zeit- und Kostenaufwände nur begrenzt realisieren, wenn vor allem Applikationen zur Unterstützung statischer, d. h. langfristig stabiler Prozesse implementiert werden – der Ansatz spielt seine Vorteile bzgl. schneller Anpassung bestehender Applikationen nicht aus. Gilt es aber, eine hohe Anpassbarkeit an sich ändernde Gegebenheiten sicherzustellen, brilliert der Ansatz insbesondere dann, wenn die benötigte Parametrisierung vorallem auf hoher Abstraktionsebene abgebildet werden kann. Die hier vom DL formulierte Praxiserfahrung könnte Tab. 1 in der Dimension Flexibilität mit positivem Impuls ergänzen (siehe kursiv hervorgehobene Zeile in Tab. 1); sie stärkt also die Dimension Flexibilität. In Projekt 1 wurde initial von sich eher dynamisch entwickelnden Prozessen ausgegangen, also der Notwendigkeit für regelmässige Anpassungen der aufgebauten Applikationen. Dank Low Code bleiben die Anpassungsaufwände insgesamt moderat, wobei Anpassungen auf tieferer Abstraktionsebene aufwändiger sind. In der Initialisierung von Projekt 2 spielte die Thematik sich verändernder Anforderungen hingegen keine Rolle. Trotzdem wurde im Projektverlauf festgestellt, dass die Low-Code-getriebene vereinfachte Anpassbarkeit das agile Entwicklungsvorgehen hervorragend unterstützt: letztlich konnte im gesetzten Zeit- und Aufwandsrahmen mehr Funktionalität als ursprünglich erwartet umgesetzt werden.
4.5 E5: Als Lösungsanbieter flexibilitäts- und qualitätsbezogene Optimierungspotenziale durch „internes“ Citizen Development realisieren
Die analysierten Projektbeispiele zeigen: Beauftragte Low-Code-basierte Projekte könnten zu grossen Teilen über ein DL-, also Lösungsanbieter-internes Citizen Development umgesetzt, die Dimension Flexibilität entsprechend stärker genutzt werden. Dabei liessen sich beim DL angestellte Business Consultants einsetzen, die nur eine begrenzte Informatikausbildung mitbringen, aber über Branchen-Knowhow verfügen. Vor dem Hintergrund des anhaltenden IT-Fachkräftemangels verbreitern solche Ressourcen – Dimension Flexibilität – die Umsetzungskapazitäten. Sie sind leichter zu rekrutieren als professionelle Softwareentwicklerinnen oder -entwickler. Zudem ergeben sich – in der Dimension Qualität – auch für die Auftraggebendenseite Mehrwerte: Der Einsatz branchenerfahrener Citizen Developer, z. B. für Front-End-Entwicklungen, Prozessautomatisierungen oder auch Validierungen, minimiert die Wahrscheinlichkeit von Missverständnissen im Bereich Anforderungen. Denn diese Personen sind mit der Fachsprache vertraut und können daher die Anforderungen, zumindest prototypisch, einfacher in der Applikation umsetzen und sicherstellen. Während der Lösungsfindung können sie zudem kompetent alternative Lösungsansätze aufzeigen.
Diesem Potenzial steht üblicherweise die Notwendigkeit einer Einführung der internen Citizen Developer auf der einzusetzenden LCAP gegenüber, was die Dimension Kosten belasten würde: Diese ist in der Regel aufwändiger, als eine IT-Fachkraft auf der LCAP einzuarbeiten.
4.6 E6: Zeit-, qualitäts- und flexibilitätsbezogene Optimierungspotenziale durch richtige Plattformwahl stärken
In den untersuchten Projekten haben sich für den DL Plattformeigenschaften herauskristallisiert, die sich für Low-Code-basierte Projektdurchführungen als wünschenswert bis unabdingbar erwiesen haben; die LCAP-Auswahl sollte dies entsprechend berücksichtigen: In der Dimension Zeit – Ermöglichung eines parallelen Entwickelns. In der Dimension Qualität – genügende Customizability auf verschiedenen Abstraktionsebenen; breite Unterstützung für die Integration von Umsystemen; Möglichkeiten für ein explizites Performance Tuning des automatisierten bzw. automatisch skalierenden Deployments; integrierte End-to-End-Testing- und Debugging-Möglichkeiten; eine alle Projektphasen abdeckende und insbesondere auch die Auftraggebendenseite einbindende Kollaborationsunterstützung; eine alle Artefakte umfassende Versionierung; Fähigkeiten zur Anbindung verbreiteter Softwareentwicklungswerkzeuge, z. B. zu Versionsverwaltungen wie SVN (subversion.apache.org) und GitHub (github.com) oder zum Testen. In der Dimension Flexibilität – Ansätze für die Wiederverwendbarkeit von Lösungsbestandteilen auf allen angebotenen Abstraktionsebenen.
Schliesslich werden seitens DL „weiche“ Faktoren wie das Supportangebot und Kommunikationsverhalten des Plattformherstellers genannt, welche die Plattform-Empfehlungen beeinflusst haben. Und je nach Projektcharakter können auch Nachweise des LCAP-Herstellers über Standards bzgl. Sicherheit und Qualität notwendig sein.
Insgesamt konnten aus der Studie beider Projekte 6 Einflussfaktoren abgeleitet werden, deren Berücksichtigung eine verbesserte Abschöpfung LCAP-getriebenen Optimierungspotenzials ermöglicht.
Sofern die oben illustrierten zeitbezogenen Potenzialbereiche ausgeschöpft werden, beschleunigen Low-Code-Technologien aus Sicht des DL die Applikationsentwicklung signifikant. Der DL, der über jahrelange Erfahrung in der „herkömmlichen“ Java-basierten Softwareentwicklung verfügt, nennt hier als Erfahrungswert einen Faktor 2 bis 4. Zudem weist der DL auf einen interessanten ressourcenbezogenen Potenzialaspekt hin: Da LCAP-getriebene Projekte mit weniger Ressourcen durchgeführt werden können, verringert sich auch der für Projektmanagement und Koordination benötige Overhead.
Aufgrund der insgesamt positiven Erfahrungen offeriert der DL Individualsoftwareentwicklungen heute immer häufiger LCAP-basiert.
5 Konklusion und Ausblick
Die vorliegende Arbeit zeigt unter Einbezug verschiedener empirischer Erhebungen, dass Low Code den Prozess der Applikationsentwicklung mit erheblichem Potenzial in der Dimension Zeit und mit tendenziellem Potenzial in den Dimensionen Flexibilität bzw. Kosten optimiert. Auf die Dimension Qualität wirkt die Verwendung einer LCAP uneinheitlich. Im Einzelfall ist der Optimierungserfolg allerdings von mehreren Einflussfaktoren abhängig, wie die vorgenommene Studie zweier Projekte illustriert. Tab. 3 fasst diese Einflussfaktoren zusammen, die als generelle Hilfestellung in der LCAP-Verwendung für die professionelle Applikationsentwicklung betrachtet werden können – ihre adäquate Berücksichtigung sorgt für eine verbesserte Abschöpfung der mit der LCAP einhergehenden Potenziale. Ein Beispiel (E1): Wird die mit den LCAP-seitig angebotenen vorgefertigten Software-Bausteinen einhergehende Standardisierung durch ein „Over-Customizing“ aufgebrochen, können prinzipiell mögliche Zeit- und Ressourceneinsparungen nicht realisiert werden. Werden die mit dem LCAP-Einsatz verknüpften Erwartungshaltungen involvierter Stakeholder von vornherein justiert – „reduziere das Customizing auf das wirklich Benötigte, akzeptiere die vom Herstellenden der LCAP ‚vorgedachten‘ Funktionslogiken“ –, verringert sich hingegen der Zeit- und Ressourcenbedarf.
In künftigen Arbeiten sollen diese exemplarisch erhobenen Praxiserfahrungen durch weitere Fallanalysen ergänzt werden, sodass die abgeleiteten Einflussfaktoren in Best Practice Empfehlungen für den Einsatz von Low-Code-Plattformen weiterentwickelt werden können. Die Analyse weiterer Quellen und eigene Erhebungen sollen zudem die vorgenommene Ableitung des mit dem Low-Code-Einsatz einhergehenden Optimierungspotenzials weiter festigen.
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
Studien, die nur wenige Einzelfälle betrachten, werden also nicht einbezogen. In diesem Sinne wird die Quellenauswahl enger gefasst als in der auf die Eruierung von Benefits und Nachteilen einer LCAP Nutzung ausgerichteten Quellenanalyse in Martinez und Pfister (2023).
Die normalisierte Wirkung auf eine Dimension D ergibt sich aus der Summe der Impulse aller Praxiserfahrungen Pi zu D, dividiert durch die Anzahl der Quellen, die jeweils mindestens ein Pi enthalten. Eine Praxiserfahrung zu D, die in weniger Quellen adressiert wird, wirkt weniger stark auf D als eine zweite Praxiserfahrung zu D, die in mehr Quellen adressiert wird.
Vgl. hierzu auch Lo Giudice und Bratincevic (2023): Low-Code-Ansätze können das „Ausprobieren“ unterschiedlicher Lösungsansätze ermöglichen. So lassen sich z. B. unterschiedliche Bildschirmlayouts direkt mit dem Endanwendenden am Bildschirm erstellen und testen, womit u. a. auch Kommunikationsbarrieren abgebaut werden. Unterstützt durch geeignete Plattform-Features können Anwendende und Entwickelnde kollaborativer und mit einem verbesserten gemeinsamen Zielverständnis zusammenarbeiten. Ggf. können so auch Durchlaufzeiten agiler Sprints gekürzt werden.
Al Alamin MA, Malakar S, Uddin G et al (2021) An empirical study of developer discussions on low-code software development challenges. In: 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE, Madrid, S 46–57CrossRef
Alamin MAA, Uddin G, Malakar S et al (2023) Developer discussion topics on the adoption and barriers of low code software development platforms. Empir Software Eng 28:4. https://doi.org/10.1007/s10664-022-10244-0CrossRef
Alsaadi HA, Radain DT, Alzahrani MM et al (2021) Factors that affect the utilization of low-code development platforms: survey study. RRIA 31:123–140. https://doi.org/10.33436/v31i3y202110CrossRef
Aveiro D, Freitas V, Cunha E et al (2023) Traditional vs. low-code development: comparing needed effort and system complexity in the NexusBRaNT experiment. In: 2023 IEEE 25th Conference on Business Informatics (CBI). IEEE, Prague, S 1–10
Di Ruscio D, Kolovos D, De Lara J et al (2022) Low-code development and model-driven engineering: two sides of the same coin? Softw Syst Model 21:437–446. https://doi.org/10.1007/s10270-021-00970-2CrossRef
Dumas M, La Rosa M, Mendling J, Reijers HA (2021) Grundlagen des Geschäftsprozessmanagements. Springer, Berlin Heidelberg (übersetzt von Thomas Grisold, Steven Groß, Jan Mendling, Bastian Wurm)CrossRef
Käss S, Strahringer S, Westner M (2023b) A multiple mini case study on the adoption of low code development platforms in work systems. IEEE Access 11:118762–118786. https://doi.org/10.1109/ACCESS.2023.3325092CrossRef
Luo Y, Liang P, Wang C et al (2021) Characteristics and challenges of low-code development: the practitioners’ perspective. In: Proceedings of the 15th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). ACM, Bari, S 1–11
Martinez E, Pfister L (2023) Benefits and limitations of using low-code development to support digitalization in the construction industry. Autom Constr 152:104909. https://doi.org/10.1016/j.autcon.2023.104909CrossRef
Matvitskyy O, Iijima K, West M et al (2023) Magic quadrant for enterprise low-code application platforms. Gartner
Pohl K, Rupp C (2021) Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, 5. Aufl. dpunkt, Heidelberg
Rafi S, Akbar MA, Sánchez-Gordón M, Colomo-Palacios R (2022) Devops practitioners’ perceptions of the low-code trend. In: Proceedings of the 16th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ACM, Helsinki, S 301–306CrossRef
Richardson C, Rymer J (2016) Vendor landscape: the fractured, fertile terrain of low-code application platforms. Forrester
Schwarz M (2022) IT-Unterstützung im Risikomanagement: eine qualitativ-empirische Studie zur Auswahl, Einführung und Verwendung von Risikomanagementsoftwarelösungen. Springer Gabler, WiesbadenCrossRef
Webster J, Watson RT (2002) Analyzing the past to prepare for the future: writing a literature review. Mis Q 26:xiii–xxiii
