Hoppa till innehåll
SteveTechArcSteveTechArc Courses

Förstå företagets data

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)

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.
Bilden är skapad med AI

Studieguide för kapitel 4 i kursen Data Architect. Läs de sex modulerna först; den här sidan hjälper dig att kontrollera vad som har fastnat.

Om den här studieguiden. Den bygger enbart på kursens eget innehåll och på listan över mål i Salesforce publicerade provguide. Den bygger aldrig på riktiga provfrågor, och den påstår inte att den vet vad som kommer på provet. Om du har skrivit provet, skicka inte frågor från det till mig: certifieringsavtalet förbjuder att de delas, och att plugga in svar är ändå fel sätt att bli arkitekt.

Provguiden säger att den inte testar databasbegrepp utanför Salesforce, och det mesta i det här kapitlet handlar om företaget runt Salesforce. Så, precis som i kapitel 1, anger den här checklistan vilka mål varje punkt stöder. Men hoppa inte över den: många scenarier på provet börjar med ett ERP, ett datalager eller en andra org, och svaret beror på vem som äger data.

Inför provet

Section titled “Inför provet ”

Bocka av dem allt eftersom. Varje punkt länkar till där den lärs ut.

Vem som äger data (stöder SDM-2, SDM-3 och kapitlet om masterdata)

Typerna av data och deras arbetslaster (stöder DM-1, LDV-1 och MDM-4)

  • Jag kan skilja på masterdata, referensdata, transaktionsdata, metadata, analytiska data och ostrukturerade data, och vad var och en betyder för var de bor. (Börja med typen, inte objektet)
  • Jag vet att referensdata är små men att det är där integrationsantagandena gömmer sig (Delivered, Complete, D). (Referensdata)
  • Jag kan skilja på operativa (OLTP), analytiska (OLAP) och strömmande arbetslaster: orgen driver verksamheten, datalager och datasjöar analyserar den. (Typen är bara halva frågan)
  • Jag känner till synkront (vänta vid dörren), asynkront (fortsätt, ta hand om det när det kommer tillbaka) och batch (varje timme, med några timmars mellanrum, dagligen), när batch räcker, och att realtid har ett pris. (Hur snabbt måste det röra sig?)
  • Jag ställer de fyra frågorna om varje datamängd: vem som äger den, hur snabbt den ändras, hur stor den blir och dess livscykel. (De fyra frågorna bakom kategorierna)

Systemen runt Salesforce (stöder SDM-3, LDV-3 och integrationskapitlen)

  • Jag känner till de fyra systemrollerna: record, engagement, reference och insight (källsystem, engagemangssystem, referenssystem och insiktssystem). (Börja inte med produktnamnet)
  • Jag vet att var analysen bor följer var data bor: rapporter i core när allt finns i Salesforce; en analysplattform (Tableau, inklusive Tableau Next, eller CRM Analytics där det används) eller datalagret när andra lager är inblandade. (Analysen bor där data bor)
  • Jag vet vad ett datalager, en datasjö och ett lakehouse är, och vilken roll MDM, en ESB eller iPaaS och händelser har. (Datalagret, datasjön och lakehouse, Integrationslagret och händelserna)
  • Jag sätter identitetsleverantören på landskapet från dag ett, och jag vet att SSO-konfigurationen kan deployas men att hemligheter och certifikat inte följer med; på landskapet är det ett delat certifikat (förtroende), inte ett anrop, eftersom inloggningen går via webbläsaren. (Systemet utvecklare glömmer: identitet)
  • Jag vet att Data 360 är nära core (near-core: hanteras på core, driftas utanför core), och att dess zero copy gör att data kan frågas utan att kopieras. (Var hör Data 360 hemma?, Core, utanför core och Hyperforce)

Orgar och drift (stöder SDM-4)

  • Jag börjar med en org och letar efter en verklig gräns (datalokalisering, reglering, juridisk separation, en annan verksamhetsmodell, ett förvärv) innan jag lägger till en till. (Börja med en org, Leta efter verkliga gränser)
  • Jag vet vad flera orgar kostar: global rapportering, masterdata, integration, identitet och deployer, var och en multiplicerad. (Gå igenom pilarna igen)
  • Jag vet att Hyperforce ger ett val av region där en orgs data lagras (inte av molnleverantör), men inte lovar att varje tjänst stannar där; och att GDPR inte i sig kräver en separat org: den sätter regler för personuppgifter som lämnar EU, och ett företag kan välja en europeisk org för att uppfylla dem. (Driften är en del av ritningen, När Europa får en egen org)

