Warum fiel die Entscheidung auf Databricks statt auf einen reinen SAP-Ansatz?

Die Plattformentscheidung fiel anhand konkreter Anforderungen: SAP-Kernsysteme und IoT-Sensorik auf einer Ebene integrieren, Datenprodukte mit Contracts und Ownership tragen, MLOps ab Tag 1 mitziehen und Governance einheitlich abbilden. Databricks bringt Lakehouse-Architektur, Unity Catalog, MLflow und die SAP-Integration über Datasphere in einer Plattform zusammen. Für ein Team, das Datenprodukte an externe Bahnkunden liefert, war das die Entscheidung gegen Fragmentierung. SAP-Investitionen bleiben erhalten, ML- und Datenprodukt-Workloads bekommen ihre eigene Plattform.

Wie lange hat der PoC gedauert?

Zwei Monate, von der Plattformfrage bis zum rollout-fähigen Blueprint mit Referenzarchitektur, produktionsnahen Pipelines, MLOps-Muster und Governance-Modell.

Welche Quellsysteme wurden im PoC integriert?

SAP S/4HANA, SAP Datasphere und SAP Business Data Cloud auf der Business-Seite sowie IoT-Sensorik aus Zügen und Streckeninfrastruktur, ergänzt um API- und Betriebsdaten. Alle liefen über produktionsnahe Pipelines in eine gemeinsame Lakehouse-Architektur.

Was liefert der PoC als konkretes Ergebnis?

Einen belastbaren Blueprint für den Rollout: Referenzarchitektur (Bronze/Silver/Gold, Delta Lake, Unity Catalog, MLflow, Terraform), produktionsnahe Pipelines für SAP und IoT, ein MLOps-Muster, ein Governance- und Data-Product-Modell sowie ein befähigtes internes Team. Kein Wegwerf-Prototyp, sondern der erste Baustein der späteren Plattform.

Wie funktioniert die Integration von SAP und Databricks?

SAP bleibt Quelle für Business-Kontext und Semantik. Über SAP Datasphere und SAP Business Data Cloud werden die Business-Daten in das Databricks Lakehouse eingebunden und dort mit IoT- und Betriebsdaten harmonisiert. Die SAP-Semantik bleibt erhalten, während Verarbeitung, Feature Engineering und ML auf Databricks laufen.

Wie kommen Daten aus Databricks wieder zurück in SAP?

Die Anbindung ist bidirektional. Auf Databricks veredelte Daten und Datenprodukte fließen über SAP Business Data Cloud Connect und Delta Sharing zurück in die SAP-Welt. Damit stehen die kuratierten Ergebnisse auch SAP-nahen Prozessen und Anwendungen zur Verfügung, ohne Datenkopien oder proprietäre Punkt-zu-Punkt-Schnittstellen.

Wie wurde MLOps im PoC aufgesetzt?

Über MLflow als MLOps-Kern: Experiment-Tracking, Modellversionierung, Feature Engineering und Deployment folgen einem einheitlichen, reproduzierbaren Muster. ML-Workloads werden damit wiederholbar betreibbar, statt in isolierten Notebook-Umgebungen zu bleiben.

Muss man schon produktive ML-Modelle haben, damit sich der PoC lohnt?

Nein. Der PoC baut die Grundlage: harmonisierte Daten, MLOps-Muster und Governance. Erste ML-Szenarien wie Predictive Maintenance werden darauf demonstriert. Produktive Modelle sind keine Voraussetzung, sondern ein Ergebnis des Wegs.

Für welche Unternehmen ist dieses Vorgehen relevant?

Für Unternehmen mit solider SAP-Basis und wachsender IoT- oder Sensor-Seite, die daraus skalierbare Datenprodukte bauen wollen, statt jede Integration einzeln zusammenzusetzen.

Was ist ein Databricks Lakehouse?

Ein Lakehouse verbindet die offene, kostengünstige Speicherung eines Data Lake mit den Governance- und Performance-Eigenschaften eines Data Warehouse. Auf Databricks bilden Delta Lake das Speicherformat und Unity Catalog die Governance-Schicht, sodass Rohdaten, kuratierte Datenprodukte und ML-Workloads auf einer Plattform liegen.

Was ist Unity Catalog?

