Konzeptkarte

Databricks

Stand 9. Oktober 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Databricks?

Databricks ist eine Daten- und KI-Plattform, aufgebaut um die Lakehouse-Idee: eine Speicherschicht, die offene Tabellenformate hält, mit Engines für SQL, Streaming, Data Science und Machine Learning, die dieselben Tabellen lesen, statt dass jede ihre eigene Kopie führt. Den größten Teil seines Lebens war es aus Sicht einer SAP-Praxis ein benachbarter Stack — etwas, das der Kunde ebenfalls besaß und das jemand anderes administrierte.

Das änderte sich, als SAP es in Business Data Cloud einbettete. BDC liefert eine Databricks-Fähigkeit innerhalb des SAP-Bestands aus, und die Bedeutung für einen Berater liegt nicht in der Technologie: sie liegt darin, dass sich die Grenze verschoben hat. Fragen, die früher mit „das liegt auf der Datenplattformseite“ beantwortet wurden, landen jetzt innerhalb eines SAP-Gesprächs, und vom Berater im Raum wird erwartet, eine Meinung dazu zu haben.

Wofür es tatsächlich gut ist, unverblümt gesagt. Databricks verdient seinen Platz dort, wo die Arbeit großskalige Transformation, Streaming-Ingestion und Machine Learning auf Daten ist, die nicht nur SAP-Daten sind — die Workloads, für die eine semantische Modellierungsschicht nicht ausgelegt ist. SAP Datasphere verdient seinen Platz dort, wo die Arbeit Geschäftssemantik, gesteuerte Wiederverwendung und ein Modellierungsparadigma ist, das SAP-Daten bereits sprechen. Keines ersetzt das andere, und eine Architektur, die die Wahl als Entweder-oder behandelt, endet meist damit, die semantische Schicht von Hand in Notebooks nachzubauen.

Das Gelenk sind die Daten, nicht das Werkzeug. Was die Paarung tragfähig macht, ist offenes Teilen von Tabellen zwischen beiden Seiten statt einer weiteren Kopie der Daten: die SAP-Seite behält Semantik und Governance, die Lakehouse-Seite behält Skalierung und die ML-Oberfläche. Der Fehlermodus, der es wert ist, benannt zu werden, ist Duplizierung — der Moment, in dem dieselbe Geschäftsentität einmal in einem semantischen Modell und einmal in einem Notebook definiert wird, driften die beiden Definitionen auseinander, und die Frage „welche Zahl stimmt“ hat keinen Verantwortlichen.

Wo der Wert eines Beraters liegt. Nicht im Betrieb von Clustern. Er liegt darin, die Person zu sein, die sagen kann, welche Fragen auf welche Seite gehören, was die Grenze überquert, und wer die Definition besitzt, wenn es dazu kommt. Das ist ein Semantik- und Governance-Gespräch, und es ist eines, das ein SAP-Analytics-Berater besser führen kann als jeder andere im Raum.

Die Bausteine, die man namentlich kennen sollte. Unter dem Marketing sind vier Dinge, die ein Berater einordnen können sollte. Delta Lake ist das offene Tabellenformat, das Dateien auf Objektspeicher transaktionales Verhalten verleiht — der Grund, warum ein Lakehouse sicher von mehreren Engines gleichzeitig gelesen und geschrieben werden kann. Unity Catalog ist die Governance-Schicht: Kataloge, Schemata, Tabellen, Eigentümerschaft, Zugriff und Lineage an einem Ort, und die Oberfläche, auf der jedes glaubwürdige „wer darf das sehen“-Gespräch stattfindet. Delta Sharing ist ein offenes Protokoll, um einer anderen Plattform live-Lesezugriff auf eine Tabelle zu geben, ohne sie zu kopieren. Mosaic AI und MLflow sind die Modellseite — Training, Tracking, Serving. Alles andere in einem Databricks-Bestand hängt an diesen vier.

