NO CODE/LOW CODE BEI SAP UND SALESFORCE: DAS EINE FUNKTIONIERT, DAS ANDERE NICHT

No Code/Low Code bei SAP und Salesforce: das Eine funktioniert, das Andere nicht Sie schrieben Quellcode, der kompiliert und zur Laufzeit ausgeführt wurde. Die Technologien und Werkzeuge zur Erstellung von Software haben sich im Laufe der Jahre verändert, aber die Grundsätze und Anforderungen sind dieselben geblieben. Um Software zu schreiben, musste man die Logik dahinter verstehen, was ein allgemeines Wissen über IT-Infrastruktur, Kenntnisse über das zugrunde liegende Betriebssystem/Webbrowser, Verständnis für funktionale und/oder objektorientierte Programmiermodelle, Datenbankkenntnisse und vieles mehr erforderte. Dies benötigt jahrelanges Lernen, und um ein wirklich großer Entwickler zu werden, brauchte man obendrein jahrelange Erfahrung.

Seit Jahrzehnten haben wir einen Mangel an qualifizierten IT-Ressourcen, insbesondere an erfahrenen Softwareentwicklern. Da dieser Mangel den Fortschritt bei der Entwicklung von Anwendungen, die Unternehmen bei der Verbesserung ihrer Geschäftsabläufe helfen, verzögerte, wurden No-Code-Tools eingeführt – Anwendungen ohne Codierung, so dass auch ein Endbenutzer die für seine Arbeit erforderlichen Programme erstellen kann. Eines der ersten Tools dieser Art war Microsoft Access, mit dem Unternehmen in den 1990er Jahren datenbankgestützte Anwendungen ohne Programmierung erstellen konnten.

Nach dem gleichen Prinzip funktionieren Low-Code-Tools, mit denen Sie 90 % der Arbeit ohne Code erledigen und spezifische Verbesserungen mit nur minimalem Programmieraufwand und Fachwissen hinzufügen können.

In den 2020er Jahren begannen alle großen Softwareanbieter und -plattformen, No-Code-Tool anzubieten (z. B. Microsoft Power Apps). Heute sind kleinere Unternehmen auf dem Markt, die sich auf No-Code-Tools spezialisiert haben (Neptune, Mendix, usw.).

In diesem Blog vergleichen wir die No-Code-Ansätze für SAP und Salesforce und erklären, warum der Eine funktioniert und der Andere nicht.

SAP Build

SAP erwarb AppGyver und integrierte es in sein Cloud-Angebot. Es heißt jetzt SAP Build und läuft auf der SAP Business Technology Platform (BTP). Im Großen und Ganzen funktioniert Build folgendermaßen:

• Man beginnt mit einer leeren Blatt auf Ihrem Bildschirm, auf dem man die UI-Elemente wie Labels, Schaltflächen, Checkboxen oder Tabellen zieht und ablegt.
• Man verbindet diese UI-Elemente mit Daten und Ereignisse.
• Man implementiert die Navigation zwischen den Screens.
• Wenn man das Backend der neuen Frontend-Anwendung auf dem SAP BTP anlegen will, muss dies in einem separaten Schritt getan werden. Wenn Ihre Benutzeroberfläche 10 Felder hat, müssen Sie diese für das Backend ein zweites Mal modellieren (und vergessen Sie nicht, dass die Datentypen und Feldlängen übereinstimmen müssen!)
• Wenn man ein bestehendes Backend wie SAP S/4HANA oder ECC 6.0 integrieren möcht, kann man OData, REST oder die SAP Integration Suite (für SAP ) nutzen. Dies erfordert ein gutes Verständnis der einzelnen verfügbaren Dienste. Wenn kein Dienst die Bedürfnisse erfüllt, muss man einen entwickeln. Leider werden BAPIs oder Funktionsbausteine nicht direkt unterstützt.
  

  Das SAP Build No-Code Tool

  SAP Build ist nur ein Beispiel für viele ähnliche Tools, die im SAP Ecosystem eingesetzt werden, darunter Lösungen wie z.B. Neptune.

Salesforce

Salesforce hat einen radikal anderen Ansatz für No-Code. Der große Vorteil besteht darin, dass die No-Code/Low-Code-Tools in die Plattform integriert sind und einen wesentlichen Bestandteil der Plattform bilden. Im Großen und Ganzen erstellt man eine Anwendung folgendermaßen:

• Im Salesforce Setup erstellt man ein neues Geschäftsobjekt, das das reale Objekt darstellt, das die Anwendung anzeigen soll.
• Man fügt die Felder zu dem neuen Objekt hinzu und legt den Datentyp, die Länge usw. fest.
• Man legt die Aktionen fest, die man ausführen möchte, und welche anderen Objekte damit verbunden sind.

