Gå til indhold

Forstå virksomhedens data

Findes også på 28 sprog

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 · 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.
Billedet er lavet med AI

Studieguide til kapitel 4 i kurset Data Architect. Læs de seks moduler først; denne side hjælper dig med at tjekke, hvad der har sat sig fast.

Om denne studieguide. Den bygger kun på kursets eget indhold og listen over mål i Salesforces offentliggjorte eksamensguide. Den bygger aldrig på rigtige eksamensspørgsmål, og den påstår ikke at vide, hvad der kommer til eksamen. Hvis du har taget eksamen, så send mig venligst ikke spørgsmål fra den: Certificeringsaftalen forbyder at dele dem, og at lære svar udenad er under alle omstændigheder den forkerte måde at blive arkitekt på.

Eksamensguiden siger, at den ikke tester databasebegreber uden for Salesforce, og det meste af dette kapitel handler om virksomheden omkring Salesforce. Så ligesom i kapitel 1 siger denne tjekliste, hvilke mål hvert punkt understøtter. Men spring den ikke over: Mange eksamensscenarier starter med et ERP, et datavarehus eller en anden org, og svaret afhænger af, hvem der ejer dataene.

Sæt flueben, efterhånden som du går frem. Hvert punkt linker til det sted, hvor det bliver undervist.

Hvem ejer dataene (understøtter SDM-2, SDM-3 og kapitlet om masterdata)

Typerne af data og deres arbejdsbelastninger (understøtter DM-1, LDV-1 og MDM-4)

  • Jeg kan skelne mellem masterdata, referencedata, transaktionsdata, metadata, analytiske data og ustrukturerede data, og hvad hver af dem betyder for, hvor de bor. (Start med typen, ikke objektet)
  • Jeg ved, at referencedata er små, men er der, hvor integrationsantagelser gemmer sig (Delivered, Complete, D). (Referencedata)
  • Jeg kan skelne mellem operationelle (OLTP), analytiske (OLAP) og streamende arbejdsbelastninger: Org’en driver forretningen, datavarehuse og data lakes analyserer den. (Typen er kun det halve spørgsmål)
  • Jeg kender synkron (vent ved døren), asynkron (fortsæt, og tag dig af det, når det kommer tilbage) og batch (hver time, med nogle timers mellemrum, dagligt), hvornår batch er nok, og at realtid har en pris. (Hvor hurtigt skal det bevæge sig?)
  • Jeg stiller de fire spørgsmål til hvert datasæt: hvem ejer det, hvor hurtigt ændrer det sig, hvor stort bliver det, og hvad er dets livscyklus. (De fire spørgsmål bag kategorierne)

Systemerne omkring Salesforce (understøtter SDM-3, LDV-3 og integrationskapitlerne)

  • Jeg kender de fire systemroller: record, engagement, reference og insight (kildesystem, engagementssystem, referencesystem og indsigtssystem). (Start ikke med produktnavnet)
  • Jeg ved, at hvor analysen bor, følger af, hvor dataene bor: rapporter i core, når det hele er i Salesforce; en analyseplatform (Tableau, herunder Tableau Next, eller CRM Analytics, hvor det er i brug) eller datavarehuset, når andre datalagre er involveret. (Analyser bor, hvor dataene bor)
  • Jeg ved, hvad et datavarehus, en data lake og et lakehouse er, og hvilken rolle MDM, en ESB eller iPaaS og hændelser spiller. (Datavarehuset, data lake og lakehouse, Integrationslaget og hændelserne)
  • Jeg sætter identitetsudbyderen på landskabet fra første dag, og jeg ved, at SSO-konfigurationen kan deployes, men at hemmeligheder og certifikater ikke følger med; på landskabet er det et delt certifikat (tillid), ikke et kald, fordi login går gennem browseren. (Systemet, udviklere glemmer: identitet)
  • Jeg ved, at Data 360 er tæt på core (near-core) (administreret på core, hostet uden for core), og at dets zero copy gør det muligt at forespørge data uden at kopiere dem. (Hvor står Data 360?, Core, uden for core og Hyperforce)

Org’er og hosting (understøtter SDM-4)

  • Jeg starter med én org og leder efter en reel grænse (dataopbevaringskrav, regulering, juridisk adskillelse, en anden driftsmodel, et opkøb), før jeg tilføjer en til. (Start med én org, Kig efter reelle grænser)
  • Jeg ved, hvad flere org’er koster: global rapportering, masterdata, integration, identitet og deployments, hver især ganget op. (Gå pilene igennem igen)
  • Jeg ved, at Hyperforce giver et valg af den region, hvor en orgs data opbevares (ikke af cloududbyderen), men ikke lover, at alle tjenester bliver der; og at GDPR (databeskyttelsesforordningen) ikke i sig selv kræver en separat org: Den fastsætter regler for personoplysninger, der forlader EU, og en virksomhed kan vælge en europæisk org for at overholde dem. (Hosting er en del af tegningen, Når Europa får sin egen org)

