Zum Inhalt springen

Checkpoint 1, den Datenentwurf von Steve Trucking zeichnen und verteidigen

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)

Eine eigene, szenariobasierte Übung. Nie echten Prüfungsfragen nachgebildet. Sie ist im Stil „Was ich entwerfen würde“ geschrieben: Es geht darum, Ihr Urteil sichtbar zu machen, nicht darum, einen Buchstaben anzukreuzen. Diese Herausforderung schließt Teil 1 des Kurses Data Architect ab; mein Durchgang kommt in Checkpoint 1, also versuchen Sie es zuerst selbst.

Steve Trucking ist ein Lieferunternehmen für die letzte Meile. Große Handelsketten (Handelspartner) verkaufen Haushaltsgeräte, Fernseher und Möbel; die Zwei-Personen-Crews von Steve Trucking liefern sie an die Kunden der Handelspartner (die Empfänger), installieren manche davon und nehmen die alten mit. Lesen Sie den Steckbrief von Steve Trucking (auf Englisch), Abschnitte 1 bis 8. Lassen Sie Abschnitt 9 (die späten Änderungen) außen vor; die kommen am Ende des Kurses.

Alles aus Abschnitt 5 des Steckbriefs (R1–R15) und Abschnitt 6 (S1–S5). Die, auf die sich dieser Checkpoint am meisten stützt:

  • R1. Die Ladelisten jedes Handelspartners in seinem eigenen Format empfangen (SFTP-Datei, API, EDI) und ohne Abtippen in Touren, Stopps und Positionen verwandeln.
  • R3. Die Leitungen der Verteilzentren jedes Handelspartners sehen im Portal ihre eigenen Lieferungen, Ausnahmen, Fotos und Reklamationen, und nie die eines anderen Partners.
  • R4. Ladelisten werden am Tag selbst geändert; Änderungen nach der Tourenplanung müssen behandelt werden.
  • S2. Ein Handelspartner darf nie die Lieferungen, Preise, Volumen oder Empfänger eines anderen Partners sehen.
  • S3. Der Sendungsverfolgungslink des Empfängers zeigt nur diese eine Lieferung, ohne Konto, und läuft ab.
  • S4. Adressen, Telefonnummern und Liefernotizen der Empfänger sind personenbezogene Daten; Crews sehen sie nur für ihre eigenen Stopps, nur am Tag selbst.
  • Etwa 3.300 Lieferungen pro Arbeitstag, eine Million im Jahr, mit 30 % Wachstum pro Jahr; etwa 1,6 Positionen und acht Statusänderungen pro Lieferung; vier bis fünf Millionen Fotos im Jahr; etwa 200.000 GPS-Messwerte am Tag.
  • Eine Salesforce-Org in den USA, die bereits Service Cloud, Field Service und ein Partnerportal betreibt; MuleSoft lizenziert; Data 360 lizenziert, aber nicht eingeführt.
  • Drei Handelspartner, drei Integrationsstile; neun Verteilzentren.

Zeichnen und verteidigen Sie den Entwurf von Teil 1. Nutzen Sie, was Sie in den Kapiteln 1 bis 6 gelernt haben:

  1. Die Landschaft (Kapitel 4): Zeichnen Sie die Systemlandschaft des Ist-Zustands von Steve Trucking in Steves Layout, jeden Pfeil beschriftet mit dem, was sich bewegt und wie.
  2. Das Modell (Kapitel 2): Modellieren Sie den Bereich Lieferungen konzeptionell, dann logisch. Handelspartner, Verteilzentren, Ladelisten, Lieferungen, Positionen, Touren, Lkw, Crews, Installations-Checklisten, Fotos, Unterschriften, Ausnahmen und Empfänger. (Herausforderung D1.)
  3. Der physische Entwurf (Kapitel 3): Welche davon sind Standardobjekte (Field Service hat Arbeitsaufträge, Serviceeinsätze, Serviceressourcen und Servicegebiete) und welche benutzerdefiniert? Welche Lizenzen brauchen die Partnerbenutzer und die Empfänger? Wo liegt jede Art von Daten: in der Org, außerhalb des Core, im Data Warehouse?
  4. Der Schlüssel (dieses Kapitel): Welcher Schlüssel ordnet die Auftragszeile eines Handelspartners Ihrer Lieferung zu, und was passiert, wenn die Ladeliste nach der Tourenplanung geändert wird? (Herausforderung D3.)
  5. Der Empfänger (dieses Kapitel): ein Kontakt, ein Personenaccount oder keins von beiden? Argumentieren Sie aus der Beziehung, dem Volumen, der Trennung der Partner und dem Lebenszyklus der Daten.
  6. Vereinheitlichen oder nicht (dieses Kapitel): Empfänger erscheinen in den Ladelisten mehrerer Partner, manchmal mehr als einmal im Jahr. Würden Sie sie vereinheitlichen, oder bewusst nicht? Was ist das Risiko, angesichts von S2? (Herausforderung DC1, ohne die späten Änderungen.)
  7. Autorität: Sagen Sie für fünf wichtige Felder (die Auftragsreferenz des Partners, den Lieferstatus, die Telefonnummer des Empfängers, das Lieferfenster, den rechtlichen Namen des Partners), wer es anlegt, wem es gehört, welches System maßgeblich ist und wer es ändern darf.

Schreiben Sie jede Entscheidung mit beiden Optionen auf, dann Ihre Wahl: „Nach meiner fachlichen Einschätzung …“

Mein Durchgang ist Checkpoint 1: Steve Trucking, was ich entwerfen würde. Vergleichen Sie Ihre Begründung, nicht nur Ihre Kästen. Wo Sie anders gewählt haben: Können Sie sagen, was Sie gewinnen und was Sie aufgeben würden?

Behalten Sie Ihren Entwurf vorerst. Teil 2 prüft ihn gegen Volumen, Abfragen, Integration, Migration, Transaktionen und Sicherheit, und die Prüfkarte in Kapitel 18 kontrolliert ihn im dritten Jahr.

  • DM-1, DM-2 (Entwurf des Datenmodells; das Modell respektiert die Freigabe)
  • MDM-1, MDM-2, MDM-3, MDM-4 (Stammdatenmanagement, Autorität, Abgleich, Nachverfolgbarkeit)
  • SDM-1 (Lizenzen), SDM-3 (eine einheitliche Sicht, und wann man keine baut)