Die Arten von Unternehmensdaten

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 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)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 2 von 6 im Kapitel Unternehmensdaten verstehen, Kapitel 4 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Salesforce ist ein System unter vielen · Weiter: Die Systeme rund um Salesforce

Die Frage, die dieses Modul beantwortet: Welche Arten von Daten hält ein Unternehmen, und warum gehören sie an verschiedene Orte?

Ein Kundendatensatz. Eine Liste von Ländern. Ein Auftrag. Eine Felddefinition. Fünf Jahre Umsatzsummen. Vier Millionen Lieferfotos. Das sind alles Daten, aber architektonisch sind sie nicht dasselbe. Sie ändern sich anders, wachsen anders, werden anders genutzt und gehören verschiedenen Menschen, und sie sollten nicht automatisch am selben Ort liegen. Wenn also jemand sagt «Wir brauchen diese Daten in Salesforce», lautet meine nächste Frage: Was für Daten sind das? Die Antwort beginnt mir zu sagen, was damit zu tun ist.

Beginnen Sie mit der Art, nicht mit dem Objekt

Als Salesforce-Leute übersetzen wir Anforderungen fast sofort in Strukturen: Kunde, Account; Foto, Datei; Status, Auswahlliste. Das ist irgendwann nützlich. Auf Unternehmensebene will ich zuerst wissen, mit welcher Art von Information ich es zu tun habe. Es gibt viele Arten, sie zu klassifizieren (das DAMA-Wissenskompendium ist die Standardreferenz), und ich finde sechs Arten nützlich: Stammdaten, Referenzdaten, Bewegungsdaten, Metadaten, analytische und unstrukturierte Daten. Die Kategorien sind nicht die Architektur. Sie sind ein Weg, bessere Fragen zu stellen.

Stammdaten: die Dinge, die das Geschäft kennt

Stammdaten beschreiben die dauerhaften Dinge, um die sich ein Geschäft dreht: Kunden, Produkte, Preise, Mitarbeitende, Lieferanten, Standorte, Anlagen. In einer Salesforce-Vertriebs-Org sind das Ihre Accounts und Kontakte, Ihre Produkte und Ihre Preisbücher. Bei Steve Trucking ist ein Handelspartner Stammdaten. Keystone ist kein Ereignis; es ist eine Organisation, mit der Steve Trucking eine dauerhafte Beziehung hat. Die neun Verteilzentren sind ebenfalls Stammdaten.

Stammdaten überleben die Transaktionen, die sie verwenden: Ein Handelspartner kann Millionen von Lieferungen haben. Die erste Frage dazu lautet also immer: Wem gehören sie? Vielleicht nicht Salesforce. Dem ERP gehören vielleicht die Produkte. Salesforce gehören vielleicht die Interessenten, während das ERP massgeblich wird, sobald sie Kunden sind. Einer MDM-Plattform gehört vielleicht die Unternehmensidentität eines Kunden, zusammengesetzt aus mehreren Systemen. Kapitel 6, Stammdaten und Identität, geht in die Tiefe. Für jetzt erkennen Sie die Form.

Referenzdaten: das Vokabular, das das Geschäft teilt

Referenzdaten sind das kontrollierte Vokabular, mit dem andere Daten klassifiziert werden: Ländercodes, Währungen, Produktkategorien, Grundcodes, Status. Die Lieferstatus von Steve Trucking (geplant, verladen, in Zustellung, kurz vor Ankunft, geliefert, installiert, Ausnahme, zurückgegeben) sind Referenzdaten. Sie sind keine Lieferungen; sie sind die Wörter, mit denen Lieferungen beschrieben werden.

Sie sehen klein und harmlos aus, oft eine Auswahlliste mit acht Werten. Verwechseln Sie klein nicht mit unwichtig. Wenn Salesforce Delivered sagt, das ERP Complete und ein Handelspartner D schickt, muss jemand festlegen, was jeder Wert bedeutet und wie sie einander zugeordnet werden. In den Referenzdaten verstecken sich die Annahmen der Integration.

Bewegungsdaten: was passiert ist

