MDM oder einfach Entity Resolution? 5 Fragen vor der Entscheidung 2026

Kurzfassung: Master Data Management (MDM) verwaltet einen einzigen vertrauenswürdigen Datensatz mit klaren Governance-Prozessen. Entity Resolution entscheidet, welche eingehenden Datensätze dieselbe reale Entität beschreiben. Die meisten Teams brauchen beides, nicht das eine anstelle des anderen. Diese fünf Fragen entscheiden 2026, ob Sie eine bestehende MDM-Plattform erweitern oder durch eine schlankere Resolution-Schicht ersetzen sollten.

Klären Sie, welche Form Ihr Problem tatsächlich hat. Gehen Sie die fünf Fragen mit unserem Team durch oder testen Sie eine Echtzeit-Resolution-Schicht an Ihren eigenen Daten. Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

1. Was unterscheidet eine MDM-Plattform tatsächlich von einer Entity-Resolution-Engine?
2. Frage 1: Brauchen Sie Governance und Stewardship, oder nur einen aufgelösten Datensatz?
3. Frage 2: Darf Ihr Golden Record Stunden alt sein, oder muss er zum Abfragezeitpunkt aktuell sein?
4. Frage 3: Erweitern Sie eine bestehende MDM-Plattform, oder ersetzen Sie sie?
5. Frage 4: Wie viele Entitätsdomänen müssen Sie tatsächlich auflösen?
6. Frage 5: Wo müssen Ihre Daten liegen?
7. Die fünf Fragen als Entscheidungstabelle

Was unterscheidet eine MDM-Plattform tatsächlich von einer Entity-Resolution-Engine?

Master Data Management ist als Kategorie zunächst eine Governance-Disziplin. Informatica bringt es in der eigenen Definition auf den Punkt: MDM „involves creating a single master record for each person, place, or thing in a business, from across internal and external data sources and applications”. Der Datensatz, den diese Disziplin erzeugt, heißt üblicherweise Golden Record, beschrieben als „the essential information upon which a business or organization relies”, und die gesamte Übung „relies heavily on the principles of data governance”.

Entity Resolution ist enger gefasst und sitzt innerhalb dieses Prozesses, nicht daneben. Sie beantwortet eine Frage: Beschreiben zwei Datensätze dieselbe reale Person, Firma oder Sache? AWS beschreibt den eigenen Entity-Resolution-Dienst genauso: Er „helps you match, link, and enhance related records stored across multiple applications, channels, and data stores” und bietet dafür „rule-based matching, machine learning-based matching, and data service provider-led matching” als verfügbare Techniken an.

Setzt man beides zusammen, wird der Zusammenhang klar: Matching ist die Entscheidung, Governance ist das, was passiert, sobald diese Entscheidung getroffen ist. Eine MDM-Plattform ohne Matching-Engine kann nicht funktionieren. Eine Matching-Engine ohne Governance kann trotzdem echten Nutzen stiften, wenn das eigentliche Problem keine Stewardship-Workflows obendrauf braucht.

Wir haben Tilores als den zweiten Baustein gebaut: eine Echtzeit-Entity-Resolution-Schicht, die unter einer bestehenden MDM-Plattform sitzen kann, um deren Golden Records aktuell zu halten, oder die für sich allein steht, wenn eine vollständige Governance-Schicht gar nicht das eigentliche Problem ist. Fünf Fragen entscheiden, welche Form passt.

Frage 1: Brauchen Sie Governance und Stewardship, oder nur einen aufgelösten Datensatz?

Vollständiges MDM rechtfertigt seine Komplexität, wenn ein Unternehmen echte Stewardship braucht: einen benannten Verantwortlichen für Datenqualitätsregeln, einen Freigabe-Workflow, bevor zwei Datensätze zusammengeführt werden, eine Änderungshistorie, die ein Data Steward öffnen und erklären kann, und Survivorship-Logik, die entscheidet, welche Quelle gewinnt, wenn sich zwei Datensätze bei der Adresse eines Kunden widersprechen. Das ist organisatorischer Prozess mindestens so sehr wie Software, und genau deshalb sind an MDM-Einführungen immer auch Fachabteilungen beteiligt, nicht nur ein Entwicklungsteam.

