Warum ich glaube, dass Low-Code-Technologie für Web- und Mobile-Anwendungen in Unternehmen die Individualprogrammierung ersetzen sollte – und wird.
Worum geht es: Ich las kürzlich einen Blogartikel bei einem Anbieter für die Entwicklung von Individualsoftware, der mich stutzig machte.1 Logisch ist, dass jeder Anbieter von seinem Produkt bzw. in diesem Fall seiner Dienstleistung überzeugt ist und deshalb tendenziell immer eine Empfehlung in diese Richtung aussprechen wird. Schwierig wird es für mich aber dann, wenn Argumente allzu einseitig beleuchtet und teils an den Haaren herbeigezogen werden. Deshalb möchte ich in diesem Blogartikel differenziert auf die dort präsentierten Argumente eingehen.
Im genannten Artikel kommt Low-Code-Technologie ziemlich schlecht weg – Hauptargumente dafür sind, dass sie erstens eine Schatten-IT bildeten und zweitens mit den standardmäßig bereitgestellten Low-Code-Bausteine große Restriktionen böten. Dieser Artikel soll Verantwortlichen in den IT- und Funktionsbereichen mehr Klarheit geben, weg von der klassischen IT- und Software-Denke, bei der jeder einfach behauptet, alles zu können, hin zu einer aufgeklärten und objektiven Debatte:
Low-Code und das Risiko einer Schatten-IT
Im zitierten Artikel ist zu lesen, dass Low-Code Plattformen die interne IT in Unternehmen vor Herausforderungen stellen, wenn sie von den Fachabteilungen ohne deren Involvierung angeschafft werden, früher oder später aber dann doch IT-Support anfällt. Dem ist absolut zuzustimmen. Was hier aber nicht differenziert gesehen wird, ist die Vielfalt der Ansätze von Low-Code-Plattformen und dass nicht per se jede Low-Code-Technologie das Ziel verfolgt, am besten von der Fachabteilung an der IT vorbei gekauft zu werden. Diese These wird zwar von einigen Anbietern im No-Code-Bereich bestätigt, die sich für einfache Applikationen speziell an Citizen Developer, also App-Ersteller in den Fachabteilungen richten. Mit No-Code lassen sich hervorragend kleine, in sich geschlossene Apps bauen, die nicht in vorhandene Systeme integriert werden – zum Beispiel eine Teilnehmer-Registrierung für Schulungen, eine interne Bestell-App für Kaffeekapseln etc.
Enterprise-fähige Low-Code-Plattformen hingegen erfordern immer das Zutun der internen IT-Abteilung und bilden definitiv keine Schatten-IT (Lesen Sie hierzu auch diesen Blogartikel): Sie verfolgen das Ziel, individuelle und anwenderfreundliche Applikationen zu liefern, die nahtlos in die vorhandene Unternehmens-IT integriert sind und auch den Sicherheitsstandards eines Unternehmens genügen. Sie unterstützen durch Möglichkeiten der Kollaboration das Zusammenwirken von Fachbereichen und IT bei der Realisierung von Applikationen und bringen so die Enterprise App-Entwicklung auf das nächste Level: Weg vom alten Spiel „Fachabteilung gegen IT“, hin zu einer kollaborativen Weiterentwicklung des Business durch Kooperation aller Beteiligten. Wer also hier noch die Angst vor der Schatten-IT schürt, bedient das Klischee überholter Verhaltensweisen in Organisationen von gestern.
Das weiter vorgebrachte Argument, von den Fachabteilungen eigenmächtig angeschaffte Low-Code-Lösungen entsprächen womöglich nicht den Sicherheitsanforderungen im Unternehmen, kann also nur für No-Code-Plattformen gelten. Und tatsächlich besteht die Gefahr, dass sich die Anwender in den Fachabteilungen nicht ausreichend über die geltenden Anforderungen hinsichtlich Datenschutz im Klaren sind. Für Low-Code-Anwendungen, die gemeinsam mit der internen IT realisiert werden, ist das auszuschließen. Vielmehr muss dort darauf hingewiesen werden, dass auch eine Individualsoftware-Entwicklung nicht automatisch hohe Sicherheitsanforderungen erfüllt. Ist nicht eher davon auszugehen, dass eine Enterprise-fähige Low-Code-Technologie, die bei tausenden Unternehmen im Einsatz ist und regelmäßige IT-Sicherheitsaudits durchläuft, deutlich höheren Sicherheitsstandards entspricht als eine von einem externen IT-Dienstleister einmalig fest programmierte Lösung? Individualentwicklungen können genau wie Low-Code-Applikationen Sicherheits- und Berechtigungskonzepte hervorragend berücksichtigen, wie etwa durch Anbindung an ein ERP-System und Verwendung der dortigen Berechtigungen, oder auch einfach schlecht, indem an diesen vorbei direkt mit der Datenbank im Hintergrund interagiert wird. Es handelt sich hierbei also nicht um ein Argument gegen Low-Code an sich, sondern um einen generell wichtigen Aspekt bei der Realisierung von Unternehmensanwendungen.
Restriktionen der Bausteine
Im zitierten Artikel wird weiter vorgebracht, dass Individualentwicklung am Ende schneller und günstiger sei, weil man mit Low-Code und dessen funktionalen Restriktionen damit rechnen müsse, an die Grenzen des Machbaren zu stoßen und schließlich alles noch einmal neu entwickeln zu müssen. Besonders wird davon abgeraten, Low-Code-Technologie für komplexe Prozessanwendungen einzusetzen, die dann auch noch an bestehende Systeme angebunden werden müssten.
Auch hier ist es wichtig zu sagen: Das kommt auf die Plattform an! Begonnen bei No-Code-Plattformen, deren Scope es definitiv nicht ist, Geschäftsprozessanwendungen zu bauen, stimmt es, dass hier tendenziell enge funktionale Beschränkungen vorherrschen und auch die Anbindung an Enterprise Systeme schwierig bis unmöglich ist.
Das gilt aber nicht für Low-Code-Systeme, deren Spezialität gerade die Abbildung komplexer ERP-Prozesse ist, und die nahtlos in die vorhandene IT-Systemlandschaft integriert werden. Ich spreche hier für unser System engomo, aber auch für viele andere Low-Code-Systeme: Neben den vorhandenen Funktionsbausteinen und der sehr einfachen Konfiguration von Oberflächen per Drag&Drop ist der besondere Vorteil, dass individueller Code dort eingebracht werden kann, wo er benötigt wird. Es sind also sehr einfache und schlanke Anwendungen genauso möglich wie hochkomplexe, durch Coding angereicherte Lösungen mit eigener Logik und Datenhaltung. Das und die Tatsache, dass externe Technologien problemlos integrierbar sind, führen dazu, dass die Grenzen des Möglichen bei Low-Code nur äußerst selten erreicht werden.
Lediglich in Embedded-Szenarien und bei der sehr Hardware-nahen Entwicklung ist es wichtig und sinnvoll, bei der Applikationserstellung auch in Richtung Individualsoftware Ausschau zu halten und die Optionen zu vergleichen.
Als zusätzliches Argument gegen Low-Code wird in diesem Kontext erwähnt, dass bei der Individualentwicklung der Code dem Unternehmen selbst gehöre, was bei einer Low-Code-Plattform nicht der Fall sei. Dabei ist zu unterscheiden: Ja, der Sourcecode der Plattform wird im Low-Code-Szenario immer Eigentum des Anbieters sein. Aber: Die Rechte an der individuellen App-Konfiguration, also die Intellectual Property dessen, wie eine App mit Low-Code konfiguriert werde – bei engomo nennen wir das ein „App-Profil“ – liegen auch hier beim Kundenunternehmen.
Abschließend wird der wichtige Punkt vorgebracht, was mit den Unternehmenslösungen passiert, wenn es einen Low-Code-Anbieter nicht mehr gibt. Tatsächlich machen sich Unternehmen mit der Wahl eines Technologieanbieters abhängig von diesem. Das gilt für Low-Code-Anbieter genauso wie für die Anbieter von Individualsoftware-Entwicklung. Mehr als einmal haben wir Kunden erlebt, die unter hohem Zeitdruck eine Low-Code-Applikation realisierten, nachdem ihr Individualsoftware-Anbieter die Wartung einer Individuallösung kurzfristig abgekündigt hatte. Hier ist es für Kunden immer wichtig, sich vor der strategischen Bindung an einen Anbieter ein Bild über dessen Stabilität und Zukunftsfähigkeit zu machen. Dabei sei angemerkt, dass die Stabilität von Low-Code Anbietern, deren Geschäftsmodell auf einem Produkt basiert, das verlässliche wiederkehrende Umsätze generiert, in der Regel derjenigen von Individualsoftwareanbietern im Projektgeschäft in nichts nachsteht, deren Business stark vom Gewinnen einzelner Aufträge abhängig ist.
Ein Punkt, der in diesem Kontext im zitierten Artikel unerwähnt bleibt, ist das Thema Wartung und Stand der Technik: Gerade im Bereich von Web- und Mobile-Apps sowie IoT müssen Anwendungen laufend auf dem Stand der Technologie gehalten werden – z.B. was die Kompatibilität mit neuer Hardware, neuen Betriebssystemen, Anforderungen an die IT-Sicherheit und neue Technologien allgemein angeht. Unternehmen müssen sich bewusst sein, dass Low-Code-Plattformanbieter diese Themen im Rahmen ihrer Produktentwicklung auf dem Schirm haben und sie Aktualität und technologische Kontinuität im Rahmen ihres SaaS-Abos oder Wartungsvertrags automatisch mitbeziehen. Individuell programmierte Software hingegen muss manuell auf Stand gehalten werden, und das macht der Anbieter wohl auch nicht kostenlos – Change Requests und laufende Anpassungen, die immer wieder nachbeauftragt werden müssen, sorgen beim IT-Dienstleister also zwar für Stabilität durch anhaltenden Umsatzstrom, unterstützen aber nicht das Argument, dass Individualsoftware-Entwicklung am Ende womöglich kostengünstiger als Low-Code-Technologie sei, zumal die anfallenden künftigen Zusatzkosten für Unternehmen im Vorfeld kaum bis gar nicht kalkulierbar sind.
Fazit: Differenzierte Betrachtung statt Bashing
Anbieter von Indivdualsoftware-Entwicklung haben ihre Daseinsberechtigung ebenso wie Low-Code-Technologie. Die wachsende Nachfrage nach Low-Code von Seiten der Unternehmen im Bereich von Web- und Mobile-Apps sowie Industrie 4.0 und IoT zeigt, dass sie nicht mehr uneingeschränkt gewillt sind, hohe Tagessätze für die Individualentwicklung starrer Lösungen zu zahlen, sondern dass Flexibilität und Agilität bei der App-Erstellung immer wichtiger werden. Dabei zeigt sich, dass Low-Code nicht gleich Low-Code ist und Unternehmen besonders darauf achten sollten, auf eine Plattform zu setzen, die integrierbar und skalierbar ist und auch komplexe Anforderungen abbilden kann. Es wird also weiter beides geben und erfolgreich werden diejenigen Unternehmen sein, denen es gelingt, für ihre individuellen Anwendungsfälle den jeweils richtigen Weg einzuschlagen.
1 Ich nenne hier bewusst nicht den Anbieter und die Quelle, da wir hier auf der Sachebene bleiben wollen. Wer nähere Details erfahren möchte, über dessen Kontaktaufnahme freue ich mich für den weiteren Austausch.
