ERP Platform Mining

Die strategische Neuausrichtung von ERP markiert einen Paradigmenwechsel, der tiefgreifende betriebswirtschaftliche, technische und organisatorische Auswirkungen auf die gesamte SAP-Community hat und von Analysten, Anwendervertretern der DSAG und Partnern gleichermaßen kritisch wie hoffnungsvoll begleitet wird. Es ist eine Roadmap von der stabilen, aber starren On-prem-Welt in ein dynamisches, aber lizenzrechtlich und technisch herausforderndes Cloud-Universum, in dem SAP nicht mehr der alleinige Fixstern, sondern eine Sonne in einem System aus Hyperscalern, Daten-Spezialisten wie Databricks und Snowflake sowie mächtigen Beratungshäusern ist.

Der Kern dieser ERP-Transformation ist die Erkenntnis, dass der digitale Nukleus des SAP-Bestandskunden sauber gehalten werden muss – die sogenannte Clean-Core-Strategie. Um die Innovationsgeschwindigkeit zu erhöhen und die Wartbarkeit eines S/4-Systems oder der neuen Business Suite zu gewährleisten, werden Modifikationen und Erweiterungen rigoros aus dem Kern verbannt und auf die SAP Business Technology Platform (BTP) verlagert. Die BTP fungiert hierbei als das technische Herzstück, als ein „PaaS“-Angebot (Platform-as-a-Service), das Entwicklung, Integration, Automatisierung, Datenmanagement und künstliche Intelligenz bündelt.

SAP BTP ist der Ort, an dem die Zukunft eines Composable ERP stattfinden kann, während der „traditionelle“ ERP-Kern in Form von S/4 zum stabilen System-of-Record wird. Doch diese schöne neue Welt des Composable ERP bringt massive technische und organisatorische Herausforderungen mit sich. SAP BTP ist kein monolithischer Block – manche meinen, nicht einmal eine Plattform –, sondern ein heterogener Baukasten aus verschiedenen Laufzeitumgebungen wie Cloud Foundry, Kyma (Kubernetes) und der für SAP-Stammkunden besonders emotionalen Abap-Umgebung, die unter dem Codenamen „Steampunk“ bekannt wurde.

CAP, RAP und Governance

Für SAP-Bestandskunden bedeutet dies, dass sie nicht nur neue Programmiermodelle wie das Cloud Application Programming Model (CAP) oder das RESTful Application Programming Model (RAP) beherrschen müssen, sondern auch eine völlig neue Form der Governance etablieren müssen, um in der Vielfalt der ERP-Services und Cloud-Angbeote (SAP und Hyperscaler) nicht die Kontrolle zu verlieren.

Besonders kritisch wird in der Community die Datenstrategie von SAP diskutiert, die in der Ankündigung der SAP Business Data Cloud (BDC) gipfelte. Die BDC soll das Datenchaos, das durch die Fragmentierung und Atomisierung der IT-Landschaften und die zahlreichen Zukäufe der SAP (wie SuccessFactors, Ariba, Concur) entstanden ist, orchestrieren und harmonisieren. Doch der Weg dorthin ist gepflastert mit den Ruinen vergangener Versuche.

Lange Zeit versuchte SAP mit dem Produkt SAP Data Hub, die Datenintegrationsprobleme zu lösen, doch das Konzept scheiterte in der Praxis oft an zu hohem Ressourcenverbrauch, technischer Komplexität und mangelnder Wirtschaftlichkeit. Als Nachfolger wurde die SAP Data Warehouse Cloud positioniert, die später in SAP Datasphere umbenannt wurde, um eine „Business Data Fabric“ zu ermöglichen – eine Architektur, die Daten nicht mehr physisch kopiert, sondern virtuell und semantisch verknüpft, unabhängig davon, wo sie liegen.

Business Data Cloud

