Gå til innholdet
SteveTechArcSteveTechArc Courses

Kontrollpunkt 1, tegn og forsvar Steve Truckings datadesign

Finnes også 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 · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Original, scenariobasert øvelse. Aldri modellert etter faktiske eksamensspørsmål. Den er skrevet i «slik ville jeg designet det»-stilen: poenget er å gjøre skjønnet ditt synlig, ikke å velge en bokstav. Denne oppgaven avslutter del 1 av kurset Data Architect; min gjennomgang kommer i Kontrollpunkt 1, så prøv selv først.

Scenario

Section titled “Scenario”

Steve Trucking er et selskap for siste-mil-levering. Store detaljhandelspartnere (Retail Partners) selger hvitevarer, TV-er og møbler; Steve Truckings team på to personer leverer dem til detaljhandelspartnernes kunder (mottakerne, Recipients), monterer noen av dem og tar med seg de gamle. Les beskrivelsen av Steve Trucking, avsnitt 1–8. La avsnitt 9 (de sene endringene) ligge; de kommer på slutten av kurset.

Krav

Section titled “Krav ”

Alt i beskrivelsens avsnitt 5 (R1–R15) og avsnitt 6 (S1–S5). De dette kontrollpunktet lener seg mest på:

  • R1. Motta hver detaljhandelspartners manifester i partnerens eget format (SFTP-fil, API, EDI) og gjør dem om til ruter, stopp og linjer uten å taste noe inn på nytt.
  • R3. Hver detaljhandelspartners DC-ledere ser sine egne leveringer, avvik, bilder og reklamasjoner i portalen, og aldri en annen partners.
  • R4. Manifester revideres samme dag; endringer etter ruteplanleggingen må håndteres.
  • S2. En detaljhandelspartner må aldri se en annen partners leveringer, priser, volumer eller mottakere.
  • S3. Mottakerens sporingslenke viser bare den ene leveringen, uten konto, og utløper.
  • S4. Mottakernes adresser, telefonnumre og leveringsnotater er personopplysninger; teamene ser dem bare for sine egne stopp, og bare den dagen.

Begrensninger

Section titled “Begrensninger ”
  • Rundt 3 300 leveringer per arbeidsdag, én million i året, med 30 % vekst per år; rundt 1,6 linjer og åtte statusendringer per levering; fire til fem millioner bilder i året; rundt 200 000 GPS-avlesninger om dagen.
  • Én Salesforce-org i USA, som allerede kjører Service Cloud, Field Service og en partnerportal; MuleSoft er lisensiert; Data 360 er lisensiert, men ikke implementert.
  • Tre detaljhandelspartnere, tre integrasjonsstiler; ni distribusjonssentre.

Din oppgave

Section titled “Din oppgave ”

Tegn og forsvar designet for del 1. Bruk det du har lært i kapittel 1–6:

  1. Landskapet (kapittel 4): tegn Steve Truckings systemlandskap slik det er i dag, i Steves oppsett, med hver pil merket med hva som flyttes og hvordan.
  2. Modellen (kapittel 2): modeller leveringsdomenet konseptuelt, deretter logisk. Detaljhandelspartnere, distribusjonssentre, manifester, leveringer, linjer, ruter, lastebiler, team, monteringssjekklister, bilder, signaturer, avvik og mottakere. (Oppgave D1.)
  3. Det fysiske designet (kapittel 3): hvilke av disse er standardobjekter (Field Service har arbeidsordrer, serviceavtaler, serviceressurser og serviceområder), og hvilke er egendefinerte? Hvilke lisenser trenger partnerbrukerne og mottakerne? Hvor bor hver type data: i orgen, utenfor core, i datavarehuset?
  4. Nøkkelen (dette kapitlet): hvilken nøkkel matcher en detaljhandelspartners ordrelinje med leveringen din, og hva skjer når manifestet revideres etter ruteplanleggingen? (Oppgave D3.)
  5. Mottakeren (dette kapitlet): en kontakt (Contact), en personkonto, eller ingen av delene? Argumenter ut fra relasjonen, volumet, isolasjonen mellom partnerne og datanes livssyklus.
  6. Samle eller ikke (dette kapitlet): mottakere dukker opp i manifestene til flere partnere, noen ganger mer enn én gang i året. Ville du samlet dem, eller bevisst latt være? Hva er risikoen, gitt S2? (Oppgave DC1, uten de sene endringene.)
  7. Autoritet: for fem nøkkelfelt (partnerens ordrereferanse, leveringsstatusen, mottakerens telefonnummer, leveringsvinduet, partnerens juridiske navn), si hvem som oppretter det, hvem som eier det, hvilket system som er autoritativt, og hvem som kan endre det.

Skriv hver beslutning som begge alternativene, og så ditt valg: «etter min faglige vurdering …»

Diskusjon

Section titled “Diskusjon ”

Min gjennomgang er Kontrollpunkt 1: Steve Trucking, slik ville jeg designet det. Sammenlign resonnementet ditt, ikke bare boksene dine. Der du valgte annerledes, kan du si hva du ville vunnet og hva du ville gitt opp?

Designgjennomgang

Section titled “Designgjennomgang ”

Hold på designet ditt inntil videre. Del 2 tester det mot volum, spørringer, integrasjon, migrering, transaksjoner og sikkerhet, og gjennomgangskortet i kapittel 18 sjekker det i år tre.

Eksamensmål som øves

Section titled “Eksamensmål som øves ”
  • DM-1, DM-2 (design av datamodellen; modellen respekterer delingen)
  • MDM-1, MDM-2, MDM-3, MDM-4 (mastring, autoritet, matching, sporbarhet)
  • SDM-1 (lisenser), SDM-3 (én samlet visning, og når du ikke skal bygge en)