Kend dine værktøjer: de ni spørgsmål

🌐 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)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 6 af 7 i kapitlet Tænk som en dataarkitekt, kapitel 1 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Byg til i dag. Planlæg for i morgen. Planlæg for fejl. · Næste: Dataarkitekten i AI’s tid

Spørgsmålet, dette modul besvarer: Hvordan vurderer du et hvilket som helst værktøj, også et, du aldrig har set før?

Arkitekter har brug for dømmekraft. Men dømmekraft uden viden er ikke til meget nytte. Du skal stadig kende dine værktøjer.

Jeg har undervist arkitekter i mange år, og en af de rammer, jeg bruger, er et sæt spørgsmål, du skal kunne besvare om ethvert vigtigt værktøj eller enhver vigtig funktion i din arkitektur. Oprindeligt underviste jeg i otte spørgsmål. Jeg har tilføjet et niende. Teknologierne ændrer sig, Salesforce ændrer sig, nye produkter dukker op, gamle funktioner udvikler sig, og AI sætter fart på det hele. Spørgsmålene bliver ved med at virke.

De ni spørgsmål

Når du lærer eller vurderer en teknologi, så spørg:

1. Hvad er det?
2. Hvor bruges det?
3. Hvordan bruger jeg det?
4. Hvilke alternativer har jeg?
5. Hvad er dets styrker?
6. Hvad er dets svagheder?
7. Hvordan forklarer jeg det for udviklere, forretningen og direktører?
8. Hvordan vedligeholdes det på lang sigt?
9. Hvad koster det, hvilke licenser kræver det, og hvad er dets grænser?

Hvis du kan besvare alle ni, begynder du at forstå værktøjet som en arkitekt. Læg mærke til, hvad der ikke er på listen: »Kan jeg konfigurere det?« Det betyder noget, men det er kun en del af at kende værktøjet.

Click to enlarge

1. Hvad er det?

Start med det indlysende spørgsmål, for folk springer det overraskende ofte over. Vi hører navnet på et produkt eller en funktion og begynder straks at diskutere, om vi skal bruge det. Sæt farten ned. Hvad gør det egentlig? Hvilket problem blev det designet til at løse? Hvor sidder det i arkitekturen, og hvad er det ikke? En arkitekt skal kunne beskrive en teknologi uden at gentage markedsføringsteksten. Hvis jeg ikke kan forklare noget med få sætninger, forstår jeg det sandsynligvis ikke godt nok endnu.

2. Hvor bruges det?

At vide, hvad noget gør, er ikke det samme som at vide, hvornår det hører hjemme i en arkitektur. Hvilke slags problemer er det godt til? Hvilke forhold gør det passende, og hvilke forhold bør gøre mig mistænksom over for det? Det er skridtet fra »jeg kender denne funktion« til »jeg genkender det problem, denne funktion løser«, og det er et stort skridt. Du vil ikke gå rundt og lede efter steder at bruge din yndlingsteknologi. Du vil genkende problemer og vide, hvilke værktøjer der passer til dem.

3. Hvordan bruger jeg det?

Ja, arkitekter skal forstå implementering. Du behøver ikke bygge hver komponent, men du skal forstå nok til at vide, hvad du beder andre om at bygge. Ved, hvordan det konfigureres, hvordan en udvikler arbejder med det, hvordan data kommer ind og ud, hvordan det deployes og sikres, og hvordan det ser ud i drift. Jeg vil ikke have en arkitekt, der designer omkring en teknologi, som vedkommende kun har set på et produktslide. Få snavs på hænderne: byg noget, ødelæg noget, se, hvordan det faktisk opfører sig. Arkitektur bliver bedre, når den står på virkelighedens grund.

4. Hvilke alternativer har jeg?

Det er måske det vigtigste spørgsmål på listen. Hvis du kun kender én måde at løse et problem på, har du ikke en arkitekturbeslutning; du har en standard. Når nogen foreslår en teknologi, vil jeg vide, hvad vi ellers kunne gøre. En anden funktion i Salesforce? Noget deklarativt eller kode? Kunne funktionen ligge uden for Salesforce? Kunne vi lade dataene blive, hvor de er, i stedet for at kopiere dem, bruge en hændelse i stedet for et API-kald eller helt lade være med at bygge noget? Alternativer skaber afvejninger, og afvejninger er kernen i arkitektur.

5. Hvad er dets styrker?

Hvert værktøj findes af en grund. Forstå, hvad det virkelig er godt til: hvad det gør nemt, hvor det skalerer godt, hvilken kompleksitet det fjerner, hvilke problemer det løser elegant. Brug teknologier, hvor deres styrker passer til problemet. Det lyder indlysende, men det er meget nemt at vælge et værktøj, fordi vi allerede ejer det, teamet kender det, det er nyt, eller fordi nogen har set en demo. Det kan være faktorer. Det er ikke det samme som arkitektonisk egnethed.