Rita och läsa ett landskap (stöder varje scenario)

  • Jag kan rita ett landskap: människor till vänster, Salesforce i mitten med sina communities som nuddar under, identitet ovanför, integration och back office till höger, Data 360 under integrationslagret, kanaler under, data in och ut nere till höger. (Steves layout för landskap)
  • På ett landskap börjar en pil vid systemet som öppnar kopplingen och dess etikett säger vad som rör sig och åt vilket håll; på ett dataflödesdiagram följer pilarna data. Två flöden är två pilar. (Rita nu pilarna)
  • För varje pil vet jag vad klienten hanterar och vad servern definierar: var, autentisering, protokoll och kontrakt, payload, tidpunkt, spårning, fel. En Named Credential och dess External Credential när Salesforce anropar ut; en External Client App och en integrationsanvändare med enbart API-åtkomst när något anropar Salesforce. (Varje pil behöver en mekanism)
  • Jag räknar innan jag ritar pilarna: volymen hamnar i inventeringen och styr mekanismen, och kan till och med ändra åt vilket håll pilen pekar. (Lägg nollorna i inventeringen)
  • Jag ritar ett simbanediagram bara när en process har mer än ett eller två utbyten fram och tillbaka. (Pilar på landskapet, samtal i ett simbanediagram)

Bortom provet

Section titled “Bortom provet ”

Provet är golvet, inte taket. Det här är vanorna från kapitlet som en arkitekt behöver, oavsett om någon fråga någonsin tar upp dem.

  • Rita landskapet innan du designar orgen. Börja från en tom duk.
  • Zooma ut kameran. Salesforce är ett system bland många.
  • Den nya vågen får sällan den gamla att försvinna. Designa för företaget som finns, inte broschyren.
  • Läs landskapet som ansvar, inte logotyper.
  • Enkelriktade pilar gör mig nervös. Vad är det här flödet beroende av, och vad kommer tillbaka?
  • Varje pil behöver en mekanism. ”Fire and forget” är inget svar.
  • Pilar på landskapet, samtal i ett simbanediagram.
  • Räkna innan du ritar pilarna. Nollorna hamnar i inventeringen, och de väljer mekanismen.
  • Rita nuläget innan du lagar det: kalkylarket, SFTP-filen, systemet ”vi ska avveckla”.
  • Markera ett nuläge ärligt: rött för en dålig process, streckat för det som görs för hand, röda prickar för det som saknas. Varje röd linje är ett krav som väntar på att skrivas.
  • Två flöden, två pilar. En dubbelriktad pil är bara för en connector.
  • Lek inte jurist. Fråga vilket specifikt krav du uppfyller, och översätt det tillsammans med dem som äger det.
  • Separat är inte samma sak som enkelt.

Ord att kunna

Section titled “Ord att kunna ”
TermPå en rad
SystemlandskapSystemen runt Salesforce, människorna som använder dem och de viktiga flödena mellan dem
System of record (källsystem)Där den auktoritativa versionen av en typ av data finns
EngagemangssystemDär människor utför arbetet
ReferenssystemDär ett system slår upp information som det behöver men inte äger
InsiktssystemDär data kommer samman för att mäta, analysera och förutsäga
ERPBack office-systemet för ekonomi, produkter, lager, inköp och leverans
MasterdataDe beständiga saker en verksamhet kretsar kring: kunder, produkter, platser
ReferensdataDet gemensamma ordförrådet som klassificerar andra data: koder, statusar, kategorier
TransaktionsdataPoster om vad som hände: ordrar, leveranser, betalningar, ärenden
Analytiska dataData som härleds ur andra data för att mäta och jämföra
Ostrukturerade dataDokument, bilder, ljud, video, transkriptioner
Datalager / datasjö / lakehouseStrukturerat analytiskt lager / rålager i stor skala / en blandning av de två
ESB / iPaaSEtt integrationslager som förmedlar mellan system
OLTP / OLAPOperativt arbete på några få poster åt gången / analys över många
Nära core (near-core)Hanteras på core, driftas utanför core: Data 360
Named Credential / External CredentialDär Salesforce sparar en utgående slutpunkt / dess autentisering
External Client AppHur ett externt system får behörighet att anropa Salesforce
NulägeLandskapet som det ser ut i dag, före designen; markerat med det som är fel
Identitetsleverantör (IdP)Systemet som autentiserar användare och fastställer den identitet som Salesforce litar på
Synkront / asynkront / batchVänta på svaret / fortsätta och hantera det när det kommer / flytta data som en grupp enligt ett schema
HyperforceSalesforce på infrastruktur i det publika molnet, med val av region
Zero copyFråga data där de bor, utan att kopiera dem

