Gå til innholdet
SteveTechArcSteveTechArc Courses

Tenk som en dataarkitekt

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 1 i kurset Data Architect. Les de sju modulene først; denne siden hjelper deg å sjekke hva som har satt seg.

Om denne studieguiden. Den er bygget bare på kursets eget innhold og på 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å.

Dette kapitlet har færre eksamensfakta, og det er med vilje. Det handler om hvordan en arkitekt tenker, og ingen eksamensmål hører til det alene. Men eksamen er bygget på scenarioer: en virksomhet, noen tall, en begrensning og flere svar som kan fungere. Vanene i dette kapitlet er måten du leser de scenarioene på. Derfor sier sjekklisten nedenfor hvilket mål hvert punkt støtter, i stedet for å påstå at det testes direkte.

Til eksamen

Section titled “Til eksamen ”

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

Å lese et scenario som en arkitekt (støtter alle målene)

  • Jeg skiller det egentlige kravet fra designet det kom forkledd som («vi trenger feltene Godkjenner 2 og Godkjenner 3» mot «vi må følge med på hver eneste godkjenning»). (Ikke bare ta imot kravet)
  • Jeg ser etter de underforståtte kravene ingen har uttalt: eierskap, ferskhet, feil, oppbevaring, tilgang. (Se etter de underforståtte kravene)
  • Jeg setter tall på det: volum per dag, per år, med vekst, og jeg legger merke til når én null til endrer svaret. (Kjenn tallene dine)
  • Blant flere svar som fungerer, sammenligner jeg hva hvert av dem vinner og gir opp, mot de oppgitte kravene og begrensningene. (Vit hva du gir avkall på, Begrensninger endrer svaret)
  • Jeg behandler kostnad, lisenser og grenser som en del av om et verktøy passer, ikke som en ettertanke. (De ni spørsmålene)

Datamodellen (støtter DM-1)

Å endre det som allerede finnes (støtter DM-1 og SDM-2)

  • Jeg vet hvorfor det å endre typen på et felt, eller å gjøre et eksisterende felt Required (obligatorisk), kan ødelegge ting senere, og hvorfor plattformen blokkerer en typeendring mens kode eller flows refererer til feltet. (Vær forsiktig med å endre skjelettet)
  • Jeg kjenner mønsteret legg til i stedet for å endre, fas ut i stedet for å overraske, og vet at Field Usage kan merke et felt som kandidat for utfasing. (Vær forsiktig med å endre skjelettet)
  • Jeg kjenner faktaene om master-detail bak reversibilitetstesten: detaljpostens tilgang og eierskap følger masterposten, når du sletter en masterpost, slettes detaljpostene, sammendragsfelt (roll-up summary) krever master-detail, og en lookup-relasjon kan bare gjøres om til master-detail når hver post har en verdi. (Reversibilitetstesten, Les mer)

Lisenser og deling (støtter SDM-1)

  • Jeg vet at fellesskapsbrukere med høyt volum (high-volume, blant dem Customer Community) ikke har roller og ikke bruker delingsmodellen, så tilgangen kommer fra sharing sets og share groups, og Apex-deling kan ikke nå dem. (Et gjennomgått eksempel: Apex-deling)

Feil (støtter MIG-1 og integrasjonskapitlene)

Utover eksamen

Section titled “Utover eksamen ”

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

  • Noen må holde tegningen. Arkitektur er å ta gode beslutninger med ufullstendig informasjon, og å kjenne konsekvensene av dem.
  • Datamodellen er skjelettet. Alt annet bygges på den.
  • Reversibilitetstesten: hvor vanskelig er dette å reversere, og hvor mye kommer til å avhenge av det?
  • Arkitektur skaper tyngdekraft. Det er avhengighetene som gjør endring dyrt, ikke endringen i seg selv.
  • Tenk på sprengradiusen, inne i Salesforce og på tvers av virksomheten. Arkitektur er toveistrafikk.
  • Skriv ned hvorfor: kontekst, alternativer, beslutning, konsekvenser, eier, gjennomgang. Erstatt; ikke slett.
  • Best til hva? En suboptimal beslutning kan være en del av en optimal arkitektur, hvis du vet at du tar den.
  • Ha et bilde av det optimale, så du vet i hvilken retning du beveger deg bort fra det, og hvorfor.
  • Think Correct. Think Fast. Fart kommer av tenkning som er gjort før øyeblikket.
  • Bygg for i dag. Planlegg for i morgen. Planlegg for feil. Og bruk 30 % vekst når ingen gir deg et tall.
  • Lær de ni spørsmålene, ikke bare svarene.
  • KI er en rakettbooster. Generering er ikke skjønn, irreversibelt er fortsatt irreversibelt, og menneskelig gjennomgang er ingen seremoni. Stol på, men kontroller.

