Wie man eine moderne ETRM-Architektur entwirft

Über „moderne ETRM-Architektur“ wird oft so gesprochen, als ginge es um die Wahl der richtigen Einzelplattform. Nach unserer Erfahrung zählt die Plattformwahl weniger als die Frage, wie gut die umgebenden Bausteine - Daten, Integration, Analytics - auf ein Zusammenspiel hin entworfen sind. Eine gut architektierte Umgebung rund um eine ältere Kernplattform schlägt in der Regel eine moderne Plattform, die auf eine fragmentierte Datenlandschaft aufgesetzt wurde.

Vom gesamten Lebenszyklus her denken, nicht nur vom ETRM

Das ETRM selbst deckt typischerweise Trade Capture bis P&L ab. Eine vollständige Architektur muss aber auch berücksichtigen, was davor liegt (Pre-Trade-Daten) und was daneben steht (Logistik, Settlement, Reporting) - und zunehmend eine separate Analytics-Schicht, die ETRM-Daten nutzt, ohne von den Reporting-Werkzeugen des ETRM abhängig zu sein.

Prinzip 1: Transaktionale und analytische Workloads trennen

ETRM-Plattformen sind auf transaktionale Integrität optimiert - die korrekte Erfassung und Verarbeitung von Geschäften -, nicht auf analytische Ad-hoc-Abfragen über Jahre an Historie. Beide Workloads in dasselbe System zu zwingen, führt meist zu einer Plattform, die in beidem mittelmäßig ist. Eine separate Cloud-Datenplattform für Analytics (siehe unsere Leistung ETRM Data Engineering), gespeist aus geplanter Extraktion, löst das, ohne die Produktion zu stören.

Prinzip 2: Eine echte Pre-Trade-Datenschicht aufbauen

Wie unter „Pre-Trade-Daten: die fehlende Schicht“ beschrieben, sollten Markt- und Stammdaten validiert und normalisiert werden, bevor sie das ETRM erreichen - nicht danach. Diese eine Entscheidung verhindert einen großen Teil der datenqualitätsbedingten P&L- und Risikoprobleme, die sonst erst nachgelagert auffallen.

Prinzip 3: Integration als Muster entwerfen, nicht als Serie von Einzelfällen

Jede neue Anbindung - an ERP, Buchhaltung, Risiko, BI - ist einfacher und verlässlicher, wenn sie einem konsistenten Integrationsmuster folgt (API-first, wo möglich, mit klarem dateibasiertem Rückfallweg, wo nicht), statt jedes Mal als maßgeschneidertes Skript zu entstehen. Sobald das Muster steht, lassen sich neue Integrationen zudem erheblich schneller umsetzen.

Prinzip 4: Datenqualität und Abstimmung sichtbar machen, nicht still laufen lassen

Fallback-Logik, der Umgang mit veralteten Daten und Abstimmungsprüfungen sollten für diejenigen sichtbar sein, die sich auf die Zahlen verlassen - und nicht in einer Konfiguration vergraben, an deren Existenz sich niemand erinnert. Ein Dashboard, das den Zustand der Pipeline und markierte Datenprobleme zeigt, ist eine kleine Investition gegenüber den Kosten eines stillen Fehlers, der in einen P&L- oder Risikobericht gelangt.

Prinzip 5: Für die Plattform planen, die Sie tatsächlich betreiben - nicht für die aus der Demo

Architekturentscheidungen sollten die tatsächliche Fähigkeit Ihres Teams berücksichtigen, das System zu betreiben und zu erweitern - Skriptsprache, Anpassungsmodell, betriebliche Komplexität -, nicht nur die theoretischen Möglichkeiten. Die ausgefeilteste Architektur ist nur so gut wie die Fähigkeit des Teams, sie am Laufen zu halten.