SAP S/4HANA Architektur & Evolution: Der ultimative Tech-Deep-Dive von 1511 bis 2022

Willkommen, Tech-Enthusiasten und Architektur-Kollegen! Wer in der heutigen SAP-Welt bestehen will, darf sich nicht nur mit Buzzwords zufriedengeben. Der Übergang von der klassischen SAP Business Suite (SAP ECC 6.0) zu SAP S/4HANA ist kein bloßes Upgrade, sondern ein fundamentaler Paradigmenwechsel auf Datenbank- und Applikationsebene. Heute nehmen wir die Architektur auseinander und analysieren die Evolution von der bahnbrechenden Version 1511 bis zum hochgradig integrierten Release 2022 tiefgreifend.

Der fundamentale Architektur-Shift: Das "Principle of One"

Bevor wir in die Versionierung eintauchen, müssen wir das architektonische Fundament betrachten, das allen S/4HANA-Releases zugrunde liegt. Die HANA In-Memory-Datenbank ermöglichte die Eliminierung von Aggregat- und Indextabellen.

Zwei absolute Gamechanger der Architektur:

1. Das Universal Journal (Tabelle ACDOCA): Im Finanzwesen wurden FI (Finanzwesen) und CO (Controlling) auf Tabellenebene verschmolzen. Historische Tabellen wie BSIS, BSAS, COEP, FAGLFLEXA oder ANEP sind als physische Tabellen obsolet und wurden durch HANA Core Data Services (CDS) Views (sogenannte Compatibility Views) ersetzt. Das bedeutet: Kein Batch-Abgleich mehr zwischen Haupt- und Nebenbüchern, sondern ein Single Source of Truth Ansatz.

2. Die Materialnummernerweiterung (MATNR): Ein massiver Bruch mit der ECC-Vergangenheit. Die Domäne MATNR wurde von 18 auf 40 Zeichen erweitert. Entwickler müssen bei Custom-Code höllisch aufpassen, da Z-Tabellen und BAPIs, die harte Längen CHAR(18) nutzen, unweigerlich Dumps oder Truncation-Fehler werfen. Transaktion AMIL erlaubt die Konfiguration dieser Erweiterung, aber der Code muss mittels Code Inspector (SCI) oder ATC (ABAP Test Cockpit) mit den S/4HANA Readiness Checks validiert werden.

Auch die Datenextraktion für das SAP BW hat sich massiv gewandelt: Die klassischen Service-API (S-API) Extraktoren der Business Suite werden sukzessive durch ABAP CDS Views ersetzt. Moderne Extraktion läuft über den ODP-Framework (Operational Data Provisioning), wobei der CDS View mit der Annotation @Analytics.dataExtraction.enabled: true versehen sein muss. Dies ermöglicht Delta-Extraktionen (Change Data Capture) direkt auf Datenbankebene ohne redundante Setup-Tabellen.

Die Evolutionsstufen: Von 1511 bis 2022

Die Nomenklatur von SAP S/4HANA hat sich über die Jahre gewandelt. Die frühen On-Premise-Releases folgten dem Schema YYMM (z.B. 1511 für November 2015), bevor SAP mit dem Release 2020 auf die Jahreszahl YYYY umschwenkte.

SAP S/4HANA 1511: Der Urknall der Logistik

Nachdem S/4HANA Finance (früher Simple Finance) bereits existierte, brachte das Release 1511 (und das wichtige Feature Pack 01) den Umbau der Logistik (S/4HANA Enterprise Management).

• Architektur-Update: Einführung der Tabelle MATDOC, die die historisch fragmentierten Tabellen MKPF (Kopf) und MSEG (Positionen) für Materialbelege ablöste. Der INSERT-Durchsatz für Materialbuchungen wurde durch diese flache Architektur verzehnfacht.

• Business Partner (BP): Die Transaktionen XD01 (Kunde) und VD01 (Lieferant) wurden rigoros durch den zentralen Business Partner (Transaktion BP) ersetzt. Ohne CVI (Customer-Vendor-Integration) ist eine Migration auf 1511 (und Folge-Releases) technisch unmöglich.

Die Brücken-Releases: 1610 bis 1909 (Embedded Era)

Zwischen 2016 und 2019 fokussierte sich SAP auf die Co-Deployment-Strategie. Standalone-Systeme wie SAP EWM (Extended Warehouse Management) und SAP TM (Transportation Management) wurden als Embedded EWM/TM direkt in den S/4-Kern integriert. Das bedeutete den Wegfall von Core Interface (CIF) Schnittstellen für Stamm- und Bewegungsdaten, was die Systemlandschaft drastisch vereinfachte. Ab 1709 wurde zudem HANA 2.0 zur zwingenden Voraussetzung.

SAP S/4HANA 2020: Das Reife-Release

