Känn dina verktyg: de nio frågorna

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 6 av 7 i kapitlet Tänk som en dataarkitekt, kapitel 1 i kursen Data Architect. Varje modul står på egna ben. Föregående: Bygg för i dag. Planera för i morgon. Planera för fel. · Nästa: Dataarkitekten i AI:s tid

Frågan den här modulen besvarar: Hur utvärderar du vilket verktyg som helst, även ett du aldrig har sett förut?

Arkitekter behöver omdöme. Men omdöme utan kunskap är inte särskilt användbart. Du måste fortfarande känna dina verktyg.

Jag har undervisat arkitekter i många år, och ett ramverk jag använder är en uppsättning frågor som du ska kunna besvara om varje viktigt verktyg eller förmåga i din arkitektur. Från början lärde jag ut åtta frågor. Jag har lagt till en nionde. Teknikerna förändras, Salesforce förändras, nya produkter dyker upp och gamla förmågor utvecklas, och AI påskyndar alltihop. De här frågorna fortsätter att fungera.

De nio frågorna

När du lär dig eller utvärderar en teknik, fråga:

1. Vad är det?
2. Var används det?
3. Hur använder jag det?
4. Vilka är mina alternativ?
5. Vilka är dess styrkor?
6. Vilka är dess svagheter?
7. Hur förklarar jag det för utvecklare, verksamheten och chefer?
8. Hur underhålls det på lång sikt?
9. Vad kostar det, vilka licenser krävs, och vilka är dess gränser?

Om du kan besvara alla nio börjar du förstå verktyget som en arkitekt. Lägg märke till vad som inte står på listan: ”Kan jag konfigurera det?” Det spelar roll, men det är bara en del av att känna verktyget.

Click to enlarge

1. Vad är det?

Börja med den uppenbara frågan, för folk hoppar över den förvånansvärt ofta. Vi hör namnet på en produkt eller funktion och börjar direkt diskutera om vi ska använda den. Sakta ner. Vad gör den egentligen? Vilket problem var den designad för att lösa? Var sitter den i arkitekturen, och vad är den inte? En arkitekt ska kunna beskriva en teknik utan att upprepa marknadsföringstexten. Om jag inte kan förklara något med några meningar förstår jag det troligen inte tillräckligt bra än.

2. Var används det?

Att veta vad något gör är inte samma sak som att veta när det hör hemma i en arkitektur. Vilka slags problem är det bra på? Vilka förutsättningar gör det lämpligt, och vilka förutsättningar ska göra mig misstänksam mot det? Det här är steget från ”jag känner till den här funktionen” till ”jag känner igen problemet som den här funktionen löser”, och det är ett stort steg. Du vill inte gå runt och leta efter ställen att använda din favoritteknik på. Du vill känna igen problem och veta vilka verktyg som passar dem.

3. Hur använder jag det?

Ja, arkitekter ska förstå implementationen. Du behöver inte bygga varje komponent, men du ska förstå tillräckligt för att veta vad du ber andra att bygga. Vet hur det konfigureras, hur en utvecklare arbetar med det, hur data kommer in och ut, hur det driftsätts och säkras, och hur det ser ut i drift. Jag vill inte att en arkitekt designar runt en teknik som den bara har sett på en produktbild. Smutsa ner händerna: bygg något, ha sönder något, se hur det faktiskt beter sig. Arkitekturen blir bättre när den är förankrad i verkligheten.

4. Vilka är mina alternativ?

Det här kan vara den viktigaste frågan på listan. Om du bara känner till ett sätt att lösa ett problem har du inget arkitekturbeslut; du har ett standardval. När någon föreslår en teknik vill jag veta vad vi annars skulle kunna göra. En annan förmåga i Salesforce? Något deklarativt, eller kod? Kan förmågan finnas utanför Salesforce? Kan vi lämna data där de är i stället för att kopiera dem, använda en händelse i stället för ett API-anrop, eller låta bli att bygga något alls? Alternativ skapar avvägningar, och avvägningar är arkitekturens hjärta.

5. Vilka är dess styrkor?

Varje verktyg finns av en anledning. Förstå vad det verkligen är bra på: vad det gör enkelt, var det skalar väl, vilken komplexitet det tar bort, vilka problem det löser elegant. Använd tekniker där deras styrkor stämmer med problemet. Det låter självklart, men det är väldigt lätt att välja ett verktyg för att vi redan äger det, teamet kan det, det är nytt eller någon såg en demo. Det kan vara faktorer. De är inte samma sak som arkitektonisk passform.