Die Business Data Cloud (BDC) ist nun der neueste strategische Überbau, der Datasphere, SAP Analytics Cloud und – das ist die eigentliche Sensation – eine tiefe Integration mit externen Partnern wie Databricks und Snowflake vereint. An dieser Stelle wird die Öffnung der SAP-Strategie am deutlichsten, aber auch das Eingeständnis, dass man im Bereich Big Data und KI nicht mehr alles alleine stemmen kann.

Die Partnerschaft mit Databricks, einem führenden Anbieter für Data-Lakehouse-Architekturen, ist ein zentraler Pfeiler der BDC. Über eine Schnittstelle namens „Zero-copy connectivity via Delta Sharing“ sollen SAP-Daten nahtlos in die Databricks-Plattform integriert werden, um dort mit leistungsfähigen KI- und Machine-Learning-Algorithmen bearbeitet zu werden, ohne dass die Daten das SAP-Ökosystem technisch verlassen oder dupliziert werden müssen. Kritiker bemängeln jedoch, dass die BDC in ihrer aktuellen Form noch Fragen offenlässt und teilweise wie ein Marketing-Wrapper um bestehende Produkte wirkt, da wesentliche Fragen zur Lizenzierung und technischen Tiefe der Integration noch geklärt werden müssen.

Neben Databricks spielt Snowflake eine entscheidende Rolle im modernen Datenmanagement der SAP-Bestandskunden. Obwohl Snowflake in gewisser Weise ein Wettbewerber zu SAPs eigenen Data-
Warehouse-Lösungen ist, erkennen viele Anwender die Vorteile der cloud-agnostischen Architektur von Snowflake. SAP hat reagiert und Partnerschaften etabliert, die einen bidirektionalen Datenaustausch ermöglichen sollen. Snowflake positioniert sich als die Plattform, die Datensilos aufbricht und SAP-Daten mit Non-SAP-Daten in einer performanten Cloud-Umgebung zusammenführt, was oft als Alternative zur reinen SAP-Datasphere-Strategie gesehen wird, insbesondere wenn Unternehmen eine Multi-Cloud-Strategie verfolgen.

Auch Google Cloud ist ein mächtiger Akteur in diesem Geflecht. Die Partnerschaft zwischen SAP und Google geht weit über reine Infrastruktur (IaaS) hinaus. Mit dem Open-Data-Angebot zielen beide Konzerne darauf ab, SAP-Daten und Google-Daten (z. B. aus Google BigQuery) ohne Replikation zu vereinen, um KI-Szenarien zu ermöglichen. Dies ist für SAP überlebenswichtig, da die eigenen KI-Ambitionen (Joule) massiv von der Rechenpower und den Modellen der Hyperscaler abhängen.

Das SAP-Konzept „Clean Core“ ist entscheidend für den Übergang von ECC 6.0 auf S/4 Hana. Zahlreiche Abap-Modifikationen haben in den vergangenen Jahren die SAP‘schen ERP-Systeme optimiert und individualisiert auch zu Lasten der Kompatibilität und Releasefähigkeit. Für die stringente Weiterentwicklung des ERP (Cloud und On-prem) gilt es, ein neues Orchestrierungskonzept für Standards und Modifikationen zu erstellen: Clean Core ist der Anfang.

Neues SAP-Partnersystem

Collibra und DataRobot ergänzen dieses Ökosystem als spezialisierte Partner für Data Governance und Advanced AI, um die Lücken zu füllen, die SAP im eigenen Portfolio hat, insbesondere im Bereich der Governance von heterogenen Datenlandschaften und der Operationalisierung von KI-Modellen.
In diesem komplexen Umfeld fungieren die großen Beratungshäuser und Systemintegratoren als unverzichtbare Navigatoren.

Unternehmen wie Accenture, Deloitte, Capgemini, PwC und EY haben massive Kapazitäten aufgebaut, um die Transformation zur BTP und BDC zu begleiten. Accenture beispielsweise nutzt seine tiefe Partnerschaft mit SAP, um Branchenlösungen auf der BTP zu entwickeln und die Clean-Core-Strategie bei großen Konzernen durchzusetzen, wobei oft auch Open-Source-Komponenten von Partnern wie Red Hat in die Architektur integriert werden.
Anwendung und Beratung

