Gå til indhold
SteveTechArcSteveTechArc Courses

Tænk som en dataarkitekt

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 1 i kurset Data Architect. Læs de syv moduler først; denne side hjælper dig med at tjekke, hvad der er blevet hængende.

Om denne studieguide. Den er udelukkende bygget 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å.

Dette kapitel har færre eksamensfakta, og det er med vilje. Det handler om, hvordan en arkitekt tænker, og intet eksamensmål hører til det alene. Men eksamen er bygget af scenarier: en virksomhed, nogle tal, en begrænsning og flere svar, der kunne virke. Vanerne i dette kapitel er den måde, du læser de scenarier på. Så tjeklisten nedenfor siger, hvilket mål hvert punkt understøtter, i stedet for at påstå, at det testes direkte.

Til eksamen

Sektion kaldt “Til eksamen ”

Sæt flueben, efterhånden som du kommer frem. Hvert punkt linker til det sted, hvor det gennemgås.

At læse et scenarie som en arkitekt (understøtter alle mål)

  • Jeg skiller det egentlige krav fra det design, det kom forklædt som (»vi skal have felterne Godkender 2 og Godkender 3« over for »vi skal registrere hver eneste godkendelse«). (Tag ikke bare imod kravet)
  • Jeg leder efter de underforståede krav, som ingen har udtalt: ejerskab, friskhed, fejl, opbevaring, adgang. (Se efter de underforståede krav)
  • Jeg sætter tal på: volumen pr. dag, pr. år, med vækst, og jeg lægger mærke til, når ét nul mere ændrer svaret. (Kend dine tal)
  • Blandt flere svar, der virker, sammenligner jeg, hvad hvert af dem vinder og giver afkald på, med de angivne krav og begrænsninger. (Ved, hvad du giver afkald på, Begrænsninger ændrer svaret)
  • Jeg behandler pris, licenser og grænser som en del af, om et værktøj passer, ikke som en eftertanke. (De ni spørgsmål)

Datamodellen (understøtter DM-1)

At ændre det, der allerede findes (understøtter DM-1 og SDM-2)

  • Jeg ved, hvorfor det at ændre et felts type eller gøre et eksisterende felt Required (påkrævet) kan få ting til at gå i stykker senere, og hvorfor platformen blokerer en typeændring, så længe kode eller flows refererer til feltet. (Vær forsigtig med at ændre skelettet)
  • Jeg kender mønsteret tilføj frem for at ændre, udfas frem for at overraske, og ved, at Field Usage kan markere et felt som kandidat til udfasning. (Vær forsigtig med at ændre skelettet)
  • Jeg kender fakta om master-detail bag reversibilitetstesten: detaljepostens adgang og ejerskab følger masterposten, sletter du en masterpost, slettes dens detaljeposter, oversigtsfelter (roll-up summary) kræver master-detail, og en lookup-relation kan kun konverteres til master-detail, når hver post har en værdi. (Reversibilitetstesten, Læs mere)

Licenser og deling (understøtter SDM-1)

  • Jeg ved, at community-brugere med høj volumen (high-volume users, heriblandt Customer Community) ikke har roller og ikke bruger delingsmodellen, så adgangen kommer fra sharing sets og share groups, og Apex-deling kan ikke nå dem. (Et gennemgået eksempel: Apex-deling)

Fejl (understøtter MIG-1 og integrationskapitlerne)

Ud over eksamen

Sektion kaldt “Ud over eksamen ”

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

  • Nogen skal holde tegningen. Arkitektur er at træffe gode beslutninger med ufuldstændig information og at kende deres konsekvenser.
  • Datamodellen er skelettet. Alt andet bygges oven på den.
  • Reversibilitetstesten: hvor svært er det her at omgøre, og hvor meget vil afhænge af det?
  • Arkitektur skaber tyngdekraft. Det er afhængighederne, der gør forandring dyr, ikke forandringen i sig selv.
  • Tænk på sprængradiussen, inde i Salesforce og på tværs af virksomheden. Arkitektur er trafik i begge retninger.
  • Skriv ned hvorfor: kontekst, muligheder, beslutning, konsekvenser, ejer, revision. Erstat; slet ikke.
  • Bedst til hvad? En suboptimal beslutning kan være en del af en optimal arkitektur, hvis du ved, at du træffer den.
  • Hav et billede af det optimale, så du ved, i hvilken retning du bevæger dig væk fra det, og hvorfor.
  • Think Correct. Think Fast. Hastighed kommer af tænkning, der er gjort, før øjeblikket kommer.
  • Byg til i dag. Planlæg for i morgen. Planlæg for fejl. Og brug 30 % vækst, når ingen giver dig et tal.
  • Lær de ni spørgsmål, ikke kun svarene.
  • AI er en raketbooster. At generere er ikke at vurdere, det, der ikke kan omgøres, kan stadig ikke omgøres, og menneskelig gennemgang er ikke en ceremoni. Stol på, men efterprøv.