Unity Catalog ist die zentrale Governance-Schicht der Databricks-Plattform. Sie regelt Zugriffe, Lineage, Auditing und Ownership über Kataloge, Schemas und Tabellen hinweg, einheitlich über Dev-, Test- und Prod-Umgebungen.

MLflow ist eine offene Plattform für den ML-Lebenszyklus. Sie deckt Experiment-Tracking, Modellversionierung, Registry und Deployment ab und macht ML-Arbeit nachvollziehbar und reproduzierbar.

Was ist die Medallion-Architektur?

Die Medallion-Architektur gliedert Daten in drei Schichten: Bronze für Rohdaten, Silver für bereinigte und angereicherte Daten und Gold für business-nahe, konsumierbare Datensätze. Dieses Modell sorgt für Nachvollziehbarkeit, Datenqualität und klare Verantwortlichkeiten. Für den Kunden dient Gold als gemeinsame Grundlage für Reporting, Analytics, ML und die eingebetteten Datenprodukte an externe Bahnkunden.

SAP und IoT auf Databricks: Lakehouse-Blueprint für datenbasierte Produkte

Wie ein Bahntechnik-Hersteller SAP-Daten, IoT-Sensorik und MLOps in einem Databricks Lakehouse verbindet und einen Blueprint für skalierbare Datenprodukte schafft.

Projekt besprechen

Lesedauer4 Min.

VeröffentlichtJuli 2026

Maschinenbau

Data & AI

Die wichtigsten Ergebnisse

Rollout-fähiger Blueprint in 2 Monaten
Databricks wurde als strategische Daten- und AI-Plattform bewertet — eingebettet in die gewachsene SAP-nahe Unternehmensarchitektur.
SAP + IoT auf einer Plattform
S/4HANA, Datasphere und Business Data Cloud liefern den Geschäftskontext, IoT-Sensorik die Betriebsdaten — verarbeitet über Bronze, Silver und Gold.
Referenzarchitektur für Datenprodukte
Der Blueprint macht künftige datenbasierte Produkte wiederholbar statt zum Einzelprojekt.

Zusammenfassung

Der Kunde ist ein europäischer Hersteller von Sensor- und Detektionstechnik für die Bahnleittechnik: rund 600 Mitarbeitende, jahrzehntelange Domänenexpertise in Zugerkennung und Streckenüberwachung, ein wachsender Anteil eingebetteter Datenprodukte im Portfolio. Für Betreiber und Instandhalter geht es um Echtzeit-Einblicke in Weichenzustände, Radverschleiß, Streckenauslastung und Anlagenperformance.

KI und Analytics gehören für den Kunden zum Produktversprechen. Die technische Grundlage aus SAP-Kernsystemen und IoT-Sensorik lieferte solide Einzelbausteine, allerdings keine gemeinsame Datenbasis für Datenprodukte, Analytics und ML. Der Global Data Architect verantwortete die Plattform-Frage und suchte einen Weg, der SAP-Investitionen sichert und gleichzeitig ML und Datenprodukte trägt.

Der Auftrag war klar: Databricks sollte in zwei Monaten als mögliche strategische Daten- und AI-Plattform bewertet werden, eingebettet in eine gewachsene SAP-nahe Unternehmensarchitektur. Entscheidend war nicht nur die technische Machbarkeit, sondern der Nachweis, ob sich SAP-Daten, moderne Analytics-Workloads, MLOps und Governance in einem gemeinsamen Lakehouse-Zielbild verbinden lassen. Das Ergebnis war ein lauffähiger Blueprint mit Pipelines, MLOps-Setup und Governance-Modell.

Übersicht

Kunde: Bahntechnik-Hersteller
Branche: Maschinenbau

Verwendete Technologien & Systeme

Terraform

Apache Spark

SAP S/4HANA

SAP Datasphere

Azure Cloud

Databricks Unity Catalog

SQL Warehouse

Databricks Delta Lake

Mosaic AI

MLflow

Services

Data & AI Strategy Consulting Databricks-Plattform Data Engineering AI und Machine Learning Databricks Training und Enablement

Die Transformation

Von der SAP-IoT-Fragmentierung zum Lakehouse-Blueprint.

01Ausgangssituation

Zwei Datenwelten, die sich nicht treffen.

