TECH MONDAY: Brauchen wir Low-Code-Tools überhaupt noch?

Das Hauptziel von Microsoft bei der Entwicklung der unter dem Namen „Power Platform“ verfügbaren Dienste war es, den Prozess der Softwareentwicklung und Datenanalyse in Unternehmen zu demokratisieren. Microsoft wollte das Problem der langen Entwicklungszeiten und der sogenannten „Engpässe“ im Softwareentwicklungsprozess durch IT-Abteilungen oder spezialisierte Anbieter lösen. Dies sollte dadurch geschehen, dass Mitarbeiter ohne Ausbildung oder Kenntnisse im Bereich der Softwareentwicklung zu sogenannten „Citizen Developers“ werden und mit Werkzeugen ausgestattet werden, um alltägliche Probleme mithilfe selbst erstellter Anwendungen zu lösen, ohne dabei Code schreiben zu müssen. Das von Microsoft bereitgestellte Toolset ermöglichte die Erstellung von Anwendungen, die über einen Browser und mobile Clients zugänglich waren, sowie von Webportalen, einer Prozess-Engine zur Automatisierung des Datenflusses zwischen Systemen und einem Tool zur Erstellung von Chatbots.

Die einfache Softwareentwicklung mit den besprochenen Tools war jedoch mit gewissen Einschränkungen verbunden. Die Bildschirme der Anwendungen, die mit den auf der Plattform verfügbaren Tools erstellt wurden, bewährten sich hervorragend bei einfachen CRUD-Lösungen. Bei komplexeren Benutzeroberflächen, die Daten aus vielen Quellen oder Tabellen zusammenführten, stießen wir leider sehr schnell an die Grenzen der Plattform. Zudem war die Implementierung komplexer Geschäftslogik mithilfe der auf der Plattform verfügbaren Tools oder „Sprachen“ recht schwierig und sehr aufwendig. In solchen Fällen griffen die Unternehmen erneut auf die Unterstützung von Entwicklerteams zurück und erweiterten ihre Anwendungen um Komponenten, die mit „klassischen“ Programmiersprachen erstellt wurden.Hinzu kam das häufig auftretende Problem der Leistung, die ebenfalls nie eine Stärke von Systemen auf Basis von Low-Code-Plattformen war.

Derzeit, im Zeitalter der zunehmenden Verbreitung generativer künstlicher Intelligenz, entwickeln sich die Tools der Microsoft Power Platform immer mehr in Richtung eines Paradigmas, das allgemein als „Vibe-Coding“ (ein Begriff, der von Andrej Karpathy, Mitbegründer von OpenAI, geprägt wurde), bei dem Software nicht mithilfe von Programmiersprachen oder Tools, sondern durch Beschreibungen in natürlicher Sprache erstellt wird. Das Sprachmodell übernimmt in diesem Fall die gesamte technische Umsetzung, einschließlich der Erstellung der Datenstruktur, der Geschäftslogik und der Benutzeroberfläche. Was in unserem Fall wichtig ist: Ein Großteil der im Rahmen der Power Platform verfügbaren Tools zum „Vibe-Coding“ von Anwendungen generiert Code in traditionellen Sprachen wie JavaScript, anstatt die in der Umgebung verfügbaren Mechanismen zu nutzen.  

Werfen wir nun einen Blick auf gängige Methoden zur Entwicklung von Funktionen oder Anwendungen mithilfe von Low-Code-Tools sowie auf deren Entsprechungen, die auf KI-Mechanismen basieren und im Rahmen der Microsoft Power Platform verfügbar sind.

Canvas-Apps vs. Code-Apps

Die Canvas-Apps-Technologie (ursprünglich unter dem Namen „PowerApps“ eingeführt) ist eine Sammlung von Tools, die die Erstellung von Anwendungen mithilfe eines WYSIWYG-Editors („What You See Is What You Get“) sowie einer Reihe von Steuerelementen und Konnektoren ermöglichen, die im Rahmen der Power Platform verfügbar sind. Die Implementierung der Geschäftslogik erfolgt in diesem Fall mithilfe der Sprache Power Fx, deren Syntax der Formelsprache in Microsoft Excel ähnelt.