6. Vilka är dess svagheter?

Det här är lika viktigt. Varje teknik har svagheter, varenda en. Om någon bara kan berätta om en tekniks styrkor har ni inte en arkitekturdiskussion än. Vad gör den inte bra? Var dyker komplexiteten upp, och vad händer i stor skala? Vilken driftbörda och vilka beroenden för den med sig? Vilka krav trycker ut den ur det område där den fungerar bäst? En svaghet betyder inte alltid att vi inte ska använda tekniken. Den betyder att vi måste veta vad vi accepterar. En avvägning du förstår kan vara ett arkitektoniskt beslut. En avvägning du inte förstår kan bli en överraskning.

7. Hur förklarar jag det för olika målgrupper?

Det här är en av frågorna som skiljer teknisk kunskap från arkitektonisk färdighet. Kan du förklara samma teknik för en utvecklare, för verksamheten och för en chef? Det ska inte vara samma förklaring. Utvecklaren behöver API:erna, transaktionsbeteendet, säkerheten, felhanteringen och implementationsmönstren. Verksamheten bryr sig om vad det möjliggör och hur deras process förändras. Chefen bryr sig om kostnad, risk, tid, påverkan på organisationen och vilka alternativ beslutet håller öppna eller stänger. Du ändrar inte sanningen; du ändrar abstraktionsnivån. Om det enda sätt du kan förklara en teknik på är med dokumentationens ordförråd, fortsätt arbeta på din förståelse.

8. Hur underhålls det på lång sikt?

Projekt tar slut. System gör det inte, eller vi hoppas åtminstone att de inte gör det. Någon måste äga det vi bygger när projektteamet har gått. Det betyder att veta hur det övervakas, uppgraderas och felsöks, vem som behöver kompetensen för att stödja det, hur ändringar driftsätts och testas, och vad som händer när tekniken utvecklas eller Salesforce ändrar något under fötterna på oss. Föreställ dig det om tre år. Jag har sett arkitekturer som var väldigt smarta på lanseringsdagen och eländiga att driva efteråt. Det är inte framgång. Underhållbarhet är en del av arkitekturen.

9. Vad kostar det, vilka licenser krävs, och vilka är dess gränser?

Det här är frågan jag lade till de ursprungliga åtta, och i dag tycker jag att den är omöjlig att utelämna. En teknik kan vara den perfekta tekniska lösningen och ändå den fel arkitektoniska om ekonomin inte går ihop. Ingår den i de licenser vi har, eller är den ett tillägg? Licensieras den per användare, användning, konsumtion, lagring eller transaktioner? Vad händer med kostnaden när vi skalar?

Sedan finns det gränser, och varje plattform har dem: gränser för API, lagring, frågor, transaktioner, samtidighet, genomströmning och licenser. En del är hårda, en del mjuka; en del kan höjas och en del kan inte det; en del spelar ingen roll i vår skala förrän vi lägger till en nolla till. Du behöver inte memorera varje gräns i Salesforce, och att göra det vore ett fruktansvärt sätt att använda din tid. Du behöver veta att gränserna finns, vilka som spelar roll för din arkitektur och när du ska gå och kontrollera den aktuella siffran. Siffrorna kommer att ändras. Den arkitektoniska frågan finns kvar.

Ett genomarbetat exempel: Apex-delning

Här är ett av mina vanligaste exempel på frågorna i arbete. Vi får ett krav på komplicerad delning, delning som inte kan uppfyllas med någon av de ägarbaserade eller kriteriebaserade delningsreglerna. Det leder oss till Apex-delning (Apex sharing): kod som själv skriver delningsposterna. Så nu behöver vi veta vad Apex-delning är, var den används, hur man använder den och resten. Det är en upptrappning: Apex-delning är alternativet (fråga 4) för när reglerna vi behöver går längre än vad ägar- och kriteriebaserad delning kan uttrycka.

Nu till dess svagheter (fråga 6). Säg att vi har en kundcommunity med 10 eller 20 miljoner medlemmar, och vi använder licensen Customer Community, inte Customer Community Plus. Det är användare med hög volym (high-volume users). De har inga roller, och de använder inte delningsmodellen alls: deras åtkomst kommer från sharing sets och share groups, matchade via deras konto och kontakt. Det finns ingen delningspost för Apex att skriva åt dem, så Apex-delning fungerar inte för dem. Och frågan om kostnad och licenser (fråga 9) är det som förde oss dit: licensvalet avgjorde vilka delningsverktyg som alls finns.

Så precis som Apex-delning var alternativet till ägar- och kriteriebaserade regler kan du stöta på ett fall där du behöver ett alternativ till Apex-delning. Och då finns det egentligen inga konfigurationsbaserade alternativ för komplexa delningsregler. Det slutar med att du gör objektet skrivskyddat och styr åtkomsten via Apex. Det är därför du ställer alla nio frågorna innan du väljer, inte efter.

Memorera inte plattformen

Det här spelar störst roll när du lär dig arkitektur i Salesforce. Försök inte memorera Salesforce. Det går inte: plattformen är för stor, och den förändras för snabbt. Jag har arbetat med Salesforce länge, och jag lär mig fortfarande. Det är normalt.

Det jag vill att du utvecklar är ett ramverk för att lära dig. När Salesforce släpper en ny förmåga i morgon behöver jag inte ha sett den förut. Jag vet vad jag ska fråga: vad är det, var passar det in, hur använder jag det, vad annat skulle jag kunna använda, vad är det bra på, var har det svårt, hur förklarar jag det, hur driver jag det, och vad kostar det och var går gränserna? Nu kan jag börja utvärdera det. Det är mycket mer värdefullt än att memorera ännu en funktionsmatris.

Bortom provet: AI gör de nio frågorna snabbare att besvara, och lättare att få fel. Möter du en teknik du inte känner till kan du be AI att förklara den, jämföra tre angreppssätt, lista dess gränser och vanliga felsätt, eller argumentera emot att använda den. Det är en anmärkningsvärd researchassistent. Men den kan ha fel, vara inaktuell eller med stor säkerhet blanda ihop två produkter eller utgåvor med liknande namn. För allt som påverkar ett beslut: kontrollera det. Följ källan och kontrollera den aktuella dokumentationen, gränserna och licenserna. Lita, men kontrollera (modul 7).

Lär dig frågorna, inte bara svaren

Vi kommer att möta många tekniker i den här kursen. Jag vill inte att du samlar på svar; jag vill att du övar på frågorna. När vi pratar om big objects, externa data, Data 360, integrationsmönster eller en AI-förmåga som Salesforce släpper sex månader efter att det här kapitlet skrevs, ställ samma nio frågor.

Svaren kommer att ändras. Frågorna håller. Det är det som gör det här till ett arkitekturramverk snarare än en studieguide.

Känn dina verktyg: vad de är bra på, vad de är dåliga på, vad annat du kan använda, vad de kostar och var de går sönder. Och vet tillräckligt för att förklara beslutet för dem som måste leva med det. Det är så en arkitekt lär sig teknik.

Vad en arkitekt bestämmer här

• Om ett verktyg passar problemet, bedömt utifrån alla nio frågorna, inte bara utifrån om det kan konfigureras.
• Vilka alternativen är, och vad verktygets kostnad, licenser och gränser betyder i din skala.
• Vem som ska underhålla det, och hur, om tre år.
• Vilka fakta om verktyget som ska kontrolleras innan du förlitar dig på dem.

Utforska vidare

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-09; kontrollerad igen 2026-10-12): användare med hög volym (licenserna External Apps, Customer Community, High Volume Customer Portal och Authenticated Website) har inga roller; deras åtkomst kommer från sharing sets och share groups; de kan inte tas med i ägarbaserade delningsregler, och poster de äger kan inte delas manuellt.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (på engelska, kontrollerad 2026-10-09; kontrollerad igen 2026-10-12): användare med hög volym (Customer Community, High Volume Customer Portal, Authenticated Website) använder inte delningsmodellen, eftersom deras licenser inte stöder roller; åtkomsten fungerar genom att användaren matchas mot lookup-fälten för Account och Contact, via sharing sets eller share groups. Samma sida listar när Apex managed sharing är rätt verktyg.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), fråga i Trailblazer Community, november 2024 (på engelska, kontrollerad 2026-10-09; kontrollerad igen 2026-10-12): en praktiker rapporterar att det misslyckades med ett fel att infoga delningsposter för användare med hög volym. En rapport från fältet, inte officiell dokumentation. (Trailblazer Community online blir skrivskyddad den 30 oktober 2026; länken kan ändras.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-09): ett sharing set ger åtkomst till poster som är relaterade till användarens konto eller kontakt.