Beyond SAP Build

Das fehlende Werteversprechen von SAP Build: Kein Low-Code-Entwicklungsansatz für jeden

Die effiziente Entwicklung von Softwareanwendungen ist in der digitalen Geschäftswelt von entscheidender Bedeutung. Ein detaillierter Blick auf die Vorteile, Herausforderungen und Einschränkungen von SAP Build und deren Auswirkungen auf die App-Entwicklung verrät, inwiefern die SAP ihrem Werteversprechen insbesondere im Hinblick auf den Low-Code-Ansatz standhalten kann.

SAP Build verspricht Unternehmen eine benutzerfreundliche Umgebung, in der Apps ohne Programmierkenntnisse entwickelt werden können. Die Plattform basiert auf der Software des Unternehmens Appgyver, das 2021 von SAP übernommen wurde. Sie bietet leistungsstarke Prototyping- und Design-Tools, mit denen Entwickler schnell interaktive Benutzeroberflächen erstellen können. Der frühe Einbezug der Benutzer und kontinuierliches Feedback sollen die Optimierung der Anwendungen für eine optimale Benutzererfahrung ermöglichen.

Ein großer Vorteil von Build liegt, wie bei jeder Low-Code-Plattform, in der Beschleunigung der Entwicklung von Applikationen. Die Plattform bietet hierzu vorgefertigte UI-Komponenten und Vorlagen, die den Entwicklungsprozess effizienter gestalten. Durch die Wiederverwendung vorhandener Komponenten können Entwicklungszeiten erheblich verkürzt werden, was zu einer schnelleren Markteinführung von Anwendungen führt.

Effektive Zusammenarbeit und Kommunikation sind entscheidend für den Erfolg von Entwicklungsprojekten. SAP Build bietet daher auch Funktionen wie Kommentare, Benachrichtigungen und die Freigabe von Entwürfen, um die nahtlose Zusammenarbeit zwischen Entwicklern, Designern und Benutzern zu unterstützen. Dies ermöglicht den Austausch von Feedback und die gemeinsame Arbeit an Verbesserungen, um Anwendungen zu entwickeln, die den Erwartungen der Benutzer entsprechen.

Programmierkenntnisse gefragt

Trotz der Vorteile gibt es jedoch auch mehrere Herausforderungen bei der Verwendung von Build im Entwicklungsprozess. Während die Vorteile darin liegen, dass benutzerzentrierte Anwendungen schnell und effektiv entwickelt werden können, bestehen die Einschränkungen vor allem bei der Nutzung der Low-Code-Entwicklung für App-Builder ohne Programmierkenntnisse.

In der Praxis zeigt sich, dass diese Plattform tatsächlich erhebliche Programmierkenntnisse erfordert. Somit ist eine intensive Einarbeitung durch Schulungen in die Plattform erforderlich, insbesondere für Anwender, Entwickler und Designer, die nicht mit der Plattform vertraut sind. Die vielfältigen Funktionen und Möglichkeiten von SAP Build erfordern eine angemessene Schulung, um das volle Potenzial der Plattform auszuschöpfen.

Ein weiteres Problem von Build ist die fehlende Internationalisierung des Wysiwyg-Editors. Während die Inhalte der erstellten Apps in verschiedene Sprachen übersetzt werden können, bleibt das Tool selbst ausschließlich auf Englisch. Dies stellt vor allem für Unternehmen in nicht englischsprachigen Ländern eine Hürde dar und erschwert die Nutzung der Plattform.

Eines der Hauptprobleme ist die eingeschränkte Exportfunktion von SAP Build. Obwohl die Plattform die Erstellung von mobilen Apps verspricht, ist derzeit nur die Generierung von Webanwendungen möglich. Sprich, derzeit ist es nicht möglich, native iOS- oder Android-Apps direkt mit Build zu entwickeln.

Der Export von Apps in eine Webanwendung dauert zudem ungewöhnlich lange und die angekündigte E-Mail-Benachrichtigung bei Fertigstellung fehlt. Die erzeugten Webanwendungen basieren auch nicht auf dem hauseigenen UI5-Framework der SAP, sondern verwenden React Native. Dies führt zu einer Abhängigkeit, die von SAP nicht kontrolliert werden kann, und erschwert die Bearbeitung und Wiederverwendung des Codes, da Build die gewohnte SAP-Fiori-Designsprache vermissen lässt. Zwar könnte eine Integration mit den SAP-Mobile-Services in Zukunft möglich sein, jedoch gibt es derzeit keine klaren Hinweise darauf in der Dokumentation oder der Roadmap von SAP Build.

Die Integration von Build in bestehende Unternehmenslandschaften stellt ebenfalls eine große Herausforderung dar. Obwohl die Plattform als Low-/No-Code-Lösung konzipiert ist, gestaltet sich die Backend-Anbindung komplex und betrifft somit insbesondere den Aspekt des Citizen Developer. Es wird deutlich, dass die Datenbindung und -verarbeitung, die im SAP-Umfeld üblich sind, nichts für den Citizen Developer sind.

Wissen über OData

Um Daten aus Unternehmenssystemen wie S/4 Hana Cloud oder On-premises anzubinden und anzuzeigen, sind spezifisches Wissen über das OData-Protokoll, die Abbildung von Variablen und deren Einbindung in den App-Lebenszyklus erforderlich. Die zur Verfügung gestellten Mechanismen und der Formeleditor gehen über das Konzept des Low Code oder No Code hinaus. Dies erschwert es Citizen Developers, ohne umfassende Kenntnisse solche Verbindungen herzustellen und komplexe Formeln zu erstellen.

