Gå til indhold
SteveTechArcSteveTechArc Courses

Tegn landskabet før org'en

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)

Kapitel 4 i Data Architect, del 1: At blive dataarkitekt. Forrige: Dataarkitektur i Salesforce.

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. Og så, først da, et første bud på datamodellen.

Folk bliver overraskede over rækkefølgen. Vi er dataarkitekter; burde vi ikke starte med datamodellen? Her er grunden til, at jeg ikke gør det. Hvis jeg tegner datamodellen først, har jeg allerede besluttet, hvad der hører hjemme i Salesforce. Hvis jeg tegner landskabet først, kan jeg se alt det, der bør forme den beslutning: ERP’et, der ejer kunderne og produkterne, datavarehuset, der besvarer femårsspørgsmålene, identitetsudbyderen, der bestemmer, hvem der kommer ind, partneren, der sender en fil hver eftermiddag, og det gamle system, som alle siger er ved at blive udfaset.

Kapitel 2 og 3 designede org’en: hvad modellen skal være, og hvordan den lever i Salesforce. Dette kapitel trækker kameraet tilbage og tegner det, der omgiver org’en, før org’en bliver designet. Salesforce er ét system blandt mange, og ret tit er det ikke det system, der ejer dataene.

Den ledende arkitekt tegner et systemlandskab omkring Salesforce på en whiteboard for to kolleger en diset morgen

Billedet er genereret med AI.

Idéerne i dette kapitel

Sektion kaldt “Idéerne i dette kapitel ”
  • Landskabet kommer først. Find systemerne, så de data, der bevæger sig mellem dem, og så hvem der ejer hver del. Først derefter beslutter du, hvad Salesforces opgave er.
  • En pil afhænger af andre pile. Ordrer ud til ERP’et kræver, at kunder, produkter og priser er kommet ind først. Hver gang jeg ser en integration med kun ét flow, begynder jeg at blive bekymret.
  • Data findes i typer og arbejdsbelastninger. Masterdata, referencedata, transaktionsdata, metadata, analytiske data og ustrukturerede data ændrer sig, vokser og bruges forskelligt; operationelle (OLTP), analytiske (OLAP) og streamende arbejdsbelastninger vil have forskellige hjem. Org’en driver forretningen; datavarehuse og data lakes analyserer den.
  • Systemer har roller, ikke bare logoer. Record, engagement, reference, indsigt. »Salesforce er vores system of record«: for hvad?
  • Hvor analysen bor, følger af, hvor dataene bor. Alt på core: standardrapporter. Data i andre lagre: en analyseplatform, og datavarehuset, når Salesforce-data flettes sammen med det.
  • Data 360 er tæt på core (near-core): administreret på core, hostet uden for core. Brugerne forbinder sig aldrig til det, så det står sammen med rørføringen.
  • Data, som ERP’et ejer, læses lokalt og skrives under kontrol, med præfikset erp_, så skemaet viser, hvem der ejer hvert felt.
  • På et landskab starter en pil ved det system, der åbner forbindelsen, og dens etiket siger, hvad der bevæger sig, og i hvilken retning. To flows er to pile; en dobbeltpil er kun til en connector.
  • Hver pil har en klient og en server, og hver ejer sin halvdel. Intet af det kommer på landskabet, men hver pil har det.
  • Tæl, før du tegner pilene. Nullerne kommer i oversigten, og de vælger mekanismen: batch, synkron eller hændelser.
  • Org-strategi er en landskabsbeslutning, truffet i de første minutter: én org eller mange, og hvor den kører.
  • En nuværende tilstand viser, hvad der er galt. Rødt for en dårlig proces, stiplet for manuelt arbejde, røde prikker for det, der mangler.

Steves landskabslayout

Sektion kaldt “Steves landskabslayout ”

Der er mange måder at tegne et systemlandskab på. Det her er min, finpudset gennem mange år, og den læses som en sætning: mennesker til venstre når Salesforce i midten, får tillid gennem systemerne over det, betjenes gennem kanalerne under det og er forbundet med back office til højre.

HvorHvad der står der
VenstreMenneskene, oppefra og ned: interne brugere, partnere, kunder
MidtenSalesforce, én enkel kasse, med sine communities, der rører den nedefra
ØverstIdentitetsudbydere over Salesforce; AppExchange skubbet til højre; offentlige websites øverst til venstre
HøjreIntegrationslaget og derefter de interne systemer: ERP, økonomi, datavarehus
Under integrationslagetData 360, tæt på core, sammen med rørføringen
NederstKundekanaler: e-mail, webformularer, telefon, beskeder
Nederst til højreData ind og ud: arkiver, dataindlæsninger, eksterne kilder, partnere

Systemer er kort i svage, navngivne zoner, hver med et ikon, og en signaturforklaring siger, hvad alt betyder. Bag billedet ligger en oversigt: for hvert datasæt eller flow dets ejer, volumen, mekanisme og timing, autentificering, og om det skal kopieres, refereres eller fødereres.

