Gestaltung hybrider Architekturen
Stand 2026-09-03
Hybride Architektur = 4 Schichten (S/4 embedded für Subsekunden-Antwortzeiten, Datasphere für die Unternehmensmodellierung, BDC für den Data-Product-Mesh + Non-SAP, SAC für die Verwendung). Drei Muster: Federated Query Hub / Replikation + semantische Schicht (kanonisch) / BDC Data Product Mesh. Fünf Fehlerbilder, denen vorzubeugen ist: Latenz-Mismatch, fragmentierte Governance, CU-Überschreitung, Cloud-Connector-Engpass, Kompetenzlücke. ADR vor der Architektur-Freigabe erforderlich.
Was Sie lernen
- Eine hybride SAP-Analytics-Architektur entwerfen — Arbeitslasttypen (operatives Reporting, Enterprise-Analytics, Data Science, Echtzeit) der richtigen Plattformschicht zuordnen (S/4 embedded, Datasphere, BDC, SAC, Databricks)
- Die drei hybriden Architekturmuster (Federated Query Hub, Replikation + semantische Schicht und BDC-Data-Product-Mesh) anwenden und je nach Projektkontext das richtige Muster wählen
- Ein Architecture Decision Record (ADR) für eine hybride Architekturentscheidung erstellen — Treiber, Randbedingungen, betrachtete Optionen, Entscheidungsbegründung und Migrationspfad dokumentieren
- Die fünf wichtigsten Fehlerbilder hybrider Architekturen identifizieren und beheben (Latenz-Mismatch, Governance-Fragmentierung, CU-Kostenüberschreitung, Netzwerkengpass, Kompetenzlücke)
Modulüberblick
Eine hybride SAP-Analytics-Architektur ist keine vorübergehende Phase auf dem Weg zu einem „reinen Cloud"-Endzustand — für die überwältigende Mehrheit der Unternehmenskunden ist sie der dauerhafte Betriebszustand. Ein Greenfield-Deployment, bei dem eine Organisation ausschließlich SAP Datasphere und SAP Business Data Cloud betreibt, ohne veraltetes BW, ohne On-Premise-HANA und ohne embedded S/4HANA-Analytics im produktiven Einsatz, ist tatsächlich selten. Jedes andere Projekt — also nahezu alle — erbt eine Landschaft, in der mehrere Analytics-Schichten koexistieren, jede mit eigenen Stärken, eigenem Latenzprofil und eigenem Governance-Modell. Erfahrene hybride Architektur ist kein Wettstreit zwischen Plattformen. Es ist die Disziplin, jeder Arbeitslast die Schicht zuzuweisen, die sie am besten bedient, und dann die Verträge an den Grenzen zwischen den Schichten so zu governieren, dass der gesamte Bestand sich wie ein kohärentes System verhält statt wie vier unkoordinierte.
Voraussetzungen
- Mittleres praktisches Erfahrungsniveau in SAP-Analytics-Projekten
- Zuerst Kernkonzepte wiederholen: C035, C033, C032
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: belgisches Logistikunternehmen, S/4HANA 2023 auf BTP, veraltetes BW/4HANA, Databricks für ML-Scoring, SAC, Zielzustand: BDC-Data-Product-Mesh innerhalb von 24 Monaten.
- Das Anti-Pattern erkennen und vermeiden: Alle Anwendungsfälle standardmäßig Datasphere zugeordnet — Latenzanforderung des operativen Reportings verfehlt; CU für Subsekunden-Anwendungsfälle verschwendet.
- Die zentrale Entscheidung des Moduls anwenden: S/4 embedded vs. Datasphere für einen Reporting-Anwendungsfall — S/4 embedded wählen, wenn Latenz < 5 s UND Daten einsystemig sind UND kein domänenübergreifender Join nötig ist; sonst Datasphere.
- Den Lernfortschritt mit dem KPI verfolgen: Abdeckung der Arbeitslast-zu-Schicht-Zuordnung (Ziel: 100 % der Anwendungsfälle vor dem Build explizit zugeordnet; Warnsignal: jeder Anwendungsfall ohne explizite Schichtzuordnung).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.