Die nahtlose Verbindung zu S/4-Hana-Cloud- oder On-premises-Daten bleibt daher eine Herausforderung innerhalb der Build-Plattform. Auch die Authentifizierung, Autorisierung und die Anbindung von Datenquellen sind nicht ausgereift und bieten nur begrenzte Möglichkeiten für professionelle Entwickler. Rollenzuweisungen und ein umfassendes Rollen- und Rechtesystem fehlen ebenfalls.

Die Skalierbarkeit und Performance von Unternehmensanwendungen sind von entscheidender Bedeutung. Bei der Verwendung von Build ist es wichtig, die Architektur gründlich zu überprüfen, effizienten Code zu entwickeln und Tests unter realen Bedingungen durchzuführen, um Engpässe oder Leistungsprobleme frühzeitig zu erkennen und zu beheben.

Security und Datenschutz

Die Sicherheit und der Datenschutz sind weitere wichtige Aspekte bei der Entwicklung von Unternehmensanwendungen. Bei der Nutzung von Build müssen Unternehmen sicherstellen, dass alle Anforderungen an den Datenschutz und die Datensicherheit erfüllt sind, insbesondere wenn sensible Unternehmensdaten verarbeitet werden.

Einer der Hauptnachteile für die IT-Teams und die professionellen SAP-Entwickler besteht darin, dass die Erstellung mit SAP Build nicht so flexibel ist wie beispielsweise das Programmieren in Abap. Abap ermöglicht es Entwicklern, hochkomplexe Geschäftslogiken umzusetzen und auf spezifische Anforderungen einzugehen. Mit der Low-Code-Plattform SAP Build gestaltet es sich schwierig, solche komplexen Logiken zu implementieren und zusätzliche Anpassungen oder Workarounds anzufordern.

Ein nicht unerheblicher Faktor besteht auch in der Akzeptanz innerhalb der SAP-Community, die bekannt für ihre leistungsstarke Programmiersprache Abap ist. Innerhalb der Community wurden jedoch auch verschiedene Ansätze im Bereich Low-Code/No-Code-Entwicklung diskutiert. Diverse Kooperationen und Zukäufe der SAP in der näheren Vergangenheit im Bereich Low und No Code wurden zwar stark gepusht, konnten aber innerhalb der SAP-Community bislang nicht wirklich überzeugen. Die SAP-Community hat eine gewisse Skepsis entwickelt, wenn es um Low-Code/No-Code-Plattformen geht.

Ein Aspekt, der in diesem Zusammenhang in der SAP-Community für Diskussionen gesorgt hat, ist die Absage einer Kooperation mit Microsoft und dem Produkt Power Apps. Viele Mitglieder der SAP-Community waren enttäuscht, da Power Apps eine große und aktive Community besitzt. Diese Absage führte allerdings auch dazu, dass andere Low-/No-Code-Plattform-Anbieter wie Simplifier nun die Chance haben, SAP-Bestandskunden und Partner für sich zu gewinnen, indem sie den Mehrwert ihrer Lösungen für die SAP-zentrische Anwendungsentwicklung überzeugend präsentieren. 

Es lohnt sich daher für Unternehmen,  mit SAP-Anwendern und -Entwicklungsteams einen Blick auf schlankere und flexiblere Low-Code-Alternativen wie Simplifier zu wagen, um die eigenen Anforderungen mit den Möglichkeiten und Funktionalitäten der Plattformen abzugleichen, um schlussendlich eine geeignete Low-Code-Technologie zu finden, die den eigenen Anforderungen gerecht wird.

Insgesamt kann festgehalten werden, dass SAP Build sein Versprechen als Low-Code-Entwicklungsplattform nicht einhalten kann. Sowohl für Fachanwender als auch für Pro-Code-Entwickler ergeben sich verschiedene Einschränkungen und Mängel. Die Plattform ist noch nicht ausgereift genug und bietet keinen umfassenden und vor allem einheitlichen Lösungsansatz für die Entwicklung von Unternehmensanwendungen. Ursprünglich wurde SAP Build als Lösung angepriesen, mit der Unternehmen eigene Apps und Prozesse ohne Programmierkenntnisse erstellen können. Doch in der Praxis zeigt sich, dass diese Plattform tatsächlich erhebliche Programmierkenntnisse erfordert.

Schlanke Alternative

Simplifier ist ein Low-Code-Anbieter, der in der SAP-Welt mittlerweile als „schlanke Alternative zu SAP Build“ bekannt ist und viele Unternehmen, die mit der Toolchain der SAP und der BTP an ihre Grenzen gestoßen sind, überzeugt hat. Mit der modernen Technologie auf Basis des in der SAP-Community beliebten UI5-Frameworks konnte die Low-Code-Plattform viele SAP- und Abap-Entwickler begeistern. Die Vorteile bei der Nutzung von Simplifier liegen unter anderem bei den vielseitigen standardisierten Integrationsmöglichkeiten, der flexibelsten UI für die App-Nutzung auf allen Endgeräten (inkl. Wearables), einem hohen Grad an Wiederverwendbarkeit für alle erstellten und existierenden Inhalte und einem schlanken Betriebskonzept beim Ausrollen und Verwenden von Applikationen und mobilen Apps.