Bewegungsdaten halten Aktivität fest: ein aufgegebener Auftrag, eine geleistete Zahlung, eine abgeschlossene Lieferung, ein eröffneter Kundenvorgang. In derselben Vertriebs-Org sind das Angebote und Angebotspositionen, Aufträge und Auftragspositionen, Zahlungen: Jede davon verweist zurück auf einen Kunden und ein Produkt. Die Million Lieferungen pro Jahr von Steve Trucking sind Bewegungsdaten, und ihre Statusaktualisierungen auch: etwa acht pro Lieferung, also acht Millionen Statusänderungen pro Jahr, in einem Unternehmen, das um 30 % pro Jahr wächst.

Das ist eine völlig andere Wachstumskurve als bei Stammdaten. Drei Handelspartner oben; Millionen Zeilen darunter. Hier zählt Steves Anzahl der Nullen: Sie können nicht auf Handelspartner → Lieferung → Status schauen und jedem Kasten dasselbe Gewicht geben. Bei Bewegungsdaten denke ich sofort an Volumen, Geschwindigkeit, Aufbewahrung, Historie, Archivierung, Integration und daran, wie Menschen sie tatsächlich finden müssen. Teil 2 verbringt dort viel Zeit.

Metadaten: Daten über die Daten

Sie arbeiten im ganzen Kurs schon mit Metadaten: die Definition eines Objekts, der Typ eines Felds, seine Beschreibung, seine Beziehungen. Das ganze Unternehmen hat sie: Warehouse-Schemata, Integrationszuordnungen, Datenkataloge, API-Verträge und für jedes Feld einen Eigentümer, eine Sensibilitätsstufe, eine Definition, eine Datenherkunft und eine Aufbewahrungsregel. Die Werte sind Daten; die Beschreibung dessen, was sie bedeuten, sind Metadaten. Wie Kapitel 3 sagte: Flag2__c sagt niemandem etwas, und das zählt mehr, jetzt da KI Metadaten liest, um herauszufinden, was Daten bedeuten.

Analytische Daten: Daten, die wir aus anderen Daten gemacht haben

«Wie hoch ist unsere Pünktlichkeitsquote pro Handelspartner über die letzten fünf Jahre?» ist keine Transaktion. Es ist eine analytische Frage, beantwortet, indem man aus Millionen von Lieferungen neue Daten ableitet: Pünktlichkeitsquote, Schadensquote, Umsatz pro Partner, Installationsqualität, Trends der Crews. Und es ist eine andere Aufgabe. Wer in der Disposition fragt «Was ist der nächste Stopp für Lastwagen 217?», muss nicht fünf Jahre Historie durchsuchen. Die Geschäftsführung, die fünf Jahre Pünktlichkeit nach Region vergleicht, schon. Deshalb leben analytische Daten meist in einem Data Warehouse, einem Lakehouse oder einer Analyseplattform, die für diese Arbeit gebaut ist. Dass Salesforce etwas speichern kann, macht die operative Plattform nicht zum Ort, an dem jede Analyse darauf laufen sollte.

Unstrukturierte Daten: was nicht in Zeilen passt

Dokumente, PDFs, Bilder, Audio, Video, E-Mails, Transkripte, Wissensartikel. Bei Steve Trucking die Lieferfotos: etwa vier pro Lieferung, mehr bei Installationen, vier bis fünf Millionen im Jahr. Ein Foto ist nicht einfach ein weiteres Feld. Es ist gross, es kann das Innere eines Zuhauses zeigen, es hat eigene Aufbewahrungsregeln, und es wird anders durchsucht, wenn überhaupt.

Diese Art zählt jedes Jahr mehr, denn KI kann jetzt Nützliches mit Informationen anfangen, die früher ausserhalb des strukturierten Modells lagen. Ein Transkript ist Daten. Ein PDF-Handbuch ist Daten. Ein Installationsfoto ist Daten. Das heisst nicht, dass es in den Core von Salesforce gehört. Es heisst, dass es in die Landschaft gehört.

Click to enlarge

Sechs Arten, je vier Fragen. Die Antworten ändern sich von Art zu Art, und genau darum geht es.

