Systemerne omkring Salesforce

🌐 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 3 af 6 i kapitlet Forstå virksomhedens data, kapitel 4 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Typerne af virksomhedsdata · Næste: Tegn systemlandskabet

Spørgsmålet, dette modul besvarer: Hvad omgiver Salesforce, og hvilken rolle spiller hvert system?

Det sidste modul sorterede dataene. Nu vil jeg placere dem et sted, og det er her, Salesforce-arkitekter kommer i problemer. Vi kender Salesforce, så kundedata betyder konto, ordredata betyder Order, dokumenter betyder Files, analyse betyder rapporter. Men virksomheden købte ikke Salesforce for at erstatte alt det andet, den ejer. Der kan være et ERP, der driver økonomi og ordreudførelse, et datavarehus med mange års historik, en integrationsplatform, en identitetsudbyder, partnersystemer, en hændelsesplatform, en MDM-platform og Data 360, der forbinder flere af dem. Jobbet er ikke at lære teknologier udenad. Det er at forstå, hvilket job hvert system har.

Start ikke med produktnavnet

»Vi har SAP« fortæller mig ikke nok. Det gør Snowflake, MuleSoft, Tableau eller Data 360 heller ikke. Jeg vil vide, hvad det system gør i denne arkitektur: hvilke data det ejer, hvad det læser, hvad det ændrer, hvem der bruger det, hvad der afhænger af det, hvad der sker, når det er nede. To virksomheder kan eje præcis de samme produkter og have helt forskellige arkitekturer.

Så jeg mærker systemer efter rolle. Fire roller dækker det meste:

• System of record (kildesystem): der, hvor den autoritative version af noget vedligeholdes.
• Engagementssystem: der, hvor folk udfører arbejdet.
• Referencesystem: der, hvor et system henter information, det har brug for, men ikke ejer.
• Indsigtssystem: der, hvor data samles for at måle, analysere og forudsige.

Én platform kan spille flere roller, og rollerne varierer efter data. Salesforce kan være system of record for sager, engagementssystem for servicemedarbejdere og forbruger af produktdata, som ERP’et ejer. Så når nogen siger »Salesforce er vores system of record«, så gør sætningen færdig: system of record for hvad?

ERP’et: back office har tyngdekraft

ERP’et er det system, du oftest finder ved siden af Salesforce, og det driver økonomi, lager, indkøb, ordreudførelse og fakturering. Mønsteret fra modul 1 (kunder og produkter ind, ordrer ud) betyder, at ERP’et ejer produkterne, men sælgerne skal stadig have dem i Salesforce. Fint: hent dem ind. Men at kopiere data overfører ikke ejerskab. En kopi er ikke autoritet.

Min holdning: data, som ERP’et ejer, læses lokalt og skrives under kontrol. Salesforce-brugerne får dataene der, hvor de arbejder, men Salesforce får ikke lov at ændre det, ERP’et ejer. Og det gør jeg synligt i skemaet: ERP’ets felter har præfikset erp_, som erp_Product_Number__c, så alle, der læser objektet, ved, hvem der ejer hvert felt, og at de skal være forsigtige med at ændre det. Præfikset håndhæver ingenting; det gør tilladelser, validering og integrationsmønsteret. Det kommunikerer hensigten, og det er autoritetskortet gjort synligt.

Datavarehuset, data lake og lakehouse

Operationelle systemer driver forretningen; analytiske systemer hjælper med at forstå den. »Vis mig mine åbne salgsmuligheder« er en Salesforce-rapport. »Vis mig fem års salg, ordreudførelse, returneringer, sager, lager og økonomi på tværs af alle kanaler« er et andet problem.

Du møder tre slags analytiske lagre. Et datavarehus rummer strukturerede data, der er forberedt til analyse. En data lake rummer langt flere data i flere former, ofte rå. Et lakehouse kombinerer de to: lagring som i en data lake med analyse som i et datavarehus. Kend dem, for de dukker op på landskaber. Men min erfaring er, at lakehouses og data mesh stadig er en niche i Salesforce-projekter. Det typiske landskab er CRM, ERP, et datavarehus og et integrationslag med andre platforme, hvor forretningen reelt har brug for dem. Lær arkitekturen; jag ikke ordforrådet.