6. Hvad er dets svagheder?

Det her er lige så vigtigt. Enhver teknologi har svagheder, hver eneste én. Hvis nogen kun kan fortælle dig om en teknologis styrker, har du endnu ikke en arkitekturdiskussion. Hvad gør den ikke godt? Hvor opstår kompleksiteten, og hvad sker der i stor skala? Hvilken driftsbyrde og hvilke afhængigheder bringer den med sig? Hvilke krav skubber den ud af dens komfortzone? En svaghed betyder ikke altid, at vi ikke skal bruge teknologien. Det betyder, at vi skal vide, hvad vi accepterer. En afvejning, du forstår, kan være en arkitektonisk beslutning. En afvejning, du ikke forstår, kan blive en overraskelse.

7. Hvordan forklarer jeg det for forskellige målgrupper?

Det er et af de spørgsmål, der skiller teknisk viden fra arkitektonisk færdighed. Kan du forklare den samme teknologi for en udvikler, for forretningen og for en direktør? Det skal ikke være den samme forklaring. Udvikleren har brug for API’erne, transaktionsadfærden, sikkerheden, fejlhåndteringen og implementeringsmønstrene. Forretningen går op i, hvad den gør muligt, og hvordan deres proces ændrer sig. Direktøren går op i pris, risiko, tid, betydning for organisationen, og hvilke muligheder beslutningen holder åbne eller lukker. Du ændrer ikke sandheden; du ændrer abstraktionsniveauet. Hvis du kun kan forklare en teknologi med ordene fra dens dokumentation, så arbejd videre med din forståelse.

8. Hvordan vedligeholdes det på lang sigt?

Projekter slutter. Systemer gør ikke, eller det håber vi i hvert fald. Nogen skal eje det, vi bygger, når projektteamet er gået. Det betyder, at du skal vide, hvordan det overvåges, opgraderes og fejlsøges, hvem der skal have kompetencerne til at understøtte det, hvordan ændringer deployes og testes, og hvad der sker, når teknologien udvikler sig, eller Salesforce ændrer noget under os. Forestil dig det om tre år. Jeg har set arkitekturer, der var meget snedige på lanceringsdagen og elendige at drive bagefter. Det er ikke succes. Vedligeholdelse er en del af arkitekturen.

9. Hvad koster det, hvilke licenser kræver det, og hvad er dets grænser?

Det er det spørgsmål, jeg tilføjede til de oprindelige otte, og i dag synes jeg, det er umuligt at udelade. En teknologi kan være den perfekte tekniske løsning og alligevel den forkerte arkitektoniske, hvis økonomien ikke hænger sammen. Er den inkluderet i de licenser, vi har, eller er det et tilkøb? Licenseres den pr. bruger, brug, forbrug, lagerplads eller transaktioner? Hvad sker der med prisen, når vi skalerer?

Så er der grænserne, og alle platforme har dem: grænser for API, lagerplads, forespørgsler, transaktioner, samtidighed, gennemløb og licenser. Nogle er hårde, nogle bløde; nogle kan hæves, og andre kan ikke; nogle betyder intet i vores skala, indtil vi tilføjer endnu et nul. Du behøver ikke lære alle grænser i Salesforce udenad, og det ville være en elendig måde at bruge din tid på. Du skal vide, at grænserne findes, hvilke af dem der betyder noget for din arkitektur, og hvornår du skal gå ud og efterprøve det aktuelle tal. Tallene ændrer sig. Det arkitektoniske spørgsmål består.

Et gennemgået eksempel: Apex-deling

Her er et af mine mest almindelige eksempler på spørgsmålene i brug. Vi får et krav om kompliceret deling, deling, der ikke kan opfyldes med nogen af de ejerbaserede eller kriteriebaserede delingsregler. Det fører os til Apex-deling (Apex sharing): kode, der selv skriver delingsposterne. Så nu skal vi vide, hvad Apex-deling er, hvor den bruges, hvordan den bruges og resten. Det er en optrapning: Apex-deling er alternativet (spørgsmål 4), når de regler, vi har brug for, går ud over, hvad ejer- og kriteriebaseret deling kan udtrykke.

Nu dens svagheder (spørgsmål 6). Lad os sige, at vi har et kundecommunity med 10 eller 20 millioner medlemmer, og vi bruger licensen Customer Community, ikke Customer Community Plus. Det er brugere med høj volumen (high-volume users). De har ikke roller, og de bruger slet ikke delingsmodellen: deres adgang kommer fra sharing sets og share groups, der matches via deres konto og kontakt. Der er ingen delingspost, som Apex kan skrive for dem, så Apex-deling virker ikke for dem. Og spørgsmålet om pris og licenser (spørgsmål 9) er det, der bragte os dertil: licensvalget afgjorde, hvilke delingsværktøjer der overhovedet findes.