Ein aufgelöster Datensatz dagegen ist das, was ein operatives System tatsächlich konsumiert: eine Entitäts-ID, eine aktuelle Sicht, eingespeist in ein CRM, ein Fraud-Modell oder das Kontextfenster eines KI-Agenten. Wenn niemand in Ihrem Unternehmen Merge-Entscheidungen von Hand prüfen wird und der Datensatz nur korrekt, nicht aber verwaltet sein muss, deckt eine dedizierte Resolution-Schicht die gesamte Anforderung allein ab.

Die meisten regulierten Teams brauchen am Ende beides, an unterschiedlichen Stellen derselben Pipeline: Governance für den Datensatz, den ein Compliance-Verantwortlicher abzeichnet, und eine Resolution-Schicht für die Systeme, die auf diesen Freigabezyklus nicht warten können.

Fünf Fragen zeigen, ob vollständiges MDM, eine fokussierte Resolution-Schicht oder das Zusammenspiel beider Ansätze passt.

Frage 2: Darf Ihr Golden Record Stunden alt sein, oder muss er zum Abfragezeitpunkt aktuell sein?

Fast jede MDM-Plattform baut ihren Golden Record auf einem geplanten Batch-Job, der alle paar Stunden oder über Nacht läuft. Das ist eine bewusste, vernünftige Designentscheidung für einen verwalteten Datensatz: Auch die Stewardship-Prüfung findet nicht in Echtzeit statt, also passt ein Matching im gleichen Takt dazu.

Die Kosten zeigen sich in dem Moment, in dem ein operatives System die Antwort früher braucht als das nächste Batch-Fenster. Ein Kunde zieht um, eine Firma wechselt den Eigentümer, oder ein neues Konto wird eröffnet, und jedes nachgelagerte System bleibt ahnungslos, bis der geplante Job aufholt. Für eine Betrugsprüfung, eine Kreditentscheidung oder einen KI-Agenten, der eine Live-Frage beantwortet, ist dieser Verzug das eigentliche Problem.

Tilores löst Datensätze auf, sobald sie eintreffen, nicht nach Zeitplan: Ein neuer Datensatz wird auf dem verwalteten AWS-Pfad in unter 150 Millisekunden in der aufgelösten Entität sichtbar, selbst gehostet neben der Workload in rund 1 Millisekunde. Wenn Ihr Anwendungsfall einen über Nacht aktualisierten Golden Record verträgt, ist Batch-Matching in MDM keine Schwäche, um die man herumplanen muss. Wenn er das nicht verträgt, ist diese Lücke der gesamte Grund für eine dedizierte Echtzeitschicht, ob Sie Ihre MDM-Plattform behalten oder nicht.

	Batch-Matching innerhalb von MDM	Echtzeit-Resolution-Schicht
Neuer Datensatz sichtbar	Beim nächsten geplanten Lauf	In unter 150 ms (1 ms selbst gehostet)
Beziehungsänderungen	Verpasst bis zum nächsten Job	Sofort erkannt
Regulatorisches Reporting	Momentaufnahme zu einem Zeitpunkt	Aktueller Zustand auf Abruf
Match-Qualität bei unsauberen Daten	Abhängig von konfigurierten Regeln	Normalisiert Namen, Adressen und Telefonformate vor dem Matching

Frage 3: Erweitern Sie eine bestehende MDM-Plattform, oder ersetzen Sie sie?

Das sind tatsächlich unterschiedliche Projekte, und die ehrliche Antwort auf Frage 3 ergibt sich meist aus den Fragen 1 und 2, nicht aus einer Markenvorliebe.

Erweitern ist sinnvoll, wenn die Governance-Schicht bereits funktioniert. Behalten Sie Informatica, Reltio, TIBCO oder welche Plattform auch immer bereits im Einsatz ist, und legen Sie eine Echtzeit-Resolution-Schicht davor, sodass operative Systeme einen lebendigen Golden Record erhalten, während die MDM-Plattform weiterhin Stewardship-Workflows und Compliance-Reporting übernimmt. Nichts an der bestehenden Investition wird verworfen, und das Problem der Batch-Verzögerung verschwindet, ohne das Governance-Modell anzurühren, das eine Compliance-Funktion bereits abgezeichnet hat.