Wie SAP es tatsächlich angebunden hat. SAP hat Business Data Cloud im Februar 2025 als gemeinsames Angebot mit Databricks gestartet, mit einem eingebetteten SAP Databricks innerhalb des SAP-Bestands, und später BDC Connect ausgeliefert für Kunden, die bereits einen eigenen Databricks-Workspace betreiben. Beide Wege stützen sich auf dieselbe Idee: Tabellen teilen statt kopieren. Was für einen Berater zählt, ist das Detail darunter — SAPs semantische Metadaten können mit den geteilten Daten mitreisen, sodass die Lakehouse-Seite den SAP-Geschäftskontext lesen kann, statt ihn aus Feldnamen neu abzuleiten. Das ist der Unterschied zwischen einem Share und einem Export, und es ist das gesamte Argument dafür, es so zu tun.

Die Entscheidung, und der Trade-off, den sie verbirgt. Die Frage, die ein Kunde stellt, ist „Datasphere oder Databricks“; die Frage, die es wert ist, beantwortet zu werden, ist, welche der tatsächlichen Fragen des Kunden auf welche Seite gehört, und wer jede Geschäftsdefinition besitzt, sobald die Grenze gezogen ist. Der Trade-off ist real: eine Definition auf die Lakehouse-Seite legen, gewinnt Skalierung und ML-Reichweite, verlässt aber die SAP-semantische Schicht; sie auf der SAP-Seite behalten, gewinnt gesteuerte Wiederverwendung, kostet aber Bewegung, wenn der ML-Workload sie braucht. Kein Trade-off ist, sie zweimal zu definieren — das ist keine Wahl, das ist ein Fehler, der sechs Monate später bei einem Audit auffällt.

Die Joule-Perspektive, September 2026

Die Semantik-gegen-Skalierung-Grenze, die diese Karte benennt, ist dieselbe Grenze, die entscheidet, welche KI-Oberfläche über welche Seite einer gemeinsamen SAP-Databricks-Landschaft räsoniert, und ein Berater sollte beide Grenzen im selben Gespräch ziehen, statt KI als separaten Arbeitsstrang zu behandeln. Auf der Databricks-Seite baut das Mosaic AI Agent Framework mehrstufige Agenten nativ auf Unity-Catalog-governten Tabellen, registrierten Modellen und Vector-Search-Indizes, und Genie beantwortet Single-Turn-Fragen in natürlicher Sprache auf in Databricks residenten Daten anhand von Freitextdefinitionen und vertrauenswürdigen SQL-Beispielen — beide lesen das Lakehouse direkt, ohne Abhängigkeit von SAPs eigener Semantikschicht. Auf der SAP-Seite verankern Joule-Agenten ihr Reasoning im SAP Knowledge Graph, der aus Daten aufgebaut wird, die als governtes Data Product innerhalb von Datasphere modelliert sind, nicht aus rohen Lakehouse-Tabellen. Das bedeutet, dass die Frage „wem gehört die Definition“, die diese Karte bereits für BI rahmt, ein genaues Gegenstück auf der KI-Ebene hat: Ein Joule-Agent, der eine Frage beantwortet, braucht das SAP-seitige Semantikmodell als Datasphere-Data-Product; ein Mosaic-AI-Agent, der dieselbe zugrunde liegende Geschäftsfrage von der Lakehouse-Seite beantwortet, braucht überhaupt kein solches SAP-seitiges Artefakt — die beiden KI-Oberflächen konvergieren nicht automatisch nur, weil BDC beiden Seiten erlaubt, die zugrunde liegenden Tabellen zu teilen.

