2027 markiert das offizielle Wartungsende für SAP R/3. Wie stark sich dies auf die Softwarekunden auswirkt, hängt mit ihrer Nutzungsart von SAP ab. Den selbst R/2 wurde noch im laufenden Betrieb im Jahre 2011 gesichtet, also 30 Jahre nach dem Release und 19 Jahre nach dem offiziellen Release von SAP R/3.
Es wird also spannend zu sehen, wie lange R/3 es schafft, im Rennen zu bleiben. 2027 markiert nicht einfach nur das Ende eines Software-Lifecycle, es ist ein Paradigmenwechsel, der mit HANA in 2010 begann und spätestens mit der Veröffentlichung von S/4 HANA anno 2015 endgültig vollzogen wurde. Von einer Plattform-unabhängigen Software, die auch anderen Firmen, wie zum Beispiel Oracle ein kontinuierliches Wachstum bescherten, geht der Weg zur festen Bindung an die eigene Datenbanktechnik mit der HANA In-Memory-Lösung.
Im Technologie-Stack der SAP finden sich jedoch viele unterschiedliche Bereiche, mit denen ein Entwickler in Berührung kommen kann. Welche Know-how-Schwerpunkte ein Entwickler haben muss, hängt im Wesentlichen davon ab, in welchem Bereich von UI, Datenbereitstellung, Geschäftslogik, Transactionsservices, Datenmodellierung und der Datenbank selbst, er unterwegs ist. Einige Bereiche sind untrennbar miteinander verbunden, andere können aufgrund der unterschiedlichen verwendeten Technologien an Spezialisten ausgelagert werden. Gehörten früher Kenntnisse im UI Design und das Wissen um die Spezialitäten des SAP GUI unabdingbar zu den Entwicklerkenntnissen, verlagert sich dies mit SAP Fiori und SAPUI5 mehr oder weniger auf die klassischen Webentwicklerstärken mit HTML, CSS und Javascript.
Die nun technisch vorgegebene Softwarearchitektur unterscheidet sich im Grunde wenig von der schon lange geltenden sinnvollen Entwicklungsstruktur von Anwendungen mit der Aufteilung in Datenbeschaffung, Anwendungslogik und Oberflächen.
Die an sich geringste Schwierigkeit für den Entwickler dürfte die Anwendung von Core Data Services und deren Architektur liegen. Letztlich wird hier die Datenbeschaffung gekapselt und im Gegensatz zum reinen SQL zur Abdeckung komplexerer Bedürfnisse mittels Coding erweitert.
Ein in der SAP-Welt neues Konzept ist das BOPF. Das Business Object Process Framework ist die Basis für Transaction Services und arbeitet mit Businessobjekten, welche über das Framework mit Geschäftslogik angereichert werden können. Auch solche Konzepte findet man bereits häufiger in der Anwendungsentwicklung. An ABAP OO führt hier kein Weg vorbei, was angesichts der Macht der Objektorientierung auch gut so ist. In einem anderen Blogartikel „ABAP … Teil eines Erfolges“ schreiben wir über die Entstehung dieser Programmiersprache.
Den größten Unterschied macht neben dem BOPF die gedankliche Umstellung in der Softwarearchitektur über den Code-Pushdown zur HANA-Datenbank aus. Während früher möglichst minimalistische Wege gesucht wurden, um Daten über den Flaschenhals Netzwerk und Plattenmechanik zu transportieren und anschließend zu verarbeiten, ist die Devise nun, die Verarbeitung am Ort der Datenhaltung stattfinden zu lassen und nur Ergebnisse zu transferieren. Hierfür gilt es auch, sich an eine neue Syntax zu gewöhnen.
Eine Revolution gibt es allerdings noch zu erwähnen: Den Bruch des Abwärtskompatibilitäts-Paradigmas. Mit S/4 HANA bricht SAP mit der 100% Abwärtskompatibilität zu vorherigen Releases, wobei es noch schwer zu beurteilen ist, welche Auswirkungen das haben wird.
So oder so bleibt die Entwicklungsarbeit spannend und abwechslungsreich und so manches wird die Anpassungsfähigkeit zukünftiger Software deutlich erleichtern.