Hoppa till innehåll
SteveTechArcSteveTechArc Courses

Kontrollpunkt 1, rita och försvara datadesignen för Steve Trucking

Finns även på 28 språk

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Egen, scenariobaserad övning. Aldrig modellerad efter riktiga provfrågor. Den är skriven i stilen ”Så skulle jag designa det”: poängen är att göra ditt omdöme synligt, inte att välja en bokstav. Den här uppgiften avslutar Del 1 av kursen Data Architect; min genomgång kommer i Kontrollpunkt 1, så försök själv först.

Scenario

Section titled “Scenario”

Steve Trucking är ett företag för leveranser sista milen. Stora detaljhandelspartner (Retail Partners) säljer vitvaror, tv-apparater och möbler; Steve Truckings team på två personer levererar dem till detaljhandelspartnernas kunder (mottagarna, Recipients), installerar en del av dem och forslar bort de gamla. Läs beskrivningen av Steve Trucking, avsnitt 1–8. Lämna avsnitt 9 (de sena ändringarna) i fred; de kommer i slutet av kursen.

Krav

Section titled “Krav ”

Allt i beskrivningens avsnitt 5 (R1–R15) och avsnitt 6 (S1–S5). De som den här kontrollpunkten lutar sig mest mot:

  • R1. Ta emot varje detaljhandelspartners manifest i partnerns eget format (SFTP-fil, API, EDI) och gör om dem till rutter, stopp och rader utan att skriva in något på nytt.
  • R3. Varje detaljhandelspartners DC-chefer ser sina egna leveranser, undantag, foton och reklamationer i portalen, och aldrig en annan partners.
  • R4. Manifest revideras under dagen; ändringar efter ruttplaneringen måste hanteras.
  • S2. En detaljhandelspartner får aldrig se en annan partners leveranser, priser, volymer eller mottagare.
  • S3. Mottagarens spårningslänk visar bara den enda leveransen, utan konto, och slutar gälla.
  • S4. Mottagarnas adresser, telefonnummer och leveransanteckningar är personuppgifter; teamen ser dem bara för sina egna stopp, och bara under dagen.

Begränsningar

Section titled “Begränsningar ”
  • Ungefär 3 300 leveranser per arbetsdag, en miljon per år, med en tillväxt på 30 % per år; ungefär 1,6 rader och åtta statusändringar per leverans; fyra till fem miljoner foton per år; ungefär 200 000 GPS-avläsningar per dag.
  • En Salesforce-org i USA, som redan kör Service Cloud, Field Service och en partnerportal; MuleSoft licensierat; Data 360 licensierat men inte implementerat.
  • Tre detaljhandelspartner, tre integrationsstilar; nio distributionscentraler.

Din uppgift

Section titled “Din uppgift ”

Rita och försvara designen för Del 1. Använd det du har lärt dig i kapitel 1–6:

  1. Landskapet (kapitel 4): rita Steve Truckings systemlandskap i nuläget i Steves layout, med varje pil märkt med vad som flyttas och hur.
  2. Modellen (kapitel 2): modellera leveransdomänen konceptuellt och sedan logiskt. Detaljhandelspartner, distributionscentraler, manifest, leveranser, rader, rutter, lastbilar, team, installationschecklistor, foton, signaturer, undantag och mottagare. (Uppgift D1.)
  3. Den fysiska designen (kapitel 3): vilka av dem är standardobjekt (Field Service har arbetsorder, servicebesök, serviceresurser och serviceterritorier) och vilka är anpassade? Vilka licenser behöver partneranvändarna och mottagarna? Var bor varje typ av data: i orgen, utanför core, i datalagret?
  4. Nyckeln (det här kapitlet): vilken nyckel matchar en detaljhandelspartners orderrad mot din leverans, och vad händer när manifestet revideras efter ruttplaneringen? (Uppgift D3.)
  5. Mottagaren (det här kapitlet): en kontakt (Contact), ett personkonto eller ingetdera? Argumentera utifrån relationen, volymen, isoleringen mellan partner och datas livscykel.
  6. Förena eller inte (det här kapitlet): mottagare förekommer i flera partners manifest, ibland mer än en gång per år. Skulle du förena dem, eller medvetet låta bli? Vad är risken, med tanke på S2? (Uppgift DC1, utan de sena ändringarna.)
  7. Auktoritet: för fem nyckelfält (partnerns orderreferens, leveransstatusen, mottagarens telefonnummer, leveransfönstret, partnerns juridiska namn), ange vem som skapar det, vem som äger det, vilket system som är auktoritativt och vem som får ändra det.

Skriv varje beslut som båda alternativen, och sedan ditt val: ”enligt min professionella bedömning …”

Diskussion

Section titled “Diskussion ”

Min genomgång är Kontrollpunkt 1: Steve Trucking, så skulle jag designa det. Jämför ditt resonemang, inte bara dina rutor. Där du valde annorlunda, kan du säga vad du skulle vinna och vad du skulle ge upp?

Designgranskning

Section titled “Designgranskning ”

Spara din design så länge. Del 2 prövar den mot volym, frågor, integration, migrering, transaktioner och säkerhet, och granskningskortet i kapitel 18 kontrollerar den vid år tre.

Provmål som övas

Section titled “Provmål som övas ”
  • DM-1, DM-2 (design av datamodellen; modellen respekterar delningen)
  • MDM-1, MDM-2, MDM-3, MDM-4 (masterdatahantering, auktoritet, matchning, spårbarhet)
  • SDM-1 (licenser), SDM-3 (en samlad bild, och när du inte ska bygga en)