Vor dem PoC war die Datenlandschaft technisch sauber, aber strukturell getrennt. SAP S/4HANA, SAP Datasphere und SAP Business Data Cloud lieferten den geschäftlichen Kontext: Stammdaten, Aufträge, Ersatzteile und Anlageninformationen. Parallel dazu erzeugten IoT-Sensoren aus Zügen und Streckeninfrastruktur kontinuierlich operative Signale wie Achszählungen, Vibration, Temperatur und Zustandsdaten.

Beide Welten funktionierten für sich. Für datenbasierte Produkte in Betrieb und Instandhaltung mussten sie jedoch zusammenkommen: Sensor-Signale gegen Anlagenstamm, Wartungshistorie gegen Ausfallmuster, Ersatzteil-Verfügbarkeit gegen prognostizierte Instandhaltungsfenster.

SAP blieb dabei wichtig für Semantik, Business-Kontext und Integration. Für große IoT-Datenmengen, Feature Engineering, Experiment-Tracking, Modellversionierung und produktive MLOps fehlte jedoch eine gemeinsame Plattform. Data Science lief in isolierten Notebook-Umgebungen, Data-Product-Standards wie Layering, Ownership und Data Contracts waren noch nicht durchgängig etabliert.

Für die Produktseite entstand daraus ein klares Risiko: Jedes neue Datenprodukt bedeutete eine neue Einzelintegration zwischen SAP-Kontext, IoT-Signalen und ML-Workloads.

Solange SAP-Kontext, IoT-Signale und ML-Workloads nur lose gekoppelt sind, bleibt jedes neue Datenprodukt eine Einzelanfertigung.

02Herausforderung

Databricks oder weiter im SAP-Umfeld?

Die naheliegende Option war, die bestehende SAP-nahe Datenlandschaft weiter auszubauen. Für klassische Business-Daten, Semantik und Integration blieb SAP ein wichtiger Baustein. Für die geplanten Datenprodukte reichte das allein jedoch nicht aus: ERP-Daten, API-Daten und IoT-Streams mussten gemeinsam verarbeitet, für Machine Learning vorbereitet und produktiv betrieben werden.

Gemeinsam mit ruhrdot bewertete das Team deshalb, ob Databricks die zentrale Daten- und AI-Plattform für diesen Workload-Mix werden kann. Entscheidend waren Skalierbarkeit, Governance, Integration in die bestehende SAP-Landschaft, ein klarer Data-Product-Blueprint und ein MLOps-Setup, das Data Scientists ohne Werkzeugbruch nutzen können.

Databricks überzeugte, weil Lakehouse-Architektur, Unity Catalog, MLflow, Notebooks und Python in einer Plattform zusammenkommen. SAP bleibt als Quelle für Business-Kontext und Semantik angebunden, während Databricks die Verarbeitung von IoT-Daten, Feature Engineering, Modell-Lifecycle und produktiven Data Products trägt.

Eine Plattform für SAP-Kontext, IoT-Signale und ML-Workloads. Ein Governance-Modell, ein MLOps-Pfad, ein Blueprint für wiederholbare Datenprodukte.

03Strategie

Erst Blueprint, dann Pipeline.

Vor der ersten Pipeline entstand mit ruhrdot eine Referenzarchitektur für den späteren Rollout. Bronze, Silver und Gold definierten das Layering, Unity Catalog das Governance-Modell, Delta Lake die Datenbasis und MLflow den MLOps-Kern. Schema-Evolution, Partitionierung und Delta-Optimierung wurden nicht als Einzelfall gelöst, sondern als wiederverwendbare Standards dokumentiert.

Der PoC sollte deshalb zwei Fragen gleichzeitig beantworten: Funktioniert Databricks technisch für SAP-, IoT- und ML-Workloads? Und lässt sich daraus ein belastbarer Blueprint für weitere Datenprodukte ableiten? Naming, Data Contracts, Ownership, Zugriffsmodell und Layer-Definitionen wurden von Anfang an so beschrieben, dass sie später im Rollout wiederverwendbar sind.

Enablement war Teil des Vorgehens. Data Engineers, Data Scientists und Plattform-Verantwortliche arbeiteten aktiv mit, damit der Blueprint nach dem PoC nicht nur verstanden, sondern weitergeführt werden kann.

Der PoC war kein Wegwerf-Prototyp. Er war der erste belastbare Baustein für den späteren Plattform-Rollout.

04Lösung

Referenzarchitektur, Production-Pipelines und ein befähigtes Team.