Mit der Version 2020 (und Feature Pack WN_OP2020_DE) verabschiedete sich SAP vom alten Namensschema und lieferte gewaltige Architekturverbesserungen.

• Advanced Financial Closing (AFC): Nahtlose Integration von RPA (Robotic Process Automation) direkt in die Abschluss-Cockpits.

• Fiori 3.0 Spaces & Pages: Die klassische Kachel-Startseite wurde durch ein komplexeres, raum- und rollenbasiertes UI-Konzept ersetzt, was die User Experience und Ladezeiten (auf Basis des OData V4 Protokolls) drastisch verbesserte.

SAP S/4HANA 2021: Tiefe SD-Integration und MRP-Optimierung

Das Release 2021 legte den Fokus stark auf das Modul Sales & Distribution (SD) sowie die Bedarfsplanung.

• Mass Change Capabilities im SD: Anwender konnten nun direkt über Fiori-Apps massive Feldänderungen (z.B. Routen oder Preiskonditionen) über hunderte Kundenaufträge hinweg durchführen, ohne die fehleranfällige Transaktion MASS bemühen zu müssen.

• Seamless MS Teams Integration: Mit 2021 wurde die Collaborative ERP-Strategie Realität. Ein Kundenauftrag konnte direkt aus Fiori als Live-Card in MS Teams geteilt werden.

SAP S/4HANA 2022: Der Enterprise Asset Management (EAM) Durchbruch

Das Release 2022 lieferte massive Architektur-Updates in peripheren Kernbereichen wie Instandhaltung und Master Data Governance.

• Neue EAM-Funktionalitäten (Instandhaltung): SAP führte das neue "Phase Model" (Phase-Based Maintenance) ein. Anstatt nur auf den Systemstatus (Eröffnet, Freigegeben, Rückgemeldet) zu setzen, läuft der Prozess nun in 9 granularen Phasen ab (Initiierung, Planung, Vorbereitung, Terminierung, Ausführung, etc.). Dies erfordert ein tiefes Customizing in der Plant Maintenance (PM) Konfiguration, verbessert die reaktive und proaktive Wartung jedoch exponentiell.

• Master Data Governance (MDG) 2022: MDG wurde "Cloud-ready". Die Version 2022 unterstützte erstmals das Federated MDG-Konzept. Master-Data-Prozesse lassen sich aufteilen: Globale Attribute (wie Name oder Steuernummer) werden in einem zentralen MDG-System auf Basis der SAP BTP (Business Technology Platform) gepflegt, während lokale Attribute (Verkaufsorganisations-Daten) im dezentralen S/4HANA-System angereichert werden. Die Synchronisation läuft über asynchrone SOAP-Services und das Data Replication Framework (DRF).

On-Premise vs. Cloud: Der architektonische Split

Während On-Premise (und Private Cloud) den vollen Zugriff auf das SAP GUI (Transaktion S-PRO) und Modifikationen im Z-Namensraum über ABAP (sogar via Classic Extensibility) erlauben, forciert SAP zeitgleich die Public Cloud. In der S/4HANA Public Cloud ist die In-App Extensibility (Key User) oder die Side-by-Side Extensibility (auf der BTP via Node.js/Java oder ABAP RAP) verpflichtend. Dieser "Clean Core"-Ansatz stellt On-Premise-Entwickler vor völlig neue Paradigmen: Das klassische User-Exit (SMOD/CMOD) oder BAdI ist im reinen Cloud-Umfeld tot. Stattdessen nutzt man freigegebene, RESTful ABAP Programming (RAP) Business Objects.

Ausführliches Fazit

Der Sprung vom SAP ECC auf S/4HANA (insbesondere auf die ausgereiften Versionen ab 2020 bis 2022) ist das größte Re-Platforming, das Unternehmen in der aktuellen Dekade durchführen. Wie unsere Deep-Dive-Analyse gezeigt hat, geht es bei weitem nicht nur um eine neue Benutzeroberfläche (Fiori).

Vom Wegfall redundanter Aggregattabellen über die Erweiterung systemkritischer Felder (MATNR) bis hin zur Einführung revolutionärer EAM-Phasenmodelle und föderierter Master Data Governance (MDG) – S/4HANA fordert IT-Abteilungen auf ganzer Linie. Die Entwicklung von 1511 (Logistik-Foundation) über die Embedded-Ära (1610-1909) bis hin zu den funktional extrem tiefgehenden Releases 2021 und 2022 beweist: SAP baut das ERP nicht nur um, sie programmieren die Basis der Unternehmens-IT neu. Wer als Consultant oder Inhouse-Architekt jetzt nicht tief in CDS-Views, RAP-Architekturen und Clean-Core-Prinzipien einsteigt, wird bei der nächsten Transition gnadenlos abgehängt.