Väl uppbyggt ramverk

Salesforce Well-Architected Framework ger arkitekter en gemensam, principiell grund för att fatta beslut som hjälper en lösning att lyckas över tid. Den är organiserad kring fem pelare – Trust, Pålitlighet, Operativ excellens, Resurs- och kostnadsoptimering och Rättvisa – som var och en fångar en dimension av kvalitet som är viktig i varje fas av en lösnings livslängd, från inledande design till långsiktig drift och tillväxt.

Ramverket hanterar den verklighet arkitekter möter idag: människor, agenter och plattformar som arbetar tillsammans i styrda verksamhetssystem. En lösning som är säker men spröd under belastning, eller effektiv men ogenomskinlig i sina beslut, är inte väl utformad. Dessa fem pelare arbetar tillsammans för att säkerställa att kvalitet behandlas som en helhet snarare än som en checklista med oberoende intressen.

Arkitekter använder ramverket som en enhetlig lins under designgranskningar, kompromisskonversationer och pågående styrning. Den föreskriver inte ett enda rätt svar. Det ger dig rätt frågor att ställa, rätt mönster att tänka på och en gemensam vokabulär att använda mellan team.

Salesforce Well-Architected Framework är en genomtänkt guide till arkitektonisk kvalitet för lösningar byggda på Salesforce Platform. Den kodifierar de principer, mönster och kompromisser som skiljer lösningar som skalar upp och anpassar sig från de som ackumulerar tekniska skulder eller misslyckas under press.

Ramverket är organiserat kring fem pelare. Varje pelare definierar en kvalitetsdimension, artikulerar kärndesignprinciper, identifierar gemensamma mönster och ger uttrycklig vägledning för både traditionell plattformskapacitet och agentisk AI-arbetsbelastning. Tillsammans täcker pelarna omfattande vad det innebär att bygga något bra i Salesforce.

Detta ramverk är inte en produkthandbok eller en implementeringsguide. Det är ett arkitektoniskt beslutsramverk – ett sätt att tänka på kvalitet som gäller oavsett vilka moln, funktioner eller verktyg en lösning använder.

Branschramverk från molnleverantörer i hyperskala ger värdefull allmän vägledning, men de är främst byggda för molninfrastruktur och driftproblem, som virtuella datorer, nätverk, lagring och beräkning. Salesforce-arkitekter möter olika begränsningar och kapaciteter: multitenantplattform med styrande begränsningar, årtionden av verksamhetslogik i Customer 360, sofistikerade integreringslösningar, deklarativ automatisering, metadatadriven konfiguration och hanterade delningsmodeller. Dessa formar varje arkitektoniskt beslut på ett sätt som allmän molnvägledning inte kan hantera.

Övergången till autonoma agenter introducerar ytterligare överväganden. Agenter som resonerar och agerar introducerar icke-determinism, probabilistiska resonemang och Human-in-the-Loop-översynsmönster som tidigare ramverk inte ursprungligen hanterade, men ramverk med allmänna syften har börjat sträcka sig in i detta utrymme genom dedikerade AI-linser. Salesforce Well-Architected Framework hanterar både traditionell plattformsarkitektur och agentsystem genom en enhetlig lins.

Detta ramverk servar alla som är ansvariga för arkitektonisk kvalitet på Salesforce Platform:

• Salesforce Architects utformar nya lösningar eller utökar befintliga lösningar
• Salesforce-administratörer konfigurerar och säkrar de organisationer där dessa lösningar körs
• Utvecklingsleads som etablerar standarder och mönster för sina team
• Konsulter och partners som ger kunder råd om rekommenderade metoder för plattform
• AI och agentspecialister bygger och styr autonoma agentsystem

Ingen tidigare expertis inom agentisk AI krävs. Ramverket är tillgängligt för alla arkitekter samtidigt som det ger djup för dem som arbetar vid gränsen av autonoma system.

Det finns ingen enskild korrekt läsordning. Välj baserat på din roll och omedelbara behov:

• Om ramverket är nytt för dig: Läs detta översiktsdokument från början till slut och utforska sedan den pelare som är mest relevant för ditt aktuella projekt.
• Om du utformar en ny lösning: Börja med Trust och Pålitlighet (icke förhandlingsbara grunder) och gå sedan igenom Operativ excellens (hur du kommer att använda den), Resurs- och kostnadsoptimering (hur du kommer att upprätthålla den) och Rättvisa (hur du kommer att se till att den servar alla användare på ett rättvist sätt).
• Om du bygger agentlösningar: Läs Agentic Enterprise-översikten först för omfattande vägledning om agentarkitektur. Läs sedan dokumenten i huvudpelaren (länkade ovan) för grundläggande mönster—Delad ansvarsmodell, styrande begränsningar, övervakningsverktyg, TCO-modeller, tillgänglighetsstandarder—som agentlösningar bygger på. Slutligen, referera till Agentföretags pelarvarianter (länkade från varje pelare) för agentspecifika överlägg på varje kvalitetsdimension.
• Om du utför en designgranskning: Använd pelardokumenten som en strukturerad checklista för granskning. En väl genomtänkt lösning har tydliga svar på nyckelfrågorna i varje relevant pelare.

De viktigaste arkitektoniska besluten innefattar kompromisser mellan pelare. Ramverket hjälper dig göra dessa explicita:

• Trust vs. Resurs- och kostnadsoptimering: Kryptering och granskningsloggning konsumerar resurser. Ramverket hjälper dig identifiera var Trust kravet inte är förhandlingsbart jämfört med var du har flexibilitet.
• Tillförlitlighet vs. Resurs- och kostnadsoptimering: Högre tillgänglighet kostar mer. SLO-definitioner hjälper dig matcha investeringar till faktiska verksamhetskrav istället för att uppnå maximal redundans.
• Excellence jämfört med hastighet: Omfattande observerbarhet och tester tar tid att implementera. Ramverket hjälper dig identifiera den lägsta genomförbara observerbarheten för din riskprofil.
• Rättvisa kontra autonomi: Större agentautonomi möjliggör effektivitet men skapar rättviserisk. Human-in-the-Loop-mönster hjälper dig hitta rätt balans för varje beslutstyp.

Det finns inget universellt svar på dessa kompromisser. Ramverket hjälper dig ställa rätt frågor och göra kompromisser medvetet istället för att upptäcka dem i produktion.

Själva det välarkitektoniska ramverket är utformat med dessa principer i åtanke:

• Plattformsspecifik men teknikagnostisk: Vägledning hanterar Salesforce-specifika begränsningar (guvernörsgränser, arkitektur med flera klienter, metadatadriven konfiguration) utan att föreskriva specifika produkter eller funktioner. Arkitekter väljer rätt kapacitet för sitt sammanhang.
• Opineras utan att vara föreskrivande: Ramverket tar tydliga positioner om vad som utgör kvalitet men bestämmer inte en enskild implementeringsväg. Den tillhandahåller principer, mönster och frågor—inte krav.
• Framåtblickande med respekt för nuet: Ramverket hanterar nya mönster (agentisk AI, autonoma system) samtidigt som det är relevant för traditionella plattformslösningar. Båda användningsfallen har samma grundläggande principer.
• Levande, inte statisk: Ramverket utvecklas i takt med att plattformen, branschpraxis och kunders behov ändras. Ändringsloggen följer uppdateringar så att arkitekter kan hålla sig uppdaterade med ny vägledning.
• Åtgärdsbart i varje fas: Oavsett om du utformar en ny lösning, utför en granskning eller förbättrar en befintlig implementering ger ramverket relevant vägledning. Det är inte bara en checklista för certifiering—det är ett arbetsverktyg.

Dessa principer säkerställer att ramverket fortsätter vara användbart i olika arkitektoniska sammanhang samtidigt som tydliga och enhetliga riktlinjer för vad arkitektonisk kvalitet innebär för Salesforce-lösningar bibehålls.

Varje pelare omfattar en grundläggande dimension av arkitektonisk kvalitet. Tillsammans ger pelarna en omfattande täckning – ingen enskild pelare är tillräcklig på egen hand, och kompromisser mellan pelarna är där de viktigaste arkitektoniska besluten finns.

De fem följande pelarna ger grundläggande arkitektonisk vägledning för alla Salesforce-lösningar—både traditionella plattformsprogram, integreringar och agentsystem. Agentic Enterprise-översikten och dess tillhörande pelarvarianter ger det agentspecifika överlägget: hur agenter bygger på dessa kapaciteter, vad som ändras när system agerar autonomt och de arkitektoniska mönster som krävs för styrd AI.

Använd båda tillsammans:

• Börja med pelarvägledningen för centrala arkitektoniska mönster (till exempel modellen för delat ansvar, styrande gränser, övervakningsverktyg, TCO-modellering, tillgänglighetsstandarder).
• Hänvisa sedan till motsvarande Agentföretag-pelare för agentspecifika överväganden (till exempel agentbehörigheter och granskningskedjor, hantering av orkestreringsfel, Agentutvecklingslivscykel, tokenoptimering, Agentarbetsenheter, förklarlighet och möjlighet att bestrida).

Pelarna är inte “traditionella” vs. “agentiska”—de är grundläggande arkitektur som agentlösningar bygger på. Agentsystem måste uppfylla samma krav på Trust, pålitlighet, operativ kvalitet, resurs- och kostnadsoptimering och rättvisa som andra företagslösningar, med ytterligare överväganden för autonom drift.

Denna tabell ger en snabbreferens. Detaljerad vägledning för varje pelare följer.

Skydda din lösning, dess data och dess användare genom modern säkerhet, åtkomst med minst behörighet, sekretesskontroller och tydlig styrning. Trust on Salesforce arbetar genom modellen Delat ansvar: Salesforce säkrar infrastrukturen och plattformen och sedan utformar du säkra lösningar på den grunden. Ditt ansvar omfattar:

• Identitets- och åtkomsthantering (roller, profiler, behörighetsuppsättningar, MFA, SSO, OAuth)
• Datastyrning (Shield Platform Encryption, säkerhet på objekt/fält/postnivå)
• Integreringssäkerhet (API-autentisering, autentiseringsuppgifter)
• Säkra utvecklingsrutiner (OWASP Top 10 anpassad för Salesforce, statisk analys, CI/CD-säkerhetsgrindar)

För agentlösningar: När agenter agerar självständigt omfattar Trust kraven att styra vad agenter har behörighet att göra, granska vad de har gjort och säkra gränser mellan agenter (Agent Fabric, Einstein Trust Layer). Se Agentic Enterprise Trust.

Mer information finns i pelaren Trust och Agentic Enterprise Trust.

Utforma för kontinuerlig tillgänglighet, snabb återhämtning från störningar och kapacitet att skala upp under oväntade behov. Pålitlighet kräver förståelse för plattformsgarantier (infrastruktur med flera regioner, plattformsservicenivåavtal) vid utformning av lösningar som förblir pålitliga inom dessa begränsningar. Pelaren omfattar:

• Styrande begränsningar med 70 % vägledning för driftstak
• Asynkrona bearbetningsmönster (Batch Apex, Köbar Apex, Plattformshändelser)
• Effektbrytare för externa integreringar
• Kapacitetsplanering
• Lasttest
• Flerorganisationsmönster
• Katastrofåterställning
• Hälsomodellering

För agentlösningar: Agentdrivna system introducerar probabilistiskt beteende som kräver nya mönster för orkestreringsfel, brytare för kaskadagentfel och deterministiska agentgrafer där verksamhetsresultat kräver förutsägbarhet. Se Agentic Enterprise-tillförlitlighet.

Mer information finns i pelaren Tillförlitlighet och Agentic Enterprise Reliability.

Bygg in omfattande observerbarhet i din lösning och hantera den genom väldefinierade procedurer och automatisering. Operativ excellens sträcker sig över:

• Observerbarhet (händelseövervakning, Proactive Monitoring, Scale Center)
• DevOps-rutiner (källdriven utveckling, CI/CD-pipelines, teststrategi)
• Automatisering (deklarativt först med Flow Builder, programmatiska mönster med Apex)
• Incidenthantering (svårighetsgrad, jourrotation, klanderfri obduktion)
• Kontinuerliga förbättringar (DORA-mått, verksamhetsgranskningar)

För agentlösningar: Observerandet blir svårare när systembeteendet är troligt. Agentutvecklingslivscykeln (ADLC) ger struktur genom fem faser: idéer och design, utveckling, tester och validering (inklusive utvärderingar av agenttestcenter för precision, enhetlighet och efterlevnad av instruktioner), distribuering och utgivning samt övervakning och finjustering (inklusive Agentforce Sessionsspårning för fullständig interaktionssynlighet). Se Agentic Enterprise Operational Excellence.

Mer information finns i Pelaren Operationell spetskompetens och Agentic Enterprise Operationell spetskompetens.

