Gå til innholdet
SteveTechArcSteveTechArc Courses

Forstå virksomhetens data

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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Bildet er laget med KI

Studieguide for kapittel 4 i kurset Data Architect. Les de seks modulene først; denne siden hjelper deg å sjekke hva som satt seg.

Om denne studieguiden. Den bygger bare på kursets eget innhold og listen over mål i Salesforces publiserte eksamensguide. Den bygger aldri på ekte eksamensspørsmål, og den påstår ikke å vite hva som kommer på eksamen. Hvis du har tatt eksamen, ikke send meg spørsmål fra den: sertifiseringsavtalen forbyr å dele dem, og å pugge svar er uansett feil måte å bli arkitekt på.

Eksamensguiden sier at den ikke tester databasebegreper utenfor Salesforce, og det meste av dette kapitlet handler om virksomheten rundt Salesforce. Så, som i kapittel 1, sier denne sjekklisten hvilke mål hvert punkt støtter. Men ikke hopp over den: mange eksamensscenarioer starter med et ERP, et datavarehus eller en org nummer to, og svaret avhenger av hvem som eier dataene.

Til eksamen

Section titled “Til eksamen ”

Kryss av etter hvert. Hvert punkt lenker til der det undervises.

Hvem eier dataene (støtter SDM-2, SDM-3 og kapitlet Masterdata og identitet)

Typene data og arbeidsbelastningene deres (støtter DM-1, LDV-1 og MDM-4)

  • Jeg kan skille masterdata, referansedata, transaksjonsdata, metadata, analytiske data og ustrukturerte data fra hverandre, og vet hva hver av dem betyr for hvor de bor. (Start med typen, ikke objektet)
  • Jeg vet at referansedata er små, men at det er der integrasjonsantakelser gjemmer seg (Delivered, Complete, D). (Referansedata)
  • Jeg kan skille operative (OLTP), analytiske (OLAP) og strømmende arbeidsbelastninger fra hverandre: orgen driver virksomheten, datavarehus og datasjøer analyserer den. (Typen er bare halve spørsmålet)
  • Jeg kjenner synkront (vent ved døren), asynkront (fortsett, og ta det når det kommer tilbake) og batch (hver time, med noen timers mellomrom, daglig), vet når batch er nok, og at sanntid har en kostnad. (Hvor fort må det gå?)
  • Jeg stiller de fire spørsmålene til hvert datasett: hvem eier det, hvor fort endres det, hvor stort blir det, og hva er livssyklusen. (De fire spørsmålene bak kategoriene)

Systemene rundt Salesforce (støtter SDM-3, LDV-3 og integrasjonskapitlene)

  • Jeg kjenner de fire systemrollene: record, engagement, reference og insight (kilde-, engasjements-, referanse- og innsiktssystem). (Ikke start med produktnavnet)
  • Jeg vet at hvor analysen bor, følger av hvor dataene bor: standardrapporter når alt ligger i Salesforce; en analyseplattform (Tableau, inkludert Tableau Next, eller CRM Analytics der det er i bruk) eller datavarehuset når andre lagre er involvert. (Analysen bor der dataene bor)
  • Jeg vet hva et datavarehus, en datasjø og et lakehouse er, og hvilken rolle MDM, en ESB eller iPaaS og hendelser spiller. (Datavarehuset, datasjøen og lakehouse, Integrasjonslaget og hendelsene)
  • Jeg setter identitetsleverandøren på landskapet fra dag én, og jeg vet at SSO-konfigurasjonen kan deployes, men at hemmeligheter og sertifikater ikke følger med; på landskapet er det et delt sertifikat (tillit), ikke et kall, fordi innloggingen går gjennom nettleseren. (Systemet utviklere glemmer: identitet)
  • Jeg vet at Data 360 er nær core (near-core) (forvaltet på core, driftet utenfor core), og at zero copy lar data spørres uten å kopiere dem. (Hvor står Data 360?, Core, utenfor core og Hyperforce)

Orger og drift (støtter SDM-4)

  • Jeg starter med én org og ser etter en ekte grense (datalokalisering, regulering, juridisk atskillelse, en annen driftsmodell, et oppkjøp) før jeg legger til en til. (Start med én org, Se etter ekte grenser)
  • Jeg vet hva flere orger koster: global rapportering, masterdata, integrasjon, identitet og deployeringer, hver av dem mangedoblet. (Gå gjennom pilene igjen)
  • Jeg vet at Hyperforce gir et valg av regionen der en orgs data ligger (ikke skyleverandøren), men ikke lover at hver tjeneste blir der; og at GDPR ikke i seg selv krever en egen org: den setter regler for personopplysninger som forlater EU, og et selskap kan velge en europeisk org for å oppfylle dem. (Driften er en del av tegningen, Når Europa får sin egen org)

