Kaum ein Bereich verändert sich derzeit so schnell wie die Software-Entwicklung. Ein Gespräch mit dem Entwickler Stefan Burghardt von GAMBIT über neue Technologien im Bereich SAP-Entwicklung, die Möglichkeiten mit der SAP Public Cloud und YouTube als Informationsquelle für Developer.
MAGAZIN: Stefan, wie hat sich der Bereich SAP-Entwicklung in den letzten Jahren aus deiner Sicht verändert? Wo kommen wir her, wo stehen wir jetzt – und warum ist das so?
STEFAN: Wir kommen ja über die letzten Jahrzehnte aus einer sehr eindimensionalen Welt für SAP-Entwickler – mit der SAP-eigenen Entwicklungsumgebung, der SE80, mit SAP GUI als einzigem Frontend und vielen Dateischnittstellen. Für lange Zeit war’s das. In den letzten zehn Jahren aber haben sich ganz viele neue Möglichkeiten eröffnet für Entwickler:innen, die nicht aus diesem Kontext kommen – ob nun im Bereich Schnittstellen oder in der Entwicklung von Applikationen für SAP-Systeme mit zum Teil komplett anderen Programmiersprachen. Auch die SAP-Programmiersprache ABAP wurde deutlich weiterentwickelt, so dass mittlerweile eine Cloud-fähige Version vorhanden ist.
MAGAZIN: Wie genau unterscheidet sich denn diese neue ABAP-Cloud-Version von der klassischen-Version?
STEFAN: Es gibt neue Sprachelemente, die das Coden einfacher, schneller und präziser machen. Außerdem gibt es Elemente, die explizit auf SAP S/4HANA abzielen, um mit der Datenbank besser zu interagieren. Die allergrößte Neuerung aber ist das neue Programmiermodell – das ABAP RESTful Application Programming Model, kurz RAP. Es ist speziell dafür ausgelegt, OData-Services zu erstellen. OData ist das Protokoll, auf dem die Fiori-Apps basieren, über das aber auch APIs angeboten werden können, um zwischen verschiedenen Systemen zu kommunizieren.
MAGAZIN: Die Veränderungen werden also vor allem durch den Wandel zur Cloud ausgelöst und vorangetrieben, richtig?
STEFAN: Ja, das ist so. Man merkt an allen Ecken und Enden, dass die Cloud die Strategie vorgibt und die Neuerungen anschließend Zeit in die On-Premise-Releases Einzug halten. Deswegen kann man sich an der Cloud-Variante strategisch immer gut orientieren. Wenn man sich an die dort geltenden Standards hält und sie auf die On-Premise-Welt portiert, bleibt der Kern des eigenen SAP-S/4HANA-Systems sauber und automatisch Cloud-ready. Damit ist man für einen späteren Umzug in die Public Cloud schon gut gerüstet!
MAGAZIN: Kannst du etwas genauer erläutern, wie Unternehmen Cloud-ready für die Public Cloud bleiben?
STEFAN: Da spielt uns das RAP-Modell wieder in die Karten. Man ist dabei wie vorher in einem Z-Namensraum unterwegs. Anders ist aber folgendes: Man programmiert die Anwendungen nicht mehr so, dass sie direkt auf Tabellen zugreifen, sondern nutzt eine Abstraktionsschicht – die sogenannten CDS-Views. Wenn man nun ausschließlich die von SAP freigegebenen CDS-Views nutzt, schränkt das zwar etwas in der Entwicklung ein. Aber es sichert einen auch dahingehend ab, dass die Anwendungen auch noch im nächsten Release laufen – und dann auch theoretisch in die Public Cloud portierbar sind.
MAGAZIN: Was ist denn das Interessanteste, was dir in den letzten fünf Jahren an Erneuerungen, Entwicklungen und neuen Technologien begegnet ist?
STEFAN: Eine der interessantesten Lösungen ist sicherlich der CoPilot zum Beiospiel für Eclipse und Visual Studio Code. Das ist ein Add-on für unsere Entwicklungsumgebungen. Der CoPilot unterstützt uns Entwickler:innen beim Schreiben von Code.
MAGAZIN: Der CoPilot ist KI-basiert?
STEFAN: Ja, ganz genau. Während man ihn benutzt, trainiert man ihn automatisch. Er nimmt einem wiederkehrende Aufgaben ab, damit man mehr Zeit in das Design und für die Architektur von Anwendungen verwenden kann und sich nicht mehr mit den einfacheren Aufgaben befassen muss.
MAGAZIN: Du bist schon fast 20 Jahre als Entwickler tätig. Wie hast du dir die Begeisterungsfähigkeit und Neugier bewahrt?
STEFAN: Ich finde es einfach spannend, sich mit immer neuen Themen zu befassen und den Fortschritt hautnah mitzuerleben und zu gestalten. Es macht ganz viel vom Berufsalltag bei unseren Kunden aus, dass wir gerade weg kommen von diesem blauen GUI-Bildschirm, hin zu einer modernen Oberfläche. Auch die Architektur der SAP-Systeme ist mittlerweile komplett Service-orientiert. Das heißt, wir arbeiten überall mit Webservices. Das ist heute der IT-Standard.
MAGAZIN: Was genau sind Webservices?
STEFAN: Eine Service-Architektur kann man sich vorstellen wie einen bidirektionalen Browser. Da gibt es Services, die liefern Daten – man gibt eine Adresse ein, ein paar Parameter und bekommt Daten zurück. Und es gibt Services, die nehmen Daten entgegen und buchen Belege oder ändern Stammdaten. Das beschreibt einen Webservice. Der besteht immer aus einem Endpunkt, wo die Daten hingehen sollen, und einem sogenannten Body, wo du entweder Daten bekommst oder Daten hinschicken kannst. Da jedes moderne System inzwischen Service-basiert APIs anbietet, öffnet das auch für SAP enorm viele Möglichkeiten der Kommunikation.
MAGAZIN: Gibt es auch neue Entwicklungen, bei denen du nicht mitgehen kannst oder mit denen du dich schwer tust?
STEFAN: Nein, kann ich nicht sagen. Es ist eher umgekehrt. Die Zeit ist der limitierende Faktor. Man kann sich als Entwickler:in mittlerweile nicht mehr alles anschauen. Wir sind irgendwann mal mit unserem Team gestartet und hatten das Ziel, dass jeder alles kann – also programmieren, auch Formulare, Workflows, Schnittstellen. Das mussten wir aber irgendwann aufgeben. Es sind heute einfach zu viele Themen. Und jedes Thema für sich dreht sich extrem schnell. Das bedeutet, dass sich jeder auf ein paar Themen spezialisieren muss, um am Ball bleiben zu können.
MAGAZIN: Für welche Themen hast du dich entschieden? Womit befasst du dich am liebsten?
STEFAN: Ich komme ja ursprünglich aus der ABAP-Welt. Mir macht daher – neben dem Thema Schnittstellen – das RAP-Modell besonders viel Spaß, weil ich da meine Stärken aus dem ABAP anwenden kann. Zugleich arbeite ich mit einem modernen Programmiermodell und benutze ein Fiori-Frontend.
MAGAZIN: Wenn du das neue Programmiermodell mit dem alten vergleichst, wo liegen da die größten Unterschiede?
STEFAN: Die alte Welt funktionierte meist eher schematisch. Du hast ein Programm angelegt, das eine Datei erzeugte oder eine Tabelle mit Daten zur Ansicht brachte. Auch war es zudem nicht immer ganz einfach, andere Systeme oder andere Programmiersprachen an ein SAP-System anzudocken. Das neue Programmiermodell hingegen ist darauf ausgelegt, Webservices zu bauen, die mit anderen Systemen kommunizieren können. Das bedeutet, du legst einmal einen Service an und kannst dann zum Beispiel ganz viele unterschiedliche UIs obendrauf setzen. Das heißt, man ist da viel freier in den Möglichkeiten.
MAGAZIN: Apropos Freiheit. Wie beurteilst du als Entwickler die Möglichkeiten in der standardisierten Public Cloud? Welche Chancen der Erweiterung haben Unternehmen hier?
STEFAN: Seit dem letzten Release von Mitte 2022 lassen sich Entwicklungen mit dem RAP-Modell in SAP S/4HANA Public Cloud umsetzen. Diese Variante wird auch als „Embedded Steampunk“ bezeichnet. Wir können also eigene Tabellen anlegen, mit dem RAP-Modell programmieren und auch Fioris entwickeln und in die Cloud deployen. Diese laufen dann in dem System selber und haben direkten Zugriff über CDS-Views. Alternativ gibt es auch eine ABAP-Platform-Variante. Diese „Standalone“-Variante ist eine ABAP-Instanz auf der BTP, die ohne die ganzen ERP-Komponenten läuft – also eine Laufzeitumgebung, die im Auslieferungszustand komplett leer ist. Als Entwickler:in kannst du deine Applikationen dort komplett frei bauen. Die Kommunikation mit einem oder mehreren SAP S/4HANA Backends – ob Public Cloud, Private Cloud oder On-Premise – erfolgt dann allerdings über APIs.
MAGAZIN: Es ist nicht das Ziel, vorhandene eigene Entwicklungen aus bisherigen ERP-Systemen in die Public Cloud zu übertragen. Hier ist ja der SAP-Standard das Maß aller Dinge. Aber das wäre so auch gar nicht möglich, oder?
STEFAN: Nein, in der Regel nicht ohne größere Anpassungen. Da müsste es schon eine relativ aktuelle Entwicklung sein, die sich schon an die Standards hält und bei der der Entwickler schon das Ziel hatte, die später mal zu portieren. Das ist aber in den wenigsten Fällen so. Wenn aber die benötigten Daten über geeignete freigegebene APIs verfügen, lassen sich Anwendungen so re-designen, dass eine Portierung möglich ist.
MAGAZIN: Mit SAP Fiori steht ja eine ganze neue Bedienoberfläche für SAP S/4HANA zur Verfügung. Wie hat sich die Entwicklung dadurch verändert, Stichwort Frontend Entwicklung?
STEFAN: In der alten Welt kam ja immer alles aus einer Hand. Der Entwickler hat das Programm geschrieben, und wenn es eine starke User-Interaktion hatte, dann hat er auch die Screens designt. Das war recht intuitiv. Man zieht Eingabe- und Ausgabefelder mit der Maus auf den Bildschirm – und hat immer eine direkte Verknüpfung zu den Daten in seinem Programm. Die Fiori-Entwicklung ist natürlich deutlich umfangreicher und bietet viel mehr Möglichkeiten. Sie basiert aber auch auf einer anderen Programmiersprache, nämlich SAP UI5. Die Logik wird in JavaScript geschrieben, das ist etwas völlig anderes als ABAP.
MAGAZIN: Das kann längst auch nicht mehr jeder?
STEFAN: Nein. Wir haben für das Thema mittlerweile Spezialist:innen. Sie kümmern sich primär um das Frontend-Development. Einige dieser Expert:innen stehen auch mit einem Bein im Backend und können die ganze Palette abdecken. Und umgekehrt können viele Backend-Entwickler:innen auch Frontend. Fiori Elements ist da eine große Erleichterung für Anforderungen, die auf die Templates passen. Bei sehr großen Applikationen arbeiten wir heute teilweise mit Aufgabenteilung in Backend und Frontend.
MAGAZIN: Könnte man eigentlich bei euch im Team als Entwickler:in auch beginnen ohne ABAP zu können?
STEFAN: Ich hätte die Frage vor dem Beginn der Cloud-Strategie mit „Nein“ beantwortet, aber mittlerweile ginge das, ja! Klar ist aber auch, dass ABAP der Kern jedes SAP- Systems bleibt. Daran wird sich auch so schnell nichts ändern. Deswegen schulen wir alle neuen Kolleg:innen ohne ABAP-Kenntnisse auch in ABAP, um eine Basis zu schaffen. Jeder soll sich bis zu einem gewissen Grad selber helfen können. Dafür sind ABAP-Kenntnisse ganz hilfreich – aber Einstellungsvoraussetzung ist das nicht mehr.
MAGAZIN: Was müssen Entwickler:innen generell mitbringen, damit sie gut in dein Team passen?
STEFAN: Auf jeden Fall Spaß und Interesse an neuen Technologien. Wir haben ganz häufig Themen, die wir als erstes ausprobieren. Da gibt es oft ganz spärliche Dokumentationen von SAP, vielleicht höchstens mal einen Blogbeitrag. Und dann ist das Pionierarbeit, diese Sachen zum Laufen zu bringen oder damit etwas zu bauen. Da muss man schon Wissensdurst und einen gewissen Spieltrieb haben!
MAGAZIN: Aber Ausgangspunkt ist immer SAP, oder?
STEFAN: Genau! Das unterscheidet uns von der reinen Softwareentwicklung. Wir haben als Dreh- und Angelpunkt in der Regel immer ein SAP-ERP-System, an das wir eine Schnittstelle anbinden, wo die Daten herkommen. Das ist bei den meisten unserer Projekte die Konstante. In der Softwareentwicklung kann es ja vorkommen, dass man etwas komplett Individuelles baut und mit einem weißen Blatt Papier anfängt. Das wird bei uns aber in den seltensten Fällen vorkommen.
MAGAZIN: Ein immer wichtigeres Thema ist auch bei SAP die Künstliche Intelligenz. Die Public Cloud zum Beispiel enthält ja schon diverse integrierte KI-Services, die man automatisch nutzen kann. Wie siehst du das Thema? Wo stehen wir da in fünf Jahren?
STEFAN: Das wird enorm wachsen, das ist klar. Neben diesen integrierten Services in dem ERP-System gibt es auch auf der BTP längst eine Reihe von Tools, mit denen man noch individuellere Lösungen entwickeln kann. Das sind Werkzeuge, die gerade entstehen, wo der Kunde oder wir zusammen mit dem Kunden ganz individuelle Lösungen erschaffen können. Ich glaube, das ist ein Feld, das wird sich in den nächsten fünf Jahren noch massiv weiterentwickeln.
MAGAZIN: Also komplett neue individuelle KI-Lösungen?
STEFAN: Ja, ganz genau. Die lassen sich dann zum Beispiel an Data Lakes anbinden. Das sind Landschaften, die strukturierte und unstrukturierte Daten enthalten. Die KI kann man auch an Hyperscaler anbinden, um Daten berechnen zu lassen. So lassen sich ganz, ganz individuelle Sachen bauen.
MAGAZIN: Für bestimmte Anforderungen entwickelt ihr auch individuelle Apps, also spezielle Anwendungen, oder?
STEFAN: Ja, wir entwickeln Fiori-Apps, die dann so beim Kunden laufen. Es kann zum Beispiel sein, dass ein Unternehmen statistische Kennzahlen vereinfacht und in großen Mengen erfassen möchte und die Standardlösung dafür nicht ausreicht. Dann erstellen wir eine App, in die er seine Daten eingeben kann oder wo er eine Datei hochladen kann mit mehreren Buchungen. Im Ergebnis kriegt er dann zum Beispiel die Verbuchung und Fehlermeldungen angezeigt und erfährt, wie viele Belege erzeugt wurden und welche Belegnummern diese haben. Das ist ein alltäglicher Anwendungsfall.
MAGAZIN: Mit welchen typischen Anforderungen kommen Kunden denn sonst zu euch? Welche Basis-Anforderungen gibt es, wenn es zum Beispiel um eine Cloud-Transformation geht? Womit fangt ihr an? Was müsst ihr machen?
STEFAN: In jedem Projekt haben wir Schnittstellen. Wir müssen also Umfeldsysteme anbinden, in welchem Format auch immer. Das kann ganz unterschiedlich sein. Zudem haben wir oft mit zusätzlichen Feldern an Datenobjekten zu tun, also einer zusätzlichen Logik. Das bedeutet, dass wenn irgendwo ein Beleg generiert wird, zusätzlich noch dieses und jenes passieren soll oder eine zusätzliche Prüfung stattfinden soll. Oder es geht um ganz individuelle Entwicklungen, um Cockpits beispielsweise, die mehrere Datentöpfe zusammenbringen und so das Handling der Daten erleichtern. Das sind einige typischen Anforderungen.
MAGAZIN: Eher untypisch waren sicherlich die Anforderungen des Kunden GAMBIT, oder? Wir haben ja 2023 selbst als Early Adopter die SAP S/4HANA Public Cloud eingeführt. Hast du dabei etwas Neues gelernt?
STEFAN: Wir haben sogar ganz viel gelernt, was unseren Kunden jetzt zugutekommt. Eine der wichtigsten Erkenntnisse für mich war, dass die Public Cloud die Blaupause ist für alles, was man von On-Premise später in die Cloud mitnehmen kann. Die Restriktionen, sauber zu programmieren – die sind da knallhart. Wenn man in einem On-Premise-System mal eine Warnung angezeigt bekommt, dass man als Entwickler:in etwas nicht nutzen soll, dann lässt sich das auch mal wegklicken. Ganz nach dem Motto: Ich habe das jetzt registriert, aber es geht schon. In der Public Cloud allerdings ist das eine Fehlermeldung, die man nicht aushebeln kann!
MAGAZIN: Das zwingt euch dazu, sehr sauber zu arbeiten.
STEFAN: Also, wir haben da schon hin und wieder geflucht, weil Sachen einfach länger dauern, wenn man sich eine Alternative überlegen muss. Aber klar, das zwingt einen dazu, blitzsauber zu arbeiten. Das ist ein riesiger Vorteil, der sich auf lange Sicht auszahlt.
MAGAZIN: Und was ist mit den Sachen, die in der Public Cloud fehlen? Das ist ja ein häufig gehörter Kritikpunkt, dass sie nicht ausreicht.
STEFAN: Ich habe die Erfahrung gemacht, dass die fehlenden Anwendungen in der Regel in ein oder zwei Releases nachgeliefert werden. Gegenüber SAP kann man Änderungswünsche auch über ein eigenes Programm kommunizieren – und die Sachen kommen dann auch recht zügig, wenn sie relevant sind.
MAGAZIN: Angesichts dieses enormen Tempos in der Entwicklung – wo informierst du dich generell über Neuheiten?
STEFAN: Entweder in SAP-Blogs, über Newsletter oder auch bei YouTube und GitHub. Es gibt zum Beispiel eine Reihe interationaler Kolleg:innen, die tolle Tutorials bereitstellen. Das hätte ich bis vor fünf Jahren auch niemals gedacht – aber YouTube ist mittlerweile eine meiner Hauptinformationsquellen. Früher war das anders. Da hat man bei SAP noch eine drei Tage lange Schulung gebucht und ist nach Walldorf gefahren.
MAGAZIN: Dann müsstest du heute bei dem Tempo wahrscheinlich jede Woche drei Tage nach Walldorf fahren, oder?
STEFAN: Das kannst du natürlich vergessen. Es gibt aber meist noch gar kein Schulungsangebot in Walldorf für die ganz neuen Themen. Selbst von SAP werden viele neue Informationen in der Entwicklung längst über einen eigenen YouTube-Kanal verbreitet, weil es einfach schneller ist und eine perfekt ausgefeilte Schulung schon veraltet sein könnte, wenn sie offiziell an den Start geht.
MAGAZIN: Und wie teilt ihr Innovationen im eigenen Team?
STEFAN: Das ist auch enorm wichtig, definitiv! Wir haben zum Beispiel extra einen alle zwei Wochen stattfindenden Termin installiert bei uns im Team für Neuerungen. Das können mal größere Themen sein, die jemand aufbereitet und den anderen präsentiert. Das können aber auch mal kleine Themen oder irgendwas Experimentelles sein.
MAGAZIN: Ihr seid jetzt rund 20 Leute im Team – und wollt weiter wachsen?
STEFAN: Ja, das soll und muss mehr werden. Wer Angst hat, mit KI oder dem SAP-Standard werden die Programmierer arbeitslos, der irrt sich – das Gegenteil ist der Fall. Wir haben Arbeit und spannende Themen zur Genüge!
MAGAZIN: Vielen Dank für das Gespräch!
Stefan Burghardt
Im Jahr 2005 begann Stefan Burghardt bei GAMBIT eine Ausbildung als Fachinformatiker Anwendungsentwicklung. Im Anschluss absolvierte er berufsbegleitend ein Bachelor- sowie Master-Studium der Wirtschaftsinformatik. Seit 2018 ist Stefan bei GAMBIT Leiter des Bereichs Connectivity + Development.
MAGAZIN: Stefan, wie hat sich der Bereich SAP-Entwicklung in den letzten Jahren aus deiner Sicht verändert? Wo kommen wir her, wo stehen wir jetzt – und warum ist das so?
STEFAN: Wir kommen ja über die letzten Jahrzehnte aus einer sehr eindimensionalen Welt für SAP-Entwickler – mit der SAP-eigenen Entwicklungsumgebung, der SE80, mit SAP GUI als einzigem Frontend und vielen Dateischnittstellen. Für lange Zeit war’s das. In den letzten zehn Jahren aber haben sich ganz viele neue Möglichkeiten eröffnet für Entwickler:innen, die nicht aus diesem Kontext kommen – ob nun im Bereich Schnittstellen oder in der Entwicklung von Applikationen für SAP-Systeme mit zum Teil komplett anderen Programmiersprachen. Auch die SAP-Programmiersprache ABAP wurde deutlich weiterentwickelt, so dass mittlerweile eine Cloud-fähige Version vorhanden ist.
MAGAZIN: Wie genau unterscheidet sich denn diese neue ABAP-Cloud-Version von der klassischen-Version?
STEFAN: Es gibt neue Sprachelemente, die das Coden einfacher, schneller und präziser machen. Außerdem gibt es Elemente, die explizit auf SAP S/4HANA abzielen, um mit der Datenbank besser zu interagieren. Die allergrößte Neuerung aber ist das neue Programmiermodell – das ABAP RESTful Application Programming Model, kurz RAP. Es ist speziell dafür ausgelegt, OData-Services zu erstellen. OData ist das Protokoll, auf dem die Fiori-Apps basieren, über das aber auch APIs angeboten werden können, um zwischen verschiedenen Systemen zu kommunizieren.
MAGAZIN: Die Veränderungen werden also vor allem durch den Wandel zur Cloud ausgelöst und vorangetrieben, richtig?
STEFAN: Ja, das ist so. Man merkt an allen Ecken und Enden, dass die Cloud die Strategie vorgibt und die Neuerungen anschließend Zeit in die On-Premise-Releases Einzug halten. Deswegen kann man sich an der Cloud-Variante strategisch immer gut orientieren. Wenn man sich an die dort geltenden Standards hält und sie auf die On-Premise-Welt portiert, bleibt der Kern des eigenen SAP-S/4HANA-Systems sauber und automatisch Cloud-ready. Damit ist man für einen späteren Umzug in die Public Cloud schon gut gerüstet!
MAGAZIN: Kannst du etwas genauer erläutern, wie Unternehmen Cloud-ready für die Public Cloud bleiben?
STEFAN: Da spielt uns das RAP-Modell wieder in die Karten. Man ist dabei wie vorher in einem Z-Namensraum unterwegs. Anders ist aber folgendes: Man programmiert die Anwendungen nicht mehr so, dass sie direkt auf Tabellen zugreifen, sondern nutzt eine Abstraktionsschicht – die sogenannten CDS-Views. Wenn man nun ausschließlich die von SAP freigegebenen CDS-Views nutzt, schränkt das zwar etwas in der Entwicklung ein. Aber es sichert einen auch dahingehend ab, dass die Anwendungen auch noch im nächsten Release laufen – und dann auch theoretisch in die Public Cloud portierbar sind.
MAGAZIN: Was ist denn das Interessanteste, was dir in den letzten fünf Jahren an Erneuerungen, Entwicklungen und neuen Technologien begegnet ist?
STEFAN: Eine der interessantesten Lösungen ist sicherlich der CoPilot zum Beiospiel für Eclipse und Visual Studio Code. Das ist ein Add-on für unsere Entwicklungsumgebungen. Der CoPilot unterstützt uns Entwickler:innen beim Schreiben von Code.
MAGAZIN: Der CoPilot ist KI-basiert?
STEFAN: Ja, ganz genau. Während man ihn benutzt, trainiert man ihn automatisch. Er nimmt einem wiederkehrende Aufgaben ab, damit man mehr Zeit in das Design und für die Architektur von Anwendungen verwenden kann und sich nicht mehr mit den einfacheren Aufgaben befassen muss.
MAGAZIN: Du bist schon fast 20 Jahre als Entwickler tätig. Wie hast du dir die Begeisterungsfähigkeit und Neugier bewahrt?
STEFAN: Ich finde es einfach spannend, sich mit immer neuen Themen zu befassen und den Fortschritt hautnah mitzuerleben und zu gestalten. Es macht ganz viel vom Berufsalltag bei unseren Kunden aus, dass wir gerade weg kommen von diesem blauen GUI-Bildschirm, hin zu einer modernen Oberfläche. Auch die Architektur der SAP-Systeme ist mittlerweile komplett Service-orientiert. Das heißt, wir arbeiten überall mit Webservices. Das ist heute der IT-Standard.
MAGAZIN: Was genau sind Webservices?
STEFAN: Eine Service-Architektur kann man sich vorstellen wie einen bidirektionalen Browser. Da gibt es Services, die liefern Daten – man gibt eine Adresse ein, ein paar Parameter und bekommt Daten zurück. Und es gibt Services, die nehmen Daten entgegen und buchen Belege oder ändern Stammdaten. Das beschreibt einen Webservice. Der besteht immer aus einem Endpunkt, wo die Daten hingehen sollen, und einem sogenannten Body, wo du entweder Daten bekommst oder Daten hinschicken kannst. Da jedes moderne System inzwischen Service-basiert APIs anbietet, öffnet das auch für SAP enorm viele Möglichkeiten der Kommunikation.
MAGAZIN: Gibt es auch neue Entwicklungen, bei denen du nicht mitgehen kannst oder mit denen du dich schwer tust?
STEFAN: Nein, kann ich nicht sagen. Es ist eher umgekehrt. Die Zeit ist der limitierende Faktor. Man kann sich als Entwickler:in mittlerweile nicht mehr alles anschauen. Wir sind irgendwann mal mit unserem Team gestartet und hatten das Ziel, dass jeder alles kann – also programmieren, auch Formulare, Workflows, Schnittstellen. Das mussten wir aber irgendwann aufgeben. Es sind heute einfach zu viele Themen. Und jedes Thema für sich dreht sich extrem schnell. Das bedeutet, dass sich jeder auf ein paar Themen spezialisieren muss, um am Ball bleiben zu können.
MAGAZIN: Für welche Themen hast du dich entschieden? Womit befasst du dich am liebsten?
STEFAN: Ich komme ja ursprünglich aus der ABAP-Welt. Mir macht daher – neben dem Thema Schnittstellen – das RAP-Modell besonders viel Spaß, weil ich da meine Stärken aus dem ABAP anwenden kann. Zugleich arbeite ich mit einem modernen Programmiermodell und benutze ein Fiori-Frontend.
MAGAZIN: Wenn du das neue Programmiermodell mit dem alten vergleichst, wo liegen da die größten Unterschiede?
STEFAN: Die alte Welt funktionierte meist eher schematisch. Du hast ein Programm angelegt, das eine Datei erzeugte oder eine Tabelle mit Daten zur Ansicht brachte. Auch war es zudem nicht immer ganz einfach, andere Systeme oder andere Programmiersprachen an ein SAP-System anzudocken. Das neue Programmiermodell hingegen ist darauf ausgelegt, Webservices zu bauen, die mit anderen Systemen kommunizieren können. Das bedeutet, du legst einmal einen Service an und kannst dann zum Beispiel ganz viele unterschiedliche UIs obendrauf setzen. Das heißt, man ist da viel freier in den Möglichkeiten.
MAGAZIN: Apropos Freiheit. Wie beurteilst du als Entwickler die Möglichkeiten in der standardisierten Public Cloud? Welche Chancen der Erweiterung haben Unternehmen hier?
STEFAN: Seit dem letzten Release von Mitte 2022 lassen sich Entwicklungen mit dem RAP-Modell in SAP S/4HANA Public Cloud umsetzen. Diese Variante wird auch als „Embedded Steampunk“ bezeichnet. Wir können also eigene Tabellen anlegen, mit dem RAP-Modell programmieren und auch Fioris entwickeln und in die Cloud deployen. Diese laufen dann in dem System selber und haben direkten Zugriff über CDS-Views. Alternativ gibt es auch eine ABAP-Platform-Variante. Diese „Standalone“-Variante ist eine ABAP-Instanz auf der BTP, die ohne die ganzen ERP-Komponenten läuft – also eine Laufzeitumgebung, die im Auslieferungszustand komplett leer ist. Als Entwickler:in kannst du deine Applikationen dort komplett frei bauen. Die Kommunikation mit einem oder mehreren SAP S/4HANA Backends – ob Public Cloud, Private Cloud oder On-Premise – erfolgt dann allerdings über APIs.
MAGAZIN: Es ist nicht das Ziel, vorhandene eigene Entwicklungen aus bisherigen ERP-Systemen in die Public Cloud zu übertragen. Hier ist ja der SAP-Standard das Maß aller Dinge. Aber das wäre so auch gar nicht möglich, oder?
STEFAN: Nein, in der Regel nicht ohne größere Anpassungen. Da müsste es schon eine relativ aktuelle Entwicklung sein, die sich schon an die Standards hält und bei der der Entwickler schon das Ziel hatte, die später mal zu portieren. Das ist aber in den wenigsten Fällen so. Wenn aber die benötigten Daten über geeignete freigegebene APIs verfügen, lassen sich Anwendungen so re-designen, dass eine Portierung möglich ist.
MAGAZIN: Mit SAP Fiori steht ja eine ganze neue Bedienoberfläche für SAP S/4HANA zur Verfügung. Wie hat sich die Entwicklung dadurch verändert, Stichwort Frontend Entwicklung?
STEFAN: In der alten Welt kam ja immer alles aus einer Hand. Der Entwickler hat das Programm geschrieben, und wenn es eine starke User-Interaktion hatte, dann hat er auch die Screens designt. Das war recht intuitiv. Man zieht Eingabe- und Ausgabefelder mit der Maus auf den Bildschirm – und hat immer eine direkte Verknüpfung zu den Daten in seinem Programm. Die Fiori-Entwicklung ist natürlich deutlich umfangreicher und bietet viel mehr Möglichkeiten. Sie basiert aber auch auf einer anderen Programmiersprache, nämlich SAP UI5. Die Logik wird in JavaScript geschrieben, das ist etwas völlig anderes als ABAP.
MAGAZIN: Das kann längst auch nicht mehr jeder?
STEFAN: Nein. Wir haben für das Thema mittlerweile Spezialist:innen. Sie kümmern sich primär um das Frontend-Development. Einige dieser Expert:innen stehen auch mit einem Bein im Backend und können die ganze Palette abdecken. Und umgekehrt können viele Backend-Entwickler:innen auch Frontend. Fiori Elements ist da eine große Erleichterung für Anforderungen, die auf die Templates passen. Bei sehr großen Applikationen arbeiten wir heute teilweise mit Aufgabenteilung in Backend und Frontend.
MAGAZIN: Könnte man eigentlich bei euch im Team als Entwickler:in auch beginnen ohne ABAP zu können?
STEFAN: Ich hätte die Frage vor dem Beginn der Cloud-Strategie mit „Nein“ beantwortet, aber mittlerweile ginge das, ja! Klar ist aber auch, dass ABAP der Kern jedes SAP- Systems bleibt. Daran wird sich auch so schnell nichts ändern. Deswegen schulen wir alle neuen Kolleg:innen ohne ABAP-Kenntnisse auch in ABAP, um eine Basis zu schaffen. Jeder soll sich bis zu einem gewissen Grad selber helfen können. Dafür sind ABAP-Kenntnisse ganz hilfreich – aber Einstellungsvoraussetzung ist das nicht mehr.
MAGAZIN: Was müssen Entwickler:innen generell mitbringen, damit sie gut in dein Team passen?
STEFAN: Auf jeden Fall Spaß und Interesse an neuen Technologien. Wir haben ganz häufig Themen, die wir als erstes ausprobieren. Da gibt es oft ganz spärliche Dokumentationen von SAP, vielleicht höchstens mal einen Blogbeitrag. Und dann ist das Pionierarbeit, diese Sachen zum Laufen zu bringen oder damit etwas zu bauen. Da muss man schon Wissensdurst und einen gewissen Spieltrieb haben!
MAGAZIN: Aber Ausgangspunkt ist immer SAP, oder?
STEFAN: Genau! Das unterscheidet uns von der reinen Softwareentwicklung. Wir haben als Dreh- und Angelpunkt in der Regel immer ein SAP-ERP-System, an das wir eine Schnittstelle anbinden, wo die Daten herkommen. Das ist bei den meisten unserer Projekte die Konstante. In der Softwareentwicklung kann es ja vorkommen, dass man etwas komplett Individuelles baut und mit einem weißen Blatt Papier anfängt. Das wird bei uns aber in den seltensten Fällen vorkommen.
MAGAZIN: Ein immer wichtigeres Thema ist auch bei SAP die Künstliche Intelligenz. Die Public Cloud zum Beispiel enthält ja schon diverse integrierte KI-Services, die man automatisch nutzen kann. Wie siehst du das Thema? Wo stehen wir da in fünf Jahren?
STEFAN: Das wird enorm wachsen, das ist klar. Neben diesen integrierten Services in dem ERP-System gibt es auch auf der BTP längst eine Reihe von Tools, mit denen man noch individuellere Lösungen entwickeln kann. Das sind Werkzeuge, die gerade entstehen, wo der Kunde oder wir zusammen mit dem Kunden ganz individuelle Lösungen erschaffen können. Ich glaube, das ist ein Feld, das wird sich in den nächsten fünf Jahren noch massiv weiterentwickeln.
MAGAZIN: Also komplett neue individuelle KI-Lösungen?
STEFAN: Ja, ganz genau. Die lassen sich dann zum Beispiel an Data Lakes anbinden. Das sind Landschaften, die strukturierte und unstrukturierte Daten enthalten. Die KI kann man auch an Hyperscaler anbinden, um Daten berechnen zu lassen. So lassen sich ganz, ganz individuelle Sachen bauen.
MAGAZIN: Für bestimmte Anforderungen entwickelt ihr auch individuelle Apps, also spezielle Anwendungen, oder?
STEFAN: Ja, wir entwickeln Fiori-Apps, die dann so beim Kunden laufen. Es kann zum Beispiel sein, dass ein Unternehmen statistische Kennzahlen vereinfacht und in großen Mengen erfassen möchte und die Standardlösung dafür nicht ausreicht. Dann erstellen wir eine App, in die er seine Daten eingeben kann oder wo er eine Datei hochladen kann mit mehreren Buchungen. Im Ergebnis kriegt er dann zum Beispiel die Verbuchung und Fehlermeldungen angezeigt und erfährt, wie viele Belege erzeugt wurden und welche Belegnummern diese haben. Das ist ein alltäglicher Anwendungsfall.
MAGAZIN: Mit welchen typischen Anforderungen kommen Kunden denn sonst zu euch? Welche Basis-Anforderungen gibt es, wenn es zum Beispiel um eine Cloud-Transformation geht? Womit fangt ihr an? Was müsst ihr machen?
STEFAN: In jedem Projekt haben wir Schnittstellen. Wir müssen also Umfeldsysteme anbinden, in welchem Format auch immer. Das kann ganz unterschiedlich sein. Zudem haben wir oft mit zusätzlichen Feldern an Datenobjekten zu tun, also einer zusätzlichen Logik. Das bedeutet, dass wenn irgendwo ein Beleg generiert wird, zusätzlich noch dieses und jenes passieren soll oder eine zusätzliche Prüfung stattfinden soll. Oder es geht um ganz individuelle Entwicklungen, um Cockpits beispielsweise, die mehrere Datentöpfe zusammenbringen und so das Handling der Daten erleichtern. Das sind einige typischen Anforderungen.
MAGAZIN: Eher untypisch waren sicherlich die Anforderungen des Kunden GAMBIT, oder? Wir haben ja 2023 selbst als Early Adopter die SAP S/4HANA Public Cloud eingeführt. Hast du dabei etwas Neues gelernt?
STEFAN: Wir haben sogar ganz viel gelernt, was unseren Kunden jetzt zugutekommt. Eine der wichtigsten Erkenntnisse für mich war, dass die Public Cloud die Blaupause ist für alles, was man von On-Premise später in die Cloud mitnehmen kann. Die Restriktionen, sauber zu programmieren – die sind da knallhart. Wenn man in einem On-Premise-System mal eine Warnung angezeigt bekommt, dass man als Entwickler:in etwas nicht nutzen soll, dann lässt sich das auch mal wegklicken. Ganz nach dem Motto: Ich habe das jetzt registriert, aber es geht schon. In der Public Cloud allerdings ist das eine Fehlermeldung, die man nicht aushebeln kann!
MAGAZIN: Das zwingt euch dazu, sehr sauber zu arbeiten.
STEFAN: Also, wir haben da schon hin und wieder geflucht, weil Sachen einfach länger dauern, wenn man sich eine Alternative überlegen muss. Aber klar, das zwingt einen dazu, blitzsauber zu arbeiten. Das ist ein riesiger Vorteil, der sich auf lange Sicht auszahlt.
MAGAZIN: Und was ist mit den Sachen, die in der Public Cloud fehlen? Das ist ja ein häufig gehörter Kritikpunkt, dass sie nicht ausreicht.
STEFAN: Ich habe die Erfahrung gemacht, dass die fehlenden Anwendungen in der Regel in ein oder zwei Releases nachgeliefert werden. Gegenüber SAP kann man Änderungswünsche auch über ein eigenes Programm kommunizieren – und die Sachen kommen dann auch recht zügig, wenn sie relevant sind.
MAGAZIN: Angesichts dieses enormen Tempos in der Entwicklung – wo informierst du dich generell über Neuheiten?
STEFAN: Entweder in SAP-Blogs, über Newsletter oder auch bei YouTube und GitHub. Es gibt zum Beispiel eine Reihe interationaler Kolleg:innen, die tolle Tutorials bereitstellen. Das hätte ich bis vor fünf Jahren auch niemals gedacht – aber YouTube ist mittlerweile eine meiner Hauptinformationsquellen. Früher war das anders. Da hat man bei SAP noch eine drei Tage lange Schulung gebucht und ist nach Walldorf gefahren.
MAGAZIN: Dann müsstest du heute bei dem Tempo wahrscheinlich jede Woche drei Tage nach Walldorf fahren, oder?
STEFAN: Das kannst du natürlich vergessen. Es gibt aber meist noch gar kein Schulungsangebot in Walldorf für die ganz neuen Themen. Selbst von SAP werden viele neue Informationen in der Entwicklung längst über einen eigenen YouTube-Kanal verbreitet, weil es einfach schneller ist und eine perfekt ausgefeilte Schulung schon veraltet sein könnte, wenn sie offiziell an den Start geht.
MAGAZIN: Und wie teilt ihr Innovationen im eigenen Team?
STEFAN: Das ist auch enorm wichtig, definitiv! Wir haben zum Beispiel extra einen alle zwei Wochen stattfindenden Termin installiert bei uns im Team für Neuerungen. Das können mal größere Themen sein, die jemand aufbereitet und den anderen präsentiert. Das können aber auch mal kleine Themen oder irgendwas Experimentelles sein.
MAGAZIN: Ihr seid jetzt rund 20 Leute im Team – und wollt weiter wachsen?
STEFAN: Ja, das soll und muss mehr werden. Wer Angst hat, mit KI oder dem SAP-Standard werden die Programmierer arbeitslos, der irrt sich – das Gegenteil ist der Fall. Wir haben Arbeit und spannende Themen zur Genüge!
MAGAZIN: Vielen Dank für das Gespräch!
Stefan Burghardt
Im Jahr 2005 begann Stefan Burghardt bei GAMBIT eine Ausbildung als Fachinformatiker Anwendungsentwicklung. Im Anschluss absolvierte er berufsbegleitend ein Bachelor- sowie Master-Studium der Wirtschaftsinformatik. Seit 2018 ist Stefan bei GAMBIT Leiter des Bereichs Connectivity + Development.
