Die meisten Entscheidungen zur SAP-Architektur wirken auf einem Diagramm solide. Die Probleme zeigen sich sechs Monate nach dem Go-live, wenn der operative Alltag, systemübergreifende Abhängigkeiten und Cloud-Latenzen das ursprüngliche Design in Richtungen verändern, die niemand vollständig vorhergesehen hat.
Resilienz in einer hybriden SAP-Architektur bedeutet nicht, zusätzliche Redundanz auf ein fragiles Design zu setzen. Es geht darum, früh die richtigen strukturellen Entscheidungen zu treffen: wie Workloads getrennt werden, wie Systeme integriert werden, wie S/4HANA im Verhältnis zu Cloud-Services positioniert wird und wie Observability in die Architektur integriert wird, bevor sie benötigt wird. Dieser Artikel behandelt jeden dieser Bereiche praxisnah.
Warum Resilienz von Anfang an in die SAP-Architektur eingeplant werden muss
Was „resilient“ im SAP-Kontext wirklich bedeutet
In einer SAP-Landschaft geht es bei Resilienz nicht nur um Uptime. Ein System kann technisch verfügbar sein und gleichzeitig Batch-Jobs verlangsamt ausführen, fehlerhafte Interface-Payloads verarbeiten oder langsame Transaktionen ausliefern, die die Produktivität schleichend beeinträchtigen. Echte Resilienz bedeutet, dass die Landschaft geplante oder ungeplante Störungen abfangen kann, ohne Datenintegrität, Kontinuität der Geschäftsprozesse oder akzeptable Antwortzeiten zu verlieren.
Dafür reicht Infrastrukturredundanz allein nicht aus. Resilienz muss gleichzeitig auf Anwendungsebene, Integrationsebene und Datenebene für Fehlerfälle ausgelegt werden. Ein Datenbank-Failover bringt wenig, wenn die Middleware, die SAP mit externen Systemen verbindet, die Wiederverbindung nicht sauber verarbeiten kann. High Availability muss Ende zu Ende gestaltet werden, nicht nur auf Infrastrukturebene.
Warum Hybrid Cloud Resilienz schwieriger macht
Eine reine On-Premise-SAP-Landschaft hat vorhersehbare Ausfallmuster. Die Netzwerklatenz ist niedrig und stabil. Das Speicherverhalten ist bekannt. Fehlergrenzen sind klar. In einem Hybrid-Cloud-Modell, in dem SAP S/4HANA möglicherweise auf einem Hyperscaler läuft, während Legacy-Systeme On-Premise bleiben und über SAP BTP oder direkte Integration verbunden sind, erweitert sich die Ausfallfläche deutlich.
Jeder Cloud-Service bringt sein eigenes Verfügbarkeitsmodell, eigene SLA-Bedingungen und einen eigenen Auswirkungsradius bei Incidents mit. Ein regionaler Ausfall bei einem Hyperscaler kann Cloud-gehostete SAP-BTP-Erweiterungen beeinträchtigen, während die zentrale S/4HANA-Instanz weiterhin läuft. Dadurch entstehen Teilstörungen, die schwerer zu erkennen und zu beheben sind als ein kompletter Ausfall. Die Architektur muss diese asymmetrischen Ausfallszenarien ausdrücklich berücksichtigen, sonst werden sie im ungünstigsten Moment sichtbar.
Zentrale Architekturpattern für resiliente hybride SAP-Landschaften
Zonenarchitektur: Workloads nach Risikoprofil trennen
Eine der wirksamsten strukturellen Entscheidungen in einer hybriden SAP-Architektur ist die Definition klarer Workload-Zonen nach Kritikalität und Risiko. Nicht jede SAP-Komponente hat dieselben Verfügbarkeitsanforderungen. Ein Echtzeit-System für die Auftragsverarbeitung und ein monatlicher Reporting-Job benötigen nicht dieselbe Infrastrukturklasse. Wenn beide gleich behandelt werden, steigen Kosten und Komplexität, ohne dass dort zusätzliche Resilienz entsteht, wo sie wirklich zählt.
Ein zonierter Ansatz trennt zentrale transaktionale Systeme wie ERP, Einkauf und Logistik von analytischen Workloads, Entwicklungs- und QA-Umgebungen sowie Cloud-nativen Erweiterungen. Jede Zone erhält die passende Infrastruktur, Netzwerkisolation und Recovery-Ziele. Dadurch wird die Architektur bei Incidents leichter nachvollziehbar: Teams wissen genau, welche Zone betroffen ist und welche Wiederherstellungspriorität gilt, ohne gemeinsam genutzte Infrastruktur erst entflechten zu müssen.
In der Praxis vereinfacht dies auch den Migrationspfad zu RISE with SAP. Wenn Workloads bereits logisch nach Zonen getrennt sind, erfordert die Verlagerung bestimmter Komponenten in die Cloud keine Neugestaltung der gesamten Landschaft, sondern nur der betroffenen Zone.
Design der Integrationsschicht für die Koexistenz von On-Premise und Cloud
Die Integrationsschicht ist der Bereich, in dem die meisten hybriden SAP-Architekturen technische Schulden anhäufen. Punkt-zu-Punkt-Verbindungen, die während einer Migration als temporär gedacht waren, werden oft dauerhaft. Schnittstellen, die für Tests mit geringem Volumen entworfen wurden, überleben bis in die Produktion. Mit der Zeit wird die Integrationsschicht zu einem Geflecht von Abhängigkeiten, das niemand vollständig versteht.
Resilientes Integrationsdesign beginnt mit einer klar definierten Middleware-Strategie. Ob SAP Integration Suite, API-Gateway oder Third-Party-Middleware-Plattform: Das Prinzip bleibt gleich. Jede systemübergreifende Kommunikation sollte durch eine Schicht laufen, die Nachrichten puffern, erneut senden, überwachen und umleiten kann. Direkte Punkt-zu-Punkt-Verbindungen zwischen Systemen in unterschiedlichen Zonen oder Umgebungen sollten die Ausnahme sein, nicht der Standard.
Neben dem Nachrichtenrouting muss diese Schicht auch die Weiterentwicklung von Daten- und API-Schemata sauber abfangen. Wenn ein S/4HANA-Upgrade einen API-Vertrag verändert oder eine Cloud-Erweiterung aktualisiert wird, dürfen nachgelagerte Systeme nicht stillschweigend brechen. Versionierte APIs mit Abwärtskompatibilität von Anfang an in das Integrationsdesign einzubauen, verhindert eine große Kategorie von Produktionsincidents.
High Availability und Disaster Recovery in einem Hybridmodell
High Availability (HA) und Disaster Recovery (DR) haben in einer hybriden SAP-Architektur unterschiedliche Anforderungen. Wenn sie vermischt werden, entstehen Lücken. HA zielt darauf ab, Serviceunterbrechungen bei Komponentenausfällen zu minimieren, etwa bei Datenbank-Node-Switchover, Neustart eines Applikationsservers oder Umleitung durch einen Load Balancer. DR zielt darauf ab, die gesamte Landschaft nach einem standort- oder regionsweiten Ereignis wiederherzustellen. Beides muss ausdrücklich gestaltet werden, denn Hyperscaler liefern nicht automatisch SAP-aware Disaster Recovery.
Für S/4HANA auf einem Hyperscaler bleibt SAP HANA System Replication (HSR) der Standardmechanismus für HA auf Datenbankebene, kombiniert mit Cluster-Management-Tools wie Pacemaker. Auf Anwendungsebene bieten mehrere Applikationsserverinstanzen, die über Availability Zones verteilt sind, Schutz vor Ausfällen einzelner Nodes. Diese Konfigurationen müssen regelmäßig getestet werden. Ein ungetesteter Failover ist eine Unbekannte.
Für DR müssen Recovery Time Objective (RTO) und Recovery Point Objective (RPO) pro Workload-Zone definiert werden, nicht als ein einziges unternehmensweites Ziel. Ein Logistiksystem kann nahezu null RPO und ein RTO von unter einer Stunde benötigen. Eine Business-Intelligence-Umgebung kann ein Wiederherstellungsfenster von 24 Stunden tolerieren. Backup-Infrastruktur und Replikationsfrequenz pauschal an der anspruchsvollsten Workload auszurichten, erhöht die Kosten, ohne die Resilienz der meisten Landschaftsbereiche tatsächlich zu verbessern.
Cloud-Readiness für S/4HANA-Deployments
RISE with SAP und was sich architektonisch wirklich ändert
RISE with SAP bündelt S/4HANA Cloud, als Private oder Public Edition, SAP BTP und Managed Infrastructure auf einem Hyperscaler in einem einzigen Subscription-Modell. Aus architektonischer Sicht verlagert sich damit die Verantwortung für die Infrastruktur zu SAP und dem Hyperscaler. Die Notwendigkeit architektonischer Entscheidungen auf Kundenseite verschwindet dadurch jedoch nicht.
Was sich ändert, ist die Verantwortungsgrenze. Kunden verwalten nicht mehr die zugrunde liegende Infrastruktur, das Datenbank-Patching oder die grundlegende HA-Konfiguration für den S/4HANA-Core. Was sie weiterhin verantworten, sind das Integrationsdesign, die Erweiterungsarchitektur auf BTP, die Datenmigrationsstrategie und vor allem das Observability-Modell. SAP betreibt die Plattform. Der Kunde verantwortet, was darauf läuft und wie es mit dem Rest der Landschaft verbunden ist.
Diese Grenze vor dem Go-live klar zu verstehen, verhindert falsche Erwartungen. Ein MSP oder Enterprise-IT-Team, das davon ausgeht, dass RISE vollständige Ende-zu-Ende-Transparenz abdeckt, wird beim ersten größeren Incident feststellen, dass das Monitoring der SAP-Schicht weiterhin in seiner Verantwortung liegt.
Sizing, Skalierung und Infrastrukturentscheidungen, die Resilienz beeinflussen
Das Cloud-Infrastruktur-Sizing für S/4HANA ist folgenreicher als bei typischen Enterprise-Anwendungen. SAP HANA ist eine In-Memory-Datenbank. Das bedeutet, dass das Speicherprofil des Produktionssystems eine harte Grenze darstellt, nicht etwas, das ohne Planung schrittweise erhöht werden kann. Unterdimensionierung beim Go-live verursacht Performanceprobleme, die unter Produktionsdruck teuer zu beheben sind.
Der richtige Ansatz besteht darin, auf Basis einer dokumentierten Workload-Analyse zu dimensionieren: Anzahl aktiver Nutzer, Transaktionsvolumen pro Spitzenstunde, Speicherbedarf von Batch-Jobs und geplantes Datenwachstum über einen 3-Jahres-Horizont. Hyperscaler bieten speicheroptimierte Instanzfamilien speziell für HANA-Workloads. Die Wahl des richtigen Instanztyps wirkt sich direkt auf Kosten und Systemstabilität aus.
Auf der Skalierungsseite kann die Applikationsserver-Schicht, also ABAP-Instanzen, horizontal skaliert werden, um Lastspitzen abzufangen. Das ist ein echter Vorteil von Cloud-Deployments gegenüber fester On-Premise-Hardware. Dafür muss die Architektur jedoch vom ersten Tag an mehrere Applikationsserverinstanzen unterstützen, inklusive sauberem Session-Handling und korrekter Lastverteilung.
Das Migrationsfenster ohne Blind Spots steuern
Der Zeitraum zwischen dem Start einer S/4HANA-Migration und dem vollständigen Go-live ist architektonisch komplex, weil sich die Landschaft in einem Übergangszustand befindet. Legacy- und neue Systeme laufen parallel, Schnittstellen müssen in beiden Umgebungen validiert werden und die Qualität der Datenmigration entscheidet direkt darüber, ob das Produktionssystem ab Tag eins vertrauenswürdig ist.
Ein häufiges Fehlermuster besteht darin, das Migrationsfenster als reine Projektphase statt als operativen Risikozustand zu behandeln. Teams konzentrieren sich auf Cutover-Aufgaben und Terminmeilensteine, während die Monitoring-Abdeckung der Übergangslandschaft minimal bleibt. Probleme, die im Parallelbetrieb entstehen, etwa Schnittstellenfehler, Datentransformationsfehler oder Performance-Regressionen, bleiben unentdeckt, bis sie den Produktions-Go-live beeinträchtigen.
Monitoring-Baselines vor und nach der Migration sollten eingerichtet werden, bevor das Migrationsfenster beginnt. Das bedeutet, das Legacy-System zu instrumentieren, normale Performanceprofile zu erfassen und dieselbe Instrumentierung für die S/4HANA-Umgebung ab dem ersten Tag des Parallelbetriebs bereitzustellen. Der Vergleich zwischen beiden Umgebungen während des Migrationsfensters ist eine der wertvollsten Datenquellen für das Projektteam.
Observability als struktureller Bestandteil einer SAP-Architektur für Hybrid Cloud und S/4HANA
Warum klassisches Monitoring in hybriden SAP-Landschaften nicht ausreicht
Klassisches SAP-Monitoring wurde für Landschaften entwickelt, in denen alle Komponenten innerhalb eines einzigen Netzwerkperimeters betrieben wurden. Es prüft, ob Systeme verfügbar sind, ob Background-Jobs abgeschlossen wurden und ob Work-Process-Queues innerhalb akzeptabler Grenzen bleiben. In einer einstufigen On-Premise-Bereitstellung ist diese Abdeckung weitgehend ausreichend.
In einer hybriden SAP-Architektur ist die Ausfallfläche über On-Premise-Rechenzentren, Cloud-Regionen, Integrationsmiddleware, BTP-Services und Third-Party-APIs verteilt. Ein Performanceproblem, das in einer Cloud-gehosteten BTP-Erweiterung beginnt, kann über eine schlecht konzipierte synchrone Integration zurück in den S/4HANA-Core wirken. Klassische Monitoring-Tools sehen das Symptom im Core-System, aber nicht die Ursache in der Erweiterungsschicht. Dadurch beginnt jede Untersuchung am falschen Ende.
Observability im hybriden SAP-Kontext bedeutet, korrelierte, systemübergreifende Telemetrie in einer zentralen Ansicht verfügbar zu machen: Applikationsmetriken, Datenbankperformance, Schnittstellenzustand, Ausführung von Background-Jobs, Verfügbarkeit von Cloud-Services und KPIs für Geschäftsprozesse. Ohne diese Korrelation bleibt Root-Cause-Analyse in einer hybriden Landschaft ein Ratespiel.
Wie Full-Stack SAP Observability in der Praxis aussieht
Full-Stack Observability für eine hybride SAP-Landschaft umfasst mehrere unterschiedliche Schichten. Jede liefert andere Signaltypen, die erst in Kombination wirklich nützlich werden.
Auf Infrastrukturebene bilden Compute-, Speicher-, Storage-I/O- und Netzwerklatenzmetriken die Basisumgebung für alles, was darüber liegt. Auf SAP-HANA-Ebene liefern Echtzeitmetriken zur Speicherallokation, Statement-Ausführungszeit, Lock Waits und Replikationsstatus den Performancekontext für das Anwendungsverhalten. Auf NetWeaver- oder S/4HANA-Anwendungsebene zeigen Work-Process-Auslastung, Short Dumps, Zustand der Update Tasks und Dialogantwortzeiten die Stabilität auf Applikationsebene. Auf Integrationsebene zeigen Queue-Tiefen von Schnittstellen, Retry-Zahlen, Fehlerquoten und Message-Processing-Latenzen, ob das verbindende Gewebe zwischen den Systemen stabil bleibt.
Business Process Monitoring ergänzt eine letzte, entscheidende Schicht. Ein technisch gesundes System, das die falsche Geschäftslogik ausführt, etwa falsche Buchungssätze erfasst oder Beschaffungsworkflows nicht auslöst, ist aus Geschäftssicht kein gesundes System. Monitoring, das bis zu Business-Process-KPIs reicht, verbindet technische Gesundheit mit operativen Ergebnissen auf eine Weise, die Infrastrukturmetriken allein nicht leisten können.
Instrumentierung vor dem Go-live: wichtige Überlegungen
Observability, die erst reaktiv nach dem ersten großen Incident hinzugefügt wird, kommt zu spät. Die Entscheidungen zur Instrumentierung während des Architekturdesigns und der Pre-Go-live-Vorbereitung bestimmen, was im Produktionsbetrieb sichtbar ist und was ein Blind Spot bleibt.
Mehrere Prinzipien der Instrumentierung sollten früh festgelegt werden. Erstens sollte Monitoring nach Möglichkeit agentenlos erfolgen. Agents in einer verteilten SAP-Landschaft auszurollen, erhöht den operativen Aufwand und schafft Wartungsabhängigkeiten, die mit der Zeit wachsen. Agentenlose Ansätze, die über Standard-SAP-APIs anbinden, reduzieren diese Belastung deutlich. Zweitens sollten Alert-Schwellenwerte auf gemessenen Baselines basieren, nicht auf willkürlichen Defaults. Ein Schwellenwert ohne Bezug zum tatsächlichen Systemverhalten erzeugt entweder Rauschen oder verpasst echte Probleme. Drittens sollten Dashboards für die operativen Teams gebaut werden, die sie nutzen. MSP-Engineers, SAP-Basis-Teams und Business-Process-Owner haben unterschiedliche Informationsbedürfnisse und sollten nicht dieselbe Ansicht teilen müssen.
Schließlich sollte die Observability-Infrastruktur während des Migrationsfensters und der Lasttests geprüft werden, nicht erst beim Go-live aktiviert werden. Die Daten aus Pre-Production-Aktivitäten sind wertvoll für das Tuning. Gleichzeitig verbessert die Nutzung der Monitoring-Tools vor der Krise die Reaktionsqualität, wenn es wirklich darauf ankommt.
Eine resiliente SAP-Architektur aufbauen, die langfristig trägt
Resiliente SAP-Landschaften für Hybrid Cloud und S/4HANA entstehen nicht durch das Befolgen eines einzelnen Deployment-Guides. Sie entstehen durch konsistente Architekturentscheidungen in vier Bereichen: wie Workloads getrennt und geschützt werden, wie Integration so gestaltet wird, dass sie Veränderungen übersteht, wie die Cloud-Migration ohne neue Blind Spots umgesetzt wird und wie Observability von Anfang an in die Architektur eingebettet wird, statt nachträglich ergänzt zu werden.
Jeder dieser Bereiche erfordert Abwägungen. Die richtigen Entscheidungen hängen von der konkreten Mischung aus On-Premise- und Cloud-Komponenten, der Kritikalität der betroffenen Workloads und der operativen Reife der Teams ab, die die Landschaft betreiben. Was sich nicht ändert, ist das Prinzip: Resilienz wird eingeplant, nicht nachträglich aufgesetzt.
Je stärker SAP-Landschaften verteilt werden, mit mehr Workloads, die zu RISE with SAP wechseln, mehr Erweiterungen auf BTP und mehr Integrationen mit Non-SAP-Cloud-Services, desto größer wird die Lücke zwischen Architekturen, die für Resilienz entwickelt wurden, und solchen, die es nicht wurden. Der richtige Zeitpunkt, diese Lücke zu schließen, ist die Designphase, nicht die Post-Incident-Review.
Entdecken Sie, wie Redpeaks Ende-zu-Ende-Observability für hybride SAP- und S/4HANA-Landschaften bereitstellt.