Die Art ist nur die halbe Frage: die Arbeitslast

Zu wissen, welche Art von Daten wir haben, reicht nicht. Ich will auch wissen, was wir damit tun. Drei Arbeitslasten zählen hier, und wer sie verwechselt, baut schlechte Architektur.

Operativ: das Geschäft betreiben. Die Disposition aktualisiert eine Lieferung, eine Crew schliesst einen Stopp ab, jemand im Service eröffnet einen Kundenvorgang. Viele kleine Lese- und Schreibvorgänge: finde dies, aktualisiere das, zeig mir die Stopps von heute. Das ist OLTP, Online Transaction Processing (Online-Transaktionsverarbeitung), und darin ist Salesforce sehr gut; dort leben Administration und Entwicklung.

Analytisch: das Geschäft verstehen. Jede Lieferung über fünf Jahre, gruppiert nach Partner und Verteilzentrum, im Jahresvergleich, mit den Finanzdaten verknüpft. Jetzt durchsuchen und aggregieren wir. Das ist OLAP, Online Analytical Processing (analytische Online-Verarbeitung), und dafür sind Warehouses, Lakehouses und Analyseplattformen gebaut. Einfach gesagt: Die Org betreibt das Geschäft; Warehouses und Lakes analysieren es. Ein klassischer Fehler ist, diese Arbeitslast auf die operative Plattform zu legen und überrascht zu sein, wenn die Nullen wachsen. Wenn jemand immer wieder riesige Mengen Historie durchsuchen will, behandeln Sie es nicht als «nur einen weiteren Bericht». Fragen Sie, ob es die richtige Plattform ist. Teil 2 kommt darauf zurück in Für Skalierung entwerfen (coming soon) (machen Sie den Core nicht zu Ihrem Warehouse), und Teil 3 zeigt in Beyond Relational (coming soon), wie analytische Strukturen gebaut werden.

Streaming: Daten in Bewegung. Ereignisse, Telemetrie, Statusänderungen, Sensormesswerte. Die Lastwagen von Steve Trucking senden etwa 200’000 GPS-Messwerte am Tag. Die Disposition interessiert, wo Lastwagen 217 jetzt ist. Muss Salesforce jeden minütlichen Messwert jedes Lastwagens behalten? Vielleicht nicht. «Wo ist er jetzt?» und «Wie waren die Trends der Toureneffizienz im letzten Quartal?» kommen aus derselben Quelle und führen zu völlig verschiedenen Speicherentscheidungen.

Wie schnell muss es sich bewegen?

Dann die Latenz. Im Kurs sage ich es so: Echtzeit heisst, an der Tür zu warten, bis jemand zurückkommt. Sie schicken die Person los und bleiben stehen, weil Sie nicht weitermachen können, bis sie zurück ist. Das ist synchron. Nahezu Echtzeit heisst, ihr nachzusehen und mit etwas anderem weiterzumachen; wenn sie kurz darauf zurückkommt, kümmern Sie sich darum. Das ist asynchron. Und dann gibt es Batch: Niemand geht einzeln zur Tür hinaus. Die Daten warten und bewegen sich als Gruppe nach Zeitplan: stündlich, alle paar Stunden oder täglich. Es gibt viele Situationen, in denen Batch genügt, und manche, in denen nicht. Zu wissen, welche welche ist, ist die Aufgabe. Diese drei sind nicht nur Integrationsbegriffe; es sind Architekturentscheidungen.

Nehmen Sie die übliche ERP-Integration. Um 11 Uhr wird im ERP ein neues Produkt angelegt. Muss der Vertrieb es wirklich bis Mittag verkaufen können? Ich habe beide Antworten gehört. Manche Kunden wollen es so schnell wie möglich; andere sagen: Wenn wir Ihnen diese SKU noch nicht geliefert haben, können wir nicht erwarten, dass Sie sie schon verkaufen. Produkte also meist täglich, manchmal schneller. Kunden mindestens täglich; ich habe stündlich gesehen und in Extremfällen nahezu Echtzeit. Aufträge sind anders: Die Abwicklung muss beginnen, also nahezu Echtzeit. Der Vertrieb schliesst das Geschäft ab und macht weiter, und der Auftrag landet in Sekunden bis ein, zwei Minuten im ERP. Es gibt keine einzelne richtige Latenz für «Unternehmensdaten». Fragen Sie, was das Geschäft tatsächlich braucht, und machen Sie nicht alles zu Echtzeit, weil es eindrucksvoll klingt. Echtzeit hat ihren Preis.