PwC hat nicht nur eine beratende Funktion, sondern setzt S/4 Public Cloud und BTP intern für die eigene globale Organisation ein, was eine hohe Glaubwürdigkeit in der Beratung verleiht. PwC nutzt den Joule Copilot und Business AI, um die eigenen Prozesse zu optimieren, und verkauft diese Erfahrung weiter. Capgemini fokussiert sich stark auf die Integration von S/4 in komplexe, hybride Landschaften und entwickelt eigene Frameworks, um den Umstieg zu beschleunigen.

Atos und Cognizant positionieren sich ebenfalls stark im Bereich der Managed Services und der Transformation von Legacy-Systemen auf die neue SAP-Plattform, wobei sie oft die Brücke zwischen der alten On-prem-Welt und der neuen Cloud-Realität schlagen. Bluetree Solutions, spezialisiert auf Planung und Analytics, spielt eine Rolle bei der Umsetzung von Finanzplanungs- und Konsolidierungslösungen, die zunehmend auf der SAP Analytics Cloud und Datasphere basieren, auch wenn sie im Vergleich zu den „Big 4“ granularer agieren.

Die Rolle von SAP Datasphere im Vergleich zur BDC und den Partnern lässt sich wie folgt differenzieren: Datasphere ist das technische Produkt, die Evolution des Data Warehouse in der Cloud. Es bietet die Werkzeuge für Datenmodellierung, Virtualisierung und Katalogisierung. BDC hingegen ist das übergeordnete SAP-Lösungskonzept, das Datasphere als Kernkomponente nutzt, aber durch die Integration von Databricks und anderen Services (wie SAP Analytics Cloud) zu einer umfassenden „Data Fabric“ erweitert wird.

Während Datasphere versucht, die semantische Hoheit über die SAP-Daten zu behalten (Business Context), bieten Databricks und Snowflake die rohe Rechenpower und die offenen Standards für Data Science und Big Data Analytics, die SAP nicht in dieser Tiefe liefern kann. Der Übergang vom gescheiterten Data Hub zu Datasphere und schließlich zur BDC ist für SAP-Bestandskunden oft schmerzhaft und erfordert eine Migration der Denkweise: weg vom monolithischen ETL (Extract, Transform, Load) hin zur Föderation und Virtualisierung von Daten.

Damit dieser Übergang gelingt, müssen Unternehmen ihre Datenarchitektur fundamental überdenken und Datasphere nicht nur als neues BW, sondern als logische Schicht über einer verteilten Datenlandschaft verstehen. Doch über all diesen technischen Visionen schwebt das Damoklesschwert der Lizenzierung und der kommerziellen Rahmenbedingungen. Die lizenrechtlichen Herausforderungen für BTP und BDC sind immens und sorgen in der SAP-Community für großen Unmut. Das Modell Rise-with- SAP zwingt Bestandskunden faktisch in ein Subskriptionsmodell, bei dem sie das Eigentum an ihren Lizenzen aufgeben und zu Mietern degradiert werden.

Das klassische Datenmanagement hat bei SAP eine lange Tradition: Basierend auf den vorliegenden Quellen lässt sich der Zusammenhang zwischen SAP Datasphere und dem Konzept der SAP Business Data Cloud (BDC) als eine evolutionäre und hierarchische Beziehung beschreiben. Kurz gesagt: SAP Datasphere ist das technologische Herzstück und die primäre Datenmanagement-Engine innerhalb des übergeordneten, strategischen Lösungsbündels, das als SAP Business Data Cloud bezeichnet wird.

Plattform-Metrik: FUE

