Salesforce er ét system blandt mange

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 1 af 6 i kapitlet Forstå virksomhedens data, kapitel 4 i kurset Data Architect. Hvert modul står på egne ben. Næste: Typerne af virksomhedsdata

Spørgsmålet, dette modul besvarer: Hvorfor tegner en dataarkitekt det, der omgiver org’en, før org’en bliver designet?

Når jeg underviser CTA-kandidater, er hjemmeopgaven efter første dag altid den samme. Læs scenariet. Start systemlandskabet på et blankt lærred. Først derefter et første bud på datamodellen. Ikke objekterne, ikke integrationerne i detaljer: landskabet. Jeg vil se, hvad der omgiver Salesforce, før vi beslutter, hvad der hører hjemme inde i det.

Det er et skift i perspektiv for mange Salesforce-folk. Hvis du har brugt din karriere som admin eller udvikler, er Salesforce naturligt centrum i din verden. Du åbner Setup, opretter objekter, bygger flows, skriver Apex og integrerer andre systemer ind i Salesforce. Alt ser ud til at starte med org’en. En arkitekt må trække kameraet tilbage, for i en virksomhed er Salesforce ét system blandt mange, og ret tit er det ikke det system, der ejer dataene.

Tegn landskabet først

Kapitel 2 byggede den logiske model, og kapitel 3 spurgte, hvordan den lever i Salesforce. Nu gør jeg problemet større. Før jeg beslutter, hvad Salesforce skal eje, vil jeg forstå virksomheden omkring det. Hvilke systemer findes allerede? Hvor bliver kunder oprettet, produkter defineret, ordrer startet, fakturaer genereret? Hvor bor identiteten? Hvor foregår analysen, hvor opbevares dokumenterne, hvor ligger historikken? Hvilke systemer har brug for Salesforces data, og hvilke afhænger Salesforce af?

De spørgsmål ændrer arkitekturen. Så jeg starter på et blankt lærred, sætter Salesforce i midten og tegner alt omkring det. Modul 4 viser præcis, hvordan jeg lægger det op. Indtil videre er lektien ganske enkelt: design ikke org’en, før du forstår den verden, den skal leve i.

Salesforce er ofte ikke system of record

Tag en meget almindelig virksomhed: Salesforce plus et ERP, et system til virksomhedens ressourcestyring (enterprise resource planning) som SAP eller Oracle, der driver økonomi, produkter, lager, indkøb og ordreudførelse. Stil nu et enkelt spørgsmål: hvor bor kunden?

Det kan være Salesforce, ERP’et eller begge, og det er her, det bliver interessant. Sælgerne arbejder måske med emner som konti i Salesforce, mens ERP’et udsteder det officielle kundenummer, når de bliver betalende kunder. Produkter og priser? Sandsynligvis ERP’et. Lager? Næsten aldrig Salesforce. Ordrer bliver måske registreret i Salesforce og udført i ERP’et; fakturaer kommer fra ERP’et; service bor i Salesforce; analysen er delt mellem Salesforce-rapporter og et datavarehus. Pludselig er vores pæne datamodel i Salesforce ikke virksomhedens datamodel. Den er én del af den.

Integrationen, jeg ser igen og igen

Den mest almindelige integration, jeg ser, ser sådan ud: kunder, produkter og priser flyder ind i Salesforce fra ERP’et, og ordrer flyder ud. Sæt SAP, Oracle eller et hvilket som helst andet ERP ind; formen er den samme. ERP’et ejer golden record for kunden og produktet, så de flows kommer fra højre, ind i Salesforce. Salg lukker aftalen i Salesforce, så ordren starter der og går tilbage til ERP’et for at blive udført, faktureret og bogført.

De flows er ikke bare integrationer. De fortæller mig, hvor virksomheden mener, sandheden bor.

Envejspile gør mig nervøs

Hver gang jeg ser en integration, der kun har ét flow, begynder jeg at blive bekymret. På det overordnede niveau tegner nogen en enkelt pil: ordrer fra Salesforce til ERP’et. Fint. Kig nu dybere. Hvordan kan jeg sende en ordre til ERP’et, hvis jeg ikke kender dets kunder, dets produkter eller dets priser? Ordren skal knyttes til en kunde, ERP’et allerede har, og hver linje skal være en SKU, ERP’et allerede sælger. Jeg kan ikke sende en ordrelinje for et produkt, der ikke findes på den anden side. Så før den ordrepil kan virke, skal der findes returflows, der løber den anden vej.