Analyser bor, hvor dataene bor

Det her er en af mine fasteste holdninger: hvor analysen bor, følger af, hvor dataene bor. Hvis rapporten kun har brug for konti, salgsmuligheder og sælgere, er det hele på core: standardrapporter og dashboards. Så beder forretningen om at få ERP-fakturaer med. Så produktomkostninger. Så fem års ordrer fra datavarehuset. Så aktivitet på websitet. På et tidspunkt giver det ikke længere mening at trække alt det ind i det operationelle CRM bare for at rapportere på det. Så snart andre datalagre er involveret, bliver en analyseplatform nødvendig: Tableau (herunder Tableau Next, bygget på Data 360) eller CRM Analytics, hvor det allerede er i brug. Den er uundværlig, når Salesforce-data flettes sammen med et datavarehus. Kravet blev ikke bare mere kompliceret; landskabet ændrede, hvor spørgsmålet skal besvares. Så jeg starter aldrig med »hvilket analyseværktøj?« Jeg starter med hvor er dataene?

Jeg spørger CTA-kandidater om det samme: »Hvilket af mine diagrammer løser det her smukt? Landskabet.« Hvis alt er på core, så brug rapporter. Hvis I har data i andre lagre, vil jeg se en analyseplatform. Landskabet besvarer rapporteringsspørgsmålet, før nogen åbner en rapportbygger. (Produktnavnene ændrer sig; kapitlet om Data 360 dækker, hvor Salesforces analyse står i dag.)

MDM: hvem er denne kunde egentlig?

Forestil dig nu, at kundeinformation bor i Salesforce, ERP’et, e-handlen, en loyalitetsplatform og et partnersystem, og at hver af dem tror, den ved, hvem kunden er. Det er her, master data management kommer ind: at fastlægge og styre den autoritative identitet for nøgledata på tværs af systemer. Men MDM er ikke »en masterkundedatabase«. De svære spørgsmål er, hvilket system der må oprette kunden, hvilke attributter hvert system ejer, hvordan dubletter findes, hvilken identifikator der overlever, og hvad der sker, når systemerne er uenige. Kapitel 6 handler udelukkende om det. Her skal du genkende rollen: hvis der findes en MDM-platform, kan den være en kritisk autoritet mellem Salesforce og resten af virksomheden.

Integrationslaget og hændelserne

Forbind hvert system direkte med hvert andet, og landskabet bliver hurtigt til spaghetti. Derfor har virksomheder et integrationslag: en ESB (enterprise service bus) eller iPaaS (integration platform as a service). MuleSoft er den, du oftest møder i Salesforce-landskaber. Den formidler, så hver applikation ikke behøver at forstå alle de andre.

Men en MuleSoft-kasse i midten gør ikke integrationen god. Jeg vil stadig vide, hvad der går igennem den, og hvad der ikke gør, hvem der transformerer dataene, hvem der ejer kontrakten, hvad der sker, når modtageren er nede, om det er synkront eller asynkront, og hvordan vi ved, at en besked lykkedes. Kurset Integration Architect går i dybden; her skal du genkende det som sin egen rolle.

Og ikke alle integrationer er system A, der kalder system B. Nogle gange sker der noget (en ordre oprettes, en levering skifter status, en lastbil kører ind i en region), en hændelse publiceres, og dem, der er interesserede, reagerer. Hændelser i bevægelse har også infrastruktur: Salesforces egne hændelsesfunktioner, en hændelsesbus for hele virksomheden, anden beskedudveksling. Tegn de mekanismer, der bærer dataene, ikke kun databaserne.

Systemet, udviklere glemmer: identitet

Der er én kasse, jeg altid vil have på landskabet, som udviklere sjældent tænker på: identitetsudbyderen. Udviklere logger direkte ind i deres sandboxes med brugernavn og adgangskode, så identitet er usynlig under udviklingen. Så kommer UAT eller produktion, og pludselig er der virksomhedens single sign-on for medarbejdere, måske en anden udbyder for partnere og social login for kunder. Identitet var altid en del af arkitekturen. Udvikleren så den bare ikke endnu.

