Frågan den här modulen besvarar: Hur ritar jag ett landskap som visar vart data tar vägen?
Ge mig ett nytt scenario och en tom whiteboard, så är systemlandskapet en av de första saker jag ritar. Inte snyggt, inte varje API, inte datamodellen än. Jag vill se företaget: vilka användarna är, vilka system som är inblandade, var Salesforce hamnar, vad som omger det, var data kommer ifrån och vart de tar vägen. Och sedan vill jag gå igenom pilarna. Ett bra landskap är ingen bild av lådor. Det är ett sätt att blotta arkitektoniska beslut.
Jag låter CTA-kandidater öva på det här. Läs scenariot och börja sedan rita. Vänta inte tills du har löst allt i huvudet; ritandet hjälper dig att lösa det. Därför är läxan efter dag ett att börja på landskapet innan du gör ett försök med datamodellen. Rita datamodellen först så har du redan antagit vad som hör hemma i Salesforce. Rita landskapet först så ser du systemen som borde forma det beslutet.
Börja högt upp och borra sedan nedåt: hela företaget först, sedan detaljerna där de spelar roll.
Det finns många sätt att rita ett systemlandskap. Det här är bara mitt sätt, ett som jag har förfinat under många år, och jag delar det så att du ser hur du snabbt sätter ihop ett. Jag använder det för varje landskap med Salesforce, 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.
Människorna till vänster, uppifrån och ned: interna användare, partner, kunder. Inte varje persona än; tillräckligt för att besvara vem försöker nå den här arkitekturen? Varje grupp pekar dit den kommer in: interna användare till Salesforce, partner till partnercommunityn, kunder till kundcommunityn. System finns inte för sin egen skull. Någon, eller något, försöker använda dem.
Steg 2 av 6: vem försöker nå den här arkitekturen?
Salesforce i mitten. En enkel låda. Inte för att Salesforce är företagets centrum (vi har just ägnat tre moduler åt att säga att det inte är det) utan för att det är systemet jag designar runt. Det är ankaret.
Communities precis under, så att de nuddar. En partnercommunity och en kundcommunity är separata slutpunkter, så de får egna lådor. Men de ligger an mot Salesforce, eftersom inget behöver integreras för att nå dem: de körs i samma org.
Steg 3 av 6: Salesforce i mitten, communities precis under.
Identitet ovanför. Identitetsleverantörerna hamnar högst upp, de som utvecklare glömmer: en för interna användare, kanske en annan för partner. AppExchange-paket hamnar också där uppe, förskjutna åt höger, eftersom de är förmågor som tas in i orgen snarare än back office-system som utbyter data med den. Publika webbplatser hamnar uppe till vänster.
Steg 4 av 6: identitet ovanför, lådan som utvecklare glömmer.
Integration, sedan back office, till höger. Integrationslagret, en ESB eller iPaaS (eller MuleSoft, när det nämns vid namn), är en hög stapel precis till höger om Salesforce. De interna systemen ligger bakom det: ERP-systemen, ekonomi, orderhantering, äldre system, datalagret. Nu läses sidan från vänster till höger: människor, Salesforce, integration, back office.
Kanaler under. Allt som har en direkt linje till kunderna: email-to-case, web-to-lead, telefon, meddelanden.
Data in och ut, nere till höger. Externa datakällor, arkiv, dataladdningar.
Data 360 till höger, under integrationslagret. Användarna ansluter aldrig till det, och dess tenant ansluter till många system i bakänden, så det hör hemma bland rören, där de linjerna förblir korta: bredvid de interna systemen, datalagret och data nere till höger. Datateamen öppnar visserligen dess skärmar, men de skärmarna finns i orgen: Data 360 är nära core, hanteras på core och driftas utanför core (modul 1). En linje tillbaka till Salesforce visar vem som hanterar det. Var du placerar lådan ska berätta historien om vad den gör.
Inget av den här geometrin är heligt. Värdet med en konvention är att jag inte uppfinner det visuella språket på nytt varje gång, och den som har sett ett av mina diagram kan läsa nästa snabbare.
Håll notationen enkel. Varje system är ett kort: dess namn, dess roll och en liten ikon som säger vad det är för sorts sak: ett ERP, en databas, en identitetsleverantör, en grupp människor. Områdena jag just beskrev ritas som svaga, märkta zoner, så att själva layouten syns. En teckenförklaring längst ned säger vad varje ikon och linje betyder.
Lägg inte för mycket i en låda. Bara på ett mycket komplicerat landskap öppnar jag upp Salesforce i dess delar (Sales Cloud och Service Cloud inuti orgen, med pilar mellan dem). Och hitta inte på femton former om inte var och en säger läsaren något. Jag vill att någon ska kunna titta på landskapet i trettio sekunder och börja förstå arkitekturen. Tjusigt hjälper inte. Tydligt gör det.
Vänta inte på den detaljerade designen för att tänka på volym. En pil som bär 500 produkter per natt och en som bär 200 000 GPS-avläsningar om dagen kan se exakt likadana ut på landskapet. De är inte samma problem. Så innan du ritar en enda pil, räkna det som rör sig. Börja inventeringen bakom bilden med antalen: en rad per viktig datamängd, med dess volym. Nollorna kanske aldrig syns på pilarna, men du måste veta när du går över till höga tal: tusentals eller miljontals på en timme, hundratusentals transaktioner, till och med tiotals till hundratals transaktioner i sekunden.
De siffrorna styr mekanismen. Några hundra poster per natt är en batch. Ett anrop som någon väntar på kan vara synkront, om volymen tillåter det. Tiotals till hundratals i sekunden kan kräva händelser, som platform events, snarare än ett anrop per post. Pilen ser likadan ut; volymen avgör vad som bär den, så skriv in den i inventeringen, där mekanismen väljs.
Mekanismen kan till och med ändra pilens riktning. Skicka ett par poster i minuten, så kan Salesforce helt enkelt anropa ut: pilen börjar vid Salesforce. Skicka betydligt fler, så kanske Salesforce publicerar händelser på händelsebussen i stället; det externa systemet prenumererar och anropar in för att hämta dem, så nu börjar pilen i andra änden. Ännu större, säg en nattlig synk av miljontals poster, och det är en batchprocess. Så känn till dina antal tidigt, när du börjar designa mekanismerna, eftersom antalen kan rita om pilarna.
Volym spelar roll på två ställen, av två skäl. På en datamodell behöver jag den för att hålla utkik efter stora datavolymer och planera arkivering; del 2 går på djupet med det. På ett systemlandskap styr de stora talen i inventeringen valet av integrationsmönster och mekanism. Modul 6 sätter verkliga nollor på Steve Truckings landskap och dess inventering. Med antalen i handen, rita pilarna.
När systemen är på plats, koppla ihop dem, så blir landskapet arkitektur. En låda är ett system; pilen visar vem som initierar kopplingen. Den börjar vid systemet som öppnar kopplingen och pekar på det som anropas: klient till server. Etiketten säger vad som rör sig, och åt vilket håll.
Den regeln gäller för systemlandskap, där system pratar med system. På ett dataflödesdiagram följer pilen data, som du skulle förvänta dig. Ta inte med landskapsregeln till andra diagram; den skapar bara förvirring.
Pilarna på plats. Varje låda står där den stod; varje pil börjar vid systemet som öppnar kopplingen, och dess etikett säger vad som rör sig och åt vilket håll.
Så om integrationslagret skickar in produkter i Salesforce går pilen från integrationslagret till Salesforce, märkt produkter in. Om Salesforce anropar ut för att hämta dem börjar pilen vid Salesforce, fortfarande märkt produkter in. Samma data, ett annat samtal, och den skillnaden talar om för mig vem som behöver inloggningsuppgifterna och vem som måste hantera felet. Salesforce skickar ordern via integrationslagret: ordrar ut. ERP:ts leveransbesked kommer tillbaka: orderstatus in. Nu ser jag vem som startar varje samtal, var data kommer in i Salesforce och var de lämnar det, vilka flöden som korsar gränser, var ägarskapet troligen ligger och var jag behöver fråga mer.
Och kom ihåg modul 1: varje gång jag bara ser ett flöde blir jag orolig. På den övergripande nivån är en pil för ordrar ut beroende av returflöden: kunder in, produkter in, priser. Titta ännu djupare så finns returresan: accepterad, avvisad, status, ett fakturanummer, en avbokning. Pilarna ger mig något konkret att ifrågasätta.
Det är här landskapet slutar vara PowerPoint-konst. Inför granskningsnämnden kan varje pil dra till sig tre frågor, och jag vill att du har svaren:
Hur autentiserar den? OAuth, ett certifikat, en named credential, något annat?
Är den synkron eller asynkron? Väntar Salesforce på ERP:t, eller publicerar det och fortsätter? Hur snabbt behöver verksamheten resultatet?
Vilken är mekanismen? Ett REST-anrop, en händelse, en fil, en meddelandekö, via MuleSoft eller direkt?
Och sedan: vad händer när andra sidan ligger nere? Varje pil behöver en mekanism. Kan du inte förklara den är linjen dekoration.
Och ”fire and forget” är inget svar. Det betyder oftast ”jag har inte designat vad som händer efter att det avfyrats”. Kom det fram? Accepterades det? Misslyckades det? Kommer det att försöka igen? Vem vet att det har fastnat? Vad händer om samma meddelande kommer två gånger? Inget av det hamnar på landskapet, som då skulle bli oläsligt. Men pilen ska få dig att veta att de frågorna finns.
Zooma in på en enda pil så finns det en klient och en server, och var och en äger sin halva. Klienten öppnar kopplingen: den behöver slutpunkten och porten, hämtar först en token från autentiseringsservern, anropar det protokoll och kontrakt som servern definierar och väljer om den ska vänta. Bara klienten ser hela rundturen, så bara klienten kan försöka igen. Servern lyssnar, definierar protokollet, kontraktet och payloaden, validerar det som kommer in och ser bara sin egen del. När jag ritar en pil vet jag redan vilken ände som är vilken, och det talar om för mig vem som äger var och en av de här frågorna.
En pil, inzoomad: klienten hanterar, servern definierar. Inget av det hamnar på landskapet, men varje pil har det.
Vänd nu på pilen. När ERP:t anropar Salesforce är Salesforce servern: det definierar API:erna, kör sin egen auktoriseringsserver och bestämmer via en External Client App och en integrationsanvändare vad anroparen får göra. Samma frågor, andra sidan.
Det är här arkitekter förstör ett bra diagram: de låter en enda artefakt besvara allt. Landskapet får API-namn, payloads, nya försök, felköer, transformationer, varje återanrop, och snart kan ingen läsa det. Gör inte så. Landskapet är helhetsbilden: systemen och de viktiga flödena mellan dem.
När jag behöver förklara en interaktion ritar jag ett andra diagram, men inte för varje integration. Om system A skickar något till B, eller till och med frågar och får ett svar, räcker den märkta pilen. Jag vill ha ett simbanediagram (swim lane) när processen blir ett samtal: A anropar B, B kollar med C, C svarar, B skapar något och anropar A tillbaka, en människa godkänner, ett annat system tar vid. Min tumregel: mer än ett eller två utbyten fram och tillbaka, så får sekvensen ett eget simbanediagram. Pilar på landskapet; samtalet i simbanediagrammet.
Och lägg märke till att en pil betyder något annat där. På landskapet är en pil en koppling: vem som öppnar den, och vad som rör sig. I ett simbanediagram är varje pil ett meddelande i ett samtal, läst i ordning: en begäran går åt ena hållet, ett svar kommer tillbaka åt andra hållet, och nästa steg följer.
Tre pilar på landskapet; sex steg i simbanediagrammet. På landskapet är en pil en koppling; i ett simbanediagram är varje pil ett meddelande, i ordning.
När landskapet ser nästan klart ut, gå igenom det, pil för pil. ERP till Salesforce: vad rör sig, vem äger det, hur autentiserar det, vilken är mekanismen, synkront eller asynkront, hur aktuellt måste det vara? Sedan nästa pil, och nästa. Det är här luckorna dyker upp. ”Jaså, vi har aldrig listat ut hur partnern faktiskt skickar det där.” ”Vi skickar ordrar till ERP:t, men vi har inte designat hur avvisade ordrar kommer tillbaka.” Bra. Du hittade det på whiteboarden i stället för i produktion.
Bilden måste förbli läsbar, så detaljerna hamnar i inventeringen bakom den. Du började den med antalen; gör nu klart den, en rad per viktig datamängd eller flöde:
Kolumn
Vad jag vill veta
Datamängd
Kund, produkt, order, leverans, faktura
Typ
Masterdata, referensdata, transaktionsdata, analytiska data, ostrukturerade data
Därför gillar jag den här artefakten: den hjälper mig att tänka. ”Hur ska vi rapportera över Salesforce och ERP:t?” Det är frågan från modul 3: vilket av mina diagram löser det här snyggt? Landskapet. Om allt ligger på core, standardrapporter. Om data finns i ERP:t och datalagret ser du det direkt. ”Var ska det här kundattributet hanteras som masterdata?” Titta på vilka system som använder det och vilket som redan äger kunden. ”Behöver Salesforce varje GPS-avläsning?” Vem producerar den, vem konsumerar den, vilken är arbetslasten? Kanske behöver Salesforce den aktuella positionen medan en annan plattform sparar historiken. Landskapet ger dig inte svaret. Det ger dig rätt vy av problemet.
En disciplin till. I ett befintligt företag, rita det som finns, inte det du önskar fanns. Kalkylarket som mejlas varje fredag: rita det. Partnerns CSV på en SFTP-server: rita den. Integrationen som går förbi ESB:n av historiska skäl: rita den. Människor som knappar in data mellan två system: visa det. Städa inte upp verkligheten medan du dokumenterar den. Du behöver det nuvarande landskapet innan du designar målet, och det är vad vi gör för Steve Trucking i modul 6.
Bortom provet: vad AI ändrar. Landskapet håller på att bli en karta för agenter. Om en agent svarar på ”var är min leverans?” måste landskapet säga om svaret kommer från Salesforce, ett partnersystem, telematik, ERP:t eller en blandning. Agenter tar inte bort systemgränserna; de gör det ännu viktigare att veta vilket system som är auktoritativt och hur det kan nås på ett säkert sätt.
Vilka system och användargrupper som hör hemma på landskapet, och hur deras placering visar deras roll.
Vilka flöden som korsar systemgränser, åt vilket håll, och vad som kommer tillbaka.
Hur varje koppling autentiserar, vilken mekanism som bär den, och om den är synkron, asynkron, batch eller federerad.
När en märkt pil räcker och när en interaktion behöver ett eget simbanediagram.
Vad inventeringen bakom bilden registrerar: ägare, arbetslast, volym, org, tidpunkt, autentisering, och kopiera, referera eller federera.
Landskapet är inget jag ritar när arkitekturen är klar. Det är så jag hittar arkitekturen. Och när du tror att det är färdigt, beundra det inte. Gå igenom det. Varje pil du inte kan förklara än visar dig var arbetet finns.