Besonders kritisch ist die Metrik Full Use Equivalent (FUE), die die User-Lizenzierung in der Cloud regelt und oft intransparent wirkt. Für SAP BTP existieren komplexe Verrechnungsmodelle wie das Cloud Platform Enterprise Agreement (CPEA) oder das neuere BTP Enterprise Agreement (BTPEA), bei denen Kunden „Credits“ vorausbezahlen, die bei Nichtnutzung am Jahresende verfallen können. Dies führt zu einem hohen Druck, die Services auch tatsächlich zu nutzen, und erschwert die Kalkulation der Total Cost of Ownership (TCO). Ein weiteres Minenfeld ist die Indirect-Access-Problematik (Digital Access), die entsteht, wenn externe Systeme – etwa über SAP BTP oder Schnittstellen von Drittanbietern – auf den digitalen Kern von S/4 Hana zugreifen und Dokumente erzeugen.

Zudem fehlt eine klare Cloud-Exit-Strategie. Wer sich einmal voll auf Rise, BTP und BDC eingelassen hat, begibt sich in einen Vendor-Lock-in, aus dem es kaum ein Entrinnen gibt, da die Daten und die Logik (insbesondere bei Entwicklungen auf der BTP) eng mit einer SAP-Infrastruktur verwoben sind. Der EU Data Act versucht hier zwar, regulatorisch einzugreifen und Portabilität zu erzwingen, doch die technische Realität hinkt den juristischen Vorgaben weit hinterher.

Hybride Plattformstrategie

Die SAP-Community steht somit vor der paradoxen Situation, dass sie einerseits die modernen Plattformen wie BTP und BDC benötigt, um innovationsfähig zu bleiben (KI, Automation, Integration), andererseits aber in ein kommerzielles Korsett gezwungen wird, das Flexibilität und Autonomie einschränkt. Die Antwort vieler Bestandskunden ist eine hybride Strategie: Sie nutzen SAP für den Kern (Clean Core), lagern aber Innovation und Datenanalyse zunehmend auf neutrale Plattformen oder Hyperscaler aus, um die Abhängigkeit zu managen. Auf dem Steampunk- und BTP-Summit der SAP-Community am 22. und 23. April in Heidelberg wird unter anderem eine alternative Datenplattform präsentiert und diskutiert. Das IT-Unternehmen Boomi bietet Integrationsszenarien und Plattformen inklusive Agentic AI an, die kompatibel zu SAP ERP/ECC 6.0 und S/4 Hana sind.

Die betriebswirtschaftlichen Herausforderungen einer SAP BTP liegen vor allem in der Rechtfertigung der Kosten. Die Plattform gilt als teuer, und der Business Case für die Migration von etablierten On-prem-Integrationslösungen (wie SAP PI/PO) hin zur Integration Suite auf der BTP ist oft schwer darstellbar, wenn man nur die reinen Betriebskosten betrachtet. Auch hierzu kann Boomi auf dem Summit 2026 adäquate Antworten liefern. Der Mehrwert muss über Agilität, schnellere Time-to-Market und die Nutzung von KI-Services (wie dem GenAI Hub) argumentiert werden.

Technisch gesehen ist SAP BTP zwar mächtig, aber auch komplex. Die Vielzahl der Services (über 90) und die unterschiedlichen Umgebungen erfordern ein breites Skillset, das intern oft nicht vorhanden ist und teuer eingekauft werden muss. Organisatorisch zwingt die Plattform-Strategie die Unternehmen dazu, ihre IT-Abteilungen umzubauen: Weg von reinen SAP-Basis-Administratoren hin zu Cloud-Architekten und DevOps-Ingenieuren, die in der Lage sind, eine dynamische PaaS-Umgebung zu managen. Das sind naturgemäß auch Aufgaben für das CCoE (Competence Center of Expertise).