At tegne og læse et landskab (understøtter alle scenarier)

  • Jeg kan tegne et landskab: mennesker til venstre, Salesforce i midten med sine communities op ad undersiden, identitet ovenover, integration og back office til højre, Data 360 under integrationslaget, kanaler nederst, data ind og ud nederst til højre. (Steves landskabslayout)
  • På et landskab starter en pil ved det system, der åbner forbindelsen, og dens tekst siger, hvad der bevæger sig, og hvilken vej; på et dataflowdiagram følger pilene dataene. To flows er to pile. (Tegn nu pilene)
  • For hver pil ved jeg, hvad klienten håndterer, og hvad serveren definerer: hvor, autentificering, protokol og kontrakt, payload, timing, sporing, fejl. En Named Credential og dens External Credential, når Salesforce kalder ud; en External Client App og en integrationsbruger, der kun har API-adgang, når noget kalder Salesforce. (Hver pil skal have en mekanisme)
  • Jeg tæller, før jeg tegner pilene: Volumen kommer i oversigten og styrer mekanismen, og den kan endda ændre, hvilken vej pilen peger. (Sæt nullerne i oversigten)
  • Jeg tegner kun en swim lane, når en proces har mere end en eller to udvekslinger frem og tilbage. (Pile på landskabet, samtaler i en swim lane)

Eksamen er gulvet, ikke loftet. Det her er de vaner fra dette kapitel, som en arkitekt har brug for, uanset om et spørgsmål nogensinde spørger til dem.

  • Tegn landskabet, før du designer org’en. Start fra et blankt lærred.
  • Træk kameraet tilbage. Salesforce er ét system blandt mange.
  • Den nye bølge får sjældent den gamle til at forsvinde. Design arkitekturen for den virksomhed, der findes, ikke for brochuren.
  • Læs landskabet som ansvarsområder, ikke logoer.
  • Envejspile gør mig nervøs. Hvad afhænger dette flow af, og hvad kommer tilbage?
  • Hver pil skal have en mekanisme. »Fire and forget« er ikke et svar.
  • Pile på landskabet, samtaler i en swim lane.
  • Tæl, før du tegner pilene. Nullerne kommer i oversigten, og de vælger mekanismen.
  • Tegn den nuværende tilstand, før du retter den: regnearket, SFTP-filen, systemet, »vi er ved at udfase«.
  • Markér en nuværende tilstand ærligt: rødt for en dårlig proces, stiplet for i hånden, røde prikker for det, der mangler. Hver rød linje er et krav, der venter på at blive skrevet.
  • To flows, to pile. En dobbeltpil er kun til en connector.
  • Spil ikke jurist. Spørg, hvilket konkret krav du opfylder, og oversæt det sammen med dem, der ejer det.
  • Separat er ikke det samme som simpelt.
TermPå én linje
SystemlandskabSystemerne omkring Salesforce, de mennesker, der bruger dem, og de vigtige flows mellem dem
System of record (kildesystem)Hvor den autoritative version af en type data opbevares
Engagementssystem (system of engagement)Hvor folk udfører arbejdet
Referencesystem (system of reference)Hvor et system slår oplysninger op, som det har brug for, men ikke ejer
Indsigtssystem (system of insight)Hvor data samles for at måle, analysere og forudsige
ERPBack office-systemet til økonomi, produkter, lager, indkøb og ordreopfyldelse
MasterdataDe varige ting, en virksomhed drives omkring: kunder, produkter, lokationer
ReferencedataDet fælles ordforråd, der klassificerer andre data: koder, statusser, kategorier
TransaktionsdataRegistreringer af, hvad der skete: ordrer, leveringer, betalinger, sager
Analytiske dataData afledt af andre data for at måle og sammenligne
Ustrukturerede dataDokumenter, billeder, lyd, video, transskriptioner
Datavarehus / data lake / lakehouseStruktureret analytisk lager / råt lager i stor skala / en blanding af de to
ESB / iPaaSEt integrationslag, der formidler mellem systemer
OLTP / OLAPOperationelt arbejde på få poster ad gangen / analyse på tværs af mange
Tæt på core (near-core)Administreret på core, hostet uden for core: Data 360
Named Credential / External CredentialHvor Salesforce gemmer et udgående endpoint / dets autentificering
External Client AppSådan får et eksternt system tilladelse til at kalde Salesforce
Nuværende tilstandLandskabet, som det er i dag, før designet; markeret med det, der er galt
Identitetsudbyder (IdP)Systemet, der autentificerer brugere og fastslår den identitet, Salesforce stoler på
Synkron / asynkron / batchVente på svaret / fortsætte og håndtere det, når det kommer / flytte data samlet efter en tidsplan
HyperforceSalesforce på offentlig cloudinfrastruktur, med valg af region
Zero copyAt forespørge data, hvor de bor, uden at kopiere dem

