SAP – Das Grauen der Technik hat einen Namen

Nachdem ich diesen Witz einer Aussage von Olaf Scholz bei heise gelesen habe, war mein Ruhepuls bestimmt um 40 erhöht. Lange überlegt, ob ich dazu wirklich etwas schreiben will, aber letztendlich hat der Hass gewonnen.
Falls sich hier ein SAP-Fanboy findet, sollte er besser jetzt gehen.

SAP – Ein Konzern, ein Produkt, ein Durchfall

SAP ist hierbei nicht nur der Name einer absolut katastrophalen technischen Entwicklung, sondern auch der Name eines börsennotierten Unternehmens mit Sitz in Walldorf. Während man von der Firma und auch deren Gründung und Strategien halten kann was man will, werde ich mich heute nicht darüber auslassen.

Abgesehen davon ist das auch rechtlich relativ unklug. Zudem bin hier auch nicht mehr auf dem aktuellsten Stand. Einfach aus puren Desinteresse.

SAP als Produkt ist ein ERP-System, quasi das „all in one für Firmen“, die Software der „Softwares“.

ABAP

ABAP ist der Name einer grauenvollen Programmiersprache, mit absurden Limitierungen und einer absolut furchtbaren Syntax.

Wessen Augen noch nicht von dieser puren Grauenhaftigkeit weg gelötet wurden, will ich das nicht vorenthalten:

Auf dem Bild oberhalb findet sich die „Entwicklungsumgebung“ im Debugger-Modus. Die Zeit für eine Session ist übrigens begrenzt, ist das nicht genial?! Ich debugge am liebsten unter Zeitdruck!

„Entwicklungsumgebung“ – ABAP Workbench

Für SAP üblich lässt sich dieses Ungetüm über den einfach und einprägsamen Kürzel SE80 öffnen.

Zu den absolut großartigen Features zählt für mich der Pretty Printer und der GUI Builder (dessen Name ich leider nicht mehr weiß) der natürlich absolut Pixel-getreu ist (und dadurch nicht skaliert).

Der Pretty Printer hat hierbei genau eine Funktion:
Er konvertiert Keywords in Großbuchstaben, und das in nur wenigen Sekunden, auch bei einigen wenigen Zeilen Code oder dem standesgemäßen Hello World.

Natürlich unterstützt die Sprache auch Konstrukte wie Ifs, wenn alle Strukturen genug auf mehrere Zeilen aufgeteilt und mit „SQL-Style-Operatoren“ ausgestattet sind lässt sich auch schon alles bauen. In nur 3 Schritten, bauen, aktivieren und starten! High-Speed bei der Entwicklung ist garantiert. Je nach Geschwindigkeit der Installation kann das auch schon mal ein paar Minuten dauern.

Hin und wieder kann es auch zu obskuren Problemen beim Übersetzen in C/C++-Code kommen, der dann in Maschinen-Code kompiliert wird.

Offline entwickeln ist natürlich nicht vorgesehen, und dezentral ist bei SAP sowieso das Fremdwort schlechthin. Versionierung ist ebenso ein Feature, das man vergeblich sucht.

Eclipse to the rescue?

Natürlich hat man „schnell“ festgestellt, dass SAP nicht so an die Entwickler denkt, also haben sich schlaue Köpfe überlegt einfach Eclipse zu nutzen. Kostet ja schließlich nichts, ist Open Source und damit ideal zum Umbau geeignet, irgendwelche „Freiwilligen“ finden sich schon, die dabei dann helfen.

Jeder der schon mal das „Vergnügen“ hatte, mit Eclipse zu arbeiten, merkt schnell, dass es sich hier auch nicht wirklich um ein Upgrade handelt.

Letztendlich landet der ganze Source-Kot dann wieder auf einem Testsystem oder im Worst Case einfach auf Produktion. Nur eben in einer Kopie, ja richtig gelesen KOPIE des Source Code.

Syntax

