Wie JPMorgan Chase Data Contracts über 50+ Domains hinweg aufgebaut hat

Anfang der 2020er Jahre arbeitete JPMorgan Chase mit über 50 unterschiedlichen Data Domains, jede von einem eigenen Geschäftsbereich verantwortet: Retail Banking, Investment Banking, Asset Management, Treasury Services und weitere. Die Data-Engineering-Teams des Hauses stellten regelmäßig fest, dass dasselbe Feld, etwa „Customer Risk Rating“, je nach produzierender Domain andere Definitionen, Aktualisierungsintervalle und Lineage-Dokumentation hatte. Die Consumer downstream, ob Risikoanalysten, Compliance-Verantwortliche oder quantitative Trading Desks, hatten keine verlässliche Möglichkeit zu erkennen, ob die gelesenen Daten validiert worden waren, wer sie verantwortete oder welche Transformationen sie durchlaufen hatten. Das ist keine JPMorgan-spezifische Pathologie, sondern der Normalzustand jedes großen Finanzinstituts, das durch Akquisitionen und dezentrale Technologieentscheidungen gewachsen ist. Was den Weg von JPMorgan unterscheidet, ist die bewusste Antwort auf Unternehmensebene, zu der man sich verpflichtet hat.

Was sie getan haben

Die Datenstrategie des Hauses, öffentlich ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen →örtert von der früheren CDO Teresa Heitsenrether und ihren Nachfolgern in verschiedenen Branchenforen, setzte darauf, Daten als Produkt mit expliziten vertraglichen Verpflichtungen zwischen Produzenten und Consumern zu behandeln. Ein Data Contract ist in diesem Kontext also kein Rechtsdokument, sondern eine formale Spezifikation, die SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →, Semantik, Qualitätsschwellen, Verfügbarkeitszusagen auf SLA-Niveau und den namentlich benannten Domain Owner definiert, der für all das verantwortlich ist.

JPMorgan hat das über mehrere konkrete Mechanismen umgesetzt.

Etabliert wurde ein föderiertes Data-Governance-Modell mit einem zentralen Data Management Office, das die Standards setzt, während Domain Stewards innerhalb jedes Geschäftsbereichs die operative Verantwortung tragen. Die CDO-Funktion versuchte nicht, die Datenproduktion zu zentralisieren, sondern standardisierte die Contract-Ebene über der verteilten Ownership. Jedes Domain-Team musste einen Data Contract veröffentlichen, bevor ein Datensatz im internen Datenkatalog des Hauses registriert werden konnte, der Mitte der 2020er Jahre auf einer Kombination aus intern entwickelten Tools und kommerziellen Katalog-Anbietern lief (das Haus hat öffentlich auf Partnerschaften mit Anbietern wie Collibra verwiesen; da Collibra selbst ein kommerzieller Katalog-Anbieter ist, sollten dessen Aussagen zu Adoption und Ergebnissen vor diesem Hintergrund gelesen werden).

Die Contract-Spezifikation selbst verlangte vier Dinge: ein kanonisches Schema mit dokumentierten Definitionen auf Feldebene, Datenqualitätsregeln in Form ausführbarer Tests, einen identifizierten Data ProductData ProductEin Datenbestand, der wie ein Produkt gemanagt wird: mit Owner, definierten Nutzern, garantierter Qualität und messbarem Geschäftswert.Vollständige Definition ansehen → Owner mit namentlicher Vertretung und ein veröffentlichtes SLA zu Aktualität und Verfügbarkeit. Teams, die die SLA-Compliance nicht einhielten, wurden an die Domain-Leitung eskaliert, nicht an ein zentrales Datenteam. Dieses organisatorische Detail ist wichtig. Indem die Verantwortung auf Domain-Ebene statt in einer gemeinsamen Data-Engineering-Funktion lag, vermied JPMorgan das übliche Fehlermuster, bei dem zentrale Teams gleichzeitig zum Bottleneck und zum Sündenbock werden.

Eingeführt wurde außerdem, was interne Dokumentation und Konferenzvorträge als „Data LineageData LineageData Lineage zeigt, wie Daten sich durch Systeme bewegen und dabei transformiert werden, von der Quelle bis zur Nutzung: woher sie kommen, was sie verändert hat und wohin sie gehen.Vollständige Definition ansehen → Attestation“ beschrieben: Domain Owner bestätigen regelmäßig, dass die Abhängigkeiten upstream geprüft wurden und dass Breaking Changes an Quellsystemen einen Prozess zur Neuverhandlung des Contracts auslösen. Damit kam Versionskontroll-Disziplin in Data Pipelines, die sich vorher ohne Ankündigung an die Teams downstream verändert hatten.

Die Rolle der Incentives

