Systemene rundt Salesforce

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

Spørsmålet denne modulen besvarer: Hva omgir Salesforce, og hvilken rolle spiller hvert system?

Forrige modul sorterte dataene. Nå vil jeg plassere dem et sted, og det er her Salesforce-arkitekter havner i trøbbel. Vi kjenner Salesforce, så kundedata betyr konto (Account), ordredata betyr Order, dokumenter betyr Files, analyse betyr Reports. Men virksomheten kjøpte ikke Salesforce for å erstatte alt annet den eier. Det kan finnes et ERP som håndterer økonomi og ordreoppfyllelse, et datavarehus med mange års historikk, en integrasjonsplattform, en identitetsleverandør, partnersystemer, en hendelsesplattform, en MDM-plattform, og Data 360 som kobler flere av dem sammen. Jobben er ikke å pugge teknologier. Den er å forstå hvilken jobb hvert system har.

Ikke start med produktnavnet

«Vi har SAP» forteller meg ikke nok. Det gjør heller ikke Snowflake, MuleSoft, Tableau eller Data 360. Jeg vil vite hva systemet gjør i denne arkitekturen: hvilke data det eier, hva det leser, hva det endrer, hvem som bruker det, hva som avhenger av det, hva som skjer når det er nede. To selskaper kan eie nøyaktig de samme produktene og ha helt forskjellige arkitekturer.

Så jeg merker systemer etter rolle. Fire roller dekker det meste:

• System of record (kildesystem): der den autoritative versjonen av noe vedlikeholdes.
• Engasjementssystem (system of engagement): der folk gjør jobben.
• Referansesystem (system of reference): der et system henter informasjon det trenger, men ikke eier.
• Innsiktssystem (system of insight): der data samles for å måle, analysere og forutsi.

Én plattform kan spille flere roller, og rollene varierer med dataene. Salesforce kan være system of record for saker, engasjementssystemet for kundeserviceagentene og en mottaker av produktdata som ERP-et eier. Så når noen sier «Salesforce er vårt system of record», fullfør setningen: system of record for hva?

ERP-et: bakkontoret har tyngdekraft

ERP-et er systemet du oftest finner ved siden av Salesforce, og det håndterer økonomi, lager, innkjøp, ordreoppfyllelse og fakturering. Mønsteret fra modul 1 (kunder og produkter inn, ordrer ut) betyr at ERP-et eier produktene, men selgerne trenger dem likevel i Salesforce. Greit: hent dem inn. Men å kopiere data overfører ikke eierskap. En kopi er ikke autoritet.

Mitt standpunkt: data som ERP-et eier, leses lokalt og skrives under kontroll. Salesforce-brukerne får dataene der de jobber, men Salesforce får ikke endre det ERP-et eier. Og det gjør jeg synlig i skjemaet: ERP-ets felt har prefikset erp_, som erp_Product_Number__c, så alle som leser objektet, vet hvem som eier hvert felt og at de skal være forsiktige med å endre det. Prefikset håndhever ingenting; det gjør tillatelser, validering og integrasjonsmønsteret. Det kommuniserer intensjonen, og det er autoritetskartet gjort synlig.

Datavarehuset, datasjøen og lakehouse

Operative systemer driver virksomheten; analytiske systemer hjelper oss å forstå den. «Vis meg de åpne salgsmulighetene mine» er en rapport i Salesforce. «Vis meg fem år med salg, ordreoppfyllelse, returer, saker, lager og økonomi på tvers av alle kanaler» er et annet problem.

Du kommer til å møte tre typer analytiske lagre. Et datavarehus holder strukturerte data klargjort for analyse. En datasjø holder langt mer data i flere former, ofte rådata. Et lakehouse kombinerer de to: lagring som i en datasjø med analyse som i et datavarehus. Kjenn dem, for de dukker opp på landskap. Men min erfaring er at lakehouses og data mesh fortsatt er nisje i Salesforce-prosjekter. Det typiske landskapet er CRM, ERP, et datavarehus og et integrasjonslag, med andre plattformer der virksomheten virkelig trenger dem. Lær arkitekturen; ikke jag etter vokabularet.