Å tegne og lese et landskap (støtter alle scenarioer)

  • Jeg kan tegne et landskap: menneskene til venstre, Salesforce i midten med portalene sine berørende under, identitet over, integrasjon og bakkontor til høyre, Data 360 under integrasjonslaget, kanaler under, data inn og ut nederst til høyre. (Steves landskapsoppsett)
  • På et landskap starter en pil ved systemet som åpner forbindelsen, og etiketten sier hva som beveger seg og hvilken vei; på et dataflytdiagram følger pilene dataene. To flyter er to piler. (Tegn så pilene)
  • For hver pil vet jeg hva klienten håndterer og hva serveren definerer: hvor, autentisering, protokoll og kontrakt, payload, timing, sporing, feil. En Named Credential og dens External Credential når Salesforce kaller ut; en External Client App og en integrasjonsbruker med bare API-tilgang når noe kaller Salesforce. (Hver pil trenger en mekanisme)
  • Jeg teller før jeg tegner pilene: volumet går inn i inventaret og styrer mekanismen, og kan til og med endre hvilken vei pilen peker. (Før nullene inn i inventaret)
  • Jeg tegner et svømmebanediagram bare når en prosess har mer enn én eller to utvekslinger fram og tilbake. (Piler på landskapet, samtaler i en svømmebane)

Utover eksamen

Section titled “Utover eksamen ”

Eksamen er gulvet, ikke taket. Dette er vanene fra dette kapitlet som en arkitekt trenger, enten et spørsmål noen gang spør om dem eller ikke.

  • Tegn landskapet før du designer orgen. Start fra et blankt lerret.
  • Trekk kameraet bakover. Salesforce er ett system blant mange.
  • Den nye bølgen får sjelden den gamle til å forsvinne. Design arkitekturen for virksomheten som finnes, ikke brosjyren.
  • Les landskapet som ansvar, ikke logoer.
  • Enveispiler gjør meg nervøs. Hva er denne flyten avhengig av, og hva kommer tilbake?
  • Hver pil trenger en mekanisme. «Fire and forget» er ikke et svar.
  • Piler på landskapet, samtaler i en svømmebane.
  • Tell før du tegner pilene. Nullene går inn i inventaret, og de velger mekanismen.
  • Tegn nåsituasjonen før du fikser den: regnearket, SFTP-slippet, systemet «vi skal fase ut».
  • Marker en nåsituasjon ærlig: rødt for en dårlig prosess, stiplet for håndarbeid, røde prikker for det som mangler. Hver røde linje er et krav som venter på å bli skrevet.
  • To flyter, to piler. En dobbeltpil er bare for en connector.
  • Ikke spill advokat. Spør hvilket konkret krav du oppfyller, og oversett det sammen med dem som eier det.
  • Atskilt er ikke det samme som enkelt.

Ord du bør kunne

Section titled “Ord du bør kunne ”
BegrepPå én linje
SystemlandskapSystemene rundt Salesforce, menneskene som bruker dem, og de viktige flytene mellom dem
System of record (kildesystem)Der den autoritative versjonen av en type data holdes
EngasjementssystemDer folk gjør jobben
ReferansesystemDer et system slår opp informasjon det trenger, men ikke eier
InnsiktssystemDer data kommer sammen for å måle, analysere og forutsi
ERPBakkontorsystemet for økonomi, produkter, lager, innkjøp og ordreoppfyllelse
MasterdataDe varige tingene en virksomhet dreier seg om: kunder, produkter, lokasjoner
ReferansedataDet felles vokabularet som klassifiserer andre data: koder, statuser, kategorier
TransaksjonsdataPoster over det som skjedde: ordrer, leveringer, betalinger, saker
Analytiske dataData avledet fra andre data for å måle og sammenligne
Ustrukturerte dataDokumenter, bilder, lyd, video, transkripsjoner
Datavarehus / datasjø / lakehouseStrukturert analytisk lager / rålager i stor skala / en blanding av de to
ESB / iPaaSEt integrasjonslag som formidler mellom systemer
OLTP / OLAPOperativt arbeid på noen få poster om gangen / analyse på tvers av mange
Nær core (near-core)Forvaltet på core, driftet utenfor core: Data 360
Named Credential / External CredentialDer Salesforce holder et utgående endepunkt / autentiseringen til det
External Client AppHvordan et eksternt system får tillatelse til å kalle Salesforce
NåsituasjonLandskapet slik det er i dag, før designet; merket med det som er galt
Identitetsleverandør (IdP)Systemet som autentiserer brukere og etablerer identiteten Salesforce stoler på
Synkront / asynkront / batchVente på svaret / fortsette og håndtere det når det kommer / flytte data som en gruppe etter en tidsplan
HyperforceSalesforce på infrastruktur i offentlig sky, med valg av region
Zero copySpørre data der de bor, uten å kopiere dem