Eine strukturelle Entscheidung, die das zum Laufen brachte, war die Verknüpfung der Data-Contract-Compliance mit den Kriterien der Leistungsbeurteilung für Domain Data Stewards. Erwähnt wird das im Kontext des breiteren Data-Literacy-Programms von JPMorgan, in dem das Haus nach eigenen Angaben bis 2023 zehntausende Mitarbeitende in Datenkompetenz geschult hatte, eine Zahl aus der öffentlichen Kommunikation des Hauses selbst, die daher als Richtwert und nicht als unabhängig geprüft zu behandeln ist. Der Punkt ist: Contract Ownership wurde zu einer Aufgabe mit Konsequenzen, nicht zu einer Best Practice in einem Wiki, das niemand liest.

Die Ergebnisse

Genaue operative Kennzahlen aus dem internen Data-Contract-Rollout von JPMorgan sind nicht öffentlich, und konkrete Zahlen, die aus Vendor-Case-Studies zirkulieren, sollten entsprechend behandelt werden. Was über Regulierungsberichte, Earnings Calls und Konferenzvorträge dokumentiert ist:

Das Haus verweist durchgängig auf kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ürzere Bearbeitungszeiten bei datenbezogenen Incidents als ein Ergebnis klarerer Ownership-Strukturen. Wenn ein Datenqualitätsproblem auftritt, benennt der Contract sofort den Owner, was die Triage-Phase in dokumentierten internen Reviews von Tagen auf Stunden verkürzt.

Die Arbeit an der regulatorischen Compliance hat messbar profitiert. JPMorgan steht unter intensiver Beobachtung durch OCC, Federal Reserve und internationale Aufsichtsbehörden, die von Instituten zunehmend den Nachweis von Data Lineage für Risikomodelle verlangen. Auditoren auf einen Contract verweisen zu können, der Herkunft, Transformationslogik und aktuelle Ownership dokumentiert, hat den manuellen Aufwand bei regulatorischen Datenanfragen reduziert. Eine präzise Zahl zu eingesparten Stunden hat das Haus dazu nicht veröffentlicht, und jeder Anbieter, der das im Namen von JPMorgan quantifiziert, ist skeptisch zu lesen.

Die domänenübergreifende Wiederverwendung von Daten hat zugenommen. Teams, die vorher ähnliche Datensätze eigenständig neu aufgebaut hatten, weil sie einer bestehenden Quelle nicht vertrauen konnten, nutzen inzwischen eher zertifizierte Datenprodukte. Das reduziert doppelte Engineering-Arbeit, auch wenn das Haus keine Baseline zu den Kosten der Duplizierung veröffentlicht hat, an der sich die Verbesserung messen ließe.

Was übertragbar ist

Der Fall JPMorgan ist gerade deshalb instruktiv, weil diese Größenordnung keine Voraussetzung für den Ansatz ist. Die Kernlogik überträgt sich auf jede Organisation mit mehr als drei oder vier datenproduzierenden Domains.

Das erste übertragbare Prinzip ist die Trennung von Governance-Standards und Datenproduktion. Ein zentrales CDO-Office, das beides besitzen will, scheitert an einem von beiden oder an beiden. Die Contract-Ebene ist der richtige Ort für zentrale Autorität, die Produktion bleibt föderiert.

Das zweite: Ownership muss namentlich und individuell sein, nicht einem Team oder einem System zugewiesen. Teams rotieren, Systeme werden umbenannt, aber eine benannte Person mit benannter Vertretung schafft einen belastbaren Verantwortungsfaden.

Drittens brauchen Contracts Zähne. Bei JPMorgan war Compliance an das Performance Management gekoppelt. In kleineren Organisationen ohne diesen HR-Hebel kann das Äquivalent darin bestehen, die Registrierung eines Datensatzes im Katalog zu blockieren, solange kein gültiger Contract existiert, oder einen unterzeichneten Contract zu verlangen, bevor ein Datensatz in einem regulierten Prozess genutzt werden darf.

Wo der Kontext abweicht: Das regulatorische Umfeld von JPMorgan erzeugte externen Druck, der die interne Adoption beschleunigt hat. Fehlt Ihrer Organisation diese externe Zwangsfunktion, dauert die Change-Management-Arbeit länger und braucht mehr sichtbare Unterstützung aus der Führungsebene. Organisationen in weniger regulierten Branchen haben zudem mehr Freiheit bei der Definition des Contract-Scope, was ein Vorteil sein kann oder eine Ausrede, zu unpräzise zu spezifizieren.

Der praktische Startpunkt für einen CDO ist nicht, Contracts in allen Domains gleichzeitig vorzuschreiben. Der Rollout bei JPMorgan lief in Phasen und begann mit den Datensätzen mit dem höchsten Risiko und der stärksten Nutzung. Identifizieren Sie die fünf Datensätze, die downstream den größten Schmerz verursachen, wenn sie brechen, versehen Sie zuerst diese mit Contracts, und nutzen Sie die frühen Erfolge, um organisatorische Muskeln aufzubauen, bevor Sie skalieren.

Data Contracts beseitigen keine Datenqualitätsprobleme. Sie schaffen eine klare Verantwortungsstruktur, damit Probleme schneller sichtbar werden und Streitigkeiten über Ownership kürzer ausfallen. Das ist eine relevante operative Verbesserung, und es ist die richtige Rahmung, wenn Sie intern den Business Case aufbauen.