Salesforce är ett system bland många

🌐 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 1 av 6 i kapitlet Förstå företagets data, kapitel 4 i kursen Data Architect. Varje modul står på egna ben. Nästa: Typerna av företagsdata

Frågan den här modulen besvarar: Varför ritar en dataarkitekt det som omger orgen innan orgen designas?

När jag undervisar CTA-kandidater är läxan efter första dagen alltid densamma. Läs scenariot. Börja på systemlandskapet från en tom duk. Först då gör du ett försök med datamodellen. Inte objekten, inte integrationerna i detalj: landskapet. Jag vill se vad som omger Salesforce innan vi bestämmer vad som hör hemma därinne.

Det är ett perspektivbyte för många som arbetar med Salesforce. Om du har ägnat din karriär åt att vara admin eller utvecklare är Salesforce naturligt nog centrum i din värld. Du öppnar Setup, skapar objekt, bygger flöden, skriver Apex och integrerar andra system in i Salesforce. Allt verkar börja med orgen. En arkitekt måste zooma ut kameran, för i ett företag är Salesforce ett system bland många, och ganska ofta är det inte det system som äger data.

Rita landskapet först

Kapitel 2 byggde den logiska modellen, och kapitel 3 frågade hur den lever i Salesforce. Nu ska jag göra problemet större. Innan jag bestämmer vad Salesforce ska äga vill jag förstå företaget runt det. Vilka system finns redan? Var skapas kunderna, definieras produkterna, startas ordrarna, genereras fakturorna? Var bor identiteten? Var sker analysen, var förvaras dokumenten, var ligger historiken? Vilka system behöver data från Salesforce, och vilka är Salesforce beroende av?

De frågorna ändrar arkitekturen. Så jag börjar från en tom duk, sätter Salesforce i mitten och ritar allt runt det. Modul 4 visar exakt hur jag lägger upp det. För tillfället är lärdomen helt enkelt: designa inte orgen innan du förstår världen den måste leva i.

Salesforce är ofta inte system of record

Ta ett mycket vanligt företag: Salesforce plus ett ERP, ett affärssystem (enterprise resource planning) som SAP eller Oracle, som sköter ekonomi, produkter, lager, inköp och leverans. Ställ nu en enkel fråga: var bor kunden?

Det kan vara Salesforce, ERP:t eller båda, och det är där det blir intressant. Säljarna kanske arbetar med prospekt som konton (Account) i Salesforce, medan ERP:t utfärdar det officiella kundnumret när de blir betalande kunder. Produkter och priser? Förmodligen ERP:t. Lager? Nästan aldrig Salesforce. Ordrar kanske fångas i Salesforce och levereras via ERP:t; fakturor kommer från ERP:t; service bor i Salesforce; analysen är uppdelad mellan rapporter i Salesforce och ett datalager. Plötsligt är vår fina datamodell i Salesforce inte företagets datamodell. Den är en del av den.

Integrationen jag ser om och om igen

Den vanligaste integrationen jag ser ser ut så här: kunder, produkter och priser flödar in i Salesforce från ERP:t, och ordrar flödar ut. Byt till SAP, Oracle eller vilket annat ERP som helst; formen är densamma. ERP:t äger golden record för kunden och produkten, så de flödena kommer från höger, in i Salesforce. Säljarna stänger affären i Salesforce, så ordern börjar där och går tillbaka till ERP:t för att levereras, faktureras och bokföras.

De flödena är inte bara integrationer. De talar om för mig var företaget tror att sanningen bor.

Enkelriktade pilar gör mig nervös

Varje gång jag ser en integration som bara har ett flöde börjar jag bli orolig. På den övergripande nivån ritar någon en enda pil: ordrar från Salesforce till ERP:t. Okej. Titta nu djupare. Hur kan jag skicka en order till ERP:t om jag inte känner till dess kunder, dess produkter eller dess priser? Ordern måste knytas till en kund som ERP:t redan har, och varje rad måste vara en SKU som ERP:t redan säljer. Jag kan inte skicka en orderrad för en produkt som inte finns på andra sidan. Så innan orderpilen kan fungera måste det finnas returflöden som går åt andra hållet.