Für das Thema CCoE und SAP for Me gibt es am 10. und 11. Juni 2026 in Salzburg den Competence Center Summit. Sowohl in Heidelberg als auch in Salzburg wird SAP-Partner Snap einen KI-Erlebnisworkshop anbieten, um die Möglichkeiten mit KI auf den SAP-Plattformen auszuloten.
Das Customer Center of Expertise (CCoE) spielt in diesem Gefüge eine entscheidende, sich wandelnde Rolle. Es muss sich vom reinen Betriebsüberwacher zum Orchestrierer der hybriden Landschaft entwickeln. Es muss die Governance über die BTP-Services sicherstellen, die Kosten (Credits) überwachen und die Einhaltung der Sicherheitsstandards in der Cloud garantieren. Ohne ein starkes CCoE droht auf der BTP ein Wildwuchs an Applikationen und Kosten, der die Vorteile der Plattform zunichtemacht.

Schritte im Prozess der Datenmigration und verantwortliche Rollen bei Neuimplementierung: Es werden ausschließlich Stammdaten und offene Objekte aus Altsystemen übernommen. Offene Belege müssen teils vor oder nach dem Go-live verarbeitet werden. Cutover-Phasen mit Sperren oder eine doppelte Pflege werden ermöglicht. Das S/4 Migration Cockpit unterstützt die Migration, wobei historische Daten nicht migriert werden.

Organisation und Technik

Zusammenfassend lässt sich sagen, dass die Plattform-Strategie von SAP mit S/4 Hana, BTP und BDC zwar technisch schlüssig ist und den Weg zum Intelligent Enterprise ebnet, aber für die SAP-Bestandskunden eine massive Hürde darstellt. Sie müssen nicht nur ihre Technik modernisieren, sondern auch ihre Verträge, ihre Organisation und ihre Denkweise komplett umstellen. Die Partner – seien es die Hyperscaler, die Daten-Spezialisten wie Databricks oder die großen Berater – sind dabei unverzichtbare Helfer, aber auch Profiteure dieser Komplexität.

Der Erfolg der SAP-Strategie wird davon abhängen, ob es gelingt, die Bestandskunden auf dieser Reise mitzunehmen, ohne sie durch Lizenzdruck und technische Überforderung zu verlieren. Die Vision ist klar: Ein modulares, datengetriebenes Unternehmen, das auf einer flexiblen Plattform – einem Composable ERP – läuft. Die Realität ist jedoch noch oft ein harter Kampf mit Migrationen, Kosten und der Suche nach dem richtigen Architektur-Mix.

Im Detail betrachtet offenbart sich bei der Analyse der Business Technology Platform eine Dualität zwischen Versprechen und Verpflichtung. SAP positioniert BTP als das unverzichtbare Bindeglied zwischen dem Clean Core des ERP-Systems und der innovativen Außenwelt. Technisch gesehen ermöglicht sie durch das Steampunk-Modell (SAP BTP Abap Environment) den Abap-Entwicklern, ihr Wissen in die Cloud zu transferieren, ohne den Kern des S/4-Systems zu modifizieren. Dies ist essenziell für die Upgrade-Fähigkeit der Cloud-ERP-Lösungen.

BTP-Lizenzierung

Doch die technische Freiheit hat ihren Preis: Die Lizenzierung von BTP-Services ist volatil. Das Pay-as-you-go-Modell bietet Flexibilität, kann aber bei unkontrollierter Nutzung zu explodierenden Kosten führen, während das Subscription-Modell mit festen Kontingenten die Gefahr von Shelfware birgt oder – im Falle des BTPEA – zum Verfall von Guthaben am Jahresende führt.

Business Data Cloud versucht, das historische Problem der SAP-Datenhaltung zu lösen. Früher waren SAP-Daten in den proprietären Formaten der Applikationen gefangen. Mit BW und später BW/4 Hana schuf SAP zwar mächtige Data Warehouses, die jedoch oft als monolithische Silos endeten. Der SAP Data Hub war der Versuch, eine Orchestrierungsschicht über diese Silos zu legen, scheiterte aber an der Komplexität der Container-Orchestrierung und der mangelnden Performance bei großen Datenmengen.