Korte scenarier i kursets stil. Beslut dig for dit svar, før du åbner det.

1. Sælgerne arbejder med konti i Salesforce, men ERP'et udsteder det officielle kundenummer, når de køber. Salesforce sender ordrer til ERP'et. Hvad skal du designe?

Hvem ejer kunden på hvert trin; ERP’ets nummer som et External ID på kontoen (Account); hvilke felter Salesforce må ændre; hvor hurtigt ændringer fra ERP’et kommer; og hvad der kommer tilbage, efter en ordre er sendt (accepteret, afvist, afsendt, faktureret). Læs Landskabet ændrer datamodellen igen.

2. Ledelsen vil have fem års leveringspræcision pr. region, koblet med økonomidata. Skal det bygges som Salesforce-rapporter?

Sandsynligvis ikke. Det er en analytisk arbejdsbelastning på tværs af flere datalagre, så den hører hjemme der, hvor dataene samles: datavarehuset, med CRM Analytics eller Tableau ovenpå. Hvor analysen bor, følger af, hvor dataene bor. Læs Analyser bor, hvor dataene bor igen.

3. En virksomhed opererer i 30 lande og beder om én org pr. land. Hvad spørger du om?

Hvilket krav der følger med hvert land: opbevaring, behandling, overførsel på tværs af grænser, kontrakter, en anden hosting. Uden en reel grænse starter du med én org, for hver ekstra org ganger rapportering, masterdata, integration, identitet og deployments op. Læs Geografi er ikke automatisk en org-strategi igen.

4. Lastbilerne sender 200.000 GPS-målinger om dagen. Skal Salesforce gemme dem alle?

Sandsynligvis ikke. Det er streamingdata: Disponenten har brug for den aktuelle position, mens historik og tendenser hører hjemme på en platform bygget til den volumen. Tæl nullerne (over 70 millioner om året), og adskil »hvor er den nu?« fra »hvad skete der sidste kvartal?«. Læs Typen er kun det halve spørgsmål igen.

5. Teamene arbejder med deres stop i Salesforce, men ruterne bygges i et gammelt dispatch-værktøj, og intet forbinder de to. Hvordan tegner du situationen i dag?

Som den er, markeret som en nuværende tilstand: ruterne indtastet igen i Salesforce og de afsluttede stop indtastet tilbage, stiplet, fordi mennesker gør det, og rødt, fordi det er forkert. Tegn ikke den integration, du ville ønske fandtes; hver rød linje bliver et krav til designet. Læs Markér det, der er galt og RouteDesk er der stadig igen.

6. Nogen siger, at europæisk databeskyttelseslovgivning kræver en separat org. Hvordan svarer du?

Hverken accepter det blindt eller underkend det. GDPR kræver ikke i sig selv en separat org; den fastsætter regler for personoplysninger, herunder overførsler ud af EU. Spørg, hvilket konkret krav den opfylder (opbevaring, behandling, overførsel, supportadgang, en kontrakt, en politik), og arbejd så sammen med privacy, jura og sikkerhed om at omsætte det til arkitektur. Læs Spil ikke jurist og Når Europa får sin egen org igen.

7. Salesforce sender ordrer til ERP'ets API. Hvilken side håndterer genforsøg, og hvor gemmer Salesforce hemmeligheden?

Salesforce er klienten: Den åbner forbindelsen, ser hele rundturen og er den eneste side, der kan forsøge igen. En Named Credential rummer endpointet, og dens External Credential autentificeringen. ERP’et, serveren, definerer kontrakten og validerer det, der kommer ind. Læs Hver pil skal have en mekanisme igen.

8. En integration sender et par poster i minuttet i dag, og forretningen forventer titusindvis i timen næste år. Ændrer pilen sig?

Muligvis dens mekanisme og endda dens retning. Et par poster i minuttet kan være et kald ud fra Salesforce; langt flere kan betyde, at der publiceres hændelser, som det andet system abonnerer på, så pilen starter i den anden ende; millioner om natten er en batch. Kend tallene, før du vælger. Læs Sæt nullerne i oversigten igen.