Det er det spørgsmål, jeg stiller til hver pil: hvad afhænger dette flow af? Den overordnede pil, du kan se, har som regel brug for returflows, du ikke har tegnet endnu.

Kig endnu dybere, og du finder returrejsen. Salesforce sender en ordre. Hvad så? Blev den accepteret eller afvist? Blev den afsendt, delvist afsendt, annulleret? Blev den faktureret? Skal nogen i Salesforce vide det? Måske ikke. Men nogen burde have spurgt. Hvis intet kommer tilbage, fint. Fortæl mig hvorfor.

Virksomheden kom ikke på én gang

Landskaber bliver komplicerede, blandt andet fordi ingen byggede dem på én gang. Data er kommet i bølger. Først filer: poster i fast format, derefter afgrænsede filer som CSV. Så relationsdatabaser til operationelle data. Så datavarehuse for at samle det hele til analyse. Så NoSQL-databaser til dokumenter, nøgle-værdi-par og grafer, der ikke passer pænt ind i tabeller. Så data lakes til enorme mængder rå og semistrukturerede data og lakehouses, der kombinerer de to. Hændelsesstrømme, som Kafka eller Salesforces event bus, flytter data, mens det sker, i stedet for i natlige batches. Og nu føderering, hvor data ikke skal kopieres ét sted hen, før en anden platform kan bruge dem.

Teknologien er ikke pointen endnu. Det her er: den nye bølge får sjældent den gamle til at forsvinde. Gå ind i en stor virksomhed, og du finder dem alle på én gang: relationsdatabaser, ERP’et, Salesforce, et datavarehus, en data lake, SFTP-drops, API’er, hændelsesstrømme, regnearket, som nogen stadig mailer hver fredag, og det ene system, alle er bange for at røre, fordi den person, der byggede det, gik på pension for seks år siden. Det er den virksomhed, du designer arkitektur til, ikke den i produktbrochuren.

Forskellige systemer findes af forskellige grunde

Det er også derfor, jeg aldrig starter med »hvordan får vi alle data ind i Salesforce?« Hvorfor skulle jeg have dem alle der? Salesforce er måske det bedste sted for salgs- og servicefolk at arbejde med kunder. Det gør det ikke til økonomisystemet, virksomhedens datavarehus, telemetrilageret, dokumentarkivet eller hjemmet for hvert klik, hver GPS-måling og hver historisk transaktion, virksomheden nogensinde har produceret.

Kapitel 3 spurgte hvor skal disse data bo? for én org. På virksomhedsniveau bliver det samme spørgsmål større: nogle gange ejer Salesforce dataene, nogle gange har det en kopi, nogle gange bare en reference, og nogle gange skal det slet ikke have dem.

Core, uden for core og Hyperforce

Der er en anden grænse, du skal forstå: selv »Salesforce« er ikke én runtime og én database. I kapitel 3 betød på core, hvor dataene ligger: på dit skrivebord, i org’ens egne objekter. Her beskriver de samme ord, hvor et produkt kører. Du vil høre arkitekter bruge begge betydninger.

