Auf die Substantive hören

🌐 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)

Mit KI erstelltes Bild

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

Modul 1 von 6 im Kapitel Daten nach ihrer Bedeutung modellieren, Kapitel 2 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: die Kapitelübersicht · Weiter: Die Beziehungen zeichnen

Die Frage, die dieses Modul beantwortet: Wie finde ich die Anfänge eines Datenmodells in einem Geschäftsgespräch?

Beim ersten Gespräch mit einem Kunden höre ich unter anderem auf die Substantive.

Ich spreche nicht von der ersten Entwurfssitzung. Ich spreche von dem ersten Gespräch, in dem ich noch versuche, das Geschäft zu verstehen und was es erreichen will.

Sie reden. Ich höre zu.

Und ich höre auf Wörter wie:

Handelspartner. Empfänger. Verteilzentrum. Ladeliste. Lieferung. Tour. Crew. Lkw.

Diese Substantive haben sofort meine Aufmerksamkeit, denn irgendwo in diesem Gespräch stecken die Anfänge meines Datenmodells.

Ich warte nicht, bis ich glaube, das Problem vollständig zu verstehen. Ich beginne die Daten zu sehen, während ich noch zuhöre: Ich höre die Substantive, ich skizziere, wie sie zusammenhängen, und diese Skizze hilft mir, das nächste Gespräch zu gestalten. Manchmal habe ich am Ende eines ersten Treffens mit einem Kunden schon mein eigenes, privates Datenmodell gezeichnet.

Für mich beginnt das mit den Substantiven.

Vergessen Sie Salesforce für einen Moment

Hier sollen Sie einem Reflex widerstehen, der besonders stark ist, wenn Sie schon eine Weile in der Salesforce-Administration arbeiten.

Der Kunde sagt Kunde, und Sie denken:

Account.

Er sagt Person, und Sie denken:

Kontakt.

Er sagt Verteilzentrum, und Sie überlegen schon, ob Sie ein benutzerdefiniertes Objekt brauchen.

Tun Sie das noch nicht.

An diesem Punkt ist mir egal, ob ein Kunde am Ende ein Account, ein Personenaccount, ein benutzerdefiniertes Objekt oder etwas anderes wird. Zuerst will ich das Geschäft verstehen.

Das ist der Unterschied zwischen dem Modellieren des Geschäfts und dem Konfigurieren von Salesforce. Wenn ich mit Salesforce-Objekten beginne, habe ich mein Denken schon auf eine einzige Umsetzung eingeengt. Vielleicht lande ich genau dort, wo ich es erwartet habe, aber ich möchte dort ankommen, weil mich das Geschäft dorthin geführt hat, nicht weil Account und Kontakt die ersten beiden Objekte waren, die ich kannte.

Vergessen Sie also für ein paar Minuten Salesforce. Hören Sie zu, wie die Menschen, die das Geschäft tatsächlich führen, ihre Welt beschreiben.

Sitz, Bleib, Modell

Bevor wir einem Geschäft zuhören, hören wir etwas zu, das alle schon verstehen. Wenn ich das live unterrichte, beginne ich mit Hunden.

Hier ist ein Hund: Marcus ist der Halter von Bella. Maple Ridge Kennels hat sie gezüchtet. Sie ist ein Labrador und kann Sitz, Bleib und Pfote.

Hören Sie auf die Substantive: Marcus, Bella, Maple Ridge Kennels, Labrador, Sitz. Das sind allerdings Namen: die konkreten Dinge. Was ich suche, ist die Art von Ding, zu der jeder Name gehört. Bella ist ein Hund. Marcus ist Halter:in. Maple Ridge Kennels ist Züchter:in. Labrador ist eine Rasse. Sitz ist ein Trick. Fünf Substantive, fünf mögliche Kästen.

Click to enlarge