Die Syntax von ABAP ist klassisch deutsch. Jede Anweisung wird, wie es sich gehört, mit einem Punkt beendet.

Keywords werden im legendären IBM-Case in den Bildschirm graviert. An sich ist das egal, aber Keywords werden per Konvention großgeschrieben.

Variablen dürfen maximal 30 Zeichen haben, klingt erstmal etwas limitiert (gerade wenn man aus er Java Enterprise Ecke kommt), aber das geht noch schlechter!

Tabellen dürfen bis zu 16 Zeichen lang werden, das ist doch eine Ansage!
Wenn man noch übliche Präfixe wegrechnet, bleiben einem also nicht einmal 10 Zeichen, um einen sprechenden Variablennamen zu vergeben. Wie zu erwarten, führt das zu sehr kryptischen Namen und damit guter Verwirrung.

Fun Fact am Rande: der Artikelstamm wird in der Tabelle MARA gespeichert.

Erprobte ABAP-Entwickler (die schon lange genug diesem Problem ausgesetzt waren) finden sich hier oft erstaunlich gut zurecht, während jeder normale Entwickler mit dem Kopf schüttelt. Als gutes Beispiel lässt sich hierbei nennen, dass nur z_ als Präfix genutzt werden darf, alles andere muss bei SAP lizenziert werden! Genial, oder?!

Zugegebenermaßen ist die direkte SQL-Integration ein Bonus für den gelangweilten Business-Entwickler. Aber immer schön die Leerräume richtig setzen, sonst bekommt man einen Fehler, der absolut nichts aussagt.

Objekt orientierte Entwicklung

Dieses Paradigma wurde in ABAP nach gepatcht und genau so fühlt sie sich an. Grauenvoll und einfach nur unter heißer Nadel nach gestrickt, hier wurde auch mehrmals nachgebessert. Letztlich bleibt aber sichtbar, dass hier mit wenig Liebe einfach ein Feature hinterher geschmissen wurde, als das Thema gerade der heiße Scheiß war.

Ein Großteil des gängigen ABAP-Codes da draußen ist deshalb auch nach wie vor prozedural geschrieben.

GUI

Wie bereits angesprochen, lassen sich GUIs nur pixelbasiert erstellen.

Der Name dieses wunderschönen Tools ist mir leider entfallen, wenn ihn noch jemand einfällt, trage ich das gerne nach. Das Tool statt aus den 90ern und wurde seitdem auch nicht mehr aktualisiert.

Hierbei handelt es sich um eine Kombination aus der Visual Studio Funktionalität für Windows Forms, nur eben ohne Einfluss auf Code oder irgendetwas dynamisch zu tun.

Ansonsten kann man noch auf den SAP Form Builder zurückgreifen, der sorgt dafür, dass man Berichte und die absolut benutzerunfreundlichen Masken erstellen kann.

Grundsätzlich kennt ABAP zwei Lifecycle-Hooks, Before- und After-Input. Bedeutet erst, wenn der User seine Eingaben bestätigt, bekommt man überhaupt die Möglichkeit etwas zu tun, zu validieren oder ähnliches. Das ist absolut nicht zeitgemäß, das haben auch viele Firmen und (teilweise) SAP erkannt.

Wenn man aus einer halbwegs modernen Umgebung kommt, wo Data-Binding de facto Standard ist (und das nicht erst seit gestern), fällt man hier erstmal in Ohnmacht.

Also gibt es relativ neu SAP Fiori, das, mit Open UI 5, auf einem Uralt-Stand stehen geblieben ist als Internet Explorer noch gut war und das Internet für uns alle Neuland. Hier kann man im Tabellenstyle mit Webtechnologien vergangener Zeit Oberflächen bauen. Diese erscheinen für den Nutzer halbwegs modern sowie nutzerfreundlich. Dabei wird noch derselbe alte Backend-Schrott genutzt.