Ord du bør kunne

Section titled “Ord du bør kunne ”
BegrepPå én linje
Arkitektonisk beslutningEn beslutning som er vanskelig å reversere, og som mye avhenger av
ReversibilitetstestenHvor vanskelig er dette å reversere, og hvor mye kommer til å avhenge av det?
TyngdekraftAvhengighetene som samler seg rundt en beslutning over tid
Sprengradius (blast radius)Alt annet som flytter seg når en beslutning endres
BeslutningsloggKontekst, alternativer, beslutning, konsekvenser, eier og tidspunkt for gjennomgang, holdt kort
AvveiningHva et alternativ vinner, og hva det gir opp for å få det
Underforstått kravNoe virksomheten forventer uten å be om det, for eksempel gjenoppretting når en innlasting feiler
Steves «antall nuller»Én null til i volumet kan endre hele arkitekturen
AvstemmingÅ sammenligne det som skulle ha skjedd, med det som skjedde, post for post
Fase utMerke noe som på vei ut, og så pensjonere det bevisst, i stedet for å endre det på stedet
Bruker med høyt volumEn fellesskapsbruker (Customer Community er blant lisensene) uten rolle, utenfor delingsmodellen
SkjemaspredningObjekter og felt som hoper seg opp fordi de var billige å lage, til ingen lenger har designet modellen

Test deg selv

Section titled “Test deg selv ”

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

1. Et salgsteam ber om feltene Godkjenner 2 og Godkjenner 3, hver med en dato, på salgsmuligheten (Opportunity). Hva spør du om, og hva kan du komme til å bygge?

Spør hvorfor, og hvor mange godkjenninger det kan bli. Hvis det kan bli flere enn to eller tre, er kravet å følge med på hver eneste godkjenning, ikke å legge til felt: et underordnet objekt, én post per godkjenning. Les Ikke bare ta imot kravet på nytt.

2. Én vil gi etiketten til et felt nytt navn, og en annen vil endre formatet på kundeidentifikatoren som fem systemer allerede lagrer. Hva fortjener mest av oppmerksomheten din, og hvorfor?

Identifikatoren. Etiketten er billig å endre. Identifikatoren stryker på reversibilitetstesten: vanskelig å reversere, og mye avhenger allerede av den. Bruk oppmerksomheten i forhold til hva det koster å ta feil. Les Noen beslutninger er billige å endre på nytt.

3. Et tekstfelt har vært i bruk i årevis. Nå vil virksomheten at det skal inneholde et tall. Hvordan går du frem?

Ikke endre det på stedet. Finn ut hva som avhenger av det (Flows, Apex, rapporter, integrasjoner, agenter) og hva som skjer med de gamle dataene. Som regel: legg til et nytt felt, migrer bevisst og fas ut det gamle. Les Vær forsiktig med å endre skjelettet på nytt.

4. 1 200 steder, 100 avtaler per sted per dag, rundt 305 dager i året, to poster per avtale, fem år beholdes, 30 % vekst. Omtrent hvor mange poster blir det, og hvorfor betyr det noe?

Rundt 73 millioner poster det første året (36,6 millioner avtaler, to poster hver), og over 650 millioner over fem år med vekst. Samme funksjon, et par nuller til, en helt annen arkitektur. Les Kjenn tallene dine på nytt.

5. En nattlig innlasting melder «fullført» for en million poster. Hvordan vet du at den virket?

Du avstemmer. Mottakersiden bekrefter hver post den lagret; avsenderen sammenligner det den sendte, med det som ble bekreftet. Manglende bekreftelser betyr at den ikke virket, uansett hva jobbstatusen sier, og forteller deg hvilke poster du skal prøve på nytt, sende til en person eller varsle om. Les Delvis suksess er fortsatt feil du må forstå på nytt.

6. Et fellesskap med 15 millioner Customer Community-brukere trenger kompleks tilgang til poster. Noen foreslår Apex-deling. Hva er problemet?

De er brukere med høyt volum: ingen roller, utenfor delingsmodellen, så det finnes ingen delingspost Apex kan skrive. Tilgangen kommer fra sharing sets og share groups. Lisensen avgjorde hvilke delingsverktøy som finnes. Les Et gjennomgått eksempel: Apex-deling på nytt.

7. Et KI-verktøy genererer tjue objekter til en ny app på noen minutter. Hva er arkitektens jobb nå?

Avgjøre om vi bør ha fem. Forstå modellen godt nok til å forsvare den: hvorfor disse objektene og relasjonene, hvor nøklene og masterdataene er, hva som skjer i stor skala. Kontrollere faktaene den bygde på. Generering er ikke skjønn. Les Billig implementering flytter verdien på nytt.

Les mer

Section titled “Les mer ”