En identitetsudbyder (IdP) er det system, der autentificerer en bruger og fastlægger den identitet, Salesforce stoler på. Den hører hjemme på landskabet fra første dag, selv om den først konfigureres senere i release-pipelinen, fordi den, der bestemmer, hvem der kommer ind, bestemmer, hvem der kommer til dataene.

Der er også en praktisk komplikation: identitetskonfiguration kan deployes, men ikke helt. Konfiguration af SAML single sign-on og autentificeringsudbydere er Metadata API-typer, så de følger med gennem pipelinen (SamlSsoConfig (opens in a new tab)). Men autentificeringsudbyderes consumer secrets returneres ikke længere i svar fra Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), og certifikater er som regel forskellige fra miljø til miljø. Planlæg for de dele, der følger med, og de dele, der ikke gør.

Click to enlarge

Læs landskabet som roller, ikke logoer: hvad hvert system ejer, læser eller bestemmer.

Hvor står Data 360?

Data 360 rejser et fint tegnespørgsmål. Jeg sætter det til højre, under ESB’en eller MuleSoft. Grunden er dets forbindelser: brugerne forbinder sig aldrig direkte til det, mens det forbinder sig direkte til mange back end-systemer. Så det hører hjemme sammen med datarørføringen, hvor de linjer forbliver korte, ikke ude hos brugerne. Tegn det som endnu en skærm, folk logger ind på, og du fortæller den forkerte historie.

Admins og datateams åbner godt nok Data 360’s skærme, men de skærme er i org’en, på core. Den tenant, der udfører arbejdet, dens data og dens behandling, kører uden for core. Derfor kalder jeg det tæt på core (near-core): administreret på core, hostet uden for core (modul 1 forklarer begreberne). Tegningen følger tenanten: den står sammen med rørføringen, med én linje tilbage til den org, der administrerer den.

Det, den gør, omfatter med Salesforces ord zero copy: en teknologi til dataføderering, der lader en virksomhed tilgå og forespørge data uden at kopiere dem (Zero Copy (opens in a new tab)). Funktionerne og connectorerne ændrer sig hurtigt, så kapitlet om Data 360 dækker dem ordentligt i stedet for at gøre dette modul til en produktrundvisning.

Læs landskabet som ansvarsområder

Når du ser på et landskab, så læs ikke logoerne; læs ansvarsområderne. ERP’et: hvad ejer det? Datavarehuset: hvilke spørgsmål besvarer det? Integrationsplatformen: hvad flytter den? IdP’en: hvem autentificerer den? MDM: hvilken identitet styrer den? Data 360: hvad forbinder det, og til hvad? Salesforce: hvad er det egentlig ansvarligt for? Når du kan svare på de spørgsmål, betyder kasserne noget, og pilene imellem dem bliver langt mere interessante. Næste skridt er at tegne dem bevidst.

Hvad en arkitekt beslutter her

• Hvilken rolle hvert system spiller, ud over sit produktnavn.
• Hvilket system der er autoritativt for hvert vigtigt datasæt, og hvor Salesforce kun har en lokal kopi.
• Om data, som ERP’et ejer, er tilgængelige i Salesforce med kontrollerede skrivninger, og hvordan det ejerskab ses i skemaet.
• Hvor analysen hører hjemme, ud fra hvor dataene bor.
• Hvor identitet, integration, hændelser og autoriteten over masterdata står på landskabet.

Et landskab med ti rektangler er ikke arkitektur; det er en oversigt. Arkitektur begynder, når du kan pege på hvert rektangel og sige, hvorfor det er der, hvad det ejer, hvem der bruger det, hvad Salesforce har brug for fra det, og hvad der går i stykker, hvis du misforstår dets rolle.

Læs mere

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
• Salesforce, Zero Copy (opens in a new tab) (produktside, på engelsk, kontrolleret 2026-10-14).
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (på engelsk).