Rita landskapet före orgen

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Kapitel 4 i Data Architect, Del 1: Att bli dataarkitekt. Föregående: Dataarkitektur i Salesforce.

När jag undervisar CTA-kandidater är läxan efter första dagen alltid densamma. Läs scenariot. Börja på systemlandskapet från en tom duk. Sedan, och först då, gör ett försök med datamodellen.

Folk blir förvånade över ordningen. Vi är dataarkitekter; borde vi inte börja med datamodellen? Här är varför jag inte gör det. Om jag ritar datamodellen först har jag redan bestämt vad som hör hemma i Salesforce. Om jag ritar landskapet först ser jag allt som borde forma det beslutet: ERP:t som äger kunderna och produkterna, datalagret som besvarar femårsfrågorna, identitetsleverantören som bestämmer vem som kommer in, partnern som skickar en fil varje eftermiddag, det gamla systemet som alla säger ska avvecklas.

Kapitel 2 och 3 designade orgen: vad modellen ska vara, och hur den lever i Salesforce. Det här kapitlet zoomar ut kameran och ritar det som omger orgen, innan orgen designas. Salesforce är ett system bland många, och ganska ofta är det inte det system som äger data.

Bilden är genererad med AI.

Idéerna i det här kapitlet

• Landskapet kommer först. Hitta systemen, sedan data som rör sig mellan dem, sedan vem som äger varje del. Först då bestämmer du vad Salesforce jobb är.
• En pil är beroende av andra pilar. Ordrar ut till ERP:t kräver att kunder, produkter och priser först har kommit in. Varje gång jag ser en integration med bara ett flöde börjar jag bli orolig.
• Data finns i olika typer, och arbetslaster. Masterdata, referensdata, transaktionsdata, metadata, analytiska data och ostrukturerade data ändras, växer och används på olika sätt; operativa (OLTP), analytiska (OLAP) och strömmande arbetslaster vill ha olika hem. Orgen driver verksamheten; datalager och datasjöar analyserar den.
• System har roller, inte bara logotyper. Record, engagement, reference, insight. ”Salesforce är vårt system of record”: för vad?
• Var analysen bor följer var data bor. Allt på core: standardrapporter. Data i andra lager: en analysplattform, och datalagret när data från Salesforce slås ihop med dem.
• Data 360 är nära core (near-core): hanteras på core, driftas utanför core. Användarna ansluter aldrig till det, så det hör hemma bland rören.
• Data som ERP:t äger läses lokalt och skrivs under kontroll, med prefixet erp_ så att schemat visar vem som äger varje fält.
• På ett landskap börjar en pil vid systemet som öppnar kopplingen, och dess etikett säger vad som rör sig och åt vilket håll. Två flöden är två pilar; en dubbelriktad pil är bara för en connector.
• Varje pil har en klient och en server, och var och en äger sin halva. Inget av det hamnar på landskapet, men varje pil har det.
• Räkna innan du ritar pilarna. Nollorna hamnar i inventeringen, och de väljer mekanismen: batch, synkront eller händelser.
• Org-strategi är ett landskapsbeslut, som fattas under de första minuterna: en org eller flera, och var den körs.
• Ett nuläge visar vad som är fel. Rött för en dålig process, streckat för det som görs för hand, röda prickar för det som saknas.

Steves layout för landskap

Det finns många sätt att rita ett systemlandskap. Det här är mitt, förfinat under många år, och det läses som en mening: människorna till vänster når Salesforce i mitten, betrodda via systemen ovanför, betjänade via kanalerna under och kopplade till back office till höger.

Var	Vad som hamnar där
Vänster	Människorna, uppifrån och ned: interna användare, partner, kunder
Mitten	Salesforce, en enkel låda, med sina communities som nuddar den underifrån
Överst	Identitetsleverantörer ovanför Salesforce; AppExchange förskjutet åt höger; publika webbplatser uppe till vänster
Höger	Integrationslagret, sedan de interna systemen: ERP, ekonomi, datalager
Under integrationslagret	Data 360, nära core, bland rören
Nederst	Kundkanaler: e-post, webbformulär, telefon, meddelanden
Nere till höger	Data in och ut: arkiv, dataladdningar, externa källor, partner

Systemen är kort i svaga, märkta zoner, vart och ett med en ikon, och en teckenförklaring säger vad allt betyder. Bakom bilden finns en inventering: för varje datamängd eller flöde, dess ägare, volym, mekanism och tidpunkt, autentisering, och om den ska kopieras, refereras eller federeras.

Click to enlarge

Landskapet från modul 4, med sina pilar.

Vägen genom kapitlet

Sex moduler, som var och en står på egna ben.

1. Salesforce är ett system bland många. Varför landskapet kommer före lådan, integrationen jag ser om och om igen och returflödena den är beroende av, data i vågor, och core, nära core och Hyperforce.
2. Typerna av företagsdata. Sex typer; skapas, redigeras, refereras; OLTP och OLAP; realtid, nära realtid och batch; de fyra frågorna bakom kategorierna.
3. Systemen runt Salesforce. Systemroller; ERP:t, datalagret och lakehouse; analysen följer data; MDM; integration och händelser; identitetsleverantören som utvecklare glömmer; var Data 360 hör hemma.
4. Rita systemlandskapet. Min layout, uppbyggd från en tom duk; nollorna före pilarna; pilar som börjar vid initiativtagaren; klienten och servern bakom varje pil, åt båda hållen; simbanor för samtal; inventeringen bakom bilden.
5. Org-strategi är ett landskapsbeslut. Börja med en org; vad som motiverar en till; regionen, inte leverantören; en uppdelning i AMER och EMEA driven av GDPR; vad den andra orgen tillför.
6. Steve Truckings landskap. I dag, före en ordentlig implementering, markerat: manifest som landar i RouteDesk, rutter som knappas in i Salesforce och tillbaka för hand, en ö av GPS-data, ett kalkylark som matar ekonomi, och 108 000 samtal om året om ”var är min leverans?”.

När du är klar kan du testa dig själv med kapitlets studieguide: en checklista inför provet, vanorna bortom det, orden att kunna och några frågor.

Vad en arkitekt bestämmer här

• Vilka system som omger Salesforce, och vilken roll vart och ett spelar.
• Vilket system som äger varje viktig typ av data, innan du bestämmer hur mycket av den Salesforce sparar.
• Hur varje koppling fungerar: vad som rör sig, åt vilket håll, hur den autentiserar, hur snabbt, och vad som kommer tillbaka.
• Hur många orgar, och var de körs, bestämt först, eftersom allt annat på landskapet beror på det.
• Om nuläget är tillräckligt väl förstått för att designa ett målläge.

Bortom provet: landskapet håller på att bli en karta för agenter. Innan en agent kan svara på ”var är min leverans?” måste någon veta vilket system som är auktoritativt för varje faktum, hur aktuellt det är och hur agenten får nå det. Varje modul avslutas med vad AI ändrar i sin del av bilden.

Utforska vidare

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Vidare läsning för CTA-kandidater: Salesforce Architects publicerar sin egen vägledning för diagram, How to Build Salesforce Diagrams (opens in a new tab) (på engelska).

Nästa: Datakvalitet och styrning