Als Äquivalent zu Canvas Apps in der Welt der generativen künstlichen Intelligenz können die Power Platform Code Apps angesehen werden. Dabei handelt es sich um Frontend-Anwendungen, die mithilfe der Frameworks Vite und React erstellt werden (in der Standardkonfiguration können wir natürlich auch andere bevorzugte Bibliotheken verwenden) und innerhalb der Plattform Power Apps ausgeführt werden.Der Zugriff auf die Daten erfolgt über Power-Platform-Konnektoren, was die Einhaltung der Sicherheitsvorschriften und DLP-Richtlinien der Organisation gewährleistet. Da die Benutzeroberfläche in diesem Fall auf JavaScript-Code basiert, der im Browser ausgeführt wird, kann sie wesentlich interaktiver und leistungsfähiger sein und auch von den innerhalb der Plattform verfügbaren Standards für die UI-Erstellung abweichen. Die Implementierung komplexer Logik (z. B. eines Angebotskalkulators) kann durch Unit-Tests abgedeckt werden, was wiederum die Automatisierung der Qualitätssicherung der Lösung im Rahmen von DevOps-Prozessen ermöglicht.

Der einzige Nachteil des oben beschriebenen Frameworks, den ich feststellen konnte, ist, dass es nicht möglich ist, eine mit diesem Code erstellte Anwendung innerhalb der mobilen Client-App „ Power Apps “ auszuführen. Möglicherweise handelt es sich hierbei um ein vorübergehendes „Problem“, doch wir müssen uns dessen bewusst sein, wenn wir eine Anwendung mit der genannten Technologie erstellen. Zudem ist für die Nutzung der Code App – selbst wenn wir Microsoft Dataverse nicht als primäre Datenquelle verwenden – ohnehin eine Power Platform Premium- oder Pay-as-you-go-Lizenz erforderlich.

Benutzerdefinierte Seiten vs. generative Seiten

Hinter dem Begriff „Custom Pages“ verbirgt sich die Möglichkeit, einseitige Canvas-Apps in modellgesteuerte Anwendungen (Power Platform Model-Driven Apps, MDA) einzubetten. Ähnlich wie im vorherigen Fall kann diese Technologie durch eine mit JavaScript erstellte Anwendung ersetzt werden, die generative künstliche Intelligenz nutzt, die sogenannten „generative pages“.Microsoft ist in diesem Fall sogar noch einen Schritt weiter gegangen und hat einen Editor bereitgestellt, mit dem Befehle an den Agenten, der die Lösung erstellt, direkt über das Portal make.powerapps.com erteilt werden können. Für fortgeschrittene Nutzer besteht die Möglichkeit, die gewünschte Funktionalität in einer lokalen Umgebung mithilfe der von Microsoft bereitgestellten Skills (bei Verwendung von Claude Code) oder Plugins (für GitHub Copilot) zu erstellen.

Power Platform Generative Pages sind derzeit nur in der Preview-Version in ausgewählten Regionen der Power Platform-Umgebungen verfügbar.

Power Pages „Classic“ vs. SPA

Power Pages Im Microsoft-Ökosystem für Unternehmensanwendungen fungieren sie als CMS (Content Management System) zur Erstellung von Portalen für Kunden und/oder Partner unserer Organisation und ermöglichen eine native Integration sowie den Zugriff auf Daten im Microsoft Dataverse-Repository. Leider sind die Tools, die eine funktionale Erweiterung der auf diese Weise erstellten Websites ermöglichen, trotz der positiven Veränderungen, die in den letzten Jahren in Form des Design Studio eingeführt wurden, im Vergleich zu anderen auf dem Markt verfügbaren Lösungen mit ähnlichem Verwendungszweck nach wie vor sehr rudimentär. Ein besonders wichtiger Punkt, der Architekten und Entwicklern von Lösungen auf Basis von Microsoft Power Pages schon immer schlaflose Nächte bereitet hat, war das Thema der UI/UX-Anpassung. Sie werden mir zustimmen, dass die Anpassung oder Implementierung von clientseitiger Logik mithilfe von jQuery oder Liquid-Vorlagen mittlerweile ziemlich veraltet klingt.