Ersetzen ist sinnvoll für eine engere Gruppe von Teams: Sie bauen von null auf, migrieren von einer Legacy-Plattform, die nicht mehr passt, oder arbeiten in einer einzigen Entitätsdomäne wie Kunden, Gegenparteien oder Lieferanten, wo eine vollständige Multi-Domain-Governance-Suite mehr Plattform ist, als das Problem braucht. In diesem Fall können Entity Resolution, Golden-Record-Aufbau und eine Abfrage-API die Anforderung abdecken, ohne die Kosten oder den Zeitplan einer vollständigen MDM-Einführung, in Tagen auf AWS eingeführt statt in einem mehrmonatigen Rollout.

Keiner der beiden Wege ist der ausgereiftere. Sie beantworten unterschiedlich große Probleme.

Frage 4: Wie viele Entitätsdomänen müssen Sie tatsächlich auflösen?

Ein Einzeldomänen-Problem, also das Auflösen eines Entitätstyps wie Kunden, ist der Fall, in dem eine schlanke Resolution-Schicht am häufigsten die gesamte Anforderung abdeckt. Ein Multi-Domain-Problem, also das Auflösen von Kunden, Lieferanten, Gegenparteien und Produkten innerhalb eines einzigen kohärenten Governance-Modells, ist der Fall, für den vollständiges MDM gebaut wurde.

Es gibt eine dritte Form, die eine eigene Nennung verdient: Multi-Party-Resolution, bei der Identität über Organisationsgrenzen hinweg abgeglichen werden muss, nicht nur zwischen Abteilungen innerhalb eines Unternehmens. Cofinity-X, das Automobil-Datenökosystem, mit dem wir zusammenarbeiten, ist ein praktisches Beispiel. Mehrere Hersteller und Zulieferer pflegen jeweils ihre eigenen Systeme, und keine einzelne MDM-Plattform eines Unternehmens wurde je dafür entworfen, Identität über die Daten aller Beteiligten gleichzeitig aufzulösen. Das ist ein Resolution-Problem, das außerhalb dessen liegt, was die MDM-Einführung einer einzelnen Organisation erreichen kann, egal wie ausgereift sie ist.

Frage 5: Wo müssen Ihre Daten liegen?

Deployment-Vorgaben entscheiden über mehr reale MDM- und Entity-Resolution-Entscheidungen, als die meisten Anbietervergleiche zugeben. Tilores ist standardmäßig AWS-nativ und gleichzeitig infrastrukturunabhängig konzipiert: Der verwaltete Pfad auf AWS ist die einfachste und häufigste Wahl, und dieselbe Matching-Engine läuft ebenso im eigenen AWS-Konto eines Kunden, in einer anderen Cloud oder vollständig On-Premise für Teams, deren Daten den eigenen Perimeter nicht verlassen dürfen. Air-Gapped-Umgebungen werden unterstützt, und der Dienst ist SOC-2-zertifiziert.

Das ist besonders relevant, sobald eine MDM-Plattform bereits an eine bestimmte Cloud oder ein Rechenzentrum gebunden ist. Eine Resolution-Schicht, die dort laufen muss, wo diese Daten bereits liegen, ist etwas anderes als eine, die nur als externer SaaS-Aufruf funktioniert, und es lohnt sich, das vor der Wahl eines der beiden Wege zu klären, nicht erst nachdem ein Proof of Concept bereits einen Cloud-Standort vorausgesetzt hat, den Ihre Daten nicht nutzen dürfen.

Die fünf Fragen als Entscheidungstabelle

Keine der fünf Fragen entscheidet für sich allein etwas. Zusammen gelesen, weisen sie auf eine von drei Formen hin: eine bestehende MDM-Plattform erweitern, sie durch eine schlankere Resolution-Schicht ersetzen, oder zu dem Schluss kommen, dass vollständiges MDM tatsächlich der richtige Umfang ist.