Eine schöne Oberfläche gibt es nur für die Teile des Unternehmens, die nicht direkt gefoltert werden soll. Auf Handhelds, in Fertigungsstraßen etc. müssen die Mitarbeiter sich nicht selten noch mit den alten benutzerunfreundlichen Oberfläche herumschlagen.

Anläufe weg von ABAP

Ein verzweifelter Versuch ABAP zu verdrängen, mit einer absolut grauenvollen Java-Implementierung ist für viele Firmen schnell gestorben. Einfach zu komplex oder schlicht, aber ergreifend unbrauchbar.

Nachdem ich zum Glück noch nicht allzu viel damit zu tun hatte, lasse ich das an dieser Stelle einfach mal aus. Hierbei kann ich nur mit Meinung aus dritter Hand dienen.

Deployen und Staging

Transportaufträge ermöglichen es die Pakete weiterzugeben, ist das nicht absolut genial?!
Dazu braucht es nur ein Abnicken einer Person, weniger vieler Klicks und schon kann man seinen lauffähigen Code wegschieben, äh ich meine in Produktion überführen.
Tests sind hierbei ebenso nicht zu finden, genauso wie das übliche Tooling.

S/4 HANA und absurde Requirements

S/4 HANA startet nicht einmal mit weniger als 256 GB RAM!

Grund hierfür ist die „In-Memory-Datenbank“, die alles besser, toller und schneller machen soll. In der Realität hat man damit massive Skalierungsprobleme und schiebt einfach nur massenhaft RAM in seine Maschine.

Mehrere Terabytes an Arbeitsspeicher sind hier eher an der Tagesordnung als Ausnahmen.

Da man im Idealfall ja ausfallsicher unterwegs sein will, kann man hier gleich zweimal den RAM skalieren. Ob hier einfach auf Komprimierung verzichtet oder nach dem Prinzip „die Kunden kaufen es eh, sie haben keine Wahl“ entwickelt wurde erschließt sich mir hier leider nicht.

Gerade in Anbetracht steigender Preise, aus rein ökonomischer Sicht schon schlecht. Über die Umweltbelastung durch Produktion und Beschaffung der Rohmaterialien reden wir an dieser Stelle gar nicht erst.

User Experience

Jeder, der mit SAP arbeiten musste, egal ob für Entwicklung oder in seiner täglichen Arbeit ist nicht zu beneiden. Einziger Grund, warum man damit arbeitet, ist wegen Bezahlung. Niemand will das freiwillig anfassen und produktiv ist definitiv etwas anderes.

Grund hierfür ist unter anderem das statische Gefühl der Eingabemasken, hier bekommt man erst beim Speichern oder Bestätigen Rückmeldung. Accessibility etc. lassen wir hier einmal außen vor, doch auch hier sieht es wirklich sehr düster aus.

Letztendlich denkt man sich hier wahrscheinlich ganz klassisch, was läuft und Geld abwirft, wird nicht einfach angepasst.

Es gibt nicht umsonst sehr umfangreiche Anwender- und Entwicklerschulungen, Fachlektüre, natürlich ist das kein Zufall. Den das sind alles Leistungen, die man als Beratungshaus oder Softwarekonzern natürlich für einen hohen Preis verkaufen kann.

Zusammenfassung

Olaf Scholz bezeichnet SAP, die Firma, die unter anderem Erwähnten (und noch viel mehr Schrott) verbrochen hat, ein Aushängeschild der deutschen Digitalwirtschaft.

Als DevOps und Entwickler empfinde ich das als pure Beleidigung.
Schließlich gibt es zahlreiche deutsche Firmen, die wirklich tolle Arbeit leisten, ohne von der Politik Lob zu ernten, wohl auch weil größere Konzerne schlicht mehr Lobbyismus betreiben können.

Disclaimer

Bitte beachte, das sind meine persönlichen Erfahrungen und Meinung und natürlich kann auch das ein oder andere mittlerweile anders sein oder anders wahrgenommen werden!