Glücklicherweise ist Microsoft, ähnlich wie in den zuvor besprochenen Beispielen, zur Vernunft gekommen und ermöglicht nun die Erstellung eines Portals mithilfe von JavaScript und dem SPA-Architekturmuster (Single Page Application). Die gesamte Benutzeroberfläche kann nun lokal in unserer bevorzugten Entwicklungsumgebung erstellt werden (natürlich am besten unter Einsatz von KI-Agenten, die durch einen dedizierten Satz von Fähigkeiten oder Erweiterungen unterstützt werden) und mithilfe der Power Platform CLI-Befehle in der Zielumgebung Power Pages installiert werden. Der Zugriff auf die hinzugefügten Daten (über eine spezielle API) sowie die Sicherheit werden weiterhin vom Backend der Plattform gewährleistet. In diesen Bereichen besteht für uns also kein größeres Risiko eines potenziellen unerwünschten Informationslecks als bei der Verwendung der klassischen „ Power Pages “-Engine.

Kommen wir nun auf die im Titel des Artikels gestellte Frage zurück. Geht die Blütezeit der No-/Low-Code-Tools angesichts der oben beschriebenen Lösungen, die dank generativer künstlicher Intelligenz die Entwicklungszeit der gewünschten Funktionen im Vergleich zum klassischen Code erheblich verkürzen, zu Ende? Leider gibt es in diesem Fall keine einfache, eindeutige Antwort. Wir kommen hier leider zu der klassischen „Berater-Antwort“: „Es kommt darauf an“ 😊.

In der Praxis sollten mehrere Faktoren über die Wahl der Technologie entscheiden. Der wichtigste davon ist meiner Meinung nach die Kompetenz des Teams, das die Funktionalität entwickelt und in Zukunft wartet. Wir müssen uns die Frage stellen, ob es sich dabei um „Maker“ handelt (also Personen ohne detaillierte,fundierten technischen Wissen im Bereich der Softwareentwicklung verfügen) sein werden oder eher Programmierer, die in der Lage sind, den von künstlicher Intelligenz generierten Code zu bewerten oder zu korrigieren (der – seien wir ehrlich – derzeit in den meisten Fällen noch weit vom Ideal entfernt ist). Wir müssen uns auch der Risiken bewusst sein, die mit den von KI erstellten Artefakten verbunden sind. Microsoft weist darauf hin, dass der von künstlicher Intelligenz generierte Code keine Garantie für die Produktionsreife oder die Einhaltung von Unternehmensstandards bietet, sofern solche bestehen.

In einigen Fällen sollten wir auch die Frage der Lizenzen berücksichtigen (neue Methoden zur Anwendungsentwicklung, die auf Mechanismen der künstlichen Intelligenz basieren, können zu höheren Gesamtbetriebskosten führen), den Vertriebskanal der Anwendungen (die oben erwähnte Unmöglichkeit, Code Apps als mobile Anwendungen oder in Microsoft Teams eingebettete Anwendungen bereitzustellen) sowie die gewünschte Funktionalität. Was den zuletzt genannten Punkt betrifft, sollten wir stets den Grundsatz der Effizienz im Auge behalten, der besagt, dass wir die Werkzeuge an den Zweck anpassen und nicht den Zweck an die Werkzeuge. Und das Ziel wird in unserem Fall immer darin bestehen, das gewünschte Endergebnis (eine Funktionalität, die den funktionalen und nicht-funktionalen Anforderungen entspricht) innerhalb des vorgesehenen Zeit- und Budgetrahmens zu liefern.

Abschließend sei noch erwähnt, dass es einen Zwischenweg in Form von KI-Agenten gibt, die klassische No-Code-Artefakte generieren. Das ist jedoch schon ein Thema für einen eigenen Artikel.

Die folgende Tabelle fasst die wichtigsten Erkenntnisse zur Wahl zwischen klassischen No-/Low-Code-Systemen und durch KI-Tools generiertem Code zusammen, der im Rahmen der Microsoft Power Platform ausgeführt wird.

Zusammenfassung der Schlussfolgerungen