Kjenn verktøyene dine: de ni spørsmålene

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

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 6 av 7 i kapitlet Tenk som en dataarkitekt, kapittel 1 i kurset Data Architect. Hver modul står på egne ben. Forrige: Bygg for i dag. Planlegg for i morgen. Planlegg for feil. · Neste: Dataarkitekten i KI-ens tid

Spørsmålet denne modulen besvarer: Hvordan vurderer du et hvilket som helst verktøy, også et du aldri har sett før?

Arkitekter trenger skjønn. Men skjønn uten kunnskap er ikke særlig nyttig. Du må fortsatt kjenne verktøyene dine.

Jeg har undervist arkitekter i mange år, og ett rammeverk jeg bruker, er et sett med spørsmål du bør kunne svare på om hvert viktige verktøy eller hver viktige funksjon i arkitekturen din. Opprinnelig underviste jeg åtte spørsmål. Jeg har lagt til et niende. Teknologiene endrer seg, Salesforce endrer seg, nye produkter dukker opp og gamle funksjoner utvikler seg, og KI setter fart på alt sammen. Disse spørsmålene fortsetter å virke.

De ni spørsmålene

Hver gang du lærer eller vurderer en teknologi, spør:

1. Hva er det?
2. Hvor brukes det?
3. Hvordan bruker jeg det?
4. Hvilke alternativer har jeg?
5. Hva er styrkene?
6. Hva er svakhetene?
7. Hvordan forklarer jeg det for utviklere, for virksomheten og for ledere?
8. Hvordan vedlikeholdes det på lang sikt?
9. Hva koster det, hvilke lisenser krever det, og hvilke grenser har det?

Hvis du kan svare på alle ni, begynner du å forstå verktøyet som en arkitekt. Legg merke til hva som ikke står på listen: «Kan jeg konfigurere det?» Det betyr noe, men det er bare en del av å kjenne verktøyet.

Click to enlarge

1. Hva er det?

Start med det åpenbare spørsmålet, for folk hopper over det overraskende ofte. Vi hører navnet på et produkt eller en funksjon og begynner straks å diskutere om vi skal bruke det. Senk farten. Hva gjør det egentlig? Hvilket problem ble det designet for å løse? Hvor sitter det i arkitekturen, og hva er det ikke? En arkitekt bør kunne beskrive en teknologi uten å gjenta markedsføringsteksten. Hvis jeg ikke kan forklare noe med noen få setninger, forstår jeg det sannsynligvis ikke godt nok ennå.

2. Hvor brukes det?

Å vite hva noe gjør, er ikke det samme som å vite når det hører hjemme i en arkitektur. Hvilke typer problemer er det godt på? Hvilke forhold gjør det passende, og hvilke forhold bør gjøre meg mistenksom? Dette er steget fra «jeg kjenner denne funksjonen» til «jeg kjenner igjen problemet denne funksjonen løser», og det er et stort steg. Du vil ikke gå rundt og lete etter steder å bruke favorittteknologien din. Du vil kjenne igjen problemer og vite hvilke verktøy som passer til dem.

3. Hvordan bruker jeg det?

Ja, arkitekter bør forstå implementering. Du trenger ikke å bygge hver komponent, men du bør forstå nok til å vite hva du ber andre om å bygge. Vit hvordan det konfigureres, hvordan en utvikler jobber med det, hvordan data kommer inn og ut, hvordan det rulles ut og sikres, og hvordan det ser ut i drift. Jeg vil ikke ha en arkitekt som designer rundt en teknologi de bare har sett på en produktslide. Bli skitten på hendene: bygg noe, ødelegg noe, se hvordan det faktisk oppfører seg. Arkitektur blir bedre når den står på virkelighetens grunn.

4. Hvilke alternativer har jeg?

Dette er kanskje det viktigste spørsmålet på listen. Hvis du bare kjenner én måte å løse et problem på, har du ikke en arkitekturbeslutning; du har en standard. Hver gang noen foreslår en teknologi, vil jeg vite hva annet vi kunne gjort. En annen funksjon i Salesforce? Noe deklarativt, eller kode? Kunne funksjonen ligget utenfor Salesforce? Kunne vi latt dataene ligge der de er i stedet for å kopiere dem, brukt en hendelse i stedet for et API-kall, eller latt være å bygge noe i det hele tatt? Alternativer skaper avveininger, og avveininger er kjernen i arkitektur.

5. Hva er styrkene?

Hvert verktøy finnes av en grunn. Forstå hva det virkelig er godt til: hva det gjør enkelt, hvor det skalerer godt, hvilken kompleksitet det fjerner, hvilke problemer det løser elegant. Bruk teknologier der styrkene deres passer med problemet. Det høres selvsagt ut, men det er veldig lett å velge et verktøy fordi vi allerede eier det, teamet kan det, det er nytt eller noen så en demo. Det kan være faktorer. Det er ikke det samme som arkitektonisk passform.