Testa dig själv

Section titled “Testa dig själv ”

Korta scenarier i kursens stil. Bestäm ditt svar innan du öppnar det.

1. Säljarna arbetar med konton i Salesforce, men ERP:t utfärdar det officiella kundnumret när kunden köper. Salesforce skickar ordrar till ERP:t. Vad behöver du designa?

Vem som äger kunden i varje steg; ERP:ts nummer som External ID på kontot (Account); vilka fält Salesforce får ändra; hur snabbt ändringar i ERP:t kommer fram; och vad som kommer tillbaka efter att en order skickats (accepterad, avvisad, skickad, fakturerad). Läs om Landskapet ändrar datamodellen.

2. Ledningen vill ha fem års leveransprecision per region, kopplat till ekonomidata. Ska det byggas som rapporter i Salesforce?

Förmodligen inte. Det är en analytisk arbetslast över flera lager, så den hör hemma där data kommer samman: datalagret, med CRM Analytics eller Tableau ovanpå. Var analysen bor följer var data bor. Läs om Analysen bor där data bor.

3. Ett företag verkar i 30 länder och ber om en org per land. Vad frågar du?

Vilket krav som följer med varje land: lagring, behandling, överföring över gränser, avtal, en annan driftplats. Utan en verklig gräns börjar du med en org, eftersom varje extra org multiplicerar rapportering, masterdata, integration, identitet och deployer. Läs om Geografi är inte automatiskt en org-strategi.

4. Lastbilarna skickar 200 000 GPS-avläsningar om dagen. Ska Salesforce lagra alla?

Förmodligen inte. Det är strömmande data: trafikledaren behöver den aktuella positionen, medan historik och trender hör hemma på en plattform byggd för den volymen. Räkna nollorna (över 70 miljoner om året) och skilj ”var är den nu?” från ”vad hände förra kvartalet?”. Läs om Typen är bara halva frågan.

5. Teamen arbetar med sina stopp i Salesforce, men rutterna byggs i ett gammalt trafikledningsverktyg, och inget kopplar ihop de två. Hur ritar du dagsläget?

Som det är, markerat som ett nuläge: rutterna som knappas in i Salesforce och de klara stoppen som knappas tillbaka, streckat för att människor gör det och rött för att det är fel. Rita inte integrationen du önskar fanns; varje röd linje blir ett krav för designen. Läs om Markera det som är fel och RouteDesk finns fortfarande kvar.

6. Någon säger att europeisk integritetslagstiftning kräver en separat org. Hur svarar du?

Varken acceptera det blint eller kör över det. GDPR kräver inte i sig en separat org; den sätter regler för personuppgifter, bland annat överföringar ut ur EU. Fråga vilket specifikt krav det uppfyller (lagring, behandling, överföring, supportåtkomst, ett avtal, en policy), och arbeta sedan med dataskydd, juridik och säkerhet för att göra det till arkitektur. Läs om Lek inte jurist och När Europa får en egen org.

7. Salesforce skickar ordrar till ERP:ts API. Vilken sida hanterar nya försök, och var sparar Salesforce hemligheten?

Salesforce är klienten: den öppnar kopplingen, ser hela rundturen och är den enda sidan som kan försöka igen. En Named Credential håller slutpunkten, och dess External Credential autentiseringen. ERP:t, servern, definierar kontraktet och validerar det som kommer in. Läs om Varje pil behöver en mekanism.

8. En integration skickar ett par poster i minuten i dag, och verksamheten väntar sig tiotusentals i timmen nästa år. Ändras pilen?

Kanske dess mekanism och till och med dess riktning. Några poster i minuten kan vara ett anrop ut från Salesforce; betydligt fler kan innebära att publicera händelser som det andra systemet prenumererar på, så att pilen börjar i andra änden; miljoner över natten är en batch. Känn till siffrorna innan du väljer. Läs om Lägg nollorna i inventeringen.

Utforska vidare

Section titled “Utforska vidare ”