Datasphere, als Kern der BDC, geht nun den Weg der Föderation: Daten bleiben dort liegen, wo sie sind, und werden virtuell verknüpft. Doch auch hier gibt es Grenzen, insbesondere wenn es um die Performance bei komplexen Joins über Systemgrenzen hinweg geht. Genau hier setzt die Partnerschaft mit Databricks an: Durch die Zero-Copy-Replikation (basierend auf Delta Sharing) können die Daten physisch (aber effizient repliziert) im Data Lakehouse von Databricks analysiert werden, ohne die semantische Bedeutung aus dem SAP-Kontext zu verlieren. Dies ist ein strategisches Eingeständnis von SAP, dass spezialisierte Anbieter im Bereich Big Data Analytics oft leistungsfähiger sind.

Die Rolle von DataRobot und Collibra fügt sich nahtlos in dieses Bild ein. DataRobot bringt automatisierte Machine-Learning-Funktionen (AutoML) ein, die es Fachanwendern ermöglichen, KI-Modelle auf SAP-Daten zu trainieren, ohne tiefe Data-Science-Kenntnisse zu haben. Collibra adressiert das massive Problem der Data Governance in verteilten Landschaften. Wenn Daten über S/4, Datasphere, Databricks und diverse Hyperscaler verstreut sind, verliert der Anwender schnell den Überblick über Herkunft (Lineage), Qualität und Zugriffsberechtigungen. Collibra liefert hier die notwendige Metadaten-Schicht, um Compliance sicherzustellen.

Während klassische SAP-Modellierung oft in einem geschlossenen Ökosystem stattfand, ist die Business Data Fabric radikal offen. Sie integriert Daten aus SAP-Systemen (S/4 und BW) nahtlos mit Daten von Hyperscalern (Google BigQuery, AWS, Azure) und spezialisierten Plattformen (Collibra, Databricks). BTP und BDC fungieren als strategisches Konstrukt, das die Ecosystem-Module verbindet, um eine einheitliche Sicht auf Unternehmensdaten zu ermöglichen.

Portfolios der SAP-Partner

Die großen Systemintegratoren haben ihre Portfolios entsprechend angepasst. Accenture betreibt beispielsweise massive Migration Factories, die den Umstieg auf S/4 und BTP industrialisieren, um die Kosten zu drücken. Deloitte fokussiert sich stark auf die betriebswirtschaftliche Transformation (Kinetic Enterprise), bei der BTP als Enabler für neue Geschäftsmodelle dient. Capgemini nutzt seine Multi-Pillar-S/4-Architecture, um Kunden zu zeigen, wie sie SAP- und Non-SAP-Lösungen auf BTP integrieren können.

Atos und Cognizant bringen ihre Stärken im Infrastruktur-Management ein, um den Betrieb der hybriden Landschaften zu stabilisieren. Bluetree Solutions, oft im Kontext von SAP Analytics und Planung genannt, unterstützt Kunden spezifisch dabei, die Lücke zwischen operativen Daten und strategischer Planung in der SAP Analytics Cloud (SAC) zu schließen. Lizenzrechtlich bleibt die Situation angespannt. Die Einführung von Rise-with-SAP hat das Lizenzmodell verändert. Bestandskunden tauschen ihre „ewigen“ On-prem-Lizenzen gegen ein befristetes Abonnementrecht. Dies wird oft mit dem Versprechen von TCO-Reduktion und Innovation verkauft, doch Kritiker und der Anwenderverein DSAG warnen vor den langfristigen Kostensteigerungen.

Der Weg zur IT-Plattform-Ökonomie mit SAP ist vorgezeichnet, aber er ist kein Spaziergang. Er erfordert eine klare Architekturvision, ein robustes Lizenzmanagement und die Bereitschaft, alte Zöpfe abzuschneiden (Clean Core). BTP und BDC sind mächtige Werkzeuge, aber sie entfalten ihren Wert nur, wenn sie nicht als reine Technik, sondern als Enabler für Business-Innovation (End-to-End-Prozesse) verstanden werden. Die Abhängigkeit von Partnern und Hyperscalern wird zunehmen, was das Management der Anbieter-Schnittstellen zu einer Kernkompetenz der IT-Abteilungen und des CCoE macht. Die SAP-Welt wird offener, aber auch komplexer und teurer – eine Realität, der sich jeder CIO stellen muss.

