Die Evolution des SAP S/4HANA Cloud ERPs: Deep-Dive in Architektur, Bereitstellungsmodelle und KI-gestützte Entwicklungen

Die SAP-Welt dreht sich in einer beispiellosen Geschwindigkeit weiter. Als Senior SAP Technology Consultant und Tech-Blogger beobachte ich täglich, wie klassische On-Premises-Architekturen durch hochflexible, KI-gestützte Cloud-native Lösungen abgelöst werden. Die Transformation erfordert jedoch ein tiefes technisches Verständnis der zugrundeliegenden Bereitstellungsmodelle, der Erweiterbarkeit und der neuen Werkzeuge, die SAP uns an die Hand gibt. In diesem Deep-Dive verknüpfe ich die bewährten architektonischen Grundlagen von S/4HANA nahtlos mit den aktuellsten Release-Informationen und Innovationen aus der SAP-Entwicklung.

Architektur und Bereitstellungsmodelle: Vom Basiswissen zur aktuellen Nomenklatur

Die historische Trennung der SAP-Landschaften hat sich weiterentwickelt. Zuletzt hat SAP ein wichtiges Rebranding vorgenommen, das die Cloud-First-Strategie unterstreicht: Aus der bisherigen SAP S/4HANA Cloud, Public Edition wurde das SAP Cloud ERP. Aus der SAP S/4HANA Cloud Private Edition wurde analog die SAP Cloud ERP Private.

Unter der Haube dieser neuen Bezeichnungen verbergen sich handfeste technische Architekturen:

• SAP Cloud ERP (ehemals Public Cloud): Hierbei handelt es sich um eine Multi-Tenant-Architektur, bei der sich das System im SAP-eigenen Rechenzentrum befindet. Die Verantwortung für Installation, Betrieb, Wartung und Updates liegt zu 100 % bei SAP. Diese Variante ist durch hochgradig standardisierte Best Practices geprägt, was den Implementierungsaufwand signifikant reduziert. Neue Funktionen werden hier monatlich ausgeliefert, mit halbjährlichen großen Releases. Große Upgrade-Projekte entfallen somit vollständig.

• SAP Cloud ERP Private (ehemals Private Cloud): Diese Variante basiert auf einer Single-Tenant-Architektur. Technisch wird das System entweder im Rechenzentrum der SAP oder bei einem Hyperscaler (wie AWS oder Microsoft Azure) betrieben. Der Funktionsumfang entspricht dem der On-Premises-Welt, und der Kern kann vollumfänglich und maßgeschneidert modifiziert werden. Die Releasezyklen sind hier klassischer Natur: Upgrades werden nicht automatisch eingespielt, sondern müssen individuell gesteuert und analysiert werden.

• On-Premises: Die klassische Bereitstellung auf unternehmenseigenen Servern. Diese Version bietet volle Kontrolle durch Modifikationen auf Code-Ebene, erfordert jedoch die vollständige Übernahme von Betriebs- und Wartungskosten. Ein Umstieg von SAP ECC auf S/4HANA im sogenannten Brownfield-Ansatz ist historisch bedingt nur für die Private Cloud und On-Premises möglich.

Hinsichtlich der Lizenzierung gibt es einen harten Schnitt: Während On-Premises-Lösungen als Software-as-a-Product mit hohen Einmalinvestitionen (CapEx) lizenziert werden, folgen die Cloud-Editionen einem Software-as-a-Service (SaaS) Modell. Die Kosten skalieren hier flexibel auf Basis der sogenannten Full User Equivalents (FUE).

Die 5 entscheidenden Faktoren für die Cloud-Transformation

Bei der Evaluierung des richtigen Migrationspfades (z. B. durch die SAP Activate Methode mit ihren sechs Phasen und detaillierten Fit-Gap-Analysen in den "Prepare" und "Explore" Phasen) müssen Architekten fünf zentrale Faktoren berücksichtigen:

1. Industrie-Anforderungen (Industry Requirements): Für hochregulierte Industrien sind Private Cloud oder hybride Modelle oft der präferierte Weg, während weniger regulierte Industrien massiv von der Public Cloud profitieren. Mit dem August-Release 248 hat SAP die Branchenabdeckung für Public Cloud massiv erweitert (z. B. Asset Retirement Obligations, Receipt Creation und Subscription Billing in Consumer Products). Fokusindustrien für zukünftige Entwicklungen bleiben Retail, Consumer Products, Automotive und der Public Sector.

2. Business-Komplexität: Tools wie das Digital Discovery Assessment (DDA) sind unerlässlich geworden, um zu evaluieren, inwieweit Standardprozesse greifen.

3. Operating Model: Hier stellt sich die Frage nach der Adaption von Standardprozessen im Gegensatz zu hochgradig individualisierten Prozessen.

4. IT-Landscape: Die Entscheidung zwischen Greenfield-Implementierungen (prädestiniert für die Public Edition) und Brownfield-Migrationen.

5. Ressourcen und Timeline: Begrenzte Budgets und fixe Timelines prädestinieren Unternehmen für Grow with SAP (Public Cloud zentriert), während Anforderungen nach massiver Flexibilität in der Architektur durch RISE with SAP (Private Cloud) abgedeckt werden.

Deep-Dive Extensibility & Clean Core Strategie im aktuellen Release

Einer der technisch spannendsten Bereiche ist die Erweiterbarkeit unter Einhaltung der Clean Core Strategie. Die strikte Trennung von Standard-Code und Eigenentwicklung ist mittlerweile über drei Architekturebenen möglich:

1. In-App-Erweiterungen (Key-User Extensibility).

2. On-Stack-Entwicklung (Developer Extensibility) in der SAP S/4HANA Cloud ABAP-Umgebung.

3. Side-by-Side-Erweiterungen über die SAP Business Technology Platform (BTP).

Die technische Tiefe, die SAP hier im Release 248 liefert, ist beeindruckend: Das System bietet inzwischen über 750 vorbereitete Integrationen in die Public Cloud, mehr als 700 Open APIs und über 6.000 verwendbare CDS Views.

Eine bahnbrechende Neuerung ist die sogenannte Multi-off Extensibility: Während in der Vergangenheit In-App-Erweiterungen oft nur für einzelne Kunden ("one-off") geschrieben wurden, können diese Entwicklungen nun über GitHub versioniert und von einem System in andere Systeme transportiert werden. Für das Jahr 2025 ist ein skalierbarer Ansatz geplant, der es erlaubt, ABAP Add-ons zu entwickeln und systemübergreifend zu deployen – ein Feature, das für die BTP bereits existiert und nun tief in die ABAP-Umgebung integriert wird.

Zusätzlich ermöglicht das Konzept "ABAP as an entity" im Identity Access Management (IAM) nun eine noch granularere Berechtigungssteuerung, bei der spezifischer ABAP-Code an bestimmte Benutzerrollen gekoppelt werden kann. Zudem können Entwickler nun über die Funktion Localization as a self-service lokale Länderversionen und branchenspezifische Standardfunktionen eigenständig adaptieren und erweitern.

Der KI-Faktor: Joule Copilot für Business und ABAP-Development

Künstliche Intelligenz (Business AI) ist im Cloud ERP nativ verankert. Der KI-Assistent Joule deckt mittlerweile rund 80 % der am häufigsten genutzten navigations- und transaktionsbasierten Aufgaben ab. Mit dem Release 2502 wird eine enorme Menge an GenAI-Use-Cases ausgerollt, darunter Smart Summarization, Situation Handling und die nahtlose Integration in den Microsoft Copilot.

Noch beeindruckender sind die neuen Architektur-Werkzeuge für uns Entwickler: Der Joule Copilot für ABAP Development revolutioniert die Code-Erstellung durch drei zentrale Säulen:

1. Joule Copilot Code Assist: Bietet Code-Vervollständigung und Echtzeit-Erklärungen für Entwicklungsobjekte und unterstützt massiv beim Onboarding in komplexe Codebasen.

2. Joule Copilot Code Prediction: Sagt basierend auf dem Kontext spezifischen ABAP-Code voraus, der exakt zur jeweiligen Sprachversion passt.

3. ABAP Cloud Model Generator: Diese Funktion, Teil der 2025 Roadmap, wird komplette ABAP Cloud Model Business Objects automatisch generieren können – eine massive Beschleunigung für Greenfield- und Side-by-Side-Projekte.

Landscape Management, SLA und Migration

Auch im operativen Basis-Betrieb (SAP Cloud ALM) gibt es harte technische Upgrades. Das Landscape Management garantiert heute ein vertragliches SLA von 99,9 %. Historische Pain-Points wie Systemstillstände bei Upgrades wurden massiv optimiert: Die Downtime-Reduktion für alle Cloud-Services beträgt nun maximal 8 Stunden.

Für den nahtlosen Übergang alter Datenstrukturen wird das Data Migration Cockpit kontinuierlich um neue Migrationsobjekte für Stamm- und Bewegungsdaten erweitert. Architektonisch besonders wertvoll für hybride Landschaften und komplexe Implementierungen ist die Parallel Project Line (PPL). Dieses Feature erlaubt eine parallele Systemlandschaft neben dem produktiven 3-System-Setup (Entwicklung, Test/Quality, Produktion), die für isoliertes Testen von Datenmigrationen, Rollouts oder als frühes Adaptions-System ("early adapter mode") genutzt werden kann. Die PPL wird voraussichtlich mit dem Release 2502 als "PGA" (Productively Generally Available) live gehen. Um die Adoption in diesen Landschaften zu steigern, nutzt SAP zudem In-App Recommendations, um spezifischen Usern gezielt embedded Benachrichtigungen über relevante neue Features ihrer Rolle zukommen zu lassen.

Fazit

Das SAP-Ökosystem transformiert sich radikal von einer historisch starren On-Premises-Architektur hin zu einem agilen, "Suite first"-getriebenen Cloud-Ökosystem. Die Umbenennung in SAP Cloud ERP und SAP Cloud ERP Private ist dabei mehr als nur Marketing – sie markiert den Punkt, an dem die Cloud-Varianten hinsichtlich Erweiterbarkeit (über 700 Open APIs, 6000+ CDS views, Multi-off GitHub Integration) funktionale Parität und teilweise Überlegenheit bei der Entwicklungsgeschwindigkeit gegenüber den klassischen Systemen erreicht haben. Die Integration von generativer KI durch den Joule Copilot bis tief in die ABAP-Entwicklungsumgebung, kombiniert mit hochverfügbaren SLAs von 99,9 %, zeigt, dass die Plattform bereit für hochkomplexe, unternehmenskritische Workloads ist. Als Technologie-Berater ist klar: Der Weg führt über die rigorose Anwendung der SAP Activate Methode und der Clean Core Strategie direkt in die vernetzte, datengesteuerte Business Data Cloud von morgen.