Hybride Datenplattform klingt modern. Ohne Entscheidungslogik klingt sie bald teuer.

Sie haben die Budgetfreigabe. Das Team steht bereit. Die Roadmap zur hybriden Datenplattform ist unterschrieben. Databricks als zentraler Baustein für SAP- und Non-SAP-Daten ist beschlossen. Doch dann kommt der Moment, in dem die erste technische Frage laut wird: „Migrieren wir die Daten – oder föderieren wir sie?"

Und genau hier beginnt das eigentliche Problem. Denn ohne eine klare Entscheidungslogik wird aus einer modernen Plattform schnell ein kostspieliges Flickwerk. In diesem Artikel zeigen wir Ihnen, warum die Frage nach Migration von SAP BW/4HANA zu Databricks nicht mit einer pauschalen Antwort beginnt – sondern mit der richtigen Entscheidungsarchitektur.

Warum Datenplattformen ohne Entscheidungslogik teuer werden

Eine hybride Business-Analytics-Plattform mit Databricks verspricht viel: Integration von SAP-Daten über SAP ODP und Databricks, Verbindung zu Non-SAP-Quellen, zentrale Governance mit Unity Catalog, skalierbare KI- und ML-Fähigkeiten. Doch in der Praxis scheitern viele Projekte nicht an der Technologie – sondern an fehlenden Leitplanken für Entscheidungen.

Typische Symptome:

• Datenredundanzen: Dieselben SAP-Tabellen werden mehrfach kopiert, weil niemand definiert hat, wo welche Daten liegen sollen.
• Explodierende Kosten: Storage, Compute und Netzwerk-Traffic wachsen unkontrolliert, weil jede Fachabteilung eigene Pipelines baut.
• Governance-Lücken: Berechtigungen, Lineage und Audit-Trails sind inkonsistent, weil keine klare Verantwortung definiert wurde.
• Lange Time-to-Value: Use Cases bleiben in Pilotphasen stecken, weil die Architektur nicht skaliert und jedes neue Projekt von vorne beginnt.

Die Ursache? Oft wird die technische Machbarkeit mit strategischer Klarheit verwechselt. Eine Plattform kann technisch alles können – aber ohne Entscheidungslogik fehlt die Orientierung, wann welche Architektur sinnvoll ist.

Der Unterschied zwischen Plattform und Plattformstrategie

Eine Plattform ist ein Werkzeug. Eine Plattformstrategie definiert, wie dieses Werkzeug im Kontext Ihrer Datenlandschaft, Ihrer Governance-Anforderungen und Ihrer Business-Ziele eingesetzt wird.

Konkret bedeutet das:

• Wann werden Daten physisch bewegt (Lift-and-Shift)?
• Wann bleiben Daten an der Quelle und werden föderiert (z. B. über Foreign Catalogs)?
• Welche Daten gehören in welche Schicht (Bronze, Silver, Gold)?
• Wer ist für Datenqualität, Aktualität und Governance verantwortlich?
• Wie werden Kosten transparent gemacht und Teams zugeordnet?

Ohne Antworten auf diese Fragen wird jede Plattform – egal wie modern – zur Blackbox.

Entscheidungscheck: Lift-and-Shift vs. Federation

Die zentrale Architekturentscheidung bei der Modernisierung der SAP-Datenplattform lautet: Sollen SAP-Daten physisch nach Databricks kopiert werden – oder bleiben sie in SAP und werden über Federation zugänglich gemacht?

Beide Ansätze haben ihre Berechtigung. Entscheidend ist, die richtige Wahl für den jeweiligen Use Case zu treffen.

Was bedeutet Lift-and-Shift?

Bei Lift-and-Shift werden SAP-Daten (z. B. aus BW/4HANA, S/4HANA oder über SAP ODP in Richtung Databricks) extrahiert, transformiert und in Databricks als Delta-Tabellen persistiert. Die Daten werden physisch bewegt und liegen dauerhaft in der Lakehouse-Architektur.

Vorteile:

• Volle Kontrolle über Datenmodellierung, Transformationen und Performance
• Optimale Integration mit anderen Datenquellen (Non-SAP, Cloud, Streaming)
• Unabhängigkeit von SAP-Systemen für Analytics-Workloads
• Skalierbare Basis für KI, ML und Advanced Analytics

Herausforderungen:

• Initiale Migrationsaufwände (Mapping, Pipelines, Testing)
• Laufende Synchronisation und Datenaktualität
• Höhere Storage- und Compute-Kosten bei großen Datenmengen
• Governance muss über Systemgrenzen hinweg sichergestellt werden

Was bedeutet Federation?

