Wie JPMorgan Chase Data Contracts über mehr als 50 Domains aufgebaut hat

Bis 2022 betrieb JPMorgan Chase rund 6.200 Anwendungen, verteilt über mehrere Legacy-Systeme und Cloud-Umgebungen. Die Datenteams der Bank produzierten Reports und analytische Outputs in großem Umfang, aber die zugrunde liegenden Daten waren uneinheitlich definiert, schlecht dokumentiert und zwischen den Geschäftsbereichen häufig umstritten. Ein „Kunde“ im Retail Banking war nicht dieselbe Entität wie ein „Kunde“ im Investment Management. Diese Definitionen abzugleichen kostete Analystenzeit, verzögerte das regulatorische Reporting und brachte erhebliches Risiko in domainübergreifende Datenprodukte. Die Führung der Bank, darunter die damalige CDO Teresa Heitsenrether, räumte öffentlich ein, dass der Weg nach vorn bedeutete, Daten als Produkt zu behandeln: mit expliziten Ownern, definierten Schnittstellen und durchsetzbaren Qualitätszusagen.

Was JPMorgan getan hat

Die Bank führte eine domainorientierte Datenarchitektur ein, weitgehend im Einklang mit den von Zhamak Dehghani formulierten Data-Mesh-Prinzipien. Jede große Geschäftsdomain, darunter Retail Banking, Commercial Banking, Asset Management und Trading, sollte ihre eigenen Datenprodukte deklarieren und pflegen. Der Mechanismus, der das konkret machte, war der Data Contract.

Ein Data Contract funktioniert bei JPMorgan als formale Vereinbarung zwischen dem Team, das einen Datensatz produziert, und jedem Downstream-Team, das ihn konsumiert. Jeder Contract spezifiziert das SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →, inklusive Feldnamen, Typen und Constraints. ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → definiert Erwartungen an die Freshness, also die akzeptable Latenz zwischen Quellereignis und verfügbaren Daten. Er benennt einen Owner, kein Team- oder Abteilungslabel, sondern eine konkrete Person, die für die Gültigkeit des Contracts verantwortlich ist. Und er enthält ein Service-Level-Agreement: was passiert, wenn der Contract verletzt wird, wer informiert wird und in welchem Zeitraum eine Behebung erwartet wird.

Die Umsetzung hatte mehrere nicht triviale Elemente. Erstens baute die Bank ein zentrales Data-Contract-Register auf, aufgesetzt auf interne Tools statt auf ein einzelnes Vendor-Produkt, das jeden aktiven Contract und dessen Compliance-Status katalogisierte. Zweitens wurden bestehende Datensätze nicht stillschweigend übernommen. Die Teams mussten ihre Outputs entweder in Contracts überführen oder abschalten. Drittens wurden Datenqualitätsmetriken direkt an die individuellen Leistungsbeurteilungen der Domain Data OwnerDomain Data OwnerA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → geknüpft, was die Anreizstruktur so veränderte, wie es Richtliniendokumente allein nie tun.

Die Bank richtete außerdem einen domainübergreifenden Data-Governance-Council mit Vertretern aus jeder großen Domain ein. Dieser Council genehmigte nicht jeden Contract, was ein Nadelöhr erzeugt hätte, aber er setzte die Standards, die Contracts erfüllen mussten, schlichtete Streitfälle, wenn Domains sich über gemeinsame Referenzdaten uneinig waren, und pflegte ein Glossar kanonischer Geschäftsbegriffe. Die Glossararbeit war besonders schwierig: Die Definition von „Umsatz“ über dreizehn Produktlinien hinweg zu standardisieren, kostete Monate an Verhandlungen und musste bis auf CFO-Ebene eskaliert werden, bevor sie geklärt war.

Für domainübergreifende Datenprodukte verlangte das Modell, dass produzierende und konsumierende Domain einen Contract gemeinsam unterzeichnen, wobei jede Seite bestimmte Pflichten übernimmt. Der Producer verpflichtet sich auf Schema und Qualitätsstandards. Der Consumer verpflichtet sich, die Daten nicht außerhalb des vereinbarten Scopes zu nutzen, was unter der DSGVO und den US-amerikanischen Bank-Secrecy-Regelwerken, denen die Bank unterliegt, erheblich ins Gewicht fällt.

Die Ergebnisse