Frage	Spricht für vollständiges MDM	Spricht für eine Resolution-Schicht
1. Governance-Bedarf	Stewardship-Workflows, manuelle Merge-Prüfung, Audit-Trail in Verantwortung einer Fachabteilung	Ein automatisierter, korrekter Datensatz reicht aus
2. Aktualitätsbedarf	Ein über Nacht oder stündlich aktualisierter Golden Record ist akzeptabel	Operative Systeme brauchen den aktuellen Zustand zum Abfragezeitpunkt
3. Bestehende Plattform	Governance-Schicht funktioniert bereits und soll bleiben	Neuaufbau, oder Migration von einer Legacy-Plattform
4. Entitätsdomänen	Mehrere verwaltete Domänen, oder Resolution über Organisationsgrenzen hinweg nötig	Eine Entitätsdomäne, ein klarer Verantwortlicher
5. Deployment-Vorgabe	Plattform passt bereits zur erforderlichen Umgebung	Muss in einer bestimmten Cloud, Region oder On-Premise laufen

Ein Team, das überwiegend in der linken Spalte landet, hat ein Governance-Problem, und vollständiges MDM ist der richtige Umfang. Ein Team, das überwiegend in der rechten Spalte landet, hat ein Matching- und Aktualitätsproblem, und eine dedizierte Resolution-Schicht beantwortet das, ohne den Overhead einer Governance-Suite, die es noch nicht braucht.

FAQ

Kann ich Entity Resolution ohne eine vollständige MDM-Plattform betreiben?

Ja, für eine einzelne Entitätsdomäne ohne Stewardship-Anforderung. Eine dedizierte Resolution-Schicht deckt Matching, Deduplizierung und den Aufbau von Golden Records über eine Abfrage-API ab, ohne die Governance-Workflows, die eine vollständige MDM-Einführung mitbringt.

Bedeutet eine zusätzliche Resolution-Schicht, dass wir unsere bestehende MDM-Plattform ersetzen müssen?

Nein. Eine Resolution-Schicht kann vor einer bestehenden Plattform wie Informatica, Reltio oder TIBCO sitzen und ihr einen aktuellen, in Echtzeit gepflegten Golden Record liefern, während die Plattform weiterhin Stewardship, Survivorship und Compliance-Reporting übernimmt.

Warum betreiben MDM-Plattformen Entity Resolution als Batch-Prozess?

Die meisten MDM-Plattformen bauen ihren Golden Record auf einem geplanten Job, der alle paar Stunden oder über Nacht läuft, im gleichen Takt wie die Stewardship- und Governance-Prüfung, die ohnehin in einem ähnlichen Rhythmus stattfindet. Der Nachteil ist ein Golden Record, der nur so aktuell ist wie der letzte Lauf.

Wie groß ist der praktische Geschwindigkeitsunterschied zwischen Batch- und Echtzeit-Matching?

Ein Batch-Job zeigt einen neuen oder geänderten Datensatz erst beim nächsten geplanten Lauf, der Stunden entfernt sein kann. Eine Echtzeit-Resolution-Schicht kann einen neuen Datensatz deutlich unter einer Sekunde in der aufgelösten Entität sichtbar machen, was am meisten für Betrugsprüfungen, Kreditentscheidungen und jeden KI-Agenten zählt, der eine Live-Frage beantwortet.

Wie veranschaulicht Cofinity-X ein Multi-Party-Entity-Resolution-Problem?

Cofinity-X ist ein Automobil-Datenökosystem, in dem mehrere Hersteller und Zulieferer jeweils ihre eigenen Systeme pflegen. Keine einzelne MDM-Plattform eines Unternehmens wurde dafür entworfen, Identität über die Daten aller Beteiligten gleichzeitig aufzulösen, was ein Resolution-Problem ist, das außerhalb dessen liegt, was die Governance-Schicht einer einzelnen Organisation allein erreichen kann.

Quellen

1. What Is Master Data Management?, Informatica, geprüft am 2026-08-26.
2. Master Data Management, Wikipedia, geprüft am 2026-08-26.
3. What Is AWS Entity Resolution?, AWS Entity Resolution Documentation, geprüft am 2026-08-26.
4. Master Data Management: Real-Time Entity Resolution for MDM, Tilores, geprüft am 2026-08-26.
5. Build vs Buy: Entity Resolution, Tilores, geprüft am 2026-08-26.
6. Deployment Options: Run Tilores Where Your Data Is, Tilores, geprüft am 2026-08-26.
7. Pricing, Tilores, geprüft am 2026-08-26.
8. API Reference, Tilores Documentation, geprüft am 2026-08-26.
9. Cofinity-X Selects Tilores as Entity Resolution Provider, Tilores, geprüft am 2026-08-26.