In zwei Monaten entstand ein rollout-fähiger Blueprint auf Databricks. SAP-Daten aus S/4HANA, Datasphere und Business Data Cloud werden über Bronze, Silver und Gold verarbeitet. IoT-Sensordaten aus Zügen und Streckeninfrastruktur laufen parallel ins Lakehouse und werden mit SAP-Stammdaten verbunden. Am konkreten Datenprodukt wurde gezeigt, wie Business-Kontext und operative Signale in einer gemeinsamen Plattform zusammenkommen.

Der PoC deckte nicht nur Data Engineering ab. MLflow wurde als MLOps-Kern aufgebaut, Predictive-Maintenance-Szenarien wurden mit kombinierten SAP- und IoT-Daten demonstriert, und ein wiederverwendbares Muster für Feature Engineering, Modellversionierung und Deployment entstand.

Unity Catalog, Data Contracts, Ownership, Lineage, Monitoring und Kostenleitlinien wurden als Rollout-Grundlage dokumentiert. Das interne Team arbeitete aktiv mit und wurde entlang des konkreten PoC-Kontexts enabled.

2 Monatebis zur rollout-fähigen Architektur

SAP + IoTauf einer gemeinsamen Plattform

Zielarchitektur

SAP- und IoT-Daten im Databricks Lakehouse

SAP-nahe Business-Daten und operative IoT-Signale wurden in einer produktionsnahen Lakehouse-Architektur auf Databricks zusammengeführt. Die Plattform verbindet Medallion-Layer, Unity-Catalog-Governance, MLflow-basiertes MLOps, Terraform-basierte Infrastruktur und ein Data-Product-Modell für wiederholbare Analytics- und AI-Use-Cases. Quellsysteme Databricks Data Intelligence Platform (Managed · Azure · Unity Catalog) Workloads Deployment & Betrieb Terraform beschreibt die Infrastruktur und zentrale Plattformobjekte reproduzierbar über Dev-, Test- und Prod-Umgebungen. Lakeflow Jobs orchestrieren Pipelines und wiederholbare Verarbeitungsschritte. MLflow dokumentiert Experimente, Modelle und Deployment-Muster. Runbooks, CI/CD-Leitlinien und Enablement sichern die Weiterführung durch das interne Team.

Bausteine

SAP S/4HANA: ERP, Anlagenstammdaten, Aufträge, Ersatzteile
SAP Datasphere: modellierte Business-Daten und semantischer Kontext
SAP Business Data Cloud: konsolidierte SAP-nahe Datenprodukte
IoT-Sensorik: Züge, Streckeninfrastruktur, Achszähltechnik, Zustandsdaten
API- und Betriebsdaten: ergänzende operative Signale für Datenprodukte
Governance: Unity Catalog · RBAC · Lineage · Audit · Ownership
Data Engineering: Bronze (Raw) → Silver (harmonisiert) → Gold (business-ready Data Products)
MLOps: MLflow · Experiment-Tracking · Modellversionierung · Deployment-Muster

Platform Outcomes

Was der PoC strukturell liefert

Rollout-fähige Referenzarchitektur

Bronze, Silver und Gold, Delta Lake, Unity Catalog, MLflow und Terraform sind als wiederverwendbares Plattformmuster dokumentiert. Der spätere Rollout startet damit nicht auf der grünen Wiese, sondern auf einem geprüften Blueprint.

SAP- und IoT-Daten auf einer Plattform

SAP-Daten aus S/4HANA, Datasphere und Business Data Cloud sowie IoT-Signale aus Zügen und Streckeninfrastruktur wurden in produktionsnahen Pipelines zusammengeführt. Der PoC zeigt, wie Business-Kontext und operative Signale in gemeinsamen Datenprodukten nutzbar werden.

MLOps-Muster mit MLflow

Experiment-Tracking, Modellversionierung, Feature Engineering und Deployment folgen einem einheitlichen Muster. ML-Workloads werden damit wiederholbar betreibbar, statt in isolierten Notebook-Umgebungen zu bleiben.

Governance und Data-Product-Standards

Unity Catalog regelt Rollen, Zugriffe, Lineage und Auditierbarkeit über Dev-, Test- und Prod-Umgebungen. Data Contracts, Ownership und Versionierung schaffen klare Leitplanken für weitere Datenprodukte.

Entscheidungsgrundlage für den Plattform-Rollout