Bei Federation bleiben die Daten in SAP. Databricks greift über Foreign Catalogs oder Konnektoren direkt auf die Quellsysteme zu. Die Daten werden bei Bedarf gelesen – nicht dauerhaft kopiert.

Vorteile:

• Minimale Datenbewegung – Single Source of Truth bleibt in SAP
• Geringere Storage-Kosten
• Schnellere Implementierung bei einfachen Reporting-Use-Cases
• Keine Synchronisationsprobleme

Herausforderungen:

• Abhängigkeit von SAP-System-Performance und Verfügbarkeit
• Eingeschränkte Transformations- und Modellierungsmöglichkeiten
• Latenz bei komplexen Abfragen oder großen Datenmengen
• Schwierigere Integration mit Non-SAP-Daten und KI-Workloads

Wann welcher Ansatz?

Die Entscheidung hängt von mehreren Faktoren ab:

• Datenvolumen: Bei sehr großen SAP-Datenmengen kann Federation Kosten sparen – sofern die Abfragen selten sind.
• Aktualitätsanforderung: Echtzeit-Anforderungen sprechen für Federation oder Streaming-Pipelines; Batch-Analysen für Lift-and-Shift.
• Transformationsbedarf: Komplexe Business-Logik, Anreicherungen und Joins mit Non-SAP-Daten erfordern physische Datenhaltung.
• Governance: Wenn Daten in verschiedenen Domänen wiederverwendet werden sollen, ist Lift-and-Shift mit klaren Ownership-Regeln oft sinnvoller.
• Kosten: Lift-and-Shift verursacht höhere Storage-Kosten; Federation belastet SAP-Systeme und kann Lizenz- und Performance-Probleme verursachen.
• Performance: Analytics-Workloads auf Delta Lake sind in der Regel deutlich schneller als Queries auf SAP-Quellsystemen.

In der Praxis setzen die meisten Unternehmen auf eine hybride Architektur: Kritische, häufig genutzte Daten werden migriert; selten genutzte oder hochdynamische Daten werden föderiert.

Export-Pipelines konkret: Von SAP nach Delta

Wenn Sie sich für Lift-and-Shift entscheiden, stellt sich die Frage: Wie kommen die Daten sauber und effizient von SAP nach Databricks?

Bewährte Integrationspfade

1. SAP ODP → Cloud Storage → Delta Lake

SAP Operational Data Provisioning (ODP) ist der moderne Standard für Datenextraktion aus SAP. ODP unterstützt Extraktoren, CDS Views und DataSources und liefert Daten inkrementell oder als Full Load.

Typischer Ablauf:

• Daten werden über ODP aus SAP extrahiert
• Export in Cloud Storage (Azure Data Lake, AWS S3, Google Cloud Storage)
• Databricks liest die Daten via Auto Loader oder strukturierten Pipelines
• Transformation und Persistierung als Delta-Tabellen

Vorteil: Hohe Flexibilität, skalierbar, gut dokumentiert, SAP-native Schnittstelle.

2. SAP SLT → Cloud Storage → Delta Lake

SAP Landscape Transformation Replication Server (SLT) eignet sich für Echtzeit- oder Near-Realtime-Replikation von Tabellen.

Vorteil: Sehr geringe Latenz, gut für operative Use Cases.

Herausforderung: Höherer Betriebsaufwand, Lizenzkosten, stärkere Belastung der Quellsysteme.

3. SAP Datasphere / Business Data Cloud → Databricks

SAP Datasphere bietet native Integration zu Databricks über Delta Sharing. Daten können als kuratierte Datenprodukte bereitgestellt und direkt in Databricks genutzt werden.

Vorteil: Semantische Anreicherung, Governance auf SAP-Seite, einfache Bereitstellung.

Herausforderung: Zusätzliche SAP-Lizenzkosten, Abhängigkeit von SAP-Roadmap.

Keine Tool-Explosion

Vermeiden Sie den Fehler, für jeden Use Case ein neues Tool einzuführen. Definieren Sie 2–3 Standard-Integrationspfade und nutzen Sie diese konsistent. Das reduziert Komplexität, Betriebsaufwand und Schulungsbedarf.

Mapping-Tipps: Was bei SAP-Migrationen schiefgeht

Die technische Integration ist die eine Seite. Die andere ist das korrekte Mapping von SAP-Datentypen, Formaten und Semantiken auf Delta Lake. Hier lauern typische Fallstricke:

1. Dezimalformate und Präzision

SAP arbeitet mit spezifischen Dezimalformaten (z. B. CURR, QUAN mit Währungs- und Mengeneinheiten). Beim Export nach Databricks gehen diese Informationen oft verloren – oder werden falsch interpretiert.

