Eine Quelle der Wahrheit pro Attribut
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 von 6 im Kapitel Stammdaten und Identität, Kapitel 6 des Kurses Data Architect. Jedes Modul steht für sich. Weiter: Die vier Wege des Stammdatenmanagements
Die Frage, die dieses Modul beantwortet: Was bedeutet „einzige Quelle der Wahrheit“ wirklich?
Es gibt einen Satz, den ich ständig höre: „Wir brauchen eine einzige Quelle der Wahrheit.“ Gut. Wofür? Den Kunden? Das ist nicht genau genug. Nehmen Sie einen Account. Wem gehören der Name des Kunden, die Rechnungsadresse, das Kreditlimit, der Account Executive, die Supportstufe, die Marketingpräferenzen? Diese Antworten zeigen nicht auf dasselbe System. Das ERP kontrolliert vielleicht den rechtlichen Namen, die Rechnungsadresse und den Kreditstatus; Salesforce den Beziehungsverantwortlichen und die Vertriebsattribute; eine andere Plattform die Einwilligung. Wenn mir also jemand sagt „Salesforce ist unsere einzige Quelle der Wahrheit für den Kunden“, lautet meine nächste Frage: Welche Wahrheit?
Die Wahrheit gehört zu einem Attribut
Abschnitt betitelt „Die Wahrheit gehört zu einem Attribut “Das erste Prinzip der Stammdaten lautet: Autorität wird pro Attribut vergeben, nicht pro Datensatz. Ein Account kann in Salesforce leben, ohne dass Salesforce für jedes Feld darauf maßgeblich ist. Sieben Felder auf einem Datensatz, zwei Autoritäten:
| Attribut | Maßgebliches System |
|---|---|
| Rechtlicher Name, Rechnungsadresse, ERP-Kunden-ID, Kreditlimit | ERP |
| Account Executive, Kennzeichen für strategischen Account, Erfolgsstufe | Salesforce |
Ein Datensatz; die Wahrheit ist verteilt. Das ist normal. „Führendes System = Salesforce“ beschreibt es nicht. Ein Autoritätsmodell schon.
Angelegt, bearbeitet, referenziert, und wie schnell?
Abschnitt betitelt „Angelegt, bearbeitet, referenziert, und wie schnell? “Wenn ich Stammdaten unterrichte, komme ich bei jedem wichtigen Datum immer wieder auf dieselben Fragen zurück: Wo wird es angelegt, wo wird es bearbeitet, wo wird es referenziert, und wie hoch ist seine Änderungslatenz? Sie legen die Architektur schnell offen. (Die ersten drei kennen Sie aus Kapitel 4, beim Einordnen der Datenarten; hier leisten sie ihre eigentliche Arbeit.)
Nehmen Sie ein Asset. Ein Kunde bestellt drei Fahrräder. Salesforce hat die Opportunity und ihre Positionen, und der Auftrag geht ans ERP. Das ERP wickelt ihn ab, und dort werden die Assets angelegt: drei Fahrräder, drei Seriennummern, zurückgeschickt an Salesforce. Monate später ruft der Kunde wegen eines davon an, und der Support referenziert das Asset in einem Kundenvorgang. Jetzt muss jemand ein Attribut korrigieren. Welche darf Salesforce bearbeiten, und welche gehören dem ERP, das sie angelegt hat? Und wenn das ERP eines ändert, wie schnell muss Salesforce davon erfahren? Ein Asset, vier Fragen, und die Antworten sind nicht für jedes Feld dieselben.
Angenommen, der rechtliche Name wird im ERP angelegt und in Salesforce referenziert, und jemand aus dem Vertrieb bemerkt, dass er falsch ist. Sollte die Person ihn in Salesforce korrigieren? Wenn das Feld dem ERP gehört, korrigiert das Ändern der Kopie nichts. Im besten Fall überschreibt die nächste Synchronisation sie; im schlimmsten widersprechen sich die beiden Systeme jetzt, und niemand weiß, welchem man trauen soll. Wenn das Geschäft will, dass der Vertrieb die Korrektur anstößt, ist das etwas anderes: Salesforce liefert das Erlebnis, schickt eine Anfrage ans ERP, das ERP nimmt die Änderung vor oder genehmigt sie, und der maßgebliche Wert kommt zurück. Das ist eine ganz andere Architektur, als Salesforce das Feld auf eigene Faust bearbeiten zu lassen.
Auch die Latenz ist Teil der Wahrheit. Das ERP ändert den Kreditstatus eines Kunden um 10 Uhr; Salesforce synchronisiert nachts; um 15 Uhr schaut jemand aus dem Vertrieb in Salesforce. Ist der Wert falsch? Er ist veraltet. Wenn sich der Wert einmal im Jahr ändert und ein Tag Verzögerung nichts kostet, reicht nachts. Wenn er entscheidet, ob Sie heute einen Auftrag über eine Million Dollar annehmen, nicht. Die Autorität sagt, woher die Wahrheit kommt; die Latenz sagt, wie schnell andere erfahren müssen, dass sie sich geändert hat. Zwei getrennte Entscheidungen.
Führendes System, Engagement-System, Referenzsystem
Abschnitt betitelt „Führendes System, Engagement-System, Referenzsystem “Das Vokabular aus Kapitel 4 hilft hier. Ein führendes System pflegt die maßgebliche Version. Ein Engagement-System ist dort, wo Menschen damit arbeiten. Ein Referenzsystem liefert Daten, die ein anderes System nutzt, aber nicht besitzt. Salesforce kann das Engagement-System für die Kundenbeziehung sein, während das ERP das führende System für deren rechtliche und finanzielle Attribute bleibt. Das ist keine Schwäche der Architektur; es ist die Architektur. Der Fehler ist, so zu tun, als müsse ein System alles besitzen, damit das Diagramm einfacher aussieht.
Der hybride Golden Record
Abschnitt betitelt „Der hybride Golden Record “Das ändert, was „Golden Record“ bedeutet. Kapitel 5 hat die Idee beim Fernhalten schlechter Daten eingeführt; hier ist sie das Herzstück des Entwurfs. Die Leute stellen sich einen magischen Datensatz vor, bei dem jedes Feld an einem Ort als Stammdatum geführt wird. Manchmal ist das der Entwurf. Auf Salesforce sehe ich häufiger einen hybriden: ein Teil des Accounts wird woanders geführt und hereinkopiert (rechtlicher Name, ERP-Kundennummer, Rechnungsadresse, Kreditstatus), und ein Teil existiert nur, weil Salesforce ihn braucht (Account Executive, Opportunity-Strategie, Erfolgsstufe, Beziehungsnotizen). Die ERP-Felder kommen herein, damit die Leute sie nutzen können. Die Salesforce-Felder gehen nie zurück, weil sie dem ERP egal sind. Völlig vernünftig, solange alle wissen, welches was ist.
Machen Sie die Autorität sichtbar
Abschnitt betitelt „Machen Sie die Autorität sichtbar “Also mache ich externe Autorität im Schema offensichtlich. Wenn SAP ein Feld kontrolliert, bekommt es ein Präfix: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Es ist dieselbe Idee wie das Präfix erp_ aus Kapitel 4. Verwenden Sie den Namen des Systems, wenn diese Autorität konkret und stabil ist, und ein generisches Präfix, wenn die Bedeutung mehr zählt als der heutige Anbieter. Es geht darum, dass sechs Monate später jemand, der das Modell liest, sehen kann: Das ist nicht einfach ein weiteres Salesforce-Feld; diesen Wert besitzt ein anderes System. Lassen Sie Menschen die Autorität nicht durch Reverse Engineering von Integrationen wiederentdecken.
Bauen Sie eine Autoritätskarte
Abschnitt betitelt „Bauen Sie eine Autoritätskarte “Für wichtige Stammdaten will ich eine Autoritätskarte: für jedes wichtige Attribut, wer es anlegt, wem die geschäftliche Entscheidung gehört, welches System maßgeblich ist und wer oder was es ändern darf. Vier verschiedene Fragen:
| Attribut | Angelegt von | Geschäftlicher Eigentümer | Maßgebliches System | Darf es ändern |
|---|---|---|---|---|
| Rechtlicher Name | Finanzen | Finanzen | ERP | Der Finanzprozess |
| Kreditlimit | Finanzen | Finanzen | ERP | Das Kreditteam |
| Account Executive | Vertriebsbetrieb | Vertrieb | Salesforce | Die Vertriebsleitung |
| Supportstufe | Servicebetrieb | Service | Salesforce | Die Serviceleitung |
| Einwilligung | Der Kunde | Datenschutz | Einwilligungsplattform | Der Kunde, ein genehmigter Prozess |
Beachten Sie, dass geschäftliche Eigentümerschaft und maßgebliches System nicht dasselbe sind. Ein System besitzt keine Richtlinie; Menschen tun es. Das System speichert das Ergebnis und setzt es durch. Das ist wieder Kapitel 5: Eigentümer:innen legen die Richtlinie fest; Architekt:innen setzen sie durch.
Ein Kunde. Viele Attribute. Eine Autorität für jedes.
Die Autorität ändert sich im Lebenszyklus
Abschnitt betitelt „Die Autorität ändert sich im Lebenszyklus “Jemand aus dem Vertrieb trifft einen Interessenten, von dem das ERP nie gehört hat, und legt den Account in Salesforce an. Zu diesem Zeitpunkt ist Salesforce maßgeblich für Name, Adresse, Kontakte und Qualifizierung. Der Interessent wird Kunde; das ERP legt den offiziellen Kunden an und vergibt Kundennummer, rechtlichen Namen, Rechnungsadresse und Kredit. Die Autorität ist gewandert. Salesforce lag vorher nicht falsch; der Lebenszyklus hat sich geändert. Es ist das Muster vorläufig → gesteuert aus Kapitel 5: Vor der Umwandlung gehört Salesforce der Interessent; danach gehören dem ERP die gesteuerten Attribute, und Salesforce gehören weiterhin seine eigenen. „Welchem System gehört der Account?“ ist also eine schwache Frage. Fragen Sie: Welchem System gehört dieses Attribut, an diesem Punkt im Lebenszyklus?
Eine Kopie ist keine Autorität
Abschnitt betitelt „Eine Kopie ist keine Autorität “Wir kopieren ERP-Daten in Salesforce, weil die Leute sie ständig brauchen. Das macht Salesforce zu einer praktischen lokalen Kopie, nicht zum Master, und die Architektur sollte sich entsprechend verhalten: schreibgeschützt für Benutzer, von der Integration aktualisiert, mit ihrer Quelle beschriftet, nur über eine Anfrage geändert, durch Abgleich geprüft, wenn die Kopie abweicht. Die Kopie ist nützlich. Die Autorität ist nicht gewandert.
Vertrauen braucht mehr als einen Wert
Abschnitt betitelt „Vertrauen braucht mehr als einen Wert “„Rechnungsadresse: 123 Main Street.“ Sollten Sie ihr trauen? Ich will Vertrauenssignale: woher sie kam, wann sie zuletzt bestätigt wurde, welches System sie geliefert hat und wer oder was sie zuletzt geändert hat: eine Person, eine Integration, ein Agent? Jetzt sagt das ERP 123 Main Street, Salesforce sagt 125, und eine Partnerdatei sagt „123 Main St., Suite 200“. Welche stimmt? Antworten Sie nicht „Nimm die neueste.“ Vielleicht. Aber „die neueste“ ist selbst eine Regel, die annimmt, dass, wer zuletzt geändert hat, gewinnen sollte. Das kann stimmen, oder schrecklich sein. Modul 3 nimmt sich das vor. Vertrauen kommt aus Autorität und Herkunft, nicht daraus, ein ausgefülltes Feld zu finden.
Steve Trucking: Wessen Wahrheit ist es?
Abschnitt betitelt „Steve Trucking: Wessen Wahrheit ist es? “Ein Handelspartner schickt eine Lieferung, und in dieser einen Transaktion verstecken sich mehrere Wahrheiten. Die Auftragsreferenz des Partners ist die des Partners; Steve Trucking behält sie, um Aktualisierungen zuzuordnen, wird aber nicht ihr Master. Der Lieferstatus (angekommen, geliefert, installiert, eine Ausnahme) ist der von Steve Trucking; der Partner empfängt ihn, aber einen Status zu empfangen macht den Partner nicht maßgeblich dafür, was auf dem Lkw passiert ist. Und der Empfänger ist der Kunde des Partners. Der Partner liefert Name, Adresse, Telefon und Liefernotizen, weil Steve Trucking sie zum Liefern braucht. Das macht Steve Trucking nicht zum Master der Identität dieser Person, und diese Unterscheidung entscheidet den Entwurf des Empfängers am Checkpoint.
Eine Lieferung, zwei Autoritäten.
Wo Daten liegen und wem ihre Wahrheit gehört, sind verschiedene Fragen. Salesforce kann die ERP-Kundennummer halten, ohne sie zu besitzen; Snowflake kann den Lieferstatus halten, ohne sein operativer Master zu sein; eine Customer Data Platform kann Identitäten vereinheitlichen, ohne jedes Attribut zu besitzen. Ein Agent kann alle drei lesen, und das erlaubt dem Agenten ganz sicher nicht zu entscheiden, was wahr ist.
Über die Prüfung hinaus: Was KI ändert. Agenten machen aus der Autorität pro Attribut eine Ausführungsregel. Ein Mensch sieht eine falsche Rechnungsadresse und weiß: „Die kommt aus SAP; ich sollte sie hier nicht ändern.“ Ein Agent, dem gesagt wird „Aktualisiere die Rechnungsadresse des Kunden“, weiß es nicht, wenn wir nicht dafür entwerfen. Er braucht dieselbe Autoritätskarte wie die Architektur: Zugriff auf ein Feld macht dieses Feld nicht zum richtigen Ort zum Schreiben.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Welches System für jedes wichtige Attribut maßgeblich ist, statt eines Systems für einen ganzen Datensatz.
- Wo jedes Attribut angelegt, bearbeitet und referenziert wird und wie schnell seine Änderungen reisen müssen.
- Wer die Richtlinie für jedes Attribut festlegt und welche Menschen, Integrationen oder Agenten es ändern dürfen.
- Wie externe Autorität im Modell sichtbar wird: Namenspräfixe, Berechtigungen, Verhalten der Integration.
- Wie sich die Autorität im Lebenszyklus verschiebt, etwa wenn ein Interessent zu einem vom ERP gesteuerten Kunden wird.
Eine einzige Quelle der Wahrheit heißt nicht eine Org, ein ERP, eine MDM-Plattform oder ein riesiger Datensatz. Sie heißt, dass die Architektur für jede gesteuerte Information sagen kann, wo der maßgebliche Wert ist, und jedes andere System deshalb weiß, wie es sich verhalten soll. Das ist keine einzige Quelle der Wahrheit. Es ist eine Architektur der Wahrheit.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Salesforce Architects, Data 360 Architecture (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.