Performance, Skalierbarkeit, Governance, MLOps und Integrationsfähigkeit wurden am konkreten PoC bewertet. Die Plattformentscheidung basiert damit auf lauffähigen Pipelines und dokumentierten Standards, nicht auf Vendor-Präsentationen.

Vorher / Nachher

Was sich konkret verändert hat

Vorher

Nachher

Datenintegration

SAP- und IoT-Daten liefen getrennt, Verknüpfung nur über Einzelintegrationen

SAP S/4HANA, Datasphere, Business Data Cloud und IoT-Sensorik in einer Lakehouse-Architektur

Datenprodukte

Datenprodukte wurden je Use Case neu gebaut

Data Contracts, Ownership, Versionierung und Lebenszyklus als wiederverwendbares Muster

MLOps

ML lief in isolierten Notebook-Umgebungen ohne einheitlichen Modell-Lifecycle

MLflow-Muster für Tracking, Versionierung, Feature Engineering und Deployment

Governance

Ownership, Zugriffe und Lineage waren nicht durchgängig standardisiert

Unity Catalog als Governance-Schicht über Dev-, Test- und Prod-Umgebungen

Plattformentscheidung

Bewertung auf Basis von Annahmen, Zielbildern und Vendor-Präsentationen

Entscheidungsgrundlage auf Basis lauffähiger, produktionsnaher Pipelines und dokumentierter Standards

Nächste Schritte

Vom PoC-Blueprint in den produktiven Rollout

Der PoC liefert die Grundlage für den nächsten Ausbau: Referenzarchitektur, produktionsnahe Pipeline-Muster, Governance-Modell und MLOps-Basis. Die nächsten Schritte zielen darauf, den Blueprint in den Regelbetrieb zu überführen und weitere Datenprodukte darauf aufzubauen.

Nächster Schritt: Plattformmuster produktiv ausrollen

Die Referenzarchitektur wird in den produktiven Betrieb überführt. Pipelines, Gold-Layer, Monitoring, Delta-Optimierungen und Kostensteuerung werden für die ersten Datenprodukte operationalisiert.

In Vorbereitung: Datenprodukte für Betreiber und Instandhalter skalieren

Auf Basis des Data-Product-Modells entstehen weitere eingebettete Datenprodukte für Kundengruppen, Use Cases und Anlagentypen. Data Contracts, Ownership und Versionierung sorgen dafür, dass neue Datenprodukte nach demselben Muster entstehen.

Ziel: AI-gestützte Betriebs- und Wartungs-Use-Cases im Feld

Predictive Maintenance, Anomalie-Erkennung und weitere AI-Use-Cases laufen auf derselben harmonisierten SAP- und IoT-Datenbasis. Der Weg vom Modell zum eingebetteten Datenprodukt folgt einem definierten MLOps- und Deployment-Muster. Mosaic AI und der Feature Store setzen dabei auf den im PoC erschlossenen Daten auf, von klassischen ML-Modellen bis zu GenAI-Anwendungsfeldern.

Können aus euren SAP- und IoT-Daten skalierbare Datenprodukte entstehen?

Wenn SAP den Business-Kontext liefert und Sensoren operative Signale erzeugen, entsteht der eigentliche Wert erst durch die Verbindung beider Welten. Genau dort entscheidet sich, ob Predictive Maintenance, Anlagenanalytik oder eingebettete Datenprodukte skalieren oder jedes Mal neu gebaut werden müssen. Wir prüfen mit euch, welche SAP- und IoT-Daten sich für ein erstes Datenprodukt eignen, wie ein Lakehouse-Blueprint aussehen kann und welche Governance-, MLOps- und Betriebsleitplanken für den Rollout nötig sind.

Jetzt unverbindliches Gespräch vereinbaren

Alexander Rabe

Co-Founder · Head of Data & AI

FAQ

Häufig gestellte Fragen

Jetzt offene Fragen klären