Dann die Frage, die ich jedem Substantiv stelle: Ist das eine Person, die eine Aufgabe erledigt, oder ein Stück Daten? Marcus ist eine Person. Aber Bellas Halter zu sein ist keine Aufgabe; es ist eine Tatsache über Bella, und früher oder später fragt jemand: „Wem gehört dieser Hund?“ Also gehören Halter:innen ins Modell. Die Person, die Bella Pfote beigebracht hat, erledigt eine Aufgabe und braucht vielleicht nie einen Kasten, es sei denn, das Geschäft fragt irgendwann, wer welchen Trick beigebracht hat.

Und beachten Sie das Wort möglich. Ist die Rasse wirklich ein eigener Kasten oder nur ein Wort, das beim Hund steht? Behalten Sie diese Frage im Kopf; wir beantworten sie beim Normalisieren in Modul 4.

Das ist die ganze Technik, an etwas Kleinem. Jetzt hören wir einem echten Geschäft zu.

Substantive liefern mögliche Entitäten

Hören wir Steve Trucking zu, dem Familienunternehmen, das uns durch diesen Kurs begleitet. Es liefert große Artikel (Kühlschränke, Waschmaschinen, Fernseher) aus den Verteilzentren großer Handelsketten zu den Menschen nach Hause und installiert einige davon.

Im ersten Gespräch hören wir:

• Handelspartner (Retail Partner)
• Empfänger (Recipient)
• Verteilzentrum (Distribution Center)
• Ladeliste (Manifest)
• Lieferung (Delivery)
• Tour (Route)
• Crew
• Lkw (Truck)

Das ist schon nützlich. Ich kann anfangen, Kästen an ein Whiteboard zu zeichnen.

Setzen Sie die Substantive also in Rechtecke. Mehr sind sie an diesem Punkt nicht: Kästen. Keine Linien, keine Farben, nichts, was nach Salesforce aussieht. Später im Kurs bekommen Formen und Farben eine Bedeutung. Für jetzt ist ein Rechteck einfach etwas, worüber das Geschäft spricht.

Dann beginnen Sie, sie anzuordnen. Während Sie jeden Kasten platzieren, sollten Sie an zwei Dinge denken: wie sie zueinander stehen und welche Art von Daten sie sind. Manches sind Kundendaten: die Unternehmen und Menschen, mit denen wir arbeiten. Manches sind Bewegungsdaten, wie Aufträge und Auftragspositionen: die Dinge, die immer wieder geschehen. Und manches sind Referenzdaten, wie die Produkte oder Leistungen, die ein Unternehmen anbietet: die Dinge, von denen die Arbeit abhängt.

Bei Steve Trucking sind der Handelspartner und der Empfänger Kundendaten. Die Ladeliste, die Lieferung und die Tour sind Transaktionen. Das Verteilzentrum, die Crew und der Lkw sind das, wovon die Arbeit abhängt.

Click to enlarge

Aber hier steht ein wichtiges Wort: möglich.

Ein Substantiv ist ein Hinweis. Es ist nicht automatisch eine Entität, und erst recht nicht automatisch ein Salesforce-Objekt.

In einer Discovery-Sitzung schreibe ich jedes Substantiv auf. Bei jedem Substantiv, das fällt, stelle ich mir eine Frage: Ist das eine Person, die eine Aufgabe erledigt, oder ist das ein Stück Daten? Business Development Management ist eine Person, die eine Aufgabe erledigt. Das ist ein Benutzer, eine Rolle, vielleicht ein Berechtigungssatz. Aufträge, Rechnungen, Positionen: Das sind Stücke von Daten. Beides zählt, aber sie landen an sehr unterschiedlichen Stellen im Entwurf, und wenn ich sie früh sortiere, zeichne ich nicht für jede Stellenbezeichnung im Organigramm einen Kasten.

Nun werden einige dieser Substantive Menschen sein. Bei Steve Trucking sind das der Empfänger, der auf den Kühlschrank wartet, die Leute beim Handelspartner, die die Ladeliste schicken, und die Crew: das Fahr- und Montagepersonal auf dem Lkw. Das sind Rollen, und eine Rolle wirkt vielleicht nicht wie Daten. Aber wenn Menschen mit Daten arbeiten oder mit ihnen verbunden sind, müssen sie selbst in den Daten abgebildet werden. Wer hat das geliefert? Wer hat den Empfang quittiert? Wer hat die Ladeliste geschickt? Viele Rollen, manchmal alle, landen also auch im Modell.