Så ligesom Apex-deling var alternativet til ejer- og kriteriebaserede regler, kan du støde på et tilfælde, hvor du har brug for et alternativ til Apex-deling. Og på det tidspunkt er der faktisk ingen konfigurationsbaserede muligheder for komplekse delingsregler. Du ender med at gøre objektet skrivebeskyttet og styre adgangen gennem Apex. Derfor stiller du alle ni spørgsmål, før du vælger, ikke bagefter.

Lær ikke platformen udenad

Det betyder mest, når du er ved at lære Salesforce-arkitektur. Prøv ikke at lære Salesforce udenad. Det kan du ikke: platformen er for stor, og den ændrer sig for hurtigt. Jeg har arbejdet med Salesforce i lang tid, og jeg lærer stadig. Det er helt normalt.

Det, jeg vil have dig til at udvikle, er en ramme for at lære. Når Salesforce udgiver en ny funktion i morgen, behøver jeg ikke have set den før. Jeg ved, hvad jeg skal spørge om: hvad er det, hvor passer det ind, hvordan bruger jeg det, hvad kunne jeg ellers bruge, hvad er det godt til, hvor kæmper det, hvordan forklarer jeg det, hvordan driver jeg det, og hvad koster det, og hvor går grænserne? Nu kan jeg begynde at vurdere det. Det er langt mere værd end at lære endnu en funktionsmatrix udenad.

Ud over eksamen: AI gør de ni spørgsmål hurtigere at besvare og nemmere at besvare forkert. Møder du en teknologi, du ikke kender, kan du bede AI om at forklare den, sammenligne tre tilgange, opstille dens grænser og typiske fejl eller argumentere imod at bruge den. Det er en bemærkelsesværdig researchassistent. Men den kan tage fejl, være forældet eller selvsikkert blande to produkter eller udgaver med lignende navne sammen. Efterprøv alt, der påvirker en beslutning: følg kilden, og tjek den aktuelle dokumentation, de aktuelle grænser og licenser. Stol på, men efterprøv (modul 7).

Lær spørgsmålene, ikke kun svarene

Vi kommer til at møde mange teknologier i kurset. Jeg vil ikke have, at du samler på svar; jeg vil have, at du øver dig i spørgsmålene. Når vi taler om big objects, eksterne data, Data 360, integrationsmønstre eller en AI-funktion, som Salesforce udgiver seks måneder efter, at dette kapitel blev skrevet, så stil de samme ni spørgsmål.

Svarene ændrer sig. Spørgsmålene holder. Det er det, der gør det her til en arkitekturramme snarere end en studieguide.

Kend dine værktøjer: hvad de er gode til, hvad de er dårlige til, hvad du ellers kunne bruge, hvad de koster, og hvor de går i stykker. Og ved nok til at forklare beslutningen for dem, der skal leve med den. Sådan lærer en arkitekt teknologi.

Hvad en arkitekt beslutter her

• Om et værktøj passer til problemet, vurderet på alle ni spørgsmål, ikke kun på, om det kan konfigureres.
• Hvad alternativerne er, og hvad værktøjets pris, licenser og grænser betyder i din skala.
• Hvem der skal vedligeholde det, og hvordan, om tre år.
• Hvilke fakta om værktøjet der skal efterprøves, før du stoler på dem.

Læs mere

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-09; kontrolleret igen 2026-10-12): brugere med høj volumen (licenserne External Apps, Customer Community, High Volume Customer Portal og Authenticated Website) har ikke roller; deres adgang kommer fra sharing sets og share groups; de kan ikke indgå i ejerbaserede delingsregler, og poster, de ejer, kan ikke deles manuelt.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (på engelsk, kontrolleret 2026-10-09; kontrolleret igen 2026-10-12): brugere med høj volumen (Customer Community, High Volume Customer Portal, Authenticated Website) bruger ikke delingsmodellen, fordi deres licenser ikke understøtter roller; adgangen virker ved at matche brugeren med lookup-felterne til konto og kontakt via sharing sets eller share groups. Samme side beskriver, hvornår Apex managed sharing er det rigtige værktøj.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), spørgsmål i Trailblazer Community, november 2024 (på engelsk, kontrolleret 2026-10-09; kontrolleret igen 2026-10-12): en praktiker fortæller, at indsættelse af delingsposter for brugere med høj volumen fejlede med en fejlmeddelelse. En erfaring fra praksis, ikke officiel dokumentation. (Online-communityet Trailblazer Community bliver skrivebeskyttet den 30. oktober 2026; linket kan ændre sig.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-09): et sharing set giver adgang til poster, der er relateret til brugerens konto eller kontakt.