Viele Unternehmen betreiben SAP BW seit Jahren oder gar Jahrzehnten als zentrales Rückgrat ihrer Data-&-Analytics-Landschaft. Doch die Zeit drängt: Wer heute noch auf Release 7.5 oder älter setzt, steht vor einer strategischen Weggabelung – mit weitreichenden Konsequenzen für die gesamte Daten- und Entscheidungskultur im Unternehmen.
1. Das Ende einer Ära: Warum jetzt gehandelt werden muss
SAP BW in den Versionen bis einschließlich 7.5 hat über Jahre hinweg gute Dienste geleistet. Historisch gewachsene Datenmodelle, erprobte ETL-Strecken und tief verankerte Reporting-Strukturen zeugen von diesem Erbe. Doch das Fundament bröckelt: SAP hat klar kommuniziert, dass die klassischen BW-Releases langfristig keine strategische Weiterentwicklung mehr erfahren. Das Mainstream-Maintenance-Fenster wird enger, und wer nichts tut, läuft auf eine technologische Sackgasse zu.
Das ist kein abstraktes Zukunftsproblem – es ist eine operative Realität, die jetzt Entscheidungen erfordert. Die Frage ist nicht mehr ob, sondern wohin und wie schnell die Reise geht.
SAP BW 7.x (non-HANA) läuft in der Extended Maintenance, die sukzessive ausläuft. Unternehmen, die keinen klaren Migrationspfad definieren, riskieren steigende Betriebskosten, fehlende Sicherheitsupdates und wachsende Inkompatibilitäten mit modernen SAP-Produkten und Cloud-Diensten.
2. Zwei Wege aus dem klassischen BW – und ein fundamentaler Unterschied
Auf den ersten Blick stehen zwei Migrationspfade zur Verfügung. Doch sie unterscheiden sich nicht nur technisch, sondern vor allem in ihrer strategischen Tragweite.
Pfad A: SAP BW/4HANA – die sichere Evolution
SAP BW/4HANA ist die direkte Nachfolgegeneration des klassischen SAP BW – bereinigt, beschleunigt und auf SAP HANA als einzige Datenbank optimiert. Die Migration ist für viele Unternehmen der naheliegende erste Schritt: Bekannte Konzepte wie InfoProvider, Transformationen und der Business Warehouse Accelerator entfallen oder werden neu interpretiert, aber das grundlegende Paradigma des klassischen Data Warehousing bleibt erhalten.
BW/4HANA bietet echte Vorteile: In-Memory-Performance, vereinfachte Datenmodelle durch HANA-native Views, vereinheitlichte Persistenzschichten und eine deutlich schlankere Systemarchitektur gegenüber dem klassischen BW. Für Unternehmen, die ihre bestehende BW-Investition sichern und schrittweise modernisieren wollen, ist dies ein solider Weg.
Dennoch bleibt BW/4HANA im Kern ein klassisches Data Warehouse. Der Charakter – zentralisierte, kuratierte Datenhaltung, ETL-getriebene Bereitstellung, SAP-zentrierter Datenfokus – ändert sich nicht grundlegend.
Pfad B: SAP Business Data Cloud – der strategische Neustart
Mit der SAP Business Data Cloud (BDC) hat SAP eine Vision formuliert, die weit über ein Produktupgrade hinausgeht. Die BDC ist SAPs strategische Antwort auf die Anforderungen moderner Data Platforms: offen, skalierbar, KI-fähig und auf eine heterogene, multi-cloud-fähige Unternehmensrealität ausgerichtet.
Wer diesen Weg geht, verlässt das klassische Data-Warehouse-Paradigma und betritt das Zeitalter des Data Fabric / Data Lakehouse. Und das verändert wirklich alles.
3. Vom Data Warehouse zum Data Fabric: Was sich wirklich ändert
Klassisches Data Warehousing mit SAP BW folgt einem wohlbekannten Muster: Daten werden aus Quellsystemen extrahiert, transformiert, in ein zentrales, strukturiertes Lager geladen (ETL) und von dort für Reporting und Analyse bereitgestellt. Dieses Modell ist verlässlich, kontrolliert – aber auch starr, teuer in der Pflege und zunehmend überfordert angesichts der Datenvolumina, Geschwindigkeiten und Vielfalt moderner Unternehmenslandschaften.
- ETL-getrieben: Extract → Transform → Load
- Zentralisierte Datenhaltung im BW-System
- Schema-on-Write: Struktur vor dem Laden
- Primär SAP-Quellen (ECC, S/4HANA)
- Starre InfoObjects und InfoProvider-Modelle
- Begrenzte Skalierbarkeit bei unstrukturierten Daten
- Monolithische Architektur
- Wenig KI/ML-Integration
- ELT-Ansatz: Laden zuerst, transformieren on-demand
- Verteilte Datenhaltung, Virtualisierung möglich
- Schema-on-Read: Flexibilität bei der Nutzung
- Multi-Source: SAP, Non-SAP, Cloud, Streaming
- Offene Formate (Parquet, Delta, Iceberg)
- Nativ skalierbar für Big Data und Echtzeit
- Modulare, servicebasierte Architektur
- Tief integrierte KI/ML-Pipelines
Das Data-Fabric-Konzept bricht die Idee des monolithischen Data Warehouses auf: Anstatt alle Daten physisch an einem Ort zu zentralisieren, entsteht eine intelligente Schicht, die Daten wo immer sie sind auffindbar, zugreifbar und nutzbar macht – mit gemeinsamen Governance-Mechanismen, Metadatenmanagement und semantischen Layern.
4. Die SAP-Produkte in der neuen Architektur: Wer macht was?
Die SAP Business Data Cloud ist kein Einzelprodukt, sondern ein orchestriertes Ökosystem. Jede Komponente hat eine spezifische Rolle in der Gesamtarchitektur:
SAP Datasphere
Der zentrale Data-Management-Hub der BDC. Datasphere bietet Data Integration, Data Catalog, Virtualisierung und Business-Semantik-Layer in einem. Es ersetzt nicht das Data Warehouse – es ist das neue Gravitationszentrum der Datenarchitektur. Hier werden Datenprodukte modelliert, Governance-Regeln definiert und Datenflüsse orchestriert.
SAP Analytics Cloud (SAC)
Die unified Analytics-Plattform für Planung, Vorhersage und Reporting. SAC konsumiert kuratierte Daten aus Datasphere und ermöglicht Self-Service-BI mit integrierten ML-Vorhersagemodellen. In der BDC-Welt ist SAC das primäre Frontend für Business-User – mit nativer KI-Unterstützung durch den Joule-Assistenten.
Databricks (integriert)
Ein Herzstück der BDC-Strategie: SAP hat eine tiefe Partnerschaft mit Databricks eingegangen. Der Databricks Lakehouse fungiert als skalierbare Compute- und Storage-Plattform für große Datenmengen, ML-Workloads und Advanced Analytics. Databricks-Notebooks und MLflow sind direkt in die BDC eingebettet.
SAP HANA Cloud
Als In-Memory-Datenbank und Data-Warehouse-Layer bildet HANA Cloud das transaktionale Rückgrat. In der BDC übernimmt sie hochperformante Abfragen auf relationalen Daten und ist der primäre Speicher für kuratierte, strukturierte Unternehmensdaten – nahtlos integriert mit Datasphere und SAC.
SAP Integration Suite
Verbindet SAP- und Non-SAP-Systeme mit der BDC. Event-Streaming, API-Management und vorgefertigte Konnektoren ermöglichen die Einbindung von Echtzeit-Datenströmen, Drittanbieter-Quellen und Legacy-Systemen in das neue Daten-Ökosystem.
Data Catalog & Business Content
Integriertes Metadatenmanagement, Datenherkunft (Data Lineage) und vorgefertigte Business-Content-Pakete für SAP-Prozesse. Unternehmen profitieren von sofort nutzbaren semantischen Modellen für Finance, Supply Chain und HR – ohne bei null anzufangen.
In der BDC-Architektur gibt es keine einzelne „goldene Kopie" mehr, die physisch alles enthält. Stattdessen entstehen Datenprodukte – dezentral verantwortet, zentral auffindbar, mit definierten SLAs und Ownership. Das ist Data Mesh-Thinking auf SAP-Infrastruktur.
5. Die Vorteile des neuen Ansatzes im Überblick
Der Wechsel von klassischem Data Warehousing auf Data Fabric / Data Lakehouse ist kein Selbstzweck. Die Mehrwerte sind konkret:
Offene Dateiformate und standardisierte APIs ermöglichen die Integration beliebiger Datenquellen – von SAP S/4HANA über Azure Event Hubs bis zu externen SaaS-Anwendungen. Lock-in-Effekte werden minimiert.
Databricks-basierte Workloads skalieren elastisch mit dem Datenwachstum – ohne dass die Grundarchitektur angepasst werden muss. Petabyte-Scale ist kein Sonderprojekt, sondern Standardbetrieb.
Vorhersagemodelle, Anomalieerkennung und generative KI-Funktionen sind keine Insellösungen mehr, sondern First-Class-Citizens der Datenarchitektur – direkt integriert, nicht nachträglich angebaut.
Streaming-Daten aus IoT, Webshops oder ERP-Transaktionen lassen sich in Echtzeit verarbeiten und für operative Analytics nutzen – weit jenseits der klassischen Nachtladeroutinen des SAP BW.
Durch Cloud-native Elastizität, Wegfall redundanter Systeme und konsolidierte Lizenzmodelle können Unternehmen langfristig signifikante TCO-Einsparungen erzielen – sofern die Architektur richtig dimensioniert wird.
Einheitlicher Data Catalog, automatisierte Lineage-Verfolgung und rollenbasierte Zugriffssteuerung über alle Datenquellen hinweg – Compliance und DSGVO-Anforderungen werden architekturseitig adressiert, nicht manuell verwaltet.
6. Die kritische Frage: Dimensionierung und der SAP Estimator
Der Wechsel auf die SAP Business Data Cloud ist strategisch der richtige Weg – davon ist SAP überzeugt, und gute Argumente sprechen dafür. Doch eine Entscheidung, die in der Strategie richtig ist, kann in der Umsetzung teuer werden, wenn ein entscheidender Schritt vernachlässigt wird: die korrekte Dimensionierung.
Die SAP Business Data Cloud wird in Capacity Units (CU) lizenziert. Diese Einheiten steuern, wie viel Rechenleistung (Compute), Speicher und Datendurchsatz für Datasphere, HANA Cloud, Databricks und SAC zur Verfügung stehen. Der Einkauf dieser Units ist eine strategische Investitionsentscheidung – und eine, bei der Unternehmen regelmäßig auf beiden Seiten danebentreffen.
Der SAP Estimator: Das Werkzeug, das richtig ausgefüllt werden muss
SAP stellt für die Dimensionierung der Business Data Cloud ein dediziertes Sizing-Tool bereit: den SAP Estimator. Dieses Werkzeug berechnet auf Basis von Nutzungsszenarien, Datenvolumina und Workload-Profilen eine initiale Empfehlung für die benötigten Capacity Units. Richtig angewendet ist es ein wertvolles Instrument. Falsch oder oberflächlich ausgefüllt, ist es eine Quelle teurer Fehlentscheidungen.
Klare Datenvolumina: Wie groß ist das aktuelle BW-Datenvolumen? Wie viele Quellsysteme werden angebunden? Welches Datenwachstum ist geplant? — Workload-Profile: Wie viele Nutzer arbeiten gleichzeitig? Welche Reports/Dashboards sind zeitkritisch? Gibt es ML/AI-Workloads? — Retention-Anforderungen: Wie lange müssen Daten warm (sofort abfragbar) versus kalt (archiviert) gehalten werden? — Integrationsdichte: Wie viele Systeme werden per Echtzeit-Streaming angebunden, wie viele per Batch?
Typische Dimensionierungsfehler in der Praxis
In der Praxis beobachten wir immer wieder dieselben Muster bei der Estimator-Nutzung: Teams schätzen Datenwachstum zu konservativ (und kaufen zu wenig), übersehen den Ressourcenbedarf für ML-Trainings-Workloads, ignorieren die Anforderungen für Entwicklungs- und Testumgebungen, oder rechnen Databricks-Compute-Anforderungen nicht separat ein.
Besonders kritisch: Der SAP Estimator arbeitet mit Annahmen über Nutzungsintensität. Wenn ein Unternehmen sein Analytics-Angebot im Zuge der Migration stark ausweitet – was der eigentliche Sinn der Investition ist – kann der tatsächliche Ressourcenbedarf signifikant über dem initialen Schätzwert liegen. Der Estimator sollte daher nicht einmalig ausgefüllt und vergessen werden, sondern als lebendes Dokument im Sinne eines Capacity-Management-Prozesses verstanden werden.
Planen Sie einen strukturierten Sizing-Workshop ein, bevor Sie Ihre BDC-Kapazitäten bestellen. Binden Sie neben dem SAP-Estimator auch technische Architekten, die Fachabteilungen (für Workload-Profile) und bei Bedarf externe Experten ein. Eine fundierte Dimensionierung dauert Tage, spart aber potenziell Hunderttausende Euro an Fehlkäufen oder Nachbestellungen.
7. Fazit: Jetzt die Weichen richtig stellen
Unternehmen, die SAP BW 7.5 oder älter betreiben, haben keine Zeit mehr für unverbindliches Abwarten. Der technologische Druck ist real, und die strategische Richtung ist klar: SAP investiert seine Zukunft in die Business Data Cloud, nicht in die Verlängerung klassischer BW-Strukturen.
Der Wechsel vom klassischen Data Warehouse auf einen Data Fabric / Data Lakehouse-Ansatz ist kein einfacher Systemwechsel, sondern ein Kulturwandel in der Art, wie Unternehmen mit Daten umgehen. Er bietet enorme Chancen – für mehr Agilität, bessere KI-Integration, niedrigere TCO und eine Architektur, die mit dem Unternehmen wächst statt es zu bremsen.
Doch der Weg dorthin muss sorgfältig geplant sein. Die richtige Produktkombination, ein fundiertes Architekturkonzept und – allen voran – eine sorgfältige Dimensionierung mit dem SAP Estimator sind keine Nebensächlichkeiten. Sie sind der Unterschied zwischen einem erfolgreichen Transformationsprojekt und einem teuren Lernprojekt auf Kosten des Unternehmens.
Jetzt ist der Moment, die Weichen zu stellen. Richtig. Und mit dem nötigen Tiefgang.
Dieser Artikel wurde auf Basis öffentlich verfügbarer SAP-Produktinformationen und Architekturdokumentation erstellt. Capacity-Unit-Angaben und Lizenzmodelle können sich im Laufe der Zeit ändern – eine individuelle Beratung durch SAP oder zertifizierte Partner ist für konkrete Sizing-Entscheidungen unerlässlich.
Fragen zum Artikel oder Beratungsbedarf?
Ob strategische Orientierung, technische Fragestellungen oder konkrete Projektunterstützung – ich freue mich über Ihre Nachricht.