Ord du skal kende

Sektion kaldt “Ord du skal kende ”
TermPå én linje
Arkitektonisk beslutningEn beslutning, der er svær at omgøre, og som meget afhænger af
ReversibilitetstestenHvor svært er det her at omgøre, og hvor meget vil afhænge af det?
TyngdekraftDe afhængigheder, der samler sig om en beslutning over tid
Sprængradius (blast radius)Alt det andet, der flytter sig, når en beslutning ændres
BeslutningslogKontekst, muligheder, beslutning, konsekvenser, ejer og revisionstidspunkt, holdt kort
AfvejningHvad en mulighed vinder, og hvad den giver afkald på for at få det
Underforstået kravNoget, forretningen forventer uden at spørge, som gendannelse, når en indlæsning fejler
Steves »antal nuller«Ét nul mere i volumen kan ændre hele arkitekturen
AfstemningAt sammenligne det, der skulle være sket, med det, der skete, post for post
UdfaseAt markere noget som på vej ud og så pensionere det bevidst i stedet for at ændre det på stedet
Bruger med høj volumen (high-volume user)En community-bruger (heriblandt licensen Customer Community) uden rolle, uden for delingsmodellen
Skemaer, der vokser vildt (schema sprawl)Objekter og felter, der hober sig op, fordi de var billige at lave, indtil ingen har designet modellen

Test dig selv

Sektion kaldt “Test dig selv ”

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

1. Et salgsteam beder om felterne Godkender 2 og Godkender 3, hver med en dato, på salgsmuligheden (Opportunity). Hvad spørger du om, og hvad kunne du bygge?

Spørg hvorfor, og hvor mange godkendelser der kan være. Hvis der kan være flere end to eller tre, er kravet at registrere hver eneste godkendelse, ikke at tilføje felter: et underordnet objekt med én post pr. godkendelse. Læs Tag ikke bare imod kravet igen.

2. Én vil omdøbe et felts etiket, og en anden vil ændre formatet på det kunde-id, som fem systemer allerede gemmer. Hvad fortjener mest af din opmærksomhed, og hvorfor?

Id’et. Etiketten er billig at ændre. Id’et dumper reversibilitetstesten: svært at omgøre, og meget afhænger allerede af det. Brug opmærksomhed i forhold til prisen for at tage fejl. Læs Nogle beslutninger er billige at ændre igen.

3. Et tekstfelt har været i brug i årevis. Forretningen vil nu have, at det skal indeholde et tal. Hvordan griber du det an?

Ændr det ikke på stedet. Find ud af, hvad der afhænger af det (Flows, Apex, rapporter, integrationer, agenter), og hvad der sker med de gamle data. Som regel: tilføj et nyt felt, migrér bevidst, og udfas det gamle. Læs Vær forsigtig med at ændre skelettet igen.

4. 1.200 lokationer, 100 aftaler pr. lokation om dagen, cirka 305 dage om året, to poster pr. aftale, fem års opbevaring, 30 % vækst. Cirka hvor mange poster, og hvorfor betyder det noget?

Cirka 73 millioner poster det første år (36,6 millioner aftaler med to poster hver) og over 650 millioner over fem år med vækst. Samme funktion, et par nuller mere, en helt anden arkitektur. Læs Kend dine tal igen.

5. En natlig indlæsning melder »fuldført« for en million poster. Hvordan ved du, at den virkede?

Du afstemmer. Den modtagende side bekræfter hver post, den har gemt; afsenderen sammenligner det, den sendte, med det, der blev bekræftet. Manglende bekræftelser betyder, at den ikke virkede, uanset hvad jobstatus siger, og fortæller dig, hvilke poster der skal prøves igen, sendes til et menneske eller udløse en alarm. Læs Delvis succes er stadig fejl, du skal forstå igen.

6. Et community med 15 millioner Customer Community-brugere har brug for kompleks adgang til poster. Nogen foreslår Apex-deling. Hvad er problemet?

Det er brugere med høj volumen: ingen roller, uden for delingsmodellen, så der er ingen delingspost, som Apex kan skrive. Adgangen kommer fra sharing sets og share groups. Licensen afgjorde, hvilke delingsværktøjer der findes. Læs Et gennemgået eksempel: Apex-deling igen.

7. Et AI-værktøj genererer tyve objekter til en ny app på få minutter. Hvad er arkitektens job nu?

Beslut, om vi skal have fem. Forstå modellen godt nok til at forsvare den: hvorfor disse objekter og relationer, hvor nøglerne og masterdataene er, hvad der sker i stor skala. Efterprøv de fakta, den byggede på. At generere er ikke at vurdere. Læs Billig implementering flytter værdien igen.

Læs mere

Sektion kaldt “Læs mere ”