Von Legacy C# und SAS zum modernen Python-Open-Source-Stack
Case Study: Dreijährige digitale Transformation eines quantitativen Asset Managers
Ausgangssituation
Ein quantitativer Asset Manager mit 140 Mitarbeitenden lebte von seinen datengetriebenen Anlageentscheidungen. Die Qualität der quantitativen Analysen war der zentrale Wettbewerbsvorteil — und genau hier geriet die Organisation an ihre Grenzen.
Die IT-Landschaft war über 15 Jahre organisch gewachsen. Application Development arbeitete in C#, der Research-Bereich setzte auf SAS und SQL. Zwischen diesen Welten existierte eine Sprachbarriere: Prototypen aus dem Research konnten nicht direkt in produktive Anwendungen überführt werden, jede Übergabe erforderte aufwändige Übersetzungsarbeit. Projekte dauerten lang, Anforderungen stauten sich, und das Tempo der Umsetzung hielt nicht mehr mit den Anforderungen des Marktes Schritt.
Gleichzeitig erzeugte die ESG-Regulierungswelle im Finanzsektor massiven Druck. Asset Manager mussten ESG-Daten schneller, transparenter und nachvollziehbarer in ihre Anlageentscheidungen integrieren. Mit dem bestehenden Legacy-Stack war das nicht leistbar.
Proprietäre Reporting-Tools wie Crystal Reports stießen an ihre Grenzen: schwer wartbar, langsam, und der Fachbereich war vollständig abhängig von der IT-Abteilung für jede Anpassung.
Herausforderung
Die Herausforderung war nicht nur technisch, sondern vor allem organisatorisch. Drei fundamentale Probleme mussten gleichzeitig gelöst werden:
Die Sprachbarriere zwischen Abteilungen
Research, Portfolio Management und Application Development arbeiteten mit unterschiedlichen Technologien und konnten kaum gemeinsam an Projekten arbeiten. Was Research als Prototyp entwickelte, musste von Application Development komplett neu implementiert werden.
Die Geschwindigkeit
Neue Releases wurden alle drei Monate ausgerollt — ein Rhythmus, der weder dem Innovationsdruck noch den wachsenden regulatorischen Anforderungen gerecht wurde. Bugfixes und kleine Anpassungen mussten warten, bis das nächste große Release anstand.
Die Befähigung der Wissensarbeiter
Portfolio Manager und Quants wollten eigene Analysen fahren, Hypothesen schnell validieren, neue Datenquellen erschließen — doch die vorhandenen Tools erlaubten das nicht ohne IT-Unterstützung.
Lösungsansatz
Die Lösung war eine konsequente Vereinheitlichung auf Python und den Open-Source-Stack für Data Analytics und KI. Nicht als rein technische Migration, sondern als organisatorische Transformation, die jeden Bereich und jede Ebene des Unternehmens betraf.
Der Ansatz ruhte auf vier Pfeilern:
Ein zentraler Data Hub
Standardisierte Datenmodelle, Qualitätskontrolle für Input und Output, und ein einheitlicher Zugang zu allen Datenquellen. Statt verstreuter Datenbanken und Ad-hoc-Zugriffe eine zentrale, verlässliche Datenbasis.
Python als gemeinsame Sprache
Research konnte Prototypen bauen, die Application Development direkt weiterentwickeln konnte. Portfolio Manager konnten eigene Analysen erstellen. Alle sprachen dieselbe technische Sprache.
Agile Entwicklungsprozesse
Sprints, User Stories, Unit Tests und vollautomatisierte Dokumentation. Der Wechsel von großen, seltenen Releases zu kleinen, häufigen Deployments.
Systematisches Enablement
Auf allen Ebenen — vom Analysten bis zum Portfolio Manager, vom Junior Developer bis zum Senior Researcher.
Umsetzung
Das Schulungsprogramm
44 Mitarbeitende wurden in vier spezialisierten Kohorten geschult:
Analysten
Einführung in Python und Open-Source-Tools für Number Crunching und Datenanalyse. Der Fokus lag auf Effizienz: Wie komme ich schneller zu den Ergebnissen, die ich für meine tägliche Arbeit brauche?
Researcher
Oft mit starkem mathematischem Hintergrund — lernten, wie sie ihre Forschung und prototypische Anwendungen mit Python im Open-Source-Stack umsetzen. Ein wichtiger Aspekt war das Software Engineering: Wie schreibe ich Code, der nicht nur funktioniert, sondern auch von anderen weiterentwickelt werden kann?
Application Development
Der umfangreichste Track: Umschulung auf Python, Entwicklung stabiler, wartbarer und skalierbarer Softwareanwendungen, inklusive der relevanten Libraries und Frameworks. Der Schwerpunkt lag auf Software Engineering Best Practices, Unit Tests und der Entwicklung für den produktiven Betrieb.
Portfolio Manager
Inhaltlich fokussierter Track: Wie können sie eigene Theorien schnell validieren, Annahmen überprüfen und neue Informationen effizient mit Open-Source-Tools gewinnen? Ziel war nicht, sie zu Entwicklern zu machen, sondern sie zu befähigen, eigenständig mit Daten zu arbeiten.
Architektur und Migration
Die Ablösung proprietärer Tools erfolgte schrittweise. Crystal Reports wurde durch eine Open-Source-Lösung ersetzt, die nicht nur schnellere und bessere Daten lieferte, sondern dem Fachbereich ermöglichte, eigene Report-Vorlagen selbst zu erstellen und anzupassen — ohne Umweg über die IT.
Die Datenmodelle wurden normalisiert und standardisiert. Der zentrale Data Hub übernahm die Rolle als einzige verlässliche Quelle für alle Anwendungen und Analysen.
Ein pragmatisches Beispiel für die Arbeitsweise: Als bei der Entwicklung der neuen Performance Attribution die Testdaten unzureichend waren, stellte das Team schnell fest, dass die strikte Trennung von Entwicklungs- und Produktionsdatenbanken in diesem Fall mehr schadete als nutzte. Read-Only-Zugriff auf die Produktionsdatenbank reichte für die Entwicklung völlig aus und vermied den aufwändigen Synchronisationsprozess. Alle Stakeholder wurden an einen Tisch geholt, das Problem wurde pragmatisch gelöst — und die Entwicklung konnte sofort mit aktuellen, vollständigen Daten weiterarbeiten.
Zusammenarbeit auf allen Ebenen
Die Transformation wurde direkt mit dem CTO und dem Geschäftsführer und Gründer gesteuert. Dieser direkte Draht war entscheidend für schnelle Entscheidungen und klare Priorisierungen. Gleichzeitig war der persönliche Austausch mit Mitarbeitenden auf allen Ebenen in allen Abteilungen ein ständiger Bestandteil der Arbeit.
Nicht alle Teammitglieder konnten die Migration mittragen. In der Application Development mussten einzelne Positionen im 10-köpfigen Team neu besetzt werden — ein schmerzhafter, aber notwendiger Schritt, der offen kommuniziert wurde.
Ergebnisse
Deployment-Frequenz: von 3 Monaten auf 3 Wochen
Neue Applikationen und Updates konnten qualitätsgesichert in einem Bruchteil der bisherigen Zeit ausgerollt werden. Bugfixes und kleine Veränderungen waren innerhalb weniger Tage umgesetzt, getestet und live.
Eine gemeinsame Sprache
Research, Portfolio Management und Application Development arbeiteten erstmals im selben Technologie-Stack. Prototypen aus dem Research konnten direkt weiterentwickelt werden, ohne vollständige Neuimplementierung.
Befähigte Wissensarbeiter
Portfolio Manager validierten eigene Hypothesen selbstständig. Der Fachbereich erstellte und pflegte eigene Report-Vorlagen ohne IT-Abhängigkeit. Analysten arbeiteten effizienter mit modernen Tools.
ESG-Fähigkeit
Die modernisierte Plattform ermöglichte es, ESG-Daten schneller und transparenter in die Anlageentscheidungen zu integrieren — eine Grundvoraussetzung, die mit dem alten Stack nicht erfüllbar gewesen wäre.
Erfolgsfaktoren und Lessons Learned
Migration dauert immer länger als gedacht. Technische Migration ist beherrschbar. Der menschliche Faktor — Gewöhnung, Umlernen, Akzeptanz — braucht mehr Zeit als jeder technische Projektplan vorsieht. In den richtigen Momenten für Geduld und Vertrauen zu sorgen, war eine der wichtigsten Aufgaben.
Persönliche Glaubwürdigkeit ist nicht verhandelbar. In einer Rolle als externer Lead über drei Jahre muss man nicht nur technisch überzeugen, sondern auch als Mensch Vertrauen aufbauen. Die Bereitschaft, auf allen Ebenen direkt zu kommunizieren — vom Geschäftsführer bis zum Junior Developer — war entscheidend.
Pragmatismus schlägt Prozess. Etablierte Trennungen und Prozesse zu hinterfragen — wie beim Read-Only-Zugriff auf Produktionsdaten — spart nicht nur Zeit, sondern signalisiert dem Team: Wir lösen Probleme, statt Prozesse zu verwalten.
Manche Veränderungen erfordern personelle Konsequenzen. Nicht alle Mitarbeitenden können oder wollen eine fundamentale technologische Transformation mittragen. Das offen zu kommunizieren und frühzeitig zu handeln, ist fairer als eine schleichende Überforderung.
Standardisierung ist der Schlüssel. Eine gemeinsame Programmiersprache, standardisierte Datenmodelle, einheitliche Entwicklungsprozesse — diese scheinbar langweiligen Entscheidungen ermöglichen erst die Geschwindigkeit und Flexibilität, die eine Organisation braucht.
Was Infrastruktur mit Investmentergebnissen zu tun hat
Quantitative Strategien sind nur so gut wie ihre Datenbasis. Wer auf fehlerhafte Inputs modelliert, bekommt zuverlässig falsche Outputs — unabhängig von der Qualität der Algorithmen.
Der eigentliche Wert dieser Transformation war nicht der schnellere Deploy-Zyklus. Es war die Rückkehr zur Kernfrage: Was ist unsere eigentliche Quelle von Urteilsvermögen — und ist unsere Infrastruktur diesem Anspruch gewachsen?
Die Migration auf den Python-Stack hat nicht nur unsere technische Basis modernisiert — sie hat die Art verändert, wie unsere Abteilungen zusammenarbeiten. Dass Research und Development heute dieselbe Sprache sprechen, hat unsere Innovationsgeschwindigkeit fundamental verändert.
— Chief Technology Officer
Diese Case Study beschreibt ein anonymisiertes Kundenprojekt. Branche und Unternehmenskontext sind korrekt wiedergegeben, identifizierende Details wurden verändert.