Hören Sie zu, wie Steve Trucking spricht, und Ihnen fällt etwas auf. Sie sagen nie einfach „Kunde“. Es gibt zwei Arten von Kunden. Der Handelspartner ist die große Handelskette, für die Steve Trucking liefert: Er schickt die Ladeliste und zahlt pro Lieferung. Der Empfänger ist die Person, zu der der Kühlschrank geliefert wird. Der Empfänger hat ihn im Geschäft gekauft und hat vielleicht nie von Steve Trucking gehört.

Hätte ich einen Kasten namens Kunde gezeichnet, hätte ich zwei völlig verschiedene Dinge vermischt.

Vielleicht ist das Verteilzentrum wichtig genug, um einen eigenen Datensatz, eine eigene Historie, eigene Beziehungen und Attribute zu haben.

Vielleicht stellt sich ein anderes Substantiv als nichts weiter heraus als ein Attribut von etwas anderem.

Das versuchen wir herauszufinden. Wir erstellen noch keine Objekte. Wir bauen unser Verständnis des Geschäfts auf.

Jetzt hören Sie auf die Beziehungen

Die Substantive geben mir einen Ausgangspunkt. Dann höre ich zu, wie das Geschäft sie verbindet.

Ein Handelspartner betreibt Verteilzentren.

Ein Handelspartner schickt für jedes Verteilzentrum und jeden Liefertag eine Ladeliste.

Eine Ladeliste führt Lieferungen auf.

Eine Lieferung geht an einen Empfänger.

Eine Tour ist die Fahrt eines Tages mit etwa zehn Stopps.

Eine Crew aus zwei Personen fährt einen Lkw.

Jetzt passiert etwas. Ich schaue nicht mehr auf eine Liste von Substantiven. Ich beginne, ein Modell zu sehen.

Click to enlarge

Hier tauchen auch die ersten Fragen auf.

Kann ein Handelspartner mehr als ein Verteilzentrum haben?

Ist eine Lieferung dasselbe wie ein Stopp?

Kann ein Stopp an zwei Empfänger liefern?

Besteht eine Crew immer aus denselben zwei Personen?

Interessiert uns, welche Crew letzten Monat welchen Lkw hatte, oder nur, welchen Lkw sie heute fährt?

Beachten Sie, was wir tun. Wir stellen noch keine Salesforce-Fragen. Wir stellen Geschäftsfragen. Und diese Antworten werden am Ende den Salesforce-Entwurf bestimmen.

Ihr erstes Modell muss nicht perfekt sein

Ich erwarte nicht, dass die ersten Kästen, die ich zeichne, unverändert überleben. Ehrlich gesagt wäre ich misstrauisch, wenn sie es täten.

Das erste Modell soll nicht richtig sein. Es soll uns etwas geben, das konkret genug ist, um herauszufinden, wo wir falschliegen.

Setzen Sie Lieferung, Tour, Crew und Lkw an die Tafel, und die Leute können darauf reagieren.

„Eigentlich ist eine Lieferung nicht immer ein Artikel. Es kann eine Waschmaschine, ein Trockner und die Mitnahme der alten Geräte sein.“

Gut. Erzählen Sie mehr.

„Wir weisen eine Crew nicht einer Lieferung zu. Wir weisen die Crew einer Tour zu.“

Sehr gut. Was gehört zur Tour?

„Und wenn installiert wird, kann die Crew den Stopp erst abschließen, wenn die Checkliste und die Fotos erledigt sind.“

Jetzt lernen wir etwas Wichtiges.

Ein Diagramm hat ein vages Gespräch in etwas verwandelt, das wir hinterfragen können. Das ist einer der Gründe, warum ich gern früh modelliere. Ich will den Raum nicht mit einem schönen Diagramm beeindrucken. Ich will schneller lernen.