Die S/4-Conversion ist eine technische Herausforderung, siehe Grafik. Sie erfordert aber ebenso Engagement für die ERP-Daten des Bestandskunden selbst: SAP Datasphere ist der Motor für das Datenmanagement, während die SAP Business Data Cloud das gesamte Fahrzeug ist, das zusätzlich noch das Cockpit (SAC) und den Turbo (Databricks) enthält, um eine vollständige Daten- und KI-Strategie für das Unternehmen abzubilden.

---

Business Data Fabric Platform und Ontologien

Business Data Fabric selbst verändert die klassische Datenmodellierung grundlegend, indem sie den Fokus von der physischen Konsolidierung und Replikation von Daten (wie in klassischen Data Warehouses) hin zu einer virtuellen, semantisch vernetzten und dezentralen Datenarchitektur verschiebt. Dieser Paradigmenwechsel adressiert die Grenzen traditioneller Ansätze, bei denen Daten aus ihren Quellsystemen extrahiert wurden und dabei oft ihren Geschäftskontext verloren.

In der klassischen Datenmodellierung mussten Daten mittels ETL-Prozessen (Extract, Transform, Load) aus operativen Systemen extrahiert und in einen zentralen Speicher (Data Warehouse oder Data Lake) geladen werden. Dies führte zu Redundanzen, Latenzzeiten und hohen Kosten für die Datenbewegung. Die Business Data Fabric hingegen setzt auf Datenföderation und Virtualisierung. Anstatt Daten physisch zu verschieben, verbleiben diese an ihrem Ursprungsort, werden aber über eine einheitliche semantische Schicht virtuell zugänglich gemacht.

Ein technologischer Schlüsselfaktor ist hierbei die „Zero-Copy“-Technik (z. B. via Delta Sharing in Partnerschaft mit Databricks oder Snowflake). Sie ermöglicht es, SAP- und Non-SAP-Daten gemeinsam zu nutzen und zu analysieren, ohne dass Duplikate erstellt werden müssen. Ein Hauptproblem der klassischen Modellierung war der Verlust der „Business Semantics“, wenn Daten das ERP-System verließen. Technische Tabellennamen und Beziehungen (z. B. Währungsumrechnungen oder Hierarchien) wurden beim Export oft getrennt, was komplexe Wiederherstellungsprojekte im Data Warehouse erforderte.

Die Business Data Fabric, realisiert durch SAP Datasphere, behält diesen Geschäftskontext bei. Sie nutzt eine semantische Schicht, die technische Datenstrukturen in verständliche geschäftliche Begriffe übersetzt und Beziehungen zwischen Datenobjekten (z. B. Bestellung, Kunde, Rechnung) aktiv verwaltet. Der SAP Datasphere Knowledge Graph automatisiert dies weiter, indem er Ontologien erstellt, die Beziehungen und den Kontext der Daten in der gesamten Landschaft darstellen, was KI-Modellen hilft, Halluzinationen zu vermeiden.

Klassische Ansätze waren oft monolithisch und wurden von einer zentralen IT-Abteilung verwaltet, die zum Flaschenhals wurde. Die Business Data Fabric unterstützt das Data-Mesh-Konzept, das die Verantwortung für Daten dezentralisiert. Während klassische SAP-Modellierung oft in einem geschlossenen Ökosystem stattfand, ist die Business Data Fabric radikal offen. Sie integriert Daten aus SAP-Systemen nahtlos mit Daten von Hyperscalern und spezialisierten Plattformen. BDC fungiert hierbei als strategisches Konstrukt.

---