6. Hva er svakhetene?

Dette er like viktig. Hver teknologi har svakheter, hver eneste en. Hvis noen bare kan fortelle deg styrkene til en teknologi, har dere ikke en arkitekturdiskusjon ennå. Hva gjør den ikke godt? Hvor dukker kompleksiteten opp, og hva skjer i stor skala? Hvilken driftsbyrde og hvilke avhengigheter følger med? Hvilke krav skyver den ut av komfortsonen? En svakhet betyr ikke alltid at vi ikke bør bruke teknologien. Den betyr at vi må vite hva vi aksepterer. En avveining du forstår, kan være en arkitektonisk beslutning. En avveining du ikke forstår, kan bli en overraskelse.

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

Dette er et av spørsmålene som skiller teknisk kunnskap fra arkitektonisk ferdighet. Kan du forklare den samme teknologien for en utvikler, for virksomheten og for en leder? Det bør ikke være den samme forklaringen. Utvikleren trenger API-ene, transaksjonsoppførselen, sikkerheten, feilhåndteringen og implementeringsmønstrene. Virksomheten bryr seg om hva det muliggjør og hvordan prosessen deres endres. Lederen bryr seg om kostnad, risiko, tid, konsekvenser for organisasjonen og hvilke muligheter beslutningen holder åpne eller lukker. Du endrer ikke sannheten; du endrer abstraksjonsnivået. Hvis den eneste måten du kan forklare en teknologi på, er med ordene fra dokumentasjonen, må du jobbe videre med forståelsen din.

8. Hvordan vedlikeholdes det på lang sikt?

Prosjekter tar slutt. Systemer gjør ikke det, eller i hvert fall håper vi at de ikke gjør det. Noen må eie det vi bygger etter at prosjektteamet har dratt. Det betyr å vite hvordan det overvåkes, oppgraderes og feilsøkes, hvem som trenger kompetansen til å støtte det, hvordan endringer rulles ut og testes, og hva som skjer når teknologien utvikler seg eller Salesforce endrer noe under oss. Se det for deg om tre år. Jeg har sett arkitekturer som var veldig smarte på lanseringsdagen og elendige å drifte etterpå. Det er ikke suksess. Vedlikeholdbarhet er en del av arkitekturen.

9. Hva koster det, hvilke lisenser krever det, og hvilke grenser har det?

Dette er spørsmålet jeg la til de opprinnelige åtte, og i dag tror jeg det er umulig å utelate det. En teknologi kan være den perfekte tekniske løsningen og likevel den gale arkitektoniske hvis økonomien ikke går opp. Er det inkludert i lisensene vi har, eller er det et tillegg? Lisensieres det per bruker, bruk, forbruk, lagring eller transaksjoner? Hva skjer med kostnaden når vi skalerer?

Så har vi grensene, og hver plattform har dem: grenser for API, lagring, spørringer, transaksjoner, samtidighet, gjennomstrømning og lisenser. Noen er harde, noen myke; noen kan heves og noen ikke; noen betyr ingenting i vår skala før vi legger til en null til. Du trenger ikke å pugge hver grense i Salesforce, og å gjøre det ville vært en elendig bruk av tiden din. Du må vite at grensene finnes, hvilke av dem som betyr noe for arkitekturen din, og når du skal sjekke det gjeldende tallet. Tallene kommer til å endre seg. Det arkitektoniske spørsmålet består.

Et gjennomgått eksempel: Apex-deling

Her er et av de vanligste eksemplene mine på spørsmålene i praksis. Vi får et krav om komplisert deling, deling som ikke kan oppfylles med noen av de eierbaserte eller kriteriebaserte delingsreglene. Det leder oss til Apex-deling (Apex sharing): kode som skriver delingspostene selv. Så nå må vi vite hva Apex-deling er, hvor det brukes, hvordan det brukes og resten. Det er en eskalering: Apex-deling er alternativet (spørsmål 4) når reglene vi trenger, går lenger enn det eierbasert og kriteriebasert deling kan uttrykke.

Nå til svakhetene (spørsmål 6). Si at vi har et kundefellesskap med 10 eller 20 millioner medlemmer, og at vi bruker lisensen Customer Community, ikke Customer Community Plus. Det er brukere med høyt volum (high-volume users). De har ikke roller, og de bruker ikke delingsmodellen i det hele tatt: tilgangen deres kommer fra sharing sets og share groups, matchet via kontoen og kontakten deres. Det finnes ingen delingspost Apex kan skrive for dem, så Apex-deling fungerer ikke for dem. Og spørsmålet om kostnad og lisenser (spørsmål 9) er det som førte oss dit: lisensvalget avgjorde hvilke delingsverktøy som i det hele tatt finnes.