Die praktische Konsequenz für das Scoping von KI-Arbeit auf einer gemeinsamen SAP-Databricks-Landschaft: nach Workload-Form routen, dieselbe Logik, die diese Karte bereits auf BI anwendet. Eine Frage, die SAP-Prozesskontext braucht — Freigabestatus, Dokumentenlebenszyklus, Organisationshierarchie —, gehört zu einem Joule-Agenten, der den Knowledge Graph liest, denn Genie und Mosaic-AI-Agenten haben kein Äquivalent zu einem strukturierten Modell von SAP-Geschäftsprozessen. Eine Frage, die im Kern eine ML-Trainings- oder groß angelegte Feature-Engineering-Aufgabe ist — ein Abwanderungsmodell, eine Nachfrageprognose, die nachts auf Terabytes an Transaktionshistorie neu trainiert wird —, gehört zu Mosaic AI, denn Joule-Agenten sind nicht für Modelltraining und -bereitstellung in diesem Maßstab gebaut. Dieses Routing in beide Richtungen falsch zu treffen, reproduziert auf der KI-Ebene genau den Duplizierungsfehler, den diese Karte bereits für die Semantik benennt: dieselbe Geschäftslogik einmal in der Verankerung eines Joule-Agenten und ein zweites Mal im Tool-Code eines Mosaic-AI-Agenten zu definieren, und beide werden auseinanderdriften, ohne dass jemand besitzt, welche maßgeblich ist.

Die ehrliche Einschränkung für jeden, der Databricks' KI-Fähigkeiten in einem SAP-Gespräch zitiert: Die eigene Faktenbasis dieser Plattform trägt keine harten GA-Daten oder Versionsnummern für das Mosaic AI Agent Framework oder Genie in derselben Weise, wie sie es für SAPs eigene Joule-Releases tut, weil Databricks' eigener Release-Rhythmus kein von SAP verfasster Inhalt ist — die aktuelle Databricks-Dokumentation direkt prüfen, bevor eine konkrete Fähigkeit als ausgeliefert zitiert wird, statt die bloße Nennung durch diese Karte als Statusbestätigung zu behandeln.

Warum es zählt

Seit BDC es eingebettet hat, ist Databricks kein Stack mehr, zu dem ein SAP-Berater keine Meinung haben kann — die Grenze hat sich in den SAP-Bestand hinein verschoben.
Es ist im Markt, den diese Plattform verfolgt, noch immer ein dünner Skill: 225 der 8.902 veröffentlichten Firmenprofile erwähnen Databricks, gegenüber 2.783 für S/4HANA, und 118 von 1.680 aktiven Opportunity-Zeilen nennen es (Stand 9. Oktober 2026, auf public/api/company-profiles.json und public/api/contracts.json).
Die Entscheidung, die es erzwingt — Semantik hier, Skalierung dort, wer die Definition besitzt — ist genau die, die standardmäßig keinen Verantwortlichen hat, weshalb es sich lohnt, die Person im Raum zu sein, die sie klären kann.

Kernpunkte

Lakehouse-Plattform: eine offene Speicherschicht, mehrere Engines lesen dieselben Tabellen, statt dass jede eine Kopie führt.
Vier Bausteine, die man namentlich kennen sollte: Delta Lake (offenes Tabellenformat), Unity Catalog (Governance), Delta Sharing (offenes Sharing-Protokoll), Mosaic AI/MLflow (Modell-Lebenszyklus).
SAP hat Business Data Cloud im Februar 2025 mit Databricks gestartet und ein SAP Databricks in den SAP-Bestand eingebettet; BDC Connect deckt Kunden ab, die bereits einen Workspace besitzen.
Das Gelenk ist ein SHARE, keine Kopie — und SAPs semantische Metadaten können mit den geteilten Daten mitreisen, sodass der Geschäftskontext nicht aus Feldnamen neu abgeleitet wird.
Es trägt großskalige Transformation, Streaming und ML auf Daten, die nicht nur SAP-Daten sind; Datasphere trägt Geschäftssemantik und gesteuerte Wiederverwendung.
Keines ersetzt das andere; die Wahl als Entweder-oder zu behandeln bedeutet meist, die semantische Schicht von Hand in Notebooks nachzubauen.
Der Fehlermodus ist DUPLIZIERUNG einer Geschäftsdefinition über beide Seiten hinweg — danach hat „welche Zahl stimmt“ keinen Verantwortlichen.
Der Wert eines Beraters liegt hier in Grenzarbeit — Fragen zuordnen, benennen was die Grenze überquert, Eigentümerschaft zuweisen —, nicht im Betrieb von Clustern.

Quellen

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.