Warum jetzt die Ablösung von SAP BW on HANA ansteht
Die Digitalisierung von Geschäftsprozessen und der Wunsch nach datengetriebener Unternehmenssteuerung machen deutlich: Die Zeit ist reif, SAP BW on HANA abzulösen. Klassische Enterprise Data Warehouses wie SAP BW geraten zunehmend an ihre Grenzen. Während SAP den Fokus auf SAP Datasphere legt, stehen Unternehmen vor einer strategischen Entscheidung: Setzen wir weiter auf die SAP-Welt – oder wählen wir zukunftssichere Alternativen wie Snowflake oder Databricks?
Für IT-Entscheider ergibt sich daraus nicht nur eine technologische, sondern auch eine wirtschaftliche Abwägung: Wie lässt sich das bestehende Wissen aus SAP BW in moderne Cloud-DWH-Plattformen überführen – und welche Architektur bietet den größten Mehrwert für Business, Analytics und Governance?
Warum SAP BW on HANA an Grenzen stößt
Die Entscheidung, SAP BW on HANA abzulösen, fällt oft mit dem Wunsch zusammen, mehr Datenquellen flexibel integrieren zu können. SAP BW on HANA war über viele Jahre hinweg der Standard für strukturiertes Reporting auf SAP-Daten. Allerdings zeigen sich mittlerweile klare Limitierungen, die eine Migration notwendig machen:
Starres Datenmodell mit limitierten Erweiterungsmöglichkeiten für Non-SAP-Quellen
Hoher Pflegeaufwand durch komplexe Transformationen und Abhängigkeiten
Hohe Lizenz- und Betriebskosten
Wenig Flexibilität bei der Integration moderner Analytics- und AI-Tools
Cloud-Reife ist begrenzt – selbst die BW/4HANA Cloud-Varianten bleiben „SAP-zentriert“
Viele Unternehmen stehen zudem vor einem weiteren Problem: BW-Experten gehen in Rente, während die Suche nach jungen BW-Talenten stockt.
Databricks und Snowflake: Moderne Alternativen für ein Cloud Data Warehouse
Snowflake – mehr als nur ein DWH
Ursprünglich als Cloud Data Warehouse konzipiert, hat sich Snowflake in den letzten Jahren jedoch zu einer hochmodernen Datenplattform entwickelt, die zentrale Elemente einer Lakehouse-Architektur integriert.
Mit Komponenten wie External Tables (Zugriff auf externe Objekte im Data Lake), Snowpipe (Streaming-Ingestion), Snowpark (datennahe Verarbeitung in Java, Scala oder Python) und Cortex (integrierte KI-Funktionen) bietet Snowflake heute deutlich mehr als klassisches BI-Reporting.
Die Trennung von Speicher und Rechenleistung, die Unterstützung semi-strukturierter Datenformate (z. B. JSON, Avro, Parquet) und eine performante, skalierbare Architektur mit ACID-Transaktionen machen Snowflake zu einer Lakehouse-fähigen Plattform. Besonders in Kombination mit Qlik Talend Cloud, dbt oder der Unified Star Schema-Modellierung eignet sich Snowflake für moderne, modulare Datenarchitekturen.
Auch wenn Snowflake von seiner DNA her eher wie ein klassisches DWH aufgebaut ist, erfüllt es heute viele Anforderungen, die bisher typischerweise Lakehouse-Plattformen wie Databricks vorbehalten waren – und das bei starker SQL-Orientierung und hoher Benutzerfreundlichkeit.
Databricks – das Lakehouse für Analytics, Data Science und AI
Im Gegensatz dazu verfolgt Databricks einen anderen architektonischen Ansatz. Denn mit dem Lakehouse-Ansatz kombiniert die Plattform die Vorteile von Data Lakes mit denen klassischer Data Warehouses. So entsteht eine flexible und leistungsstarke Datenbasis – nicht nur für Reporting, sondern auch für Data Science und künstliche Intelligenz:
Delta Lake als zentrales Storage-Format (ACID-konform, performant, versionierbar)
Apache Spark-basiert – ideal für große Datenmengen und parallele Verarbeitung
Native Unterstützung für Machine Learning und KI
Python, SQL, R, Scala – alles in Notebooks kombinierbar
Unity Catalog für Data Governance
Dank nativer Unterstützung von Delta Lake, ML und Streaming eignet sich Databricks besonders gut als Lakehouse-Plattform. In Kombination mit der Data Vault Modellierung auf Delta Tables entstehen skalierbare, compliance-fähige Architekturen – ideal für Unternehmen mit AI-Strategie.
Architekturüberlegungen: Lakehouse, Data Mesh, DWH – was passt wann?
Klassisches Data Warehouse (z.B. Snowflake „out of the box“)
Empfehlenswert, wenn:
klare Strukturierung und Governance im Vordergrund stehen
BI und Controlling die primären Use Cases darstellen
strukturierte Datenquellen dominieren
schnelle Umsetzung mit SQL-orientierten Teams gefragt ist
Lakehouse (z.B. Databricks oder Snowflake mit Qlik Talend Upsolver)
Empfehlenswert, wenn:
strukturierte und semi-/unstrukturierte Datenquellen integriert werden sollen
große Datenmengen performant verarbeitet werden müssen
sowohl klassisches Reporting als auch explorative Data Science & AI geplant sind
ein einheitliches Speicherformat (z. B. Parquet) gewünscht ist
Snowflake lässt sich – besonders in Kombination mit Tools wie Qlik Talend Cloud (inkl. Upsolver-Streaming) – ebenfalls als Lakehouse-kompatible Plattform betreiben. Dabei wird eine flexible Architektur ermöglicht, bei der Rohdaten zunächst in einer Landing Zone landen, dann in Snowflake transformiert, modelliert (z. B. via Data Vault) und anschließend für Reporting, Self-Service und Advanced Analytics verwendet werden können.
Hybridarchitekturen
Für viele Unternehmen ist eine Mischform sinnvoll:
strukturierte SAP-Daten fließen über konventionelle Pipelines in Snowflake
Event-Streams und Logs gelangen über Streaming-Lösungen wie Upsolver in ein semi-strukturiertes Datendesign
Das Ganze wird im Data Vault konsolidiert und über ein Semantic Layer exponiert (z. B. Power BI oder Qlik)
Data Mesh-Ansätze
Insbesondere bei verteilten Verantwortlichkeiten in großen Organisationen kann ein Data Mesh sinnvoll sein – sowohl mit Snowflake als auch mit Databricks realisierbar.
💡
Exkurs: MACH-Architektur als strategischer Rahmen
Moderne Data-Warehouse- und Analytics-Plattformen wie Snowflake oder Databricks lassen sich hervorragend in MACH-Architekturen integrieren. MACH steht für Microservices, API-first, Cloud-native und Headless – ein Architekturprinzip, das auf maximale Flexibilität, Skalierbarkeit und Unabhängigkeit von monolithischen Systemen abzielt.
Gerade im Kontext composable Data Stacks ermöglicht MACH die Kombination spezialisierter Tools entlang der gesamten Daten-Wertschöpfungskette – von der Ingestion über die Modellierung (z. B. Data Vault) bis hin zum Reporting in Power BI, Tableau oder Qlik.
Modellierungsansätze im Vergleich: Delta Vault vs. Unified Star Schema
Data Vault (mit Databricks oder Snowflake)
Die Data Vault Modellierung ermöglicht eine flexible, historisierbare und skalierbare Architektur für moderne Data Warehouses – insbesondere in regulatorisch anspruchsvollen Szenarien.
Historisierung und Auditierbarkeit durch strukturierte Hubs, Links und Satelliten
ELT-Verarbeitung in Kombination mit modernen Engines (z. B. Delta Lake bei Databricks oder Snowflake Streams/Tasks)
Skalierbarkeit durch Trennung von Struktur und Inhalt
Hohe Automatisierbarkeit, insbesondere mit Tools wie Qlik Talend oder dbt
Data Vault eignet sich besonders für hybride Organisationen mit strengen Governance-Anforderungen und komplexen Datenlandschaften.
Unified Star Schema (Snowflake)
Das Unified Star Schema (USS), entwickelt von Bill Inmon und Francesco Puppini, ist ein agiles, resilienteres Datenmodell. Es konsolidiert Informationen aus unterschiedlichen Themenbereichen in einem einzigen Schema:
- Agil & belastbar: Anpassungsfähig an neue Datenquellen und Geschäftsanforderungen
- Holistische Datenansicht: Verdeutlicht Beziehungen und vermeidet typische „SQL-Traps“ wie Fan- oder Chasm-Traps
- Self-Service-freundlich: Optimiert für Tools wie Power BI, Tableau oder Qlik
Einsatzszenario: Unternehmen, die ein flexibles, konzernweites BI-Modell mit Self-Service-Zugriff anstreben.
Migrationsstrategie: Von SAP BW on HANA zu Snowflake oder Databricks
1. Analyse der bestehenden BW-Landschaft
Welche Objekte (InfoCubes, Queries, Transformations) sind aktiv?
Welche Datenquellen werden angebunden?
Welche Usergruppen und Reports existieren?
2. Mapping auf Zielarchitektur
BW-Queries ➝ SQL Views / Materialisierte Views in Snowflake
DSO / InfoCubes ➝ Delta Tables (Databricks) oder optimierte Table-Strukturen (Snowflake)
Prozessketten ➝ orchestrierte Pipelines (z. B. mit Qlik Talend, dbt, Azure Data Factory, Apache Airflow)
3. Wahl des geeigneten Migrationsansatzes
Lift & Shift (kurzfristig, geringe Transformation)
Greenfield / Re-Design (mittelfristig, neue Architektur mit modernem Modell)
Hybrid Migration (Kombination, z. B. für schnelle Quick-Wins und langfristige Optimierung)
4. Aufbau einer Data Platform
Zentrale Landing-Zone für Rohdaten
Automatisierte Ladeprozesse (ELT)
Modellierung (USS / Data Vault)
Semantic Layer für Self-Service
Rollen- und Rechtemanagement
Monitoring & Cost Control
Entscheidungsmatrix: Snowflake oder Databricks?
| Kriterium | Snowflake | Databricks |
|---|---|---|
| Zielgruppe | BI, Controlling, Reporting | Data Science, AI, Engineering |
| Datenformate | Strukturiert + semi-strukturiert | Strukturiert + semi-/unstrukturiert |
| Benutzeroberfläche | SQL, klassische BI | Notebooks, Code-first |
| Modellierung | Data Vault, Unified Star Schema (USS) | Data Vault, USS möglich (Lakehouse) |
| Plattform-Architektur | Cloud-DWH mit Lakehouse-Funktionen (z. B. Snowpipe, Snowpark, Cortex) | Lakehouse (Delta Lake, Unity Catalog, ML nativ) |
| Governance & Sharing | Stark (Data Sharing, Masking, RBAC) | Stark (Unity Catalog, RBAC, Lineage) |
| Kostenmodell | Nutzungsgesteuert (Storage & Compute getrennt) | Compute-intensiv, granular skalierbar |
| Skillset im Unternehmen | SQL / BI | Python / Notebooks / Engineering |
Fazit: Der richtige Weg aus der SAP-BW-Welt
Die Ablösung von SAP BW on HANA ist mehr als ein technisches Projekt – sie ist ein strategischer Schritt in Richtung moderner, flexibler Datenarchitekturen.
Snowflake eignet sich ideal, wenn klare Strukturen, SQL-basierte Workflows und BI-Reporting im Vordergrund stehen. Mit External Tables, Snowpipe, Snowpark und Cortex kann Snowflake jedoch auch als moderne Lakehouse-Plattform genutzt werden – besonders in Kombination mit Qlik Talend, dbt und semantischer Modellierung.
Databricks punktet vor allem bei explorativer Datenanalyse, Machine Learning und der Verarbeitung großer, heterogener Datenmengen. Die native Lakehouse-Architektur mit Delta Lake und Unity Catalog bietet maximale Flexibilität für Engineering- und KI-Teams.
Sowohl Snowflake als auch Databricks lassen sich Lakehouse-ähnlich betreiben – je nach Toolstack, Architekturstrategie und Data Engineering-Kompetenz im Unternehmen. Während Databricks diese Architektur nativ abbildet, kann Snowflake in Kombination mit Qlik Talend Cloud (Upsolver) ebenfalls zu einer hochperformanten Lakehouse-Lösung ausgebaut werden. Weitere Informationen zur Lakehouse Architektur beleuchten wir auch in unserem Blogbeitrag: “ Eine differenzierte Betrachtung der architektonischen Unterschiede „
Beide Plattformen lassen sich modular, performant und zukunftssicher betreiben. Entscheidungsrelevant ist vor allem: Welche Ziele verfolgst du mit deiner Datenstrategie – und welche Architektur passt zu deiner Organisation?
🚀 Jetzt handeln: Assessment oder Pilot starten
Du willst wissen, wie eine konkrete Ablösung deines BW-Systems aussehen kann? Wir bieten:
- Schnellanalyse bestehender BW-Architektur
- Workshops für Zielarchitektur Snowflake oder Databricks
- Pilot-Setups inkl. Data Vault oder Unified Star Schema
- Technologieunabhängige Beratung durch erfahrene Architekten