Fertig. Der Benutzer muss keine Designentscheidungen treffen, da Salesforce diese übernimmt.

Definieren des Datenmodells, der Aktionen und der Benutzeroberfläche an einer zentralen Stelle in Salesforce

Vergleich der Ansätze

SAP Build bietet einem viel mehr Flexibilität, wenn es um die Definition der Benutzeroberfläche geht, aber das ist normalerweise keine gute Idee. Wir kennen viele fantastische Softwareentwickler, die wirklich gut in dem sind, was sie tun, aber selbst ihnen fällt es schwer, eine anständige, benutzerfreundliche Benutzeroberfläche zu erstellen (dafür gibt es ja UX-Designer!). Wenn schon Softwareentwickler vor einer Herausforderung stehen, wie können wir dann von Endbenutzern erwarten, dass sie eine Benutzeroberfläche erstellen, die die grundlegenden Anforderungen erfüllt? Der Drag-and-Drop-Ansatz von Build kann auch dazu führen, dass die Anwendungen anders aussehen, sich anders anfühlen und sich anders verhalten, was es für den Endbenutzer sehr schwierig macht, sie zu erlernen und zu benutzen.

Salesforce hingegen lässt einem diese Freiheit nicht. Man legt fest, was man anzeigen möchten und welche Aktionen gewünscht sind, und Salesforce erledigt den Rest. Salesforce erstellt für einen eine Listenansicht und einen Detaildialog – einen zum Bearbeiten des Objekts und einen weiteren zum Erstellen neuer Objekte. Es sorgt dafür, dass ein Datumsfeld eine Datumsauswahl hat und dass die Zahlen rechts ausgerichtet sind. Man muss sich auch keine Gedanken darüber machen, wie die Daten gespeichert werden; das übernimmt Salesforce für einen. Geschickterweise nimmt Salesforce dem Benutzer viel Verantwortung ab und sorgt dafür, dass alle Listen und Detailseiten gleich aussehen. Die Schaltflächen befinden sich immer an der gleichen Stelle, was es den Benutzern erleichtert, neue Anwendungen und Prozesse zu erlernen.

Mit der Salesforce Plattform kann man neue Geschäftsprozesse und Anwendungen schneller erstellen als mit SAP Build.

Schlussfolgerung

Es gibt keinen besseren Weg, um den Unterschied zwischen den beiden Plattformen zu verdeutlichen, als zu vergleichen, wie SAP und Salesforce ihre eigenen standard Lösungen erstellen. Die Fiori-basierten Anwendungen von SAP (ob sie nun auf einem ABAP-Stack oder auf dem BTP laufen) werden auf klassische Weise geschrieben: Entwickler programmieren OData-Dienste, JavaScript und XML. Salesforce hingegen verwendet seine eigenen No-Code-Tools zur Erstellung von neuen Lösungen. Erkennen Sie den Unterschied?

Unserer Meinung nach ist Salesforce die bessere Lösung, um neue, benutzerfreundliche Anwendungen zu erstellen, ohne Code schreiben zu müssen. Selbst wenn Sie eine neue Benutzeroberfläche auf der Grundlage von SAP erstellen möchten, lässt sich dies auf der Salesforce Plattform einfacher und besser bewerkstelligen.

Mit Vigience Overcast können Sie Daten, die in SAP S/4HANA, SAP ERP oder einer der cloudbasierten Lösungen, die auf dem SAP BTP laufen, gespeichert sind, ganz einfach integrieren und sie entweder replizieren oder in Echtzeit in der Salesforce UI anzeigen. Auf diese Weise können Sie eigenständige Anwendungen oder Lösungen erstellen, die Daten aus SAP mit Informationen aus Salesforce oder Drittanbieteranwendungen kombinieren. Overcast geht über das hinaus, was SAP Build bietet, da Sie problemlos jedes der Tausenden von BAPIs integrieren können, die in SAP verfügbar sind.

SAP Daten in Salesforce ohne eine Zeile Code

Da Salesforce DAS System für den Einsatz auf dem heutigen Geschäftsmarkt ist, macht es Sinn, benutzerdefinierte Anwendungen darauf aufzubauen, indem man seine No-Code-Infrastruktur nutzt und Overcast zur Integration mit jedem Backend-System, insbesondere SAP, einsetzt.

Wenn Sie mehr über die Möglichkeiten erfahren möchten, die Sie mit Vigience Overcast und der Salesforce-Plattform haben, sollten Sie sich bei uns melden und unseren Newsletter abonnieren.