Salesforce er ett system blant mange

🌐 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 1 av 6 i kapitlet Forstå virksomhetens data, kapittel 4 i kurset Data Architect. Hver modul står på egne ben. Neste: Typene virksomhetsdata

Spørsmålet denne modulen besvarer: Hvorfor tegner en dataarkitekt det som omgir orgen før orgen designes?

Når jeg underviser CTA-kandidater, er hjemmeleksen etter første dag alltid den samme. Les scenarioet. Start systemlandskapet fra et blankt lerret. Først da gjør du et forsøk på datamodellen. Ikke objektene, ikke integrasjonene i detalj: landskapet. Jeg vil se hva som omgir Salesforce før vi bestemmer hva som hører hjemme inni det.

Det er et perspektivskifte for mange som jobber med Salesforce. Har du brukt karrieren som admin eller utvikler, er Salesforce naturlig nok midten av verdenen din. Du åpner Setup, lager objekter, bygger flows, skriver Apex og integrerer andre systemer inn i Salesforce. Alt ser ut til å starte med orgen. En arkitekt må trekke kameraet bakover, for i en virksomhet er Salesforce ett system blant mange, og ganske ofte er det ikke det systemet som eier dataene.

Tegn landskapet først

Kapittel 2 bygget den logiske modellen, og kapittel 3 spurte hvordan den lever i Salesforce. Nå skal jeg gjøre problemet større. Før jeg bestemmer hva Salesforce skal eie, vil jeg forstå virksomheten rundt det. Hvilke systemer finnes allerede? Hvor blir kunder opprettet, produkter definert, ordrer startet, fakturaer laget? Hvor bor identitet? Hvor skjer analysen, hvor oppbevares dokumentene, hvor ligger historikken? Hvilke systemer trenger dataene i Salesforce, og hvilke er Salesforce avhengig av?

De spørsmålene endrer arkitekturen. Så jeg starter fra et blankt lerret, setter Salesforce i midten og tegner alt rundt det. Modul 4 viser nøyaktig hvordan jeg legger det opp. Foreløpig er lærdommen ganske enkelt: ikke design orgen før du forstår verdenen den skal leve i.

Salesforce er ofte ikke system of record

Ta en helt vanlig virksomhet: Salesforce pluss et ERP, et system for virksomhetsstyring (enterprise resource planning) som SAP eller Oracle, som håndterer økonomi, produkter, lager, innkjøp og ordreoppfyllelse. Still så et enkelt spørsmål: hvor bor kunden?

Det kan være Salesforce, ERP-et eller begge, og det er der det blir interessant. Selgerne kan jobbe med potensielle kunder som kontoer (Accounts) i Salesforce, mens ERP-et utsteder det offisielle kundenummeret når de blir betalende kunder. Produkter og priser? Sannsynligvis ERP-et. Lagerbeholdning? Nesten aldri Salesforce. Ordrer kan registreres i Salesforce og oppfylles i ERP-et; fakturaene kommer fra ERP-et; service bor i Salesforce; analysen er delt mellom rapporter i Salesforce og et datavarehus. Plutselig er ikke den fine datamodellen vår i Salesforce virksomhetens datamodell. Den er én del av den.

Integrasjonen jeg ser igjen og igjen

Den vanligste integrasjonen jeg ser, går slik: kunder, produkter og priser flyter inn i Salesforce fra ERP-et, og ordrer flyter ut. Bytt inn SAP, Oracle eller et hvilket som helst annet ERP; formen er den samme. ERP-et eier golden record for kunden og produktet, så de flytene kommer fra høyre, inn i Salesforce. Salg lukker avtalen i Salesforce, så ordren starter der og går tilbake til ERP-et for å bli oppfylt, fakturert og regnskapsført.

De flytene er ikke bare integrasjoner. De forteller meg hvor virksomheten mener sannheten bor.

Enveispiler gjør meg nervøs

Hver gang jeg ser en integrasjon som bare har én flyt, begynner jeg å bli bekymret. På overordnet nivå tegner noen én enkelt pil: ordrer fra Salesforce til ERP-et. Greit. Se nå dypere. Hvordan kan jeg sende en ordre til ERP-et hvis jeg ikke kjenner kundene, produktene eller prisene dets? Ordren må knyttes til en kunde ERP-et allerede har, og hver linje må være et varenummer (SKU) ERP-et allerede selger. Jeg kan ikke sende en ordrelinje for et produkt som ikke finnes på den andre siden. Så før den ordrepilen kan fungere, må det finnes returflyter som går den andre veien.

