Low-Code- und No-Code-Plattformen (LCNC) sind vielseitig und versprechen Entwicklern eine hohe Produktivität. Mithilfe vorgegebener Funktionen und einer visuellen Umgebung soll ihre Arbeit vereinfacht und beschleunigt werden. No-Code-Plattformen sollen auch Anwendern in den Fachbereichen ermöglichen, Applikationen teilweise oder vollständig zu erstellen - ganz ohne DevOps oder der Erfordernis, eine Cloud-Infrastruktur zu konfigurieren.

Die Vereinfachung kann Unternehmen erhebliche Vorteile bieten. Allerdings müssen sie damit auch Kompromisse eingehen, die sie vielleicht erst nach mehrmaligem Einsatz dieser Plattformen erkennt. Die Notwendigkeit, schnell zu modernisieren hat zu einer steigenden Nachfrage nach LCNC-Plattformen geführt - und dazu, dass sich einige Lösungen auf dem Markt befinden, die nicht halten, was sie versprechen. Ich verwende selbst diverse LCNC-Plattformen. Zu den Unwägbarkeiten, mit denen ich am häufigsten kämpfe, gehören:

• Low-Code-Plattformen, die es erforderlich machen Anwendungen erheblich zu überarbeiten oder manchmal sogar neu zu schreiben, wenn eine neue Version des Tools herauskommt.

• Plattformen, die Ausfälle, Defekte oder andere Probleme, die die Anwendungsleistung beeinträchtigen, nicht kommunizieren.

• Angeblich fortschrittliche Plattformen, die keinen vernünftigen technischen Support mitbringen. Spätestens wenn Anwender mehr über die Plattform wissen als die Kundendienstmitarbeiter, stimmt etwas Gravierendes nicht.

Gerade bei LCNC-Plattformen ist es wichtig, dass IT-Entscheider ihre Hausaufgaben machen. Viele Lösungen bieten beträchtliche Vorteile, erfordern aber intensive Beschäftigung damit und auch Proofs-of-Concepts, um die Fähigkeiten zu prüfen. Die folgenden acht Anzeichen deuten darauf hin, dass Ihre LCNC-Plattform mehr Probleme schafft als löst.

1. Benutzererwartungen nicht erfüllt

Wenn Ihr Unternehmen eine Villa mit drei Schlafzimmern und einer Garage erwarten, Ihr Low-Code-Tool aber nur eine Hütte mit Plumpsklo ermöglicht, sind die Erfolgsaussichten für Ihr Projekt gelinde gesagt überschaubar. Um eine LCNC-Plattform effektiv zu nutzen, sind Schulungen genauso unabdingbar wie Diskussionen mit den Stakeholdern darüber, welche Kompromisse nötig sein werden, um ein Geschäftsergebnis zu erzielen. Sind die Entwickler nicht in der Lage, Geschäftsziel oder Vision zu unterstützen beziehungsweise zu erreichen, sollten Sie die Wahl der Plattform und den technischen Ansatz überdenken.

Tam Ayers, Field CTO bei Digibee, beschreibt, worauf es ankommt: "Es ist ein wichtiger Indikator, wenn ein Unternehmen beginnt, wegen der Probleme mit seiner LCNC-Plattform seine Anforderungen zurückzunehmen beziehungsweise seine Erwartungen an die Geschäftsergebnisse einzuschränken. Eine solche Plattform sollte die Wertschöpfung für das Unternehmen erhöhen, nicht reduzieren."

2. Business-Anforderungen verfehlt

Viele LCNC-Plattformen ermöglichen es Entwicklern, die Implementierung mit benutzerdefiniertem Code anzupassen. Muss jedoch zu viel professioneller Code einfließen, könnten sich LCNC-Lösungen als Hemmschuh erweisen. Andererseits: Wenn die Stakeholder die Anforderungen schreiben und dann den entstehenden LCNC-Anwendungen nicht offen gegenüberstehen, sollten sie lieber gleich eine individuelle Lösung entwickeln lassen.

"Eine Low-Code-Lösung, bei der die Entwickler der Plattform irgendwann den Rücken zukehren und wieder auf eine Full-Code-Entwicklungsumgebung setzen, um eine entstandene Anwendung zu verbessern, ist eine Lösung, die durchweg unterdurchschnittlich abschneiden wird", sagt David Brault, Product Marketing Manager bei Mendix.

Guljeet Nagpaul, Chief Product Officer bei ACCELQ, sieht das ähnlich: "Wenn Sie feststellen, dass Ihre Plattform ständig angepasst werden muss, deutet das darauf hin, dass der Code ohne Disziplin geschrieben wurde." Der Wartungsaufwand für solche Anwendungen werde schnell untragbar, der Return on Investment stelle sich nicht ein.

3. No No-Code

No-Code-Plattformen sollten von Nicht-IT-Profis genutzt werden können, um eine Funktion zu entwickeln und zu unterstützen, ohne dass die IT-Abteilung entwickeln, testen und bereitstellen muss. No-Code-Lösungen sind Citizen Developern vorbehalten - Business-Menschen, die die Zeit, das Interesse und den technischen Scharfsinn mitbringen, um mit vereinfachten Werkzeugen Funktionen zu entwickeln.

Manchmal heißen Plattformen aber auch einfach nur No Code, wie Dinesh Varadharajan, Chief Product Officer bei Kissflow, kritisiert: "Wenn Business-Anwender Schwierigkeiten haben, einfache Prozesse oder Anwendungen selbst zu erstellen und weiterhin von der IT abhängig sind, bietet die verwendete No-Code-Plattform entgegen der Herstellerversprechen keinen integrativen Ansatz."