Historisk husede Core-runtimen det meste af platformen. I dag beskriver Salesforce en platform af hundredvis af uafhængige, metadatadrevne tjenester, hvor Core fortsat er det eneste system of record for applikationsmetadata (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Derfor vil du høre arkitekter sige, at en funktion kører på core eller uden for core.

Det betød noget længe før, platformen blev delt op i tjenester. Når jeg spørger en klasse, hvorfor Salesforce købte SteelBrick til tilbud i stedet for Apttus, er det svar, jeg leder efter, enkelt: SteelBrick var bygget 100 % på core. Flows og triggers bor i core, så et produkt, der er bygget der, får platformens metadata, tilpasninger og automatisering med. Det tilbudsprodukt er siden afløst af Revenue Cloud, men lektien består. Så er der tæt på core (near-core), og Data 360 er det eksempel, jeg bruger. Data 360 er ikke core. Dets tenant ligger uden for core: dataene og de mekanismer, der behandler dem, kører i deres eget lakehouse ved siden af org’ens relationsdatabase i stedet for inde i den (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Men de skærme, du bruger til at sætte det op og styre det, vises på core, i org’en. Så den mest præcise måde, jeg kan sige det på, er: administreret på core, hostet uden for core. Ingen af dataene eller behandlingen kører faktisk i Core; brugerfladen på Core styrer tenanten uden for core. Og så er der selvfølgelig alt det, der er uden for core, fordi det slet ikke er Salesforce.

Jeg går mindre op i at lære udenad, hvilket produkt der kører hvor i år, for det ændrer sig, end i vanen: en grænse kan påvirke dataflytning, latens, identitet, integration og dataopbevaringssted. Så gå ikke ud fra, at fordi der står Salesforce på et produkt, ligger dets data lige ved siden af dine kontoposter. Kig på den faktiske arkitektur.

Så er der Hyperforce: Salesforces infrastruktur bygget til den offentlige cloud og defineret som kode i stedet for de traditionelle egne datacentre, som giver kunderne flere valg over, hvor deres data opbevares (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Det betyder noget, og modul 5 vender tilbage til det. Men infrastrukturarkitektur er ikke virksomhedens dataarkitektur. At flytte en org til den offentlige cloud fortæller dig ikke, hvem der ejer kunden, hvor lageret bor, hvor analysen kører, eller hvilke data der må krydse en grænse. Hyperforce kan forme nogle af de beslutninger, især om dataopbevaringssted. Det erstatter ikke at kende landskabet.

Landskabet kommer før kassen

Så her er vanen. Nogen giver dig et scenarie. Begynd ikke at bygge Salesforce-løsningen. Find først systemerne: ERP’et, identitetsudbyderen, datavarehuset, integrationsplatformen, partnersystemer, kundekanaler, dokumentlagre. Find så de data, der bevæger sig mellem dem: kunder, produkter, ordrer, fakturaer, dokumenter, hændelser, identiteter. Spørg så, hvem der ejer hver af dem. Først derefter beslutter du, hvad der hører hjemme i Salesforce. Ellers designer du en kasse uden at vide, hvad den er forbundet med.

Click to enlarge

Trin 1 af 3: den org, vi designer, alene. Herfra ligner den hele verden.

Click to enlarge

Trin 2 af 3: zoom ud. Salesforce er ét system blandt mange (modul 4 lærer dig dette layout).

Click to enlarge

Trin 3 af 3: de første pile. Kunder, produkter og priser ind fra ERP’et, ordrer ud: de viser, hvor virksomheden mener, sandheden bor.

Landskabet ændrer datamodellen

Det er derfor, det betyder noget for en dataarkitekt. Kapitel 2 siger, at kunden er en vigtig enhed. Fint. Så siger landskabet, at ERP’et er autoritativt for kunden. Det ændrer den fysiske model. Salesforce beholder måske stadig en lokal konto, fordi folk bruger den hver dag, men nu skal vi have ERP’ets identifikator som et External ID; vi skal vide, hvilke felter Salesforce må ændre (jeg markerer ERP’ets felter med præfikset erp_, som vi ser i modul 3); hvor hurtigt ændringer fra ERP’et kommer; om Salesforce kan oprette en kunde, før ERP’et kender til den; og hvad der sker, når de to er uenige. Det er ikke integrationsspørgsmål til senere. Det er dataarkitekturspørgsmål, og landskabet afslørede dem.

Sådan bider et af dem. En sælger konverterer et kundeemne for et stort drikkevarefirma, opretter kontoen, vinder aftalen, og kunden går over til ERP’et. Men virksomheden har handlet med det drikkevarefirma i årevis, og ERP’et har dem allerede. Nu er der to. Burde sælgeren overhovedet have kunnet oprette den konto? Kapitel 5 og 6 vender tilbage til det; landskabet er der, hvor du ser det komme.

Hvad en arkitekt beslutter her

• Hvilke systemer der omgiver Salesforce, og hvilken rolle hvert af dem spiller.
• Hvilket system der ejer hver vigtig type data, før det besluttes, hvor meget af dem Salesforce gemmer.
• Hvad der flyder ind i Salesforce, hvad der flyder ud, og hvad der kommer tilbage.
• Hvilke data Salesforce skal eje, kopiere, referere til, føderere, arkivere eller lade være.
• Hvilke platforms- og infrastrukturgrænser der betyder noget, i stedet for at gå ud fra, at alt med Salesforce-navnet bor ét sted.

Skiftet fra udvikler til arkitekt handler ofte ikke om at lære endnu en funktion. Det handler om at lære, hvornår man skal holde op med at kigge på Salesforce: træk kameraet tilbage, følg dataene, find ud af, hvem der ejer sandheden, og kom så tilbage og beslut, hvad Salesforces opgave skal være.

Læs mere

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