Det är frågan jag ställer om varje pil: vad är det här flödet beroende av? Den övergripande pilen du ser behöver oftast returflöden som du inte har ritat än.

Titta ännu djupare så hittar du returresan. Salesforce skickar en order. Sedan då? Accepterades den eller avvisades den? Skickades den, delvis skickad, avbröts den? Fakturerades den? Behöver någon i Salesforce veta det? Kanske inte. Men någon borde ha frågat. Om inget kommer tillbaka, okej. Säg varför.

Företaget kom inte på en gång

Landskap blir komplicerade delvis för att ingen byggde dem på en gång. Data har kommit i vågor. Först filer: poster med fast format, sedan avgränsade filer som CSV. Sedan relationsdatabaser för operativa data. Sedan datalager för att föra samman dem för analys. Sedan NoSQL-databaser för dokument, nyckel-värde-par och grafer som inte passar snyggt i tabeller. Sedan datasjöar för enorma mängder råa och semistrukturerade data, och lakehouses som kombinerar de två. Händelseströmmar, som Kafka eller händelsebussen i Salesforce, flyttar data när något händer i stället för i nattliga batcher. Och nu federering, där data inte måste kopieras till ett ställe innan en annan plattform kan använda dem.

Tekniken är inte poängen än. Det här är: den nya vågen får sällan den gamla att försvinna. Gå in i ett stort företag så hittar du alla på en gång: relationsdatabaser, ERP:t, Salesforce, ett datalager, en datasjö, SFTP-filer, API:er, händelseströmmar, kalkylarket som någon fortfarande mejlar varje fredag, och det enda systemet som alla är rädda att röra eftersom personen som byggde det gick i pension för sex år sedan. Det är företaget du designar arkitekturen för, inte det i produktbroschyren.

Olika system finns av olika skäl

Det är också därför jag aldrig börjar med ”hur får vi in all data i Salesforce?”. Varför skulle jag vilja ha allt där? Salesforce kan vara det bästa stället för sälj- och servicefolk att arbeta med kunder. Det gör det inte till ekonomisystemet, företagets datalager, lagret för telemetri, dokumentarkivet eller hemmet för varje klick, varje GPS-avläsning och varje historisk transaktion som företaget någonsin har producerat.

Kapitel 3 frågade var ska de här data bo? för en org. På företagsnivå blir samma fråga större: ibland äger Salesforce data, ibland sparar det en kopia, ibland bara en referens, och ibland ska det inte ha dem alls.

Core, utanför core och Hyperforce

Det finns en annan gräns att förstå: inte ens ”Salesforce” är en körmiljö och en databas. I kapitel 3 betydde på core var data ligger: på ditt skrivbord, i orgens egna objekt. Här beskriver samma ord var en produkt körs. Du kommer att höra arkitekter använda båda.