Det er spørsmålet jeg stiller hver pil: hva avhenger denne flyten av? Den overordnede pilen du ser, trenger som regel returflyter du ikke har tegnet ennå.

Ser du enda dypere, finner du returreisen. Salesforce sender en ordre. Hva så? Ble den godtatt eller avvist? Ble den sendt, delvis sendt, kansellert? Ble den fakturert? Trenger noen i Salesforce å vite det? Kanskje ikke. Men noen burde ha spurt. Hvis ingenting kommer tilbake, greit. Fortell meg hvorfor.

Virksomheten kom ikke på én gang

Landskap blir kompliserte blant annet fordi ingen bygget dem på én gang. Data har kommet i bølger. Filer først: poster med fast format, så skilletegnseparerte filer som CSV. Så relasjonsdatabaser for operative data. Så datavarehus for å samle dem til analyse. Så NoSQL-databaser for dokumenter, nøkkel-verdi-par og grafer som ikke passer pent i tabeller. Så datasjøer for enorme mengder rådata og semistrukturerte data, og lakehouses som kombinerer de to. Hendelsesstrømmer, som Kafka eller hendelsesbussen i Salesforce, flytter data etter hvert som ting skjer, i stedet for i nattlige batcher. Og nå føderering, der data ikke må kopieres til ett sted før en annen plattform kan bruke dem.

Teknologien er ikke poenget ennå. Dette er det: den nye bølgen får sjelden den gamle til å forsvinne. Gå inn i en stor virksomhet, så finner du alle samtidig: relasjonsdatabaser, ERP-et, Salesforce, et datavarehus, en datasjø, SFTP-filer, API-er, hendelsesstrømmer, regnearket noen fortsatt sender på e-post hver fredag, og det ene systemet alle er redde for å røre fordi personen som bygget det, gikk av med pensjon for seks år siden. Det er virksomheten du designer arkitekturen for, ikke den i produktbrosjyren.

Forskjellige systemer finnes av forskjellige grunner

Det er også derfor jeg aldri starter med «hvordan får vi alle dataene inn i Salesforce?» Hvorfor skulle jeg ville ha alt der? Salesforce kan være det beste stedet for salgs- og servicefolk å jobbe med kunder. Det gjør det ikke til økonomisystemet, virksomhetens datavarehus, telemetrilageret, dokumentarkivet eller hjemmet for hvert klikk, hver GPS-måling og hver historiske transaksjon selskapet noen gang har produsert.

Kapittel 3 spurte hvor bør disse dataene bo? for én org. På virksomhetsnivå blir det samme spørsmålet større: noen ganger eier Salesforce dataene, noen ganger holder det en kopi, noen ganger bare en referanse, og noen ganger burde det ikke ha dem i det hele tatt.

Core, utenfor core og Hyperforce

Det finnes en annen grense å forstå: selv «Salesforce» er ikke én kjøretid og én database. I kapittel 3 betydde på core hvor dataene ligger: på pulten din, i orgens egne objekter. Her beskriver de samme ordene hvor et produkt kjører. Du vil høre arkitekter bruke begge.