Så akkurat som Apex-deling var alternativet til eierbaserte og kriteriebaserte regler, kan du havne i en situasjon der du trenger et alternativ til Apex-deling. Og da finnes det egentlig ingen konfigurasjonsbaserte alternativer for komplekse delingsregler. Du ender opp med å gjøre objektet skrivebeskyttet og styre tilgangen gjennom Apex. Derfor stiller du alle ni spørsmålene før du velger, ikke etterpå.

Ikke pugg plattformen

Dette betyr mest når du lærer Salesforce-arkitektur. Ikke prøv å pugge Salesforce. Du klarer det ikke: plattformen er for stor, og den endrer seg for raskt. Jeg har jobbet med Salesforce lenge, og jeg lærer fortsatt. Det er normalt.

Det jeg vil at du skal utvikle, er et rammeverk for å lære. Når Salesforce lanserer en ny funksjon i morgen, trenger jeg ikke å ha sett den før. Jeg vet hva jeg skal spørre om: hva er det, hvor passer det inn, hvordan bruker jeg det, hva annet kunne jeg brukt, hva er det godt til, hvor sliter det, hvordan forklarer jeg det, hvordan drifter jeg det, og hva koster det og hvor går grensene? Nå kan jeg begynne å vurdere det. Det er mye mer verdifullt enn å pugge enda en funksjonsmatrise.

Utover eksamen: KI gjør de ni spørsmålene raskere å besvare, og lettere å svare feil på. Møter du en teknologi du ikke kjenner, kan du be KI forklare den, sammenligne tre tilnærminger, liste opp grensene og vanlige feilmåter, eller argumentere mot å bruke den. Det er en bemerkelsesverdig researchassistent. Men den kan ta feil, være utdatert eller selvsikkert blande sammen to produkter eller utgaver med lignende navn. For alt som påvirker en beslutning: kontroller det. Følg kilden og sjekk gjeldende dokumentasjon, grenser og lisenser. Stol på, men kontroller (modul 7).

Lær spørsmålene, ikke bare svarene

Vi kommer til å møte mange teknologier i kurset. Jeg vil ikke at du skal samle svar; jeg vil at du skal øve på spørsmålene. Når vi snakker om big objects, eksterne data, Data 360, integrasjonsmønstre eller en KI-funksjon Salesforce lanserer seks måneder etter at dette kapitlet ble skrevet, still de samme ni spørsmålene.

Svarene kommer til å endre seg. Spørsmålene varer. Det er det som gjør dette til et arkitekturrammeverk og ikke en studieguide.

Kjenn verktøyene dine: hva de er gode til, hva de er dårlige til, hva annet du kunne brukt, hva de koster og hvor de ryker. Og vit nok til å forklare beslutningen for dem som må leve med den. Slik lærer en arkitekt teknologi.

Hva en arkitekt bestemmer her

• Om et verktøy passer til problemet, vurdert ut fra alle ni spørsmålene, ikke bare ut fra om det kan konfigureres.
• Hva alternativene er, og hva verktøyets kostnad, lisenser og grenser betyr i din skala.
• Hvem som skal vedlikeholde det, og hvordan, om tre år.
• Hvilke fakta om verktøyet du må kontrollere før du stoler på dem.

Les mer

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-09; kontrollert på nytt 2026-10-12): brukere med høyt volum (lisensene External Apps, Customer Community, High Volume Customer Portal og Authenticated Website) har ikke roller; tilgangen deres kommer fra sharing sets og share groups; de kan ikke inkluderes i eierbaserte delingsregler, og poster de eier, kan ikke deles manuelt.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (på engelsk, kontrollert 2026-10-09; kontrollert på nytt 2026-10-12): brukere med høyt volum (Customer Community, High Volume Customer Portal, Authenticated Website) bruker ikke delingsmodellen, fordi lisensene deres ikke støtter roller; tilgangen fungerer ved at brukeren matches mot lookup-feltene til konto (Account) og kontakt (Contact), via sharing sets eller share groups. Den samme siden viser når Apex managed sharing er riktig verktøy.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), spørsmål i Trailblazer Community, november 2024 (på engelsk, kontrollert 2026-10-09; kontrollert på nytt 2026-10-12): en praktiker forteller at innsetting av delingsposter for brukere med høyt volum feilet med en feilmelding. En erfaringsrapport, ikke offisiell dokumentasjon. (Nettforumet Trailblazer Community blir skrivebeskyttet 30. oktober 2026; lenken kan endre seg.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-09): et sharing set gir tilgang til poster som er knyttet til brukerens konto eller kontakt.