Low-Code & Co.: Mehr Schaden als Nutzen?

Inhaltsverzeichnis

Stellen Sie sich für einen kurzen Augenblick vor, Sie würden nicht in der Softwareentwicklung arbeiten, sondern wären vielleicht Domänenexpertin oder -experte für Versicherungs-Policen. Sie arbeiten bei einer Versicherung in der Fachabteilung. Programmierung und Softwareentwicklung sind so gar nicht Ihre Themen, aber Sie kennen sich dafür bestens mit all den inhaltlichen Aspekten wie Policen, Schäden, Haftung und Regress aus.

Nun benötigen Sie ein kleines Stück Software: Vielleicht ein einfaches Tool, um die Daten von Kundinnen und Kunden effizienter zu erfassen, oder einen Report, der Ihnen ermöglicht, Ihre Policen für das nächste Jahr besser zu optimieren. Was es konkret ist, spielt letztlich keine Rolle. Es geht um etwas Kleines und Einfaches, das Ihnen und Ihren Kolleginnen und Kollegen das Leben erleichtert und Ihr Business voranbringt.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Wie kommen Sie nun zu dieser Software? Klar, Sie könnten natürlich zur hausinternen IT-Abteilung gehen und nett fragen. Wenn Sie Glück haben, sagt Ihnen die freundliche Kollegin aus der IT, dass das kein Problem sei. Sie würde sich darum kümmern und Ihnen das nebenbei bauen. Natürlich stellt sich nachher heraus, dass sie leider nicht ganz so viel Zeit erübrigen kann wie gedacht, und sie wusste vielleicht auch nicht ganz so genau, was Sie eigentlich im Detail wollten.

Deshalb macht die Software am Ende nicht ganz das, was sie sollte. Aber hey, beschweren Sie sich nicht: Immerhin haben Sie überhaupt etwas bekommen! Es hätte nämlich auch schlimmer kommen können: Wären Sie statt an die freundliche und hilfsbereite Kollegin an ihren grummeligen Kollegen geraten, hätte er Ihnen wahrscheinlich sehr deutlich zu verstehen gegeben, dass für so einen Quatsch keine Zeit da sei, die IT ohnehin völlig überlastet sei und Sie ohne eine um 27 Ecken eingeholte Budgetfreigabe gar nicht erst wieder ankommen bräuchten.

Wie schön wäre es, wenn Sie die IT einfach gar nicht bräuchten, sondern sich das, was Sie benötigen, einfach selbst hätten zusammenbauen können – ganz ohne jegliche Programmierkenntnisse? Willkommen bei der Welt der Low-Code- und No-Code-Plattformen!

Das Versprechen hinter Low-Code

Das, was ich Ihnen gerade geschildert habe, beschreibt letztlich das Werbeversprechen von Low-Code- und No-Code-Umgebungen. Die Idee dahinter ist, dass viele Vorgänge in Fachanwendungen mehr oder weniger immer gleich ablaufen: Formulareingaben, Datenabrufe aus einem SharePoint, tabellarische oder grafische Visualisierungen – all das sind immer wiederkehrende Muster. Die Plattform stellt nun solche Aktivitäten als Bausteine zur Verfügung, und Sie können sich daraus Ihre eigene Anwendung zusammenbauen, ohne wissen zu müssen, wie die technischen Details funktionieren.

Ich selbst habe das vor einiger Zeit einmal ausprobiert, gemeinsam mit einem Freund, auf Basis der Microsoft Power Platform, genauer gesagt mit Power Automate. Es ging um einen simplen Anwendungsfall: Daten von einer HTTP-API abrufen und anzeigen. Nach drei bis vier Stunden hatten wir dann allerdings keine Lust mehr, weil wir immer wieder auf Probleme stießen. Entweder waren wir zu zweit zu unfähig (was ich bezweifle), oder unser Anwendungsfall lag geringfügig außerhalb der vorgesehenen Nutzungspfade. Schlussendlich zogen wir einen Kollegen hinzu – einen zertifizierten "Microsoft Power Platform Developer". Ein Entwickler also für eine Plattform, die Entwickler angeblich überflüssig machen soll – an Absurdität lässt sich das kaum überbieten!

Die Realität: Mehr Frust als Nutzen