Historiskt var det körmiljön Core som drev det mesta av plattformen. I dag beskriver Salesforce en plattform med hundratals oberoende, metadatadrivna tjänster, där Core förblir det enda system of record för applikationsmetadata (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Det är därför du hör arkitekter säga att en förmåga körs på core eller utanför core.

Det spelade roll långt innan plattformen delades upp i tjänster. När jag frågar en klass varför Salesforce köpte SteelBrick för offerter i stället för Apttus är svaret jag är ute efter enkelt: SteelBrick var byggt till 100 % på core. Flöden och triggers bor i core, så en produkt som byggs där får plattformens metadata, anpassningar och automatisering på köpet. Den offertprodukten har sedan dess fått ge plats åt Revenue Cloud, men lärdomen finns kvar. Sedan har vi nära core (near-core), och Data 360 är exemplet jag använder. Data 360 är inte core. Dess tenant ligger utanför core: data och mekanismerna som bearbetar dem körs i ett eget lakehouse, bredvid orgens relationsdatabas i stället för i den (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Men skärmarna du använder för att sätta upp och styra det visas på core, i orgen. Så det mest exakta sättet jag kan uttrycka det på: hanteras på core, driftas utanför core. Inget av data eller bearbetningen körs faktiskt i Core; gränssnittet på Core styr tenanten utanför core. Och sedan finns förstås allt som är utanför core för att det inte är Salesforce alls.

Jag bryr mig mindre om att plugga in vilken produkt som körs var i år, eftersom det ändras, än om vanan: en gräns kan påverka dataflöden, latens, identitet, integration och datalokalisering. Så anta inte att data ligger precis bredvid dina kontoposter bara för att en produkt heter Salesforce. Titta på den faktiska arkitekturen.

Sedan har vi Hyperforce: Salesforce infrastruktur byggd för det publika molnet och definierad som kod, i stället för de traditionella egna datacentren, vilket ger kunderna större val av var deras data finns (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Det spelar roll, och modul 5 återkommer till det. Men infrastrukturarkitektur är inte företagets dataarkitektur. Att flytta en org till det publika molnet säger inget om vem som äger kunden, var lagret finns, var analysen körs eller vilka data som får korsa en gräns. Hyperforce kan forma några av de besluten, särskilt datalokalisering. Det ersätter inte kunskapen om landskapet.

Landskapet kommer före lådan

Så här är vanan. Någon ger dig ett scenario. Börja inte bygga lösningen i Salesforce. Hitta först systemen: ERP:t, identitetsleverantören, datalagret, integrationsplattformen, partnersystem, kundkanaler, dokumentlager. Hitta sedan data som rör sig mellan dem: kunder, produkter, ordrar, fakturor, dokument, händelser, identiteter. Fråga sedan vem som äger var och en. Först då bestämmer du vad som hör hemma i Salesforce. Annars designar du en låda utan att veta vad den kopplas till.

Click to enlarge

Steg 1 av 3: orgen vi designar, ensam. Härifrån ser den ut som hela världen.

Click to enlarge

Steg 2 av 3: zooma ut. Salesforce är ett system bland många (modul 4 lär ut den här layouten).

Click to enlarge

Steg 3 av 3: de första pilarna. Kunder, produkter och priser in från ERP:t, ordrar ut: de visar var företaget anser att sanningen finns.

Landskapet ändrar datamodellen

Det är därför det spelar roll för en dataarkitekt. Kapitel 2 säger att kunden är en viktig entitet. Okej. Sedan säger landskapet att ERP:t är auktoritativt för kunden. Det ändrar den fysiska modellen. Salesforce kanske fortfarande har ett lokalt konto, eftersom folk använder det varje dag, men nu behöver vi ERP:ts identifierare som External ID; vi behöver veta vilka fält Salesforce får ändra (jag märker ERP:ts fält med prefixet erp_, som vi ska se i modul 3); hur snabbt ändringar i ERP:t kommer fram; om Salesforce kan skapa en kund innan ERP:t känner till den; och vad som händer när de två inte stämmer överens. Det är inte integrationsfrågor för senare. Det är frågor om dataarkitektur, och landskapet blottlade dem.

Så här kan en av dem bita. En säljare konverterar en lead för ett stort dryckesföretag, skapar kontot, vinner affären, och kunden går över till ERP:t. Men företaget har gjort affärer med det dryckesföretaget i flera år, och ERP:t har det redan. Nu finns det två. Borde säljaren alls ha kunnat skapa det kontot? Kapitel 5 och 6 återkommer till det; landskapet är där du ser det komma.

Vad en arkitekt bestämmer här

• Vilka system som omger Salesforce, och vilken roll vart och ett spelar.
• Vilket system som äger varje viktig typ av data, innan du bestämmer hur mycket av den Salesforce sparar.
• Vad som flödar in i Salesforce, vad som flödar ut, och vad som kommer tillbaka.
• Vilka data Salesforce ska äga, kopiera, referera, federera, arkivera eller låta bli.
• Vilka plattforms- och infrastrukturgränser som spelar roll, i stället för att anta att allt som bär varumärket Salesforce bor på ett ställe.

Steget från utvecklare till arkitekt handlar ofta inte om att lära sig ännu en funktion. Det handlar om att lära sig när man ska sluta titta på Salesforce: zooma ut kameran, följ data, ta reda på vem som äger sanningen, och kom sedan tillbaka och bestäm vad Salesforce jobb ska vara.

Utforska vidare

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (på engelska, kontrollerad 2026-10-14).