Das Modell ist Teil des Gesprächs.

Das ist Ihr konzeptionelles Modell

Für das, was wir hier zu bauen begonnen haben, gibt es einen Fachbegriff: ein konzeptionelles Datenmodell.

Auf dieser Ebene interessieren mich die wichtigen Dinge, um die sich das Geschäft kümmert, und wie sie zusammenhängen. Ich mache mir noch keine Gedanken über Standard- oder benutzerdefinierte Objekte, API-Namen von Feldern, Nachschlagen oder Master-Detail, Pflichtfelder, Indizes, Automatisierung, Apex oder Flows. Das alles ist wichtig, und wir kommen dahin. Aber wenn wir es entscheiden, bevor wir verstehen, was wir modellieren, lösen wir zuerst das falsche Problem.

Das konzeptionelle Modell sollte für die Menschen im Raum Sinn ergeben, die Salesforce nicht kennen. Das ist ein nützlicher Test. Wenn ich erklären muss, was Delivery__c bedeutet, bevor die Betriebsleiterin mein Diagramm lesen kann, bin ich zu früh in die Umsetzung gegangen.

Ich möchte, dass sie das Modell ansehen und sagen:

„Ja, so funktioniert unser Geschäft.“

Oder noch besser:

„Nein, so funktioniert es nicht.“

Denn jetzt habe ich etwas zu korrigieren.

Dieselbe Technik funktioniert, wenn niemand spricht

Das nutze ich nicht nur in der Discovery mit Kunden. Es funktioniert auch, wenn der „Kunde“ ein Dokument ist.

Wenn ich ein Anforderungsdokument durcharbeite, tue ich im Wesentlichen dasselbe. Was sind die wichtigen Geschäftskonzepte? Welche Beziehungen werden beschrieben? Was taucht immer wieder auf? Was hat einen eigenen Lebenszyklus, muss für sich identifiziert werden oder braucht eine Historie? Was wird erstellt, geändert, zugewiesen, übertragen, geplant oder außer Betrieb genommen?

Das sind dieselben Dinge, auf die ich im ersten Treffen höre. Auf dem Papier verwandeln diese Hinweise seitenlange Anforderungen in ein Modell, über das ich nachdenken kann, und in bessere Fragen für das nächste Gespräch.

Ein Modell ist nicht nur etwas, das Sie erstellen, nachdem Sie das Problem gelöst haben. Es ist eines der Werkzeuge, mit denen Sie das Problem lösen.

Was Architekt:innen hier entscheiden

Am Ende dieses ersten Durchgangs versuche ich zu entscheiden:

• Welche Substantive sinnvolle mögliche Entitäten darstellen.
• Welche verschiedenen Wörter dasselbe Geschäftskonzept bezeichnen und welches eine Wort zwei verbirgt (wie „Kunde“).
• Welche Konzepte einen eigenen Datensatz und Lebenszyklus brauchen.
• Wie die wichtigsten Konzepte zueinander stehen.
• Welche Fragen das Geschäft beantworten muss, bevor ich sie sicher modellieren kann.

Ich entscheide die Salesforce-Umsetzung noch nicht. Zuerst müssen wir das Geschäft gut genug verstehen, um es zu zeichnen. Und sobald die Substantive an der Tafel stehen, möchte ich als Nächstes die Linien zwischen ihnen verstehen.

Über die Prüfung hinaus: Was KI ändert. Geben Sie einem KI-Werkzeug ein Anforderungsdokument, und es findet in Sekunden die Substantive, schlägt Entitäten vor und skizziert Beziehungen. Nutzen Sie es, um die Discovery zu beschleunigen, aber lagern Sie das Verstehen nicht aus: Es kann nicht wissen, dass „Kunde“ bei Steve Trucking zwei verschiedene Dinge bedeutet, wenn das Geschäft es Ihnen nicht sagt. Legen Sie sein erstes Modell den Menschen vor, die das Geschäft führen, und fragen Sie: „Funktioniert Ihr Geschäft wirklich so?“