Ga naar inhoud

Checkpoint 1, teken en verdedig het dataontwerp van Steve Trucking

Ook beschikbaar in 28 talen

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

Originele oefening op basis van een scenario. Nooit gemodelleerd naar echte examenvragen. Ze is geschreven in de stijl van “hoe ik het zou ontwerpen”: het gaat erom je oordeel zichtbaar te maken, niet om een letter te kiezen. Deze opdracht sluit Deel 1 van de cursus Data Architect af; mijn uitwerking staat in Checkpoint 1, dus probeer het eerst zelf.

Steve Trucking is een bedrijf voor de laatste kilometer. Grote retailpartners verkopen witgoed, tv’s en meubels; de tweemansploegen van Steve Trucking bezorgen ze bij de klanten van de retailpartners (de ontvangers), installeren er een deel van en voeren de oude apparaten af. Lees de briefing van Steve Trucking, secties 1–8. Laat sectie 9 (de late wijzigingen) met rust; die komen aan het eind van de cursus.

Alles in sectie 5 (R1–R15) en sectie 6 (S1–S5) van de briefing. Waar deze checkpoint het meest op leunt:

  • R1. De vrachtlijsten van elke retailpartner in zijn eigen formaat ontvangen (SFTP-bestand, API, EDI) en ze omzetten in routes, stops en regels zonder overtypen.
  • R3. De DC-managers van elke retailpartner zien hun eigen leveringen, uitzonderingen, foto’s en claims in het portaal, en nooit die van een andere partner.
  • R4. Vrachtlijsten worden op de dag zelf herzien; wijzigingen na de routering moeten afgehandeld worden.
  • S2. Een retailpartner mag nooit de leveringen, prijzen, volumes of ontvangers van een andere partner zien.
  • S3. De trackinglink van de ontvanger toont alleen die ene levering, zonder account, en verloopt.
  • S4. Adressen, telefoonnummers en leveringsnotities van ontvangers zijn persoonsgegevens; ploegen zien ze alleen voor hun eigen stops, alleen op die dag.
  • Ongeveer 3.300 leveringen per werkdag, een miljoen per jaar, met 30% groei per jaar; ongeveer 1,6 regels en acht statuswijzigingen per levering; vier tot vijf miljoen foto’s per jaar; ongeveer 200.000 gps-metingen per dag.
  • Eén Salesforce-org in de VS, die al Service Cloud, Field Service en een partnerportaal draait; MuleSoft gelicentieerd; Data 360 gelicentieerd maar niet geïmplementeerd.
  • Drie retailpartners, drie integratiestijlen; negen distributiecentra.

Teken en verdedig het ontwerp van Deel 1. Gebruik wat je in hoofdstuk 1–6 geleerd hebt:

  1. Het landschap (hoofdstuk 4): teken het systeemlandschap van de huidige situatie van Steve Trucking in Steves indeling, elke pijl gelabeld met wat er beweegt en hoe.
  2. Het model (hoofdstuk 2): modelleer het domein van de leveringen conceptueel, en dan logisch. Retailpartners, distributiecentra, vrachtlijsten, leveringen, regels, routes, vrachtwagens, ploegen, installatiechecklists, foto’s, handtekeningen, uitzonderingen en ontvangers. (Uitdaging D1.)
  3. Het fysieke ontwerp (hoofdstuk 3): welke daarvan zijn standaardobjecten (Field Service heeft werkorders, serviceafspraken, serviceresources en servicegebieden) en welke zijn aangepast? Welke licenties hebben de partnergebruikers en de ontvangers nodig? Waar staat elke soort data: in de org, off-core, in het datawarehouse?
  4. De sleutel (dit hoofdstuk): welke sleutel koppelt de orderregel van een retailpartner aan jouw levering, en wat gebeurt er als de vrachtlijst na de routering herzien wordt? (Uitdaging D3.)
  5. De ontvanger (dit hoofdstuk): een contactpersoon, een persoonsaccount, of geen van beide? Beargumenteer het vanuit de relatie, het volume, de isolatie tussen partners en de levenscyclus van de data.
  6. Unificeren of niet (dit hoofdstuk): ontvangers verschijnen in de vrachtlijsten van meerdere partners, soms meer dan eens per jaar. Zou je ze unificeren, of bewust niet? Wat is het risico, gezien S2? (Uitdaging DC1, zonder de late wijzigingen.)
  7. Zeggenschap: zeg voor vijf belangrijke velden (de orderreferentie van de partner, de leveringsstatus, het telefoonnummer van de ontvanger, het leveringsvenster, de juridische naam van de partner) wie het aanmaakt, wie er eigenaar van is, welk systeem gezaghebbend is en wie het mag wijzigen.

Schrijf elke beslissing op als beide opties, en dan je keuze: “naar mijn professionele mening…”

Mijn uitwerking is Checkpoint 1: Steve Trucking, hoe ik het zou ontwerpen. Vergelijk je redenering, niet alleen je vakjes. Waar je anders koos: kun je zeggen wat je zou winnen en wat je zou opgeven?

Houd je ontwerp voorlopig vast. Deel 2 toetst het aan volume, query’s, integratie, migratie, transacties en beveiliging, en de reviewkaart van hoofdstuk 18 controleert het in jaar drie.

  • DM-1, DM-2 (ontwerp van het datamodel; het model respecteert sharing)
  • MDM-1, MDM-2, MDM-3, MDM-4 (beheer, zeggenschap, matchen, herleidbaarheid)
  • SDM-1 (licenties), SDM-3 (één totaalbeeld, en wanneer je er geen bouwt)