: Die Plattformentscheidung fiel anhand konkreter Anforderungen: SAP-Kernsysteme und IoT-Sensorik auf einer Ebene integrieren, Datenprodukte mit Contracts und Ownership tragen, MLOps ab Tag 1 mitziehen und Governance einheitlich abbilden. Databricks bringt Lakehouse-Architektur, Unity Catalog, MLflow und die SAP-Integration über Datasphere in einer Plattform zusammen. Für ein Team, das Datenprodukte an externe Bahnkunden liefert, war das die Entscheidung gegen Fragmentierung. SAP-Investitionen bleiben erhalten, ML- und Datenprodukt-Workloads bekommen ihre eigene Plattform.
: Zwei Monate, von der Plattformfrage bis zum rollout-fähigen Blueprint mit Referenzarchitektur, produktionsnahen Pipelines, MLOps-Muster und Governance-Modell.
: SAP S/4HANA, SAP Datasphere und SAP Business Data Cloud auf der Business-Seite sowie IoT-Sensorik aus Zügen und Streckeninfrastruktur, ergänzt um API- und Betriebsdaten. Alle liefen über produktionsnahe Pipelines in eine gemeinsame Lakehouse-Architektur.
: Einen belastbaren Blueprint für den Rollout: Referenzarchitektur (Bronze/Silver/Gold, Delta Lake, Unity Catalog, MLflow, Terraform), produktionsnahe Pipelines für SAP und IoT, ein MLOps-Muster, ein Governance- und Data-Product-Modell sowie ein befähigtes internes Team. Kein Wegwerf-Prototyp, sondern der erste Baustein der späteren Plattform.
: SAP bleibt Quelle für Business-Kontext und Semantik. Über SAP Datasphere und SAP Business Data Cloud werden die Business-Daten in das Databricks Lakehouse eingebunden und dort mit IoT- und Betriebsdaten harmonisiert. Die SAP-Semantik bleibt erhalten, während Verarbeitung, Feature Engineering und ML auf Databricks laufen.
: Die Anbindung ist bidirektional. Auf Databricks veredelte Daten und Datenprodukte fließen über SAP Business Data Cloud Connect und Delta Sharing zurück in die SAP-Welt. Damit stehen die kuratierten Ergebnisse auch SAP-nahen Prozessen und Anwendungen zur Verfügung, ohne Datenkopien oder proprietäre Punkt-zu-Punkt-Schnittstellen.
: Über MLflow als MLOps-Kern: Experiment-Tracking, Modellversionierung, Feature Engineering und Deployment folgen einem einheitlichen, reproduzierbaren Muster. ML-Workloads werden damit wiederholbar betreibbar, statt in isolierten Notebook-Umgebungen zu bleiben.
: Governance war von Anfang an Teil der Plattform, nicht nachgelagert. Unity Catalog regelt Rollen, Zugriffe, Lineage und Auditierbarkeit über Dev-, Test- und Prod-Umgebungen. Data Contracts, Ownership und Versionierung schaffen Leitplanken für weitere Datenprodukte.
: Nein. Der PoC baut die Grundlage: harmonisierte Daten, MLOps-Muster und Governance. Erste ML-Szenarien wie Predictive Maintenance werden darauf demonstriert. Produktive Modelle sind keine Voraussetzung, sondern ein Ergebnis des Wegs.
: Für Unternehmen mit solider SAP-Basis und wachsender IoT- oder Sensor-Seite, die daraus skalierbare Datenprodukte bauen wollen, statt jede Integration einzeln zusammenzusetzen.
: Ein Lakehouse verbindet die offene, kostengünstige Speicherung eines Data Lake mit den Governance- und Performance-Eigenschaften eines Data Warehouse. Auf Databricks bilden Delta Lake das Speicherformat und Unity Catalog die Governance-Schicht, sodass Rohdaten, kuratierte Datenprodukte und ML-Workloads auf einer Plattform liegen.
: Unity Catalog ist die zentrale Governance-Schicht der Databricks-Plattform. Sie regelt Zugriffe, Lineage, Auditing und Ownership über Kataloge, Schemas und Tabellen hinweg, einheitlich über Dev-, Test- und Prod-Umgebungen.
: MLflow ist eine offene Plattform für den ML-Lebenszyklus. Sie deckt Experiment-Tracking, Modellversionierung, Registry und Deployment ab und macht ML-Arbeit nachvollziehbar und reproduzierbar.
: Die Medallion-Architektur gliedert Daten in drei Schichten: Bronze für Rohdaten, Silver für bereinigte und angereicherte Daten und Gold für business-nahe, konsumierbare Datensätze. Dieses Modell sorgt für Nachvollziehbarkeit, Datenqualität und klare Verantwortlichkeiten. Für den Kunden dient Gold als gemeinsame Grundlage für Reporting, Analytics, ML und die eingebetteten Datenprodukte an externe Bahnkunden.