Historisk sett var det Core-kjøretiden som hostet det meste av plattformen. I dag beskriver Salesforce en plattform med hundrevis av uavhengige, metadatadrevne tjenester, der Core fortsatt er det eneste system of record for applikasjonsmetadata (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Derfor hører du arkitekter si at en funksjon kjører på core eller utenfor core.

Det betydde noe lenge før plattformen ble delt opp i tjenester. Når jeg spør en klasse hvorfor Salesforce kjøpte SteelBrick for tilbud i stedet for Apttus, er svaret jeg er ute etter, enkelt: SteelBrick var bygget 100 % på core. Flows og triggere bor i core, så et produkt bygget der får med seg plattformens metadata, tilpasninger og automatisering. Det tilbudsproduktet har siden gitt plass til Revenue Cloud, men lærdommen består. Så har vi nær core (near-core), og Data 360 er eksemplet jeg bruker. Data 360 er ikke core. Tenanten er utenfor core: dataene og mekanismene som behandler dem, kjører i sitt eget lakehouse, ved siden av orgens relasjonsdatabase i stedet for inni den (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Men skjermene du bruker til å sette den opp og styre den, vises på core, i orgen. Så den mest presise måten jeg kan si det på, er: administrert på core, driftet utenfor core. Ingen av dataene eller behandlingen kjører faktisk i Core; brukergrensesnittet på Core styrer tenanten utenfor core. Og så er det selvsagt alt som er utenfor core fordi det ikke er Salesforce i det hele tatt.

Jeg bryr meg mindre om å pugge hvilket produkt som kjører hvor i år, for det endrer seg, enn om vanen: en grense kan påvirke dataflyt, forsinkelse, identitet, integrasjon og datalagringssted. Så ikke anta at fordi et produkt heter Salesforce, ligger dataene rett ved siden av kontopostene dine. Se på den faktiske arkitekturen.

Så har vi Hyperforce: Salesforces infrastruktur bygget for den offentlige skyen og definert som kode, i stedet for de tradisjonelle egne datasentrene, som gir kundene flere valg om hvor dataene deres ligger (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Det betyr noe, og modul 5 kommer tilbake til det. Men infrastrukturarkitektur er ikke virksomhetens dataarkitektur. Å flytte en org til den offentlige skyen forteller deg ikke hvem som eier kunden, hvor lagerbeholdningen bor, hvor analysen kjører, eller hvilke data som får krysse en grense. Hyperforce kan forme noen av de beslutningene, særlig om datalagringssted. Det erstatter ikke det å kjenne landskapet.

Landskapet kommer før boksen

Så her er vanen. Noen gir deg et scenario. Ikke begynn å bygge Salesforce-løsningen. Finn først systemene: ERP-et, identitetsleverandøren, datavarehuset, integrasjonsplattformen, partnersystemer, kundekanaler, dokumentlagre. Finn så dataene som beveger seg mellom dem: kunder, produkter, ordrer, fakturaer, dokumenter, hendelser, identiteter. Spør så hvem som eier hver av dem. Først da bestemmer du hva som hører hjemme i Salesforce. Ellers designer du en boks uten å vite hva den kobles til.

Click to enlarge

Steg 1 av 3: orgen vi designer, alene. Herfra ser den ut som hele verden.

Click to enlarge

Steg 2 av 3: zoom ut. Salesforce er ett system blant mange (modul 4 lærer deg dette oppsettet).

Click to enlarge

Steg 3 av 3: de første pilene. Kunder, produkter og priser inn fra ERP-et, ordrer ut: de viser hvor virksomheten mener sannheten bor.

Landskapet endrer datamodellen

Derfor betyr dette noe for en dataarkitekt. Kapittel 2 sier at kunden er en viktig entitet. Greit. Så sier landskapet at ERP-et er autoritativt for kunden. Det endrer den fysiske modellen. Salesforce kan fortsatt holde en lokal konto, fordi folk bruker den hver dag, men nå trenger vi ERP-ets identifikator som External ID; vi må vite hvilke felt Salesforce får endre (jeg merker ERP-ets felt med prefikset erp_, som vi skal se i modul 3); hvor fort endringer fra ERP-et kommer; om Salesforce kan opprette en kunde før ERP-et vet om den; og hva som skjer når de to er uenige. Det er ikke integrasjonsspørsmål for senere. Det er dataarkitekturspørsmål, og landskapet avdekket dem.

Slik kan ett av dem bite. En selger konverterer et kundeemne for et stort drikkevareselskap, oppretter kontoen, vinner avtalen, og kunden går over til ERP-et. Men selskapet har gjort forretninger med det drikkevareselskapet i årevis, og ERP-et har det allerede. Nå finnes det to. Burde selgeren i det hele tatt kunnet opprette den kontoen? Kapittel 5 og 6 kommer tilbake til det; landskapet er der du ser det komme.

Hva en arkitekt bestemmer her

• Hvilke systemer som omgir Salesforce, og hvilken rolle hvert av dem spiller.
• Hvilket system som eier hver viktig type data, før du bestemmer hvor mye av dem Salesforce beholder.
• Hva som flyter inn i Salesforce, hva som flyter ut, og hva som kommer tilbake.
• Hvilke data Salesforce skal eie, kopiere, referere til, føderere, arkivere eller la være.
• Hvilke plattform- og infrastrukturgrenser som betyr noe, i stedet for å anta at alt med Salesforce-merket bor på ett sted.

Skiftet fra utvikler til arkitekt handler ofte ikke om å lære enda en funksjon. Det handler om å lære når du skal slutte å se på Salesforce: trekk kameraet bakover, følg dataene, finn ut hvem som eier sannheten, og kom så tilbake og bestem hva Salesforce sin jobb skal være.

Les mer

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