Dieser Vorfall ist natürlich nicht repräsentativ für alle Low- und No-Code-Plattformen. Aber er zeigt ein grundlegendes Problem auf: Die Plattformen machen große Versprechungen, schüren hohe Erwartungen – und die Realität bleibt dahinter zurück: Fachabteilungen können nicht plötzlich auf magische Weise alles selbst lösen. Sie können nicht auf die IT-Abteilung und Entwickler verzichten. Und sie sparen am Ende oft weder Zeit noch Geld. Im ungünstigsten Fall passiert sogar genau das Gegenteil.

Woran liegt das? Programmieren bedeutet, eine Sprache zu beherrschen. Egal, ob Sie Französisch oder eine Programmiersprache lernen: Sie müssen Vokabeln und Grammatik lernen, lesen, schreiben, sprechen – und üben. Entwicklerinnen und Entwickler haben sich all dieses Wissen in jahrelanger, mühsamer Arbeit angeeignet. Und nun kommt eine Plattform daher, die behauptet:

"Das brauchen Sie alles nicht!"

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Stattdessen bekommen Sie Bausteine, die Sie anordnen sollen. Aber diese Bausteine reichen oft nicht aus, um komplexe Anforderungen abzubilden. Die fachliche und technische Komplexität bleibt bestehen – sie wird nur unsichtbar. Und spätestens, wenn eine Anwendung nicht performant läuft, Race Conditions auftreten oder der Datenverkehr das Netzwerk lahmlegt, kommen Sie ohne grundlegende Programmierkenntnisse nicht weiter.

Langfristige Risiken

Hinzu kommt, dass viele Plattformen proprietär sind. Sobald Sie eine Anwendung auf Basis einer solchen Plattform entwickeln, schaffen Sie einen Vendor-Lock-in. Die IT wird sich hüten, solche Anwendungen zu supporten. Das erinnert nämlich zu sehr an Microsoft Access, das in vielen Unternehmen bis heute Probleme verursacht. Das Problem ist also nicht neu – nur die Technologien haben sich geändert.

Darüber hinaus wissen Fachabteilungen oft selbst nicht, wie ihre Prozesse im Detail aussehen oder was sie genau wollen. Deshalb gibt es Business-Analysten und Requirements Engineers, die diese Anforderungen gemeinsam mit den Fachabteilungen erarbeiten. Fachabteilungen haben das fachliche Know-how, aber sie sind meist nicht darauf vorbereitet, dieses Wissen zielführend und nachhaltig in digitale Prozesse umzusetzen.

Trotz aller Kritik haben Low-Code-Plattformen aber natürlich auch ihre Berechtigung. Sie können die Kommunikation zwischen Entwicklung und Fachabteilung erleichtern, indem die Fachabteilung beispielsweise eigenständig Prototypen erstellt. Für einfache Anforderungen – wie "Formular ausfüllen und Daten per E-Mail senden" – können sie zudem durchaus ausreichen. Bei komplexeren Aufgaben würde ich jedoch zur Vorsicht raten.

Ein Plädoyer für Zusammenarbeit

Was mich an dem ganzen Thema aber mit Abstand am meisten stört, ist das Narrativ von "Entwicklung gegen Fachabteilung". Es geht nicht um "wir gegen die", und dieses Narrativ war noch nie konstruktiv oder gar zielführend, sondern führt stets nur zu Zwist und Schuldzuweisungen. Am Ende des Tages sind wir doch eigentlich dann erfolgreich, wenn wir unsere unterschiedlichen Fähigkeiten und Kenntnisse konstruktiv zusammenbringen und gemeinsam und partnerschaftlich auf ein gemeinsames Ziel hinarbeiten: Es geht um Partnerschaft auf Augenhöhe. Und Low-Code-Plattformen sollten diese Partnerschaft unterstützen, nicht spalten – doch genau das ist es, was sie letztlich machen.

Langer Rede, kurzer Sinn: Gehen Sie kritisch mit solchen Plattformen um. Verstehen Sie deren Grenzen und setzen Sie auf eine solide Zusammenarbeit zwischen Entwicklung und Fachabteilung. Nur so profitieren letztlich alle Beteiligten – außer vielleicht der Hersteller der Plattform.

(rme)