4. IT-Profis "unnötig"

Low-Code ist nicht gleichbedeutend mit No-Code. Erstere Plattformen zielen darauf ab, Entwickler dabei zu unterstützen, Lösungen schneller und einfacher zu erstellen als mit einer Professional-Code-Lösung. Obwohl die Plattformen visuelle Funktionen mitbringen, sind im Entwicklungszyklus einer Low-Code-Umgebung häufig irgendwann Programmier- oder IT-Kenntnisse erforderlich.

Francis Carden, Vice President für intelligente Automatisierung und Robotik bei Pega, hält es für ein Warnsignal, wenn Low-Code-Plattformen explizit versprechen, dass die IT-Abteilung nicht für den Support benötigt werde. "Ein solches Versprechen schafft eine Diskrepanz: Man kann vielleicht schnell bauen, aber was passiert, wenn die Dinge in Betrieb gehen? Wer bestimmt die Durchführbarkeit und das Risiko zu diesem Zeitpunkt? Und wer unterstützt das, was Sie aufgebaut haben, wenn Dinge aktualisiert oder repariert werden müssen oder wenn die Compliance kritische Änderungen erzwingt?" Das überzogene Versprechen, die IT außen vor lassen zu können, werde im Nachhinein zu Komplikationen führen, ist der Pega-Mann überzeugt.

Einige Plattformen unterstützen sowohl das No-Code- als auch das Low-Code-Paradigma, indem sie Tools für Citizen Developer genauso wie für fortgeschrittenen Low-Code-Programmierer mitbringen. Allerdings ist die Behauptung, überhaupt keine IT mehr zu benötigen, selbst im Fall einer reinen No-Code-Lösung nicht besonders glaubwürdig. Zudem kann ein solch falsches Versprechen zu technischen Schulden, Security-Problemen und anderen Komplikationen führen.

5. Integrationsflut

Ich habe schon Anwendungen und Workflows entwickelt, die verschiedene Low-Code-Plattformen in eine Gesamtlösungsarchitektur einbinden. Es stellt sich aber die Frage, ob Kosten und Aufwand für Kauf, Konfiguration und Integration mehrerer SaaS- und Low-Code-Lösungen - gemessen an den zu erwartenden Vorteilen - nicht viel zu hoch sind.

Kevin Marcus, CTO und Mitbegründer von Versium, gibt zu bedenken: "Die starre Natur von Low- und No-Code-Systemen verleitet Teams dazu, irgendwann weitere Systeme anzuschaffen, um Fälle zu bearbeiten, die außerhalb der Möglichkeiten des ursprünglichen Systems liegen." So könne ein Sammelsurium von Systemen entstehen, in dem erstmal integriert werden müsse. Das nimmt oft viel Zeit und Ressourcen in Anspruch. "Am Ende wäre es dann oft sinnvoller gewesen, gleich die IT- oder Entwicklungsabteilung machen zu lassen."

Das verdeutlicht, warum LCNC-Entwicklung durch die IT-Architektur unterstützt werden muss. Vielleicht wird durch die Integration von Low-Code mit SaaS ein Minimum Viable Pproduct erreicht. Wenn jedoch einige Iterationen später die Lösung in viele integrierte Tools ausufert, könnte die IT-Abteilung ein Refactoring vorschlagen, um zu einer robusteren Lösung zu kommen.

6. Risikobehaftete Integrationen

Bei Alon Jackson, CEO und Mitbegründer von Astrix Security, schrillen die Alarmglocken, wenn eine Plattform zu viele offene Ports oder eine Integration mit vollen Zugriffsrechten erfordert. "Das untergräbt traditionelle Sicherheitsprozesse und setzt Unternehmen einem potenziellen Datenverlust aus." Diese - wichtigen - Bedenken gelten für jede Integration, unabhängig davon, ob SaaS, Low-Code oder benutzerdefinierter Code. Laut Jackson erfordern sichere Implementierungen und Integrationen folgende Schlüsselfunktionen:

• Sichtbarkeit,

• Threat Detection,

• kontextbezogene Abschwächungen,

• Security Policies sowie

• Leitplanken, um diese Maßnahmen durchzusetzen.

7. Plattform-Hürden

Mendix-Manager Brault betont zudem, wie wichtig es sei, dass LCNC-Technologien flexible Bereitstellungs- und Cloud-Hosting-Plattformen unterstützten. "Zu den Anzeichen einer schlechten Low-Code-Lösung gehört, dass sie neben der Web- und Progressive-Web-Apps-Unterstützung keine native mobile App-Entwicklung unterstützt oder nicht Cloud-Native beziehungsweise Multi-Cloud-fähig ist."

Zu ergänzen wäe, dass auch ein fehlender oder unzureichender Mobile-Support ein großes Problem bei der Anwendungsentwicklung auf jeder Plattform ist. Die Frage, um die es geht, ist, ob Web- und Mobile-Experiences einfach auf Grundlage der erwarteten User Personas und Use Cases konfiguriert werden können.

8. Testing-Schwierigkeiten

Cyril Otalora, Director of Solution Engineering bei Provar, stellt sich die Frage, wie einfach es ist, auf LCNC-Plattformen zu testen. "Eine Testing-Strategie entsteht hier oft erst nachträglich", meint der Experte und weist auf die Risiken hin: "Das Versprechen von schneller Bereitstellung, geringeren Kosten und höherer Sicherheit wird zunichte gemacht, wenn die Unternehmen das Regressionsrisiko nicht im Griff haben und auf kostspieliges und langwieriges manuelles Testing zurückgreifen." (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation InfoWorld.