Präzise Zahlen aus dem internen Programm von JPMorgan sind nicht in der Detailtiefe öffentlich, die man sich wünschen würde. Aktenkundig ist über Konferenzvorträge und veröffentlichte Interviews mit Heitsenrether und ihrem Team zwischen 2022 und 2024 Folgendes. Die Bank berichtete von einer verkürzten Zeit bis zur Lösung von Datenvorfällen: Domainübergreifende Datenqualitätsprobleme wurden nach Einführung des Contract-Registers messbar schneller erkannt und an den richtigen Owner geleitet. Der Wegfall unklarer Datensatz-Ownership wurde als beitragender Faktor für die Beschleunigung mehrerer regulatorischer Reporting-Workflows genannt.

Ende 2023 hatte JPMorgan aktive Data Contracts, die Datenprodukte in mehr als 50 Domains abdeckten. Die Zahl verwaister Datensätze, also solcher ohne deklarierten Owner und ohne Quality-SLA, sank deutlich in den Domains, die ihre Migration auf das Contract-Modell abgeschlossen hatten. Teams, die zuvor viel Zeit in „Wem gehören diese Daten“-Gespräche gesteckt hatten, berichteten, dass sich diese Gespräche weitgehend von der Recherche zur Durchsetzung verschoben hätten, und das ist eine andere und schneller lösbare Art von Problem.

Eine öffentlich dokumentierte Hürde: Das Data-Contract-Modell löste den kulturellen Widerstand von Domain-Teams nicht automatisch, die Ownership eher als Haftung denn als Befugnis sahen. Mehrere Teams vermieden es zunächst, ihre Datenprodukte zu registrieren, um sich der Verantwortung zu entziehen. Die Bank reagierte darauf, indem nicht registrierte Datenprodukte für die Nutzung in domainübergreifenden Analyseprodukten nicht mehr zugelassen wurden, was einen praktischen Anreiz zur Teilnahme schuf.

Was sich übertragen lässt

Der Fall JPMorgan enthält mehrere Schritte, die sich verallgemeinern lassen, und einige, die von Ressourcen abhängen, die die meisten Organisationen nicht haben.

Die übertragbaren Elemente: Die Einhaltung von Data Contracts an individuelle Leistungsbeurteilungen zu koppeln, ist in jeder Größenordnung replizierbar und der Governance-Mechanismus mit der größten Hebelwirkung im Modell. Ohne ihn werden Data Contracts zur Dokumentationsübung. Konsumierende Teams als benannte Vertragsparteien einzubinden statt nur als informierte Abonnenten verändert ihr Verhalten gegenüber den Daten. Und die Entscheidung, nicht registrierte Daten für die domainübergreifende Nutzung zu sperren, war eine Policy-Entscheidung, keine Technologieentscheidung, und steht jeder Organisation offen, die bereit ist, sie durchzusetzen.

Wo Ihr Kontext wahrscheinlich abweicht: JPMorgan hat eigene Tools gebaut. Sofern Sie keine vergleichbare Engineering-Kapazität haben, werden Sie Vendor-Produkte wie Soda, Atlan oder Monte Carlo prüfen (alles kommerzielle Anbieter, deren Produktpositionierung Sie neben unabhängigen Analystenbewertungen abwägen sollten). Der richtige Startpunkt für die meisten Organisationen ist ein einfaches Contract-Schema in einem gemeinsamen Dokumentensystem, manuell validiert, bevor in Tooling investiert wird. Der Inhalt des Contracts zählt mehr als die Plattform, auf der er liegt.

Das Modell eines domainübergreifenden Governance-Councils erfordert außerdem echtes Sponsoring durch die Geschäftsleitung. Der Streit über die Definition von „Umsatz“ bei JPMorgan wurde gelöst, weil ein CFO eingriff. Wenn Ihr CDO keinen klaren Eskalationsweg zur Leitung der Geschäftsbereiche hat, bleiben semantische Streitfälle auf Arbeitsgruppenebene unbegrenzt hängen.

Noch ein Punkt, den man sich merken sollte: Das Modell von JPMorgan trennt Schema-Ownership von Data StewardshipData StewardshipA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen →. Die Domain besitzt den Contract und ist für die Qualität verantwortlich. Eine separate Stewardship-Funktion berät zu Standards. Beide Rollen zu vermischen, stiftet Verwirrung und verwässert die Verantwortlichkeit.

Beginnen Sie mit zwei oder drei stark genutzten, domainübergreifenden Datensätzen, bei denen unklare Ownership bereits sichtbar Schmerzen verursacht. Schreiben Sie für jeden einen Contract, benennen Sie einen Owner, hängen Sie an einen Verstoß eine Konsequenz und setzen Sie sie durch. Das organisatorische Lernen aus diesen drei Contracts bringt mehr als ein Governance-Framework-Dokument für das gesamte Unternehmen.