Landskabet med sine pile Det samme landskab som før, nu med pile; hver pil starter ved det system, der åbner forbindelsen, og dens etiket siger, hvad der flytter sig, og i hvilken retning. Interne brugere når Salesforce, partnerbrugere partnercommunityen, kunder kundecommunityen. Hver identitetsudbyder og Salesforce deler et certifikat, vist som en prikket grøn streg med et certifikat i hver ende: tillid, ikke et direkte kald, fordi login går gennem brugerens browser som omdirigeringer. Medarbejdernes identitetsudbyder sender også brugeropdateringer til Salesforce. Salesforce sender dokumenter ud til AppExchange-appen til e-signatur og ordrer ud til integrationslaget, som sender produkter ind i Salesforce. Integrationslaget sender ordrer ud og henter produkter ind fra ERP'en; ERP'en sender ordrestatus ind til integrationslaget; integrationslaget henter betalinger ind fra økonomi. Data 360, under integrationslaget, åbner sine forbindelser: CRM-data ud af Salesforce, zero copy til datavarehuset og en reference til de eksterne data. Nedefra sender e-mail sager ind og webformularer kundeemner ind i Salesforce; Salesforce sender gamle sager ud til arkivet; dataindlæsninger sender poster ind. OVENOVER: IDENTITET, APPEXCHANGE, WEB MENNESKER TIL HØJRE: INTERNE SYSTEMER NEDENUNDER: KUNDEKANALER NEDERST TIL HØJRE: DATA IND OG UD Interne brugere salg, service, drift Partnerbrugere Kunder Offentligt website Medarbejdernes IdP single sign-on Partnernes IdP single sign-on AppExchange-app e-signatur Partnercommunity Kundecommunity Data 360 tæt på core: styres på core, hostes uden for core INTEGRATIONSLAG (ESB) ERP ordrer, fakturaer Økonomi betalinger Ordrestyring Datavarehus analyse E-mail e-mail til sag Webformularer web til kundeemne Telefon kundeservice Beskeder sms, chat Arkiv gamle sager Dataindlæsninger migrering Eksterne data refereres, kopieres ikke Salesforce den org, vi designer omkring delt certifikat brugeropdateringer delt certifikat dokumenter ud ordrer ud produkter ind ordrer ud, produkter ind ordrestatus ind betalinger ind CRM-data ud zero copy refereret sager ind kundeemner ind gamle sager ud poster ind Salesforce en community mennesker identitet, apps, web et internt system en kundekanal data ind og ud integrationslaget stiplet: ikke i drift endnu, eller refereret starter ved det system, der åbner forbindelsen; etiketten siger, hvad der flytter sig et delt certifikat: tillid, intet direkte kald © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Landskabet fra modul 4 med sine pile.

Vejen gennem dette kapitel

Sektion kaldt “Vejen gennem dette kapitel ”

Seks moduler, der hver står på egne ben.

  1. Salesforce er ét system blandt mange. Hvorfor landskabet kommer før kassen, integrationen, jeg ser igen og igen, og de returflows, den afhænger af, data i bølger, og core, tæt på core og Hyperforce.
  2. Typerne af virksomhedsdata. Seks typer; oprettet, redigeret, refereret; OLTP og OLAP; realtid, næsten realtid og batch; de fire spørgsmål bag kategorierne.
  3. Systemerne omkring Salesforce. Systemroller; ERP’et, datavarehuset og lakehouse; analysen følger dataene; MDM; integration og hændelser; identitetsudbyderen, udviklere glemmer; hvor Data 360 står.
  4. Tegn systemlandskabet. Mit layout, bygget op fra et blankt lærred; nullerne før pilene; pile, der starter ved initiativtageren; klienten og serveren bag hver pil, begge veje; swim lanes til samtaler; oversigten bag billedet.
  5. Org-strategi er en landskabsbeslutning. Start med én org; hvad der retfærdiggør en til; regionen, ikke udbyderen; en GDPR-drevet opdeling i AMER og EMEA; hvad den anden org tilføjer.
  6. Steve Truckings landskab. I dag, før en ordentlig implementering, med markeringer: manifester, der lander i RouteDesk, ruter, der tastes ind i Salesforce og tilbage igen i hånden, en ø af GPS-data, et regneark, der fodrer økonomi, og 108.000 opkald om året med »hvor er min levering?«.

Når du er færdig, så test dig selv med studieguiden til kapitlet: en tjekliste til eksamen, vanerne ud over den, ordene du skal kende, og et par spørgsmål.

Hvad en arkitekt beslutter her

Sektion kaldt “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.
  • Hvordan hver forbindelse fungerer: hvad der bevæger sig, i hvilken retning, hvordan den autentificerer, hvor hurtigt, og hvad der kommer tilbage.
  • Hvor mange org’er, og hvor de kører, besluttet først, fordi alt andet på landskabet afhænger af det.
  • Om den nuværende tilstand er forstået godt nok til at designe en måltilstand.

Ud over eksamen: landskabet er ved at blive et agentkort. Før en agent kan svare på »hvor er min levering?«, skal nogen vide, hvilket system der er autoritativt for hvert faktum, hvor aktuelt det er, og hvordan agenten må nå det. Hvert modul slutter med, hvad AI ændrer for dets del af billedet.

Læs mere

Sektion kaldt “Læs mere ”

Næste: Datakvalitet og styring