Low-Code und No-Code waren lange Zeit in aller Munde und galten als „Gamechanger“. Von einer Revolution kann aktuell zwar keine Rede sein, aber die Nutzung steigt kontinuierlich. Low-Code- und No-Code-Konzepte weisen allerdings einige Grenzen und Risiken auf. IT-Dienstleister Consol nennt vier Kriterien für den anwendungsspezifischen und sicheren Einsatz der Entwicklungsumgebungen.
Die zentralen Vorteile der Low-Code- und No-Code-Konzepte sind der geringere Programmieraufwand, der niedrigere Know-how-Bedarf und die kürzeren Entwicklungszyklen. Auch wenn beide Methoden letztlich auf den Citizen Developer abzielen, also den Fachbereichsentwickler, sollte die Plattformeinführung nicht allein in die Hände von Fachabteilungen gegeben werden, denn dies kann zu Risiken und Inkonsistenzen führen. So besteht die Gefahr, dass lokale Insellösungen entstehen, die nicht mehr umfassend der Verantwortlichkeit der IT unterliegen und die gegebenenfalls auch Sicherheitsrisiken mit sich bringen. Insellösungen verursachen zudem oft organisatorische und prozessuale Probleme, etwa wenn verschiedene Systeme „stand-alone“ agieren und dadurch viele dezentrale Datenpools vorhanden sind – mit teilweise duplizierten, redundanten oder inkonsistenten Datenbeständen.
Für einen adäquaten und sicheren Einsatz empfiehlt Consol deshalb vier konkrete Maßnahmen:
1. Definition der Anwendungsfälle
Die Entscheidung zwischen No-Code und Low-Code hängt immer von den Einsatzbereichen ab. Insbesondere No-Code-Applikationen stoßen häufig schnell an ihre Grenzen, wenn es um komplexe Integrationen oder die Vernetzung mit Drittsystemen geht. Da diese Applikationen auf Standard-Toolsets basieren, ist es häufig schwierig, kundenspezifische und vom Standard abweichende funktionale Anforderungen zu erfüllen. Folglich eignet sich die No-Code-Nutzung nur für relativ einfache Anwendungsfälle. Mit Low-Code-Tools hingegen können Nutzer auch komplexe technische und fachliche Aufgaben mit einem geringen Programmieraufwand erledigen. Dies betrifft etwa die flexible anforderungsspezifische Anpassung von Prozessen, Businesslogik und Datenmodellen oder die Interaktion und den Datenaustausch mit Drittsystemen im Unternehmen.
2. Zentrale Steuerung des Einkaufs durch die IT
Der Einkauf von No-Code- oder Low-Code-Lösungen sollte immer zentral gesteuert und unter Einbeziehung der Unternehmens-IT erfolgen. Nur so ist gewährleistet, dass die Entwicklungsumgebungen im Einklang mit der gesamten IT-Strategie eines Unternehmens stehen und keine Silo-Lösungen entstehen. Die IT kann zudem sicherstellen, dass die Plattformen den Security-Richtlinien und Datenschutzvorgaben des Unternehmens entsprechen.
3. Aufbau des erforderlichen Know-hows
Zur Betreuung der Low-Code- und No-Code-Systeme braucht es qualifiziertes Personal. Das heißt, Unternehmen müssen Verantwortliche zur fachlichen Betreuung der Applikationen festlegen. Dies erfordert unter Umständen Schulungen und Weiterbildungsmaßnahmen, um die nötigen fachlichen Skills zu erlangen. Unternehmen können hier auch abwägen, ob sie interne Ressourcen aufbauen wollen oder ob es kostengünstiger ist, externe Leistungen nach Bedarf einzukaufen.
4. Betreuung und Weiterentwicklung der Low-Code- und No-Code-Systeme
Mit Low-Code- und No-Code-Plattformen haben Fachabteilungen die Möglichkeit, neue Lösungen autark und damit agil zu erstellen und zu adaptieren. Dies darf aber nicht bedeuten, dass sie völlig unabhängig von der IT agieren können. Die IT bleibt schließlich für die Wartung, regelmäßige Updates oder den Support der Plattformen verantwortlich. Es bedeutet auch, dass die IT eine ausreichende Kenntnis der Systeme besitzen muss.
„Gerade Low-Code-Plattformen besitzen ein hohes Potenzial für die schnelle Entwicklung und Adaption von Applikationen. Allerdings sollten Unternehmen sie nicht ungeprüft ohne Einbindung in die zentrale IT-Strategie einsetzen, um eine optimale Nutzung und Vermeidung von Sicherheitsrisiken zu gewährleisten“, erklärt Kai Hinke, Leiter Consol CM Software bei Consol. „Aber eines muss klar sein: Ausschließlich auf Low-Code-Entwicklung zu setzen, wird kein gangbarer Weg sein. Die Individualentwicklung wird auch weiterhin bei sehr komplexen und kundenspezifischen Anwendungsfällen das Mittel der Wahl bleiben.“
www.consol.de