Analysen bor der dataene bor

Dette er et av mine fasteste standpunkter: hvor analysen bor, følger av hvor dataene bor. Hvis rapporten bare trenger kontoer, salgsmuligheter og selgere, er alt på core: standardrapporter og dashbord. Så ber virksomheten om å legge til fakturaer fra ERP-et. Så produktkostnad. Så fem år med ordrer fra datavarehuset. Så aktivitet på nettstedet. På et tidspunkt slutter det å gi mening å dra alt det inn i det operative CRM-et bare for å rapportere på det. Så snart andre datalagre er involvert, blir en analyseplattform nødvendig: Tableau (inkludert Tableau Next, bygget på Data 360), eller CRM Analytics der det allerede er i bruk. Den er helt avgjørende når Salesforce-data slås sammen med et datavarehus. Kravet ble ikke bare mer komplisert; landskapet endret hvor spørsmålet bør besvares. Så jeg starter aldri med «hvilket analyseverktøy?» Jeg starter med hvor er dataene?

Jeg spør CTA-kandidater om det samme: «Hvilket av diagrammene mine løser dette på en vakker måte? Landskapet.» Hvis alt er på core, bruk rapporter. Hvis du har data i andre lagre, vil jeg se en analyseplattform. Landskapet svarer på rapporteringsspørsmålet før noen åpner en rapportbygger. (Produktnavnene endrer seg; kapitlet om Data 360 dekker hvor analysen i Salesforce står i dag.)

MDM: hvem er egentlig denne kunden?

Tenk deg nå at kundeinformasjonen bor i Salesforce, ERP-et, nettbutikken, en lojalitetsplattform og et partnersystem, og at hvert av dem tror det vet hvem kunden er. Det er der masterdatahåndtering (MDM) kommer inn: å etablere og styre den autoritative identiteten til viktige data på tvers av systemer. Men MDM er ikke «en masterdatabase for kunder». De vanskelige spørsmålene er hvilket system som får opprette kunden, hvilke attributter hvert system eier, hvordan duplikater blir funnet, hvilken identifikator som overlever, og hva som skjer når systemene er uenige. Kapittel 6 handler om akkurat det. Her er det nok å kjenne igjen rollen: hvis det finnes en MDM-plattform, kan den være en kritisk autoritet mellom Salesforce og resten av virksomheten.

Integrasjonslaget og hendelsene

Kobler du hvert system direkte til hvert annet, blir landskapet fort til spagetti. Derfor har virksomheter et integrasjonslag: en ESB (enterprise service bus) eller iPaaS (integrasjonsplattform som tjeneste). MuleSoft er den du oftest møter i Salesforce-landskap. Den formidler, så hver applikasjon slipper å forstå alle de andre.

Men en MuleSoft-boks i midten gjør ikke integrasjonen god. Jeg vil fortsatt vite hva som går gjennom den og hva som ikke gjør det, hvem som transformerer dataene, hvem som eier kontrakten, hva som skjer når mottakeren er nede, om det er synkront eller asynkront, og hvordan vi vet at en melding gikk gjennom. Kurset Integration Architect går i dybden; her er det nok å kjenne den igjen som en egen rolle.

Og ikke hver integrasjon er system A som kaller system B. Noen ganger skjer det noe (en ordre opprettes, en levering endrer status, en lastebil kjører inn i en region), en hendelse publiseres, og den som er interessert, reagerer. Hendelser i bevegelse har også infrastruktur: Salesforce sine egne hendelsesfunksjoner, en hendelsesbuss for virksomheten, andre meldingssystemer. Tegn mekanismene som bærer dataene, ikke bare databasene.

Systemet utviklere glemmer: identitet

