Wenn ein Migrationsprojekt technische Führung braucht: Databricks und SAP Datasphere im Energiekonzern

Ausgangslage

Das Projekt lief bereits, als Fidan Consulting dazukam: Mehrere Entwickler arbeiteten an der Migration bestehender Datenschichten in eine neue Databricks-Architektur, parallel wurde SAP Datasphere als Schicht für die SAP-nahen Daten eingeführt. Was fehlte, war eine technische Instanz, die Entscheidungen trifft: Wie werden Schichten geschnitten, wie wird historisiert, was ist ein fertiges Datenprodukt, wie kommt Code von der Entwicklung in die Produktion. Jedes Teilteam beantwortete diese Fragen für sich, mit entsprechend unterschiedlichen Ergebnissen.

Vom Entwickler zur technischen Leitung

Fidan Consulting startete mit Entwicklungsaufgaben. Nach kurzer Zeit war klar, dass das Projekt weniger an Kapazität als an Steuerung litt. In Abstimmung mit dem Projektmanagement übernahm Fidan Consulting die Rolle des technischen Leads für die Databricks-Plattform. Seitdem umfasst die Verantwortung:

• Technische Gesamtsteuerung der Plattform: Architekturentscheidungen, Schnittstellen zu Datasphere, Zielbild für die Schichten.
• Governance-, Entwicklungs- und Architekturstandards, verbindlich für alle Teilteams.
• Abstimmung mit Projektmanagement und Fachbereichen: Was ist technisch machbar, was zuerst, was kostet was.
• Priorisierung technischer Themen und Qualitätssicherung durch Reviews.
• Fachliche Führung und Schulung der beteiligten Entwickler.

Architektur und Standards

Der erste Schritt war eine Scope-Bewertung: Welche bestehenden Datencontainer und Datenprodukte müssen migriert werden, welche können entfallen, welche werden neu geschnitten. Daraus entstand eine Aufwandsschätzung und ein Migrationsplan in Stufen, sodass fachliche Abnehmer früh mit ersten Produkten arbeiten konnten, statt auf ein Big-Bang-Ende zu warten.

Parallel wurden die Standards festgelegt, die vorher fehlten:

• Schichtenmodell: klare Regeln, was in Bronze, Silver und Gold passiert – und was nicht. Fachlogik gehört nicht in Ladeprozesse, Historisierung nicht in Berichte.
• Historisierung: Für Silver- und Gold-Tabellen wurde eine wiederverwendbare Merge-Utility entwickelt, die SCD Type 2 mit Surrogate Keys einheitlich umsetzt. Vorher hatte jedes Team seine eigene Variante; jetzt gibt es eine getestete Implementierung, die per Konfiguration eingesetzt wird.
• Entwicklungsrichtlinien: Namenskonventionen, Code-Struktur, Tests, Dokumentation. Kein Code geht ohne Review in die nächste Umgebung.
• Deployment: Auslieferung über Entwicklungs- und Qualitätssicherungsumgebungen mit CI/CD statt manueller Kopien von Notebooks.

Zusammenspiel mit SAP Datasphere

Datasphere und Databricks haben im Zielbild getrennte Aufgaben: Datasphere für die SAP-nahe Semantik und die Anbindung der SAP-Quellen, Databricks für Integration, Historisierung, Engineering und die Bereitstellung der übergreifenden Datenprodukte. Die Schnittstellen zwischen beiden sind definiert, damit Daten nicht doppelt modelliert werden und die Verantwortung für jede Tabelle eindeutig ist.

Führung und Schulung

Standards wirken nur, wenn das Team sie versteht und mitträgt. Deshalb gehört zur Rolle die fachliche Führung der Entwickler: Reviews mit Begründung statt bloßer Korrektur, Schulungen zu Delta Lake, Historisierung und den Projektstandards, und ein Ansprechpartner für technische Fragen, der Entscheidungen trifft, statt sie zu vertagen.

Stand

Das Projekt läuft. Die Migration wird in Stufen umgesetzt; die Standards sind eingeführt und werden von allen Teilteams genutzt. Fidan Consulting steuert die Plattform weiterhin technisch.