Transformation des ABAP Entwicklers
Die Rolle des ABAP Entwicklers befindet sich seit einer Weile in der Transformation zu einem neuen Bild, mit neuen Technologien und Möglichkeiten. Schauen wir uns einmal diesen Weg an und diskutieren, wo die Reise hingeht.
Inhaltsverzeichnis
In diesem Artikel schauen wir auf die Veränderungen der Rolle des ABAP Entwicklers und wie aus dem ABAP only ein SAP Fokus entsteht.
Einleitung
Als ABAP Entwickler waren wir bisher vor allem auf die Erweiterung von SAP ERP Systemen fokussiert. Wir haben Reports für Auswertungen geschrieben, komplexere GUIs designt, um die Anforderungen des Fachbereichs zu unterstützen, haben SAP Systeme über RFC und IDOC miteinander verknüpft, um so komplexe Strukturen innerhalb von Unternehmen zu schaffen. Natürlich durfte auch die Modifikation nicht fehlen. Der Fachbereich wollte unbedingt einen neuen Button in seiner Standardtransaktion, um über einen einfachen Weg seine Kollegen über Neuigkeiten in der Verarbeitung zu informieren. Dann kamen hier ein Formular, da ein Workflow und dort eine Transformation per LSMW dazu, die uns als ABAP Entwickler mehr spezialisiert haben.
Dabei lag aber eigentlich immer der Fokus auf dem ERP System und der SAP GUI als Gesamtbild des ABAP Entwicklers. Fast alle Tools waren in ABAP geschrieben und wurden über die SAP GUI bedient und erweitert. Partner schrieben ihre Addons für den ABAP Stack, die Unternehmen dann auf den Systemen installiert und betrieben haben. Was aber eigentlich eher zum Leid der Partner war, da es so viele unterschiedliche Releases und Möglichkeiten gab, die alle unterstützt werden mussten.
Foto von Chris Lawton auf Unsplash
Schleichender Wandel
Grundsätzlich änderte sich auch erst einmal mit der Einführung der ersten S/4HANA Version nichts an diesem Konzept, die Unternehmen und der ABAP Entwickler konnten erst einmal so weitermachen, wenn sie nicht bereits in der Vergangenheit neue Dinge probiert hatten.
Fiori
Fiori gab es bereits zu ECC Zeiten, wurde aber auch nicht flächendeckend von den Unternehmen eingesetzt, da die Hauptanwendungen immer noch in der SAP GUI waren und für die besonderen Use-Cases von hübschen Anwendungen dann meist auch ein anderer Entwickler, als der ABAP Entwickler eingesetzt wurde. So entstanden erste Umsetzungen meist im HR Bereich für die Endanwender außerhalb der SAP Blase. Der ABAP Entwickler wurde dann meist benötigt, um den SEGW-Service zu erstellen und Daten bereitzustellen, dass UI wurde vom Fiori Entwickler erstellt und war für den ABAP Kollegen meist eher eine Black Box.
BTP
Dann gibt es auch noch die Business Technologie Plattform. Eingeführt, um eine Cloud Infrastruktur für Unternehmen bereitzustellen, aber auch Lösungen, auf die SAP selbst aufbauen kann. Dabei werden unterschiedliche Cloudservices zur Verfügung gestellt, die spezifische Aufgaben übernehmen und meist auch einen On-Prem Service damit ablösen. Schauen wir zum Beispiel auf die Erstellung von PDF-Formularen, dann gibt es hier den Cloud ADS. Die einzelnen Service sollte sich allerdings jedes Unternehmen auch individuell anschauen und bewerten, da zum Beispiel der ADS Probleme bei der Massenerzeugung von Dokumenten hat oder einfach viel zu teuer ist, bei einer großen Anzahl zu erstellende Dokumente.
Composable ERP
Mit der BTP wurde auch der Begriff des Composable ERP geprägt. Nicht jeder Service und jede Anwendung liegen mehr in einem monolithischen System (ein großes System), sondern sind verteilt über Services, Middleware, Cloud und On-Prem. Schauen wir einmal auf die Lösungen Success Factors und Ariba, dann liegen die Systeme in der Cloud, sind nicht mehr in ABAP geschrieben, verwenden aber zum Großteil die Stammdaten aus den SAP Systemen. Damit verteilen sich Bestandteile von HR und dem Einkauf auf verschiedene Lösungen.
Clean Core
Im Moment wird das Thema Clean Core auch sehr prominent platziert. Dabei handelt es sich erst einmal nicht um eine Technologie, aber um verschiedene Konzepte die verschiedene Bereiche betreffen. Für uns als Entwickler ist vor allem das Thema Extensibility wichtig, aber es gibt auch noch Data, Integration, Prozesse und Operation. Damit prüfen wir unsere Erweiterungen, auf welcher Plattform und mit welchen Tools wir sie umsetzen. Ob per Key User Extensibility, On-Stack mit ABAP Cloud oder Side-by-Side in der BTP. Clean Core setzt aber auch die neuen Standards und schränkt bestehende Technologien ein. Mit dem aktuellen Clean Core Level Concept wurde zwar das Verbot aufgehoben, aber die Richtung Fiori anstatt SAP GUI ist so weit den meisten klar.
IDE
Früher die SE80, heute die ABAP Development Tools und morgen VS Code? Die Landschaft der Tools hat sich die letzten Jahre entwickelt und wird sich auch in Zukunft entwickeln. Die Entwicklungsumgebung ist heute nicht nur noch die SE80, sondern besteht aus einer Vielzahl von Tools, die du für die tägliche Arbeit benötigst. Am Morgen die SPAU in der GUI, dann die neue App in Eclipse zu Ende entwickeln und mit BAS das UI generieren lassen. Am Nachmittag dann den Workflow in SAP Build Process Automation anpassen, die Daten in Git sichern und das Deplyoment über Cloud ALM durchführen. Die Tool Landschaft hat sich die letzten Jahre nicht verkleinert und als Entwickler sollten wir flexibel sein.
SAP Entwickler
Damit ändert sich auch etwas das Bild des ABAP Entwicklers, der sich nun für viele seiner Aufgaben weiterentwickeln muss. Daher würden wir ab diesem Punkt auch nicht mehr von "ABAP Entwickler" sprechen, sondern von "SAP Entwickler". Schauen wir uns einmal verschiedene Punkte dazu an.
Erweiterung
Eine der Kernaufgaben des SAP Entwicklers wird weiterhin die Erweiterung von SAP Systemen bleiben. Es werden sich aber die Methodiken, die Tools und die Plattformen etwas ändern. Die neue Funktion wird dann nicht mehr als Report umgesetzt, sondern als RAP App. Der Workflow wird nicht mehr im System erstellt, sondern weil auch Cloud Systeme betroffen sind in Process Automation. Der Standard soll erweitert werden, dann nicht mehr per Modifikation, sondern über die Key User Extensibility oder per Verwendung des Standard Services. Im Grunde werden wir auch in Zukunft die Standard Systeme für den Kunden erweitern.
Baukasten
In unserem Baukasten befindet sich jetzt nicht mehr nur noch der Hammer aka. ABAP, sondern es sind weitere Werkzeuge dazugekommen, die wir uns anschauen und verstehen sollten.
- Key User Extensibility - Erweiterung des Standards mit Low Code Tools, um kundeneigene Felder in den Prozess zu bringen. Implementierung von BADIs oder Anlage von kundeneigenen CDS über Fiori Apps.
- Workflow - Modellierung von Workflows mit SAP Build Process Automation und Verwendung von JavaScript, um eigene Logik in den Workflow zu bringen. Die Workflows verbinden Cloud und On-Prem Lösungen und geben uns die Möglichkeit in der neuen Welt Entscheidungen abzubilden.
- Destinations - Einrichtung, Pflege und das Verständnis für den Destination Service in der BTP, um eine Verbindung von Cloud zu On-Prem herzustellen. Am Ende, um Funktionen und Services der Systeme zu konsumieren.
- Fiori Elements - Native Entwicklung mit Fiori Freestyle Apps kosten Zeit und Geld. Fiori Elements mit der nativen Integration in RAP erhöhen die Zeit bis zur Produktivsetzung einer App enorm und sollten nicht außer Acht gelassen werden, um eine hohe Anzahl an Anwendungen liefern zu können.
- Web - Verständnis für die Funktionsweise der Webkommunikation und von REST. Sie bilden die Grundlage, um ein Verständnis für das Zusammenspiel der Systeme zu erhalten.
- Integration - Zur Integration gehört nicht nur eine RFC-Verbindung, sondern meist eine Schnittstelle, Middleware, Protokolle. Welches davon geht in deiner Umgebung und welche solltest du für deine Anwendung nutzen?
Technologie
Der Technologie Stack ist nun vielfältiger geworden. Du musst vielleicht noch klassische Anwendungen in der SAP GUI betreuen oder überlegen, wie du sie in die neue Fiori Welt migrieren kannst. Damit wirst du als SAP Entwickler ein breiteres Spektrum an Technologie haben, welches du die nächsten Jahre betreiben wirst. Dazu wird dann auch dein spezifischer Baukasten zum Einsatz kommen.
ABAP
ABAP wird sehr wahrscheinlich noch ein zentraler Bestandteil deiner täglichen Arbeit sein. Es ist immer noch die Business Programmiersprache zur Erweiterung von Systemen und kann auch in der Cloud verwendet werden. Damit ist die zeitliche Investition in diese Fähigkeit immer noch gerechtfertigt und wichtig. Du wirst aber auch Java Script benötigen, ob als Script Task in Process Automation oder zum Lesen von Fiori Elements Anwendungen. Hier wird dir sicherlich auch AI helfen können, den Java Script Code zu verstehen oder eine Lösung zu finden. Allerdings bist du auch hier immer in der Verantwortung.
Frontend
Das "neue" Frontend ist Fiori und über das ABAP RESTful Application Programming Model können annotationsgetrieben neue Anwendungen erstellt werden. Daher gehört Fiori Elements ebenfalls zum SAP Entwickler und ersetzt langsam die SAP GUI. Hier macht es eigentlich nicht mehr so viel Sinn, die Rolle ABAP und Fiori Entwickler zu trennen. Aktuell passiert der "Großteil" der Entwicklung in ABAP und meist nur die Generierung und kleinere Anpassungen im Frontend Bereich.
Addons
Partner müssen die Addons nicht mehr als Installation für ein On-Prem System zur Verfügung stellen. Es können nun Produkte mit dem ABAP Environment als SaaS Lösung zur Verfügung gestellt werden. Die Entwickler bleiben damit auf dem aktuellsten Stand der Technologie und der Partner muss nicht mehr an veraltete Releases denken, zumindest so lange alle Standard Schnittstellen zur Verfügung stehen.
RAP oder CAP
Am Ende bleibt immer die Frage offen, ob CAP und/oder RAP gemacht werden sollte. Der SAP Entwickler sollte auf jeden Fall eines der beiden Modelle beherrschen und umsetzen können. Aktuell würden wir aber nicht empfehlen beide Methodiken zu lernen. Wenn du nun fragst: Warum eigentlich, ich kann in beiden Frameworks Software entwickeln? Dann ist das grundsätzlich in Ordnung, um einfache Anwendungen zu bauen. Aber zur professionellen Entwicklung gehört nicht nur, eine äußerlich funktionierende Anwendung zu erstellen, sondern weitere Konzepte wie:
- Software Architektur
- Testbarkeit
- Performance
- Clean Code
- Wartbarkeit
- Sicherheit
Aus eigener Erfahrung können wir sagen, dass all die Punkte meist nur auf eine Programmiersprache und ein Framework passt, vor allem wenn sich die Sprache noch weiterentwickelt. Auf dem aktuellen Stand bleiben, die neuen Methodiken zu lernen, dass können einige Talente in mehrere Sprachen schaffen, aber in einem normalen Arbeitstag, passt das meist nicht. Deshalb empfehlen wir den Fokus auf ein Thema zu behalten und darin professionelle Software zu entwickeln.
Fazit
Die Rolle befindet sich bereits längst im Wandel und du solltest für dich oder im Unternehmen schauen, wo dein Fokus die nächsten Jahre liegen wird und welche Fähigkeiten dir dafür noch fehlen. Der alte ABAP Entwickler wird noch einige Jahre existieren, da nicht jedes Unternehmen bereit ist für den aktuellen Technologie-Stack und daher auch ABAP Entwickler gesucht werden.