Test deg selv

Section titled “Test deg selv ”

Korte scenarioer i kursets stil. Bestem deg for svaret før du åpner det.

1. Selgerne jobber med kontoer i Salesforce, men ERP-et utsteder det offisielle kundenummeret når de kjøper. Salesforce sender ordrer til ERP-et. Hva må du designe?

Hvem som eier kunden i hver fase; ERP-ets nummer som External ID på kontoen (Account); hvilke felt Salesforce får endre; hvor fort endringer fra ERP-et kommer; og hva som kommer tilbake etter at en ordre er sendt (godtatt, avvist, sendt, fakturert). Les Landskapet endrer datamodellen på nytt.

2. Ledelsen vil ha fem år med leveringspresisjon per region, koblet til økonomi. Bygge det som Salesforce-rapporter?

Sannsynligvis ikke. Det er en analytisk arbeidsbelastning på tvers av flere lagre, så den hører hjemme der dataene kommer sammen: i datavarehuset, med CRM Analytics eller Tableau oppå. Hvor analysen bor, følger av hvor dataene bor. Les Analysen bor der dataene bor på nytt.

3. Et selskap driver i 30 land og ber om én org per land. Hva spør du om?

Hvilket krav som følger med hvert land: lagring, behandling, overføring over landegrenser, kontrakter, en annen driftsplassering. Uten en ekte grense starter du med én org, fordi hver ekstra org mangedobler rapportering, masterdata, integrasjon, identitet og deployeringer. Les Geografi er ikke automatisk en org-strategi på nytt.

4. Lastebilene sender 200 000 GPS-målinger om dagen. Bør Salesforce lagre alle?

Sannsynligvis ikke. Det er strømmende data: koordinatoren trenger den nåværende posisjonen, mens historikk og trender hører hjemme på en plattform bygd for det volumet. Tell nullene (over 70 millioner i året) og skill «hvor er den nå?» fra «hva skjedde forrige kvartal?». Les Typen er bare halve spørsmålet på nytt.

5. Teamene jobber med stoppene sine i Salesforce, men rutene bygges i et gammelt utkjøringsverktøy, og ingenting kobler de to sammen. Hvordan tegner du dagens situasjon?

Slik den er, merket som en nåsituasjon: rutene tastet inn på nytt i Salesforce og de fullførte stoppene tastet inn tilbake, stiplet fordi mennesker gjør det, og rødt fordi det er galt. Ikke tegn integrasjonen du skulle ønske fantes; hver røde linje blir et krav til designet. Les Marker det som er galt og RouteDesk er der fortsatt på nytt.

6. Noen sier at europeisk personvernlovgivning krever en egen org. Hvordan svarer du?

Verken godta det blindt eller overstyr det. GDPR krever ikke i seg selv en egen org; den setter regler for personopplysninger, inkludert overføringer ut av EU. Spør hvilket konkret krav det oppfyller (lagring, behandling, overføring, support-tilgang, en kontrakt, en policy), og samarbeid så med personvern, juridisk og sikkerhet for å gjøre det om til arkitektur. Les Ikke spill advokat og Når Europa får sin egen org på nytt.

7. Salesforce sender ordrer til ERP-ets API. Hvilken side håndterer nye forsøk, og hvor holder Salesforce hemmeligheten?

Salesforce er klienten: den åpner forbindelsen, ser hele tur-retur-reisen og er den eneste siden som kan prøve på nytt. En Named Credential holder endepunktet, og dens External Credential autentiseringen. ERP-et, serveren, definerer kontrakten og validerer det som kommer inn. Les Hver pil trenger en mekanisme på nytt.

8. En integrasjon sender et par poster i minuttet i dag, og virksomheten venter titusener i timen neste år. Endrer pilen seg?

Kanskje mekanismen og til og med retningen. Noen få poster i minuttet kan være et kall ut fra Salesforce; langt flere kan bety å publisere hendelser som det andre systemet abonnerer på, slik at pilen starter i den andre enden; millioner over natten er en batch. Kjenn tallene før du velger. Les Før nullene inn i inventaret på nytt.

Les mer

Section titled “Les mer ”