Det finnes én boks jeg alltid vil ha på landskapet som utviklere sjelden tenker på: identitetsleverandøren. Utviklere logger rett inn i sandkassene sine med brukernavn og passord, så identitet er usynlig mens det bygges. Så kommer UAT eller produksjon, og plutselig finnes selskapets single sign-on for ansatte, kanskje en annen leverandør for partnere, sosial innlogging for kunder. Identitet var alltid en del av arkitekturen. Utvikleren hadde bare ikke sett det ennå.

En identitetsleverandør (IdP) er systemet som autentiserer en bruker og etablerer identiteten Salesforce stoler på. Den hører hjemme på landskapet fra første dag, selv om den konfigureres senere i release-pipelinen, fordi hvem som slipper inn, avgjør hvem som når dataene.

Det finnes også en praktisk hake: identitetskonfigurasjon kan deployes, men ikke helt. Konfigurasjon av SAML single sign-on og autentiseringsleverandører er typer i Metadata API, så de reiser gjennom pipelinen (SamlSsoConfig (opens in a new tab)). Men consumer secrets for autentiseringsleverandører returneres ikke lenger i svar fra Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), og sertifikater er som regel forskjellige fra miljø til miljø. Planlegg for delene som reiser, og delene som ikke gjør det.

Click to enlarge

Les landskapet som roller, ikke logoer: hva hvert system eier, leser eller bestemmer.

Hvor står Data 360?

Data 360 gir et fint tegnespørsmål. Jeg plasserer den til høyre, under ESB-en eller MuleSoft. Grunnen er forbindelsene: brukerne kobler seg aldri direkte til den, mens den kobler seg direkte til mange bakenforliggende systemer. Så den hører hjemme sammen med rørleggerarbeidet for data, der de linjene holder seg korte, ikke ute blant brukerne. Tegner du den som enda en skjerm folk logger inn på, forteller du feil historie.

Admins og datateam åpner riktignok skjermene i Data 360, men de skjermene er i orgen, på core. Tenanten som gjør jobben, dataene og behandlingen, kjører utenfor core. Derfor kaller jeg den nær core (near-core): administrert på core, driftet utenfor core (modul 1 forklarer begrepene). Tegningen følger tenanten: den står sammen med rørleggerarbeidet, med én linje tilbake til orgen som administrerer den.

Det den gjør, med Salesforce sine ord, inkluderer zero copy: en teknologi for dataføderering som lar en virksomhet få tilgang til og spørre mot data uten å kopiere dem (Zero Copy (opens in a new tab)). Funksjonene og konnektorene endrer seg raskt, så kapitlet om Data 360 dekker dem ordentlig i stedet for å gjøre denne modulen om til en produktomvisning.

Les landskapet som ansvar

Når du ser på et landskap, ikke les logoene; les ansvaret. ERP-et: hva eier det? Datavarehuset: hvilke spørsmål svarer det på? Integrasjonsplattformen: hva flytter den? IdP-en: hvem autentiserer den? MDM: hvilken identitet styrer den? Data 360: hva kobler den sammen, og til hva? Salesforce: hva er det egentlig ansvarlig for? Når du kan svare på det, betyr boksene noe, og pilene mellom dem blir mye mer interessante. Neste steg er å tegne dem med vilje.

Hva en arkitekt bestemmer her

• Hvilken rolle hvert system spiller, utover produktnavnet.
• Hvilket system som er autoritativt for hvert viktig datasett, og hvor Salesforce bare holder en lokal kopi.
• Om data som ERP-et eier, er tilgjengelige i Salesforce med kontrollerte skrivinger, og hvordan det eierskapet vises i skjemaet.
• Hvor analysen hører hjemme, ut fra hvor dataene bor.
• Hvor identitet, integrasjon, hendelser og autoriteten over masterdata står på landskapet.

Et landskap med ti rektangler er ikke arkitektur; det er inventar. Arkitektur starter når du kan peke på hvert rektangel og si hvorfor det er der, hva det eier, hvem som bruker det, hva Salesforce trenger fra det, og hva som går i stykker hvis du misforstår rollen.

Les mer

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab), på engelsk, kontrollert 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, kontrollert 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (produktside), på engelsk, kontrollert 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).