Die vier Fragen hinter den Kategorien

Sie müssen nicht herumlaufen und verkünden «Das sind Bewegungsdaten!» Die Klassifizierung ist dazu da, zu jedem wichtigen Datenbestand vier Fragen auszulösen:

• Wem gehören sie? Welches System ist massgeblich? Ich zerlege das in drei Fragen: Wo werden sie angelegt, wo werden sie bearbeitet, und wo werden sie referenziert? Kapitel 6 geht darauf ausführlich ein (Angelegt, bearbeitet, referenziert, und wie schnell?).
• Wie schnell ändern sie sich? Einmal im Jahr, täglich, zehn- bis hundertmal pro Sekunde?
• Wie gross werden sie? Zehn Datensätze, zehntausend, zehn Millionen, zehn Milliarden?
• Was ist ihr Lebenszyklus? Leben sie für immer, werden sie archiviert, müssen sie gelöscht werden, verlieren sie mit der Zeit an Wert?

Diese vier sagen mir weit mehr als «Kann Salesforce das speichern?» Und sie bringen zusammen, was wir schon gelernt haben: Eigentümerschaft, Lebenszyklus, die Anzahl der Nullen, wo Daten liegen.

Ein Geschäft erzeugt jede Art

Bei Steve Trucking ist der Handelspartner Stammdaten; das Statusvokabular Referenzdaten; jede Lieferung ist eine Bewegung; die Definitionen ihrer Felder sind Metadaten; die Pünktlichkeits-Scorecard über fünf Jahre ist analytisch; das Installationsfoto ist unstrukturiert; und der GPS-Strom ist Streaming. All das sind «Daten von Steve Trucking». Nichts davon heisst, dass sie in dieselbe Datenbank gehören. Das ist der Wechsel.

Über die Prüfung hinaus: Was KI ändert. Um eine Frage zu beantworten, braucht ein Agent vielleicht einen strukturierten Kundendatensatz, eine aktuelle Transaktion, ein PDF-Handbuch, ein Servicetranskript und Live-Telemetrie. Unstrukturierte und Streaming-Daten werden zu vollwertigen Teilen der Architektur, auch wenn sie nicht in die CRM-Datenbank gehören, und in der Architektur müssen wir weiterhin wissen, wem jede Quelle gehört, wie aktuell sie ist und ob der Agent ihr vertrauen sollte.

Was Architekt:innen hier entscheiden

• Welche Art von Daten jeder wichtige Datenbestand ist und wem er gehört.
• Ob seine Arbeitslast operativ, analytisch, Streaming oder eine Mischung ist.
• Wie schnell er sich ändert und wie schnell andere Systeme die Änderung wirklich sehen müssen.
• Wie Volumen und Lebenszyklus bestimmen, wo er liegt und wie lange.
• Ob Salesforce ihn besitzen, eine Kopie halten, ihn referenzieren oder ihn an einem Ort lassen sollte, der besser zur Arbeitslast passt.

Wenn Ihnen jemand eine Anforderung gibt, springen Sie nicht zu welchem Objekt, welchem Feld, welcher API. Fragen Sie zuerst, welche Art von Daten es ist, wem sie gehören, wie schnell sie sich ändern, wie gross sie werden, wie lange sie leben und was wir damit vorhaben. Ein Account, ein Lieferereignis, ein Aggregat über fünf Jahre und ein Foto können für dasselbe Geschäft wichtig sein, ohne dasselbe Architekturproblem zu sein.

Weiterlesen

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2. Auflage (2017): die Standardreferenz für Datenkategorien und Datenmanagement.
• Der Steckbrief von Steve Trucking (auf Englisch), Abschnitt 4 (Volumen).