Lösung: Definieren Sie klare Mapping-Regeln für Dezimalstellen, Scale und Precision. Nutzen Sie Metadaten aus SAP (z. B. DDIC) und dokumentieren Sie Rundungsregeln.

2. Datum, Zeit und Timezone

SAP speichert Datumsfelder häufig als YYYYMMDD (String) oder DATS. Zeitstempel sind oft in UTC – aber nicht immer. Bei der Migration nach Databricks entstehen Fehler, wenn Timezone-Informationen fehlen oder inkonsistent sind.

Lösung: Standardisieren Sie Datum/Zeit-Formate auf ISO 8601 oder Timestamp-Typen. Klären Sie Timezone-Handling und dokumentieren Sie Konventionen im Data Catalog.

3. Führende Nullen

SAP-Schlüsselfelder (z. B. Kunden- oder Materialnummern) enthalten oft führende Nullen. Beim Export als numerische Felder gehen diese verloren – mit gravierenden Folgen für Joins und Lookups.

Lösung: Exportieren Sie Schlüsselfelder als String-Typen. Definieren Sie im Unity Catalog klare Datentypen und nutzen Sie Constraints, um Konsistenz zu sichern.

4. Zeichensätze und Sonderzeichen

SAP-Systeme nutzen oft spezifische Zeichensätze (z. B. SAP Code Page 1100). Beim Export nach UTF-8 können Umlaute, Sonderzeichen oder asiatische Schriftzeichen fehlerhaft übertragen werden.

Lösung: Testen Sie Zeichensatz-Konvertierungen frühzeitig. Nutzen Sie SAP-native Export-Funktionen, die UTF-8 unterstützen.

5. NULL-Werte vs Leerstrings

In SAP werden NULL-Werte und Leerstrings oft unterschiedlich behandelt. In Databricks kann das zu unerwarteten Ergebnissen in Aggregationen und Filtern führen.

Lösung: Definieren Sie eine konsistente NULL-Handling-Strategie und dokumentieren Sie diese im Data-Governance-Framework.

Unity Catalog im Zielbild: Governance von Anfang an

Eine erfolgreiche Migration von SAP BW/4HANA zu Databricks endet nicht mit der Datenbewegung. Sie beginnt mit einer klaren Governance-Architektur – und hier spielt Unity Catalog eine zentrale Rolle.

Warum Unity Catalog?

Unity Catalog ist die zentrale Governance-Schicht in Databricks. Es ermöglicht:

• Katalogisierung: Strukturierung von Daten in Catalogs, Schemas und Tables
• Berechtigungen: Fein granulare, rollenbasierte Zugriffskontrolle
• Lineage: Automatische Nachverfolgung von Datenflüssen und Transformationen
• Auditing: Protokollierung aller Zugriffe und Änderungen
• Metadaten-Management: Zentrale Verwaltung von Beschreibungen, Tags und Ownership

Katalogstruktur für SAP-Migrationen

Definieren Sie frühzeitig eine klare Katalogstruktur. Beispiel:

• Catalog „SAP": Alle SAP-Quelldaten (Bronze-Schicht)
• Catalog „Curated": Transformierte, angereicherte Daten (Silver-Schicht)
• Catalog „Business": Fachlich kuratierte Datenprodukte (Gold-Schicht)
• Catalog „Sandbox": Experimentelle Workspaces für Data Science

Innerhalb jedes Catalogs können Sie Schemas nach Domänen (z. B. Finance, Supply Chain, Sales) oder Quellsystemen (z. B. SAP ERP, SAP BW) strukturieren.

Managed vs External Tables

Entscheiden Sie bewusst, ob Tabellen als Managed (Databricks verwaltet Daten und Metadaten) oder External (Daten liegen in eigenem Storage) angelegt werden.

Managed Tables bieten einfachere Governance und Lifecycle-Management – sind aber weniger flexibel bei Multi-Cloud-Szenarien. External Tables ermöglichen mehr Kontrolle über Storage, erfordern aber zusätzliche Governance-Mechanismen.

Rollen und Verantwortlichkeiten

Definieren Sie klare Ownership-Regeln:

• Data Owners: Fachbereich, der für Datenqualität und Business-Semantik verantwortlich ist
• Data Stewards: Technische Verantwortung für Pipelines, Transformationen und Metadaten
• Data Consumers: Teams und Nutzer mit Lesezugriff

Nutzen Sie Tags in Unity Catalog, um Ownership, Sensitivität (z. B. GDPR-relevante Daten) und Lebenszyklen (z. B. Archivierung nach 7 Jahren) zu kennzeichnen.

Migrations-Factory Roadmap: Von Assessment bis Cutover

Eine strukturierte Modernisierung der SAP-Datenplattform folgt einem klaren Phasenmodell. Hier eine bewährte Roadmap:

Phase 1: Assessment

Ziel: Transparenz über Ist-Zustand und Migrationsumfang schaffen

Aktivitäten:

• Inventarisierung aller SAP-Datenquellen (BW, S/4HANA, DataSources, CDS Views)
• Analyse von Datenvolumen, Aktualitätsanforderungen und Abhängigkeiten
• Bewertung von Use Cases (Reporting, Analytics, KI/ML)
• Entscheidung Lift-and-Shift vs Federation pro Datenquelle
• Kosten- und Ressourcenplanung

Ergebnis: Priorisierte Migrationsliste, Architekturskizze, Business Case

Phase 2: Pilot

Ziel: Machbarkeit beweisen und Learnings generieren

Aktivitäten:

• Migration von 2–3 repräsentativen Datenquellen
• Aufbau der ersten Pipelines (z. B. SAP ODP mit Databricks)
• Einrichtung von Unity Catalog (Catalogs, Schemas, Berechtigungen)
• Test von Mapping-Regeln (Dezimal, Datum, Nullen)
• Validierung von Performance, Kosten und Datenqualität

Ergebnis: Funktionierender Proof-of-Concept, validierte Architektur, dokumentierte Lessons Learned

Phase 3: Migrations-Factory

Ziel: Skalierung der Migration auf alle Datenquellen

Aktivitäten:

• Industrialisierung der Pipelines (Templates, Automatisierung)
• Parallelisierung der Migration in Wellen (nach Priorität)
• Kontinuierliche Qualitätssicherung und Testing
• Aufbau von Monitoring und Alerting
• Schulung der Teams (Data Engineers, Analysts, Business User)

Ergebnis: Vollständig migrierte Datenlandschaft, produktive Pipelines, etablierte Governance

Phase 4: Cutover und Betrieb

Ziel: Übergang in den Regelbetrieb und Dekommissionierung alter Systeme

Aktivitäten:

• Finaler Cutover (Umstellung von Alt- auf Neusystem)
• Deaktivierung oder Archivierung von Legacy-Systemen
• Etablierung von Support- und Betriebsprozessen
• Kontinuierliche Optimierung (Performance, Kosten, Governance)
• Erweiterung um neue Use Cases (KI, GenAI, Self-Service)

Ergebnis: Stabile, skalierbare Plattform im Produktivbetrieb

Kosten-Fallen und saubere Kostenallokation

Eine hybride Datenplattform kann schnell teuer werden – wenn Kosten nicht transparent gemacht und gesteuert werden.

Typische Kostentreiber

• Storage: Datenvolumen wächst unkontrolliert, weil niemand alte oder redundante Daten löscht
• Compute: Ineffiziente Queries, fehlende Cluster-Policies und unkontrollierte Workloads treiben Rechenkosten
• Netzwerk-Traffic: Datenbewegung zwischen Regionen oder Cloud-Anbietern verursacht hohe Transferkosten
• Lizenzen: SAP-Lizenzen (z. B. für SLT, Datasphere) und Databricks-Lizenzen summieren sich

Kostenallokation mit Tags

Nutzen Sie Tags in Unity Catalog und Cloud-Storage, um Kosten transparent zuzuordnen:

• Team-Tags: Welches Team ist Owner?
• Projekt-Tags: Welchem Projekt oder Use Case ist die Tabelle zugeordnet?
• Lifecycle-Tags: Ist die Tabelle produktiv, im Test oder veraltet?
• Sensitivitäts-Tags: GDPR-relevant, vertraulich, öffentlich?

Mit diesen Tags können Sie Kosten pro Team, Projekt oder Domäne auswerten – und Budgets fair verteilen.

Automatisierte Lifecycle-Policies

Definieren Sie Regeln für Datenlebenszyklen:

• Bronze-Daten: Archivierung nach 90 Tagen
• Silver-Daten: Archivierung nach 2 Jahren
• Gold-Daten: Langfristige Aufbewahrung, aber regelmäßige Qualitätsprüfung

Automatisieren Sie Archivierung und Löschung über Databricks Jobs oder Cloud-native Lifecycle-Policies.

Wie sind Ihre Erfahrungen mit hybriden Datenplattformen? Welche Herausforderungen sehen Sie bei der Integration von SAP- und Non-SAP-Daten? Wir freuen uns auf Ihr Feedback und den Austausch.

Erfahren Sie in unserem kostenfreien Webinar „3 häufige Migration-Fehler bei SAP → Databricks – und wie Sie sie vermeiden“, wie Sie Ihre Datenplattform-Modernisierung strukturiert und kosteneffizient umsetzen. Jetzt anmelden und Platz sichern!