Neue Data Platform für Reporting bei Uniper SE

Ausgangslage

Das zentrale Reporting-Data-Warehouse von Uniper SE basierte auf Oracle und BODS. Nach vielen Jahren organischem Wachstum hatte die Plattform ihr Performance-Limit erreicht: Reports wurden langsamer, Datenvolumen stiegen weiter, und die laufenden Betriebs-, Infrastruktur- und Administrationskosten wuchsen überproportional.

Eine reine Erweiterung der Altplattform war keine realistische Option. Gleichzeitig war das Reporting geschäftskritisch – ein Big-Bang-Wechsel hätte zu Unterbrechungen und Abweichungen geführt, die weder Controlling noch Vorstand akzeptieren würden. Gesucht war ein Weg, die Plattform grundlegend neu aufzustellen, ohne das Tagesgeschäft zu gefährden.

Delivery

Wir haben die Plattformneugestaltung über mehrere parallele Streams koordiniert und eine konsistente Zielarchitektur etabliert, die über alle Teilprojekte hinweg trägt. Die Migration lief inkrementell – mit Parallelbetrieb und kontinuierlicher Qualitätssicherung gegen das Altsystem.

• Scaffolding-First – ein früh aufgesetztes Plattform-Grundgerüst lieferte sofortigen Business Value, während weitere Streams parallel ausgebaut wurden
• Free Zone für die Lieferung – ein organisatorischer Schutzraum mit kurzen Entscheidungswegen und reduzierter Governance-Last sicherte zero friction in der Umsetzung
• ~30% KI-gestützte Code-Generierung – ein relevanter Anteil des Codes entstand mit AI-Coding-Tools, beschleunigt durch Senior-Engineers und nicht durch sie ersetzt
• Parallele Arbeitsströme – Ingestion, Modellierung, Reporting-Migration und Infrastruktur liefen koordiniert, aber nicht seriell
• Konsistente Zielarchitektur – jede Einzelentscheidung in jedem Stream gemessen am übergreifenden Architektur-Zielbild
• Inkrementeller Go-Live – neue Reporting-Strecken gingen produktiv, während Alt-Reports weiter aus Oracle/BODS bedient wurden
• Parallelbetrieb und Abgleich – jede migrierte Datenstrecke wurde business-seitig gegen das Altsystem geprüft, bevor der Altreport abgeschaltet wurde
• ~450 neu entwickelte ETL-Jobs – konsistent strukturiert, getestet und dokumentiert, als Grundlage für stabilen Betrieb nach dem Projekt

Eingesetzte Technologien

Die neue Plattform wurde cloud-nativ auf Microsoft Azure aufgebaut, mit Snowflake als zentrales Data Warehouse für analytisches Reporting. Datenintegration und Orchestrierung laufen über Azure Data Factory; die fachliche Modellierungsschicht ist in dbt umgesetzt – versioniert, getestet und dokumentiert. Die gesamte Cloud-Infrastruktur ist über Terraform als Infrastructure-as-Code beschrieben – reproduzierbar, auditierbar und Grundlage für stabile CI/CD-Strecken.

Ergebnisse

Nach 2,5 Jahren war die neue Datenplattform für das Reporting produktiv. Die Altsystem-Landschaft (Oracle/BODS) konnte abgelöst werden, ohne dass im laufenden Betrieb Brüche entstanden sind. Die neue Plattform ist skalierbar – sowohl technisch als auch organisatorisch: weitere Fachbereiche können anschließen, ohne die Architektur aufzubrechen.

• Performance +84% – Reporting-Pipelines deutlich schneller als auf dem Altsystem
• Monatliche Plattformkosten um ~76% reduziert – durch cloud-native Architektur und Wegfall der Legacy-Lizenzen
• Zero critical incidents – kein einziger kritischer Vorfall im laufenden Betrieb der neuen Plattform
• Sofortiger Business Value durch Scaffolding – erste produktive Strecken gingen lange vor dem finalen Go-Live live

Der business-seitige Abgleich war der entscheidende Qualitätsanker: Keine Reportzahl hat sich durch die Migration in relevanter Weise verändert – und wo doch, wurde gemeinsam mit dem Fachbereich geklärt, welche Version die korrekte ist. Das hat Vertrauen in die neue Plattform aufgebaut, das auch in die Folgeprojekte getragen wird.

Lessons Learned

Eine Plattform-Migration dieser Größenordnung steht und fällt mit der Koordination paralleler Streams gegen ein konsistentes Zielbild. Wer die Streams unabhängig arbeiten lässt, bekommt am Ende ein Flickwerk – wer zu stark zentralisiert, bremst jede einzelne Entscheidung aus.

Die zweite Lektion betrifft den Parallelbetrieb: Er ist teurer und aufwendiger als ein Big Bang. Aber er ist die einzige realistische Option, um in einem reporting-kritischen Umfeld Vertrauen aufzubauen und Abweichungen sauber zu klären. Wer diese Phase zu kurz plant, spart an der falschen Stelle.

Das war eine großartige Zusammenarbeit mit dem Uniper-Team – insbesondere mit Peter Boldt, Surya Ayyagari, Kim Jongen und Bernd Hausmann – sowie unseren Partnerunternehmen. Vielen Dank dafür.