Returnera maximalt affärsvärde för varje dollar och varje enhet av plattformsresurs, genom effektiv användning av det du har och avsiktliga investeringar i det du köper. På resurssidan innebär detta att förstå styrande gränser (SOQL-frågor, DML-uttryck, heapstorlek, CPU-tid) och utforma inom dem genom SOQL-optimering, asynkron bearbetning och förhindrande av datavridningar. På kostnadssidan innebär det omfattande TCO-modellering över både direkta kostnader (implementering, drift, underhåll) och indirekta kostnader (teknisk skuld, styrningsomkostnader) som ofta överstiger direkta licenskostnader. Pelaren omfattar:

• Kodorganisationsmönster (utlösarhanterare, servicelager, väljare)
• Paketering och modularitet (hanterade 2GP vs. olåsta paket, som båda är andra generationens paketeringstyper, LWC-sammansättning)
• Hantering av datalivscykel (arkivstrategier, flödesoptimering)
• Prestandaövervakningsverktyg (Skalacenter, Frågeplanverktyg, ApexGuru, Salesforce Code Analyzer)
• Bygg vs. köpanalys (AgentExchange-utvärdering)
• Optimering av licens och sandbox
• Kostnadsövervakning och styrning (instrumentpaneler, budgetkontroller, showback vs. chargeback-modeller)

För agentlösningar: Agentflöden blandar resursanvändning över resonemangssteg, verktygsanrop och datahämtning, så tokenanvändning, slutledningslatens och minnesmönster kräver optimering. Agentsystem introducerar även konsumtionsbaserade kostnader (flexkrediter, slutledningstokens) som är svårare att förutsäga än licensiering per användare. Agentiska arbetsenheter (AWU) mäter det arbete agenter faktiskt utför – diskreta uppgifter utförda – snarare än råtokenanvändning. Se Agentisk företagsresurs och kostnadsoptimering.

Mer information finns i pelaren Resurs- och kostnadsoptimering och Agentic Enterprise Resource and Cost Optimization.

Se till att din lösning är tillgänglig, icke-diskriminerande, inkluderande och transparent, med lämplig mänsklig kontroll över automatiserade beslut. Rättvisa bygger på plattformsgrunder. Salesforce Lightning Design System (SLDS) ger inbyggd åtkomst för standardkomponenter, medan egna komponenter kräver uttrycklig implementering av WCAG 2.1 AA (med WCAG 2.2 AA, W3C:s nuvarande rekommendation från december 2024, rekommenderad för nytt arbete). Pelaren omfattar:

• Tillgänglighetstest (axe-core, sfdx-skanner)
• Icke-diskrimineringsmönster (OWD, delningsregler, FLS med Shield Event Monitoring)
• Sekretessarkitektur (Data 360-samtyckeshantering, Fältgranskningslogg)
• AI-etisk styrning (granskningsnämnder, rättvisegrindar, efterlevnad av föreskrifter).

För agentlösningar: När agenter fattar autonoma beslut som påverkar människor ökar rättviseinsatserna. Förklarbarhet (att förstå varför en agent agerade), bestridbarhet (att utmana beslut) och Människan-i-ögat (proportionell tillsyn) blir avgörande. Se Agentic Enterprise Fairness.

Mer information finns i Pelaren Rättvisa och Agentic Enterprise Fairness.

Ingen pelare existerar isolerad. Arkitektoniska beslut inom en pelare påverkar oundvikligen andra:

• Starkare Trust (kryptering, granskningsloggning) konsumerar mer resurser och lägger till kostnader (resurs- och kostnadsoptimering) och lägger till latens som påverkar pålitligheten
• Större tillförlitlighet (redundans, flera regioner) ökar kostnaderna (resurs- och kostnadsoptimering) och den operativa komplexiteten (operativ excellens)
• Mer omfattande tillämpning av rättvisa (mänsklig tillsyn, biasövervakning) saktar ner agenters genomströmning (resurs- och kostnadsoptimering)
• Högre operativ förträfflighet (omfattande instrumentering) möjliggör bättre tillämpning av Trust och tidigare upptäckt av problem med rättvisa

Dessa interaktioner innebär att arkitektonisk kvalitet alltid är en balans. Ramverket hjälper arkitekter förstå vad de handlar med och göra dessa affärer avsiktligt. Målet är inte att maximera varje pelare samtidigt—det är att uppnå rätt kvalitetsprofil för en given lösnings krav, risktolerans och verksamhetssammanhang.

Dela din feedback om det välarkitektoniska ramverket.