Spørsmålet denne modulen besvarer: Hvordan tegner jeg et landskap som viser hvor dataene går?
Gi meg et nytt scenario og en blank tavle, og noe av det første jeg tegner, er systemlandskapet. Ikke vakkert, ikke hvert API, ikke datamodellen ennå. Jeg vil se virksomheten: hvem brukerne er, hvilke systemer som er involvert, hvor Salesforce står, hva som omgir det, hvor data kommer fra og hvor de går. Og så vil jeg gå gjennom pilene. Et godt landskap er ikke et bilde av bokser. Det er en måte å avdekke arkitektoniske beslutninger på.
Jeg får CTA-kandidater til å øve på dette. Les scenarioet, og begynn så å tegne. Ikke vent til du har løst alt i hodet; tegningen hjelper deg å løse det. Derfor er hjemmeleksen etter første dag å starte landskapet før du gjør et forsøk på datamodellen. Tegner du datamodellen først, har du allerede antatt hva som hører hjemme i Salesforce. Tegner du landskapet først, kan du se systemene som bør forme den beslutningen.
Start høyt, og bor deg så ned: hele virksomheten først, så detaljene der de betyr noe.
Det finnes mange måter å tegne et systemlandskap på. Dette er bare min måte, en jeg har finpusset gjennom mange år, og jeg deler den så du kan se hvordan du raskt setter et sammen. Jeg bruker den for hvert Salesforce-landskap, og den leses som en setning: menneskene til venstre når Salesforce i midten, får tillit gjennom systemene over den, blir betjent gjennom kanalene under den, og er koblet til bakkontoret til høyre.
Menneskene til venstre, ovenfra og ned: interne brukere, partnere, kunder. Ikke hver persona ennå; nok til å svare på hvem prøver å nå denne arkitekturen? Hver gruppe peker dit den kommer inn: interne brukere til Salesforce, partnere til partnercommunityet, kunder til kundecommunityet. Systemer finnes ikke for seg selv. Noen, eller noe, prøver å bruke dem.
Salesforce i midten. Én enkel boks. Ikke fordi Salesforce er midten av virksomheten (vi har nettopp brukt tre moduler på å si at det ikke er det), men fordi det er systemet jeg designer rundt. Det er ankeret.
Communityene rett under, inntil den. Et partnercommunity og et kundecommunity er separate endepunkter, så de får egne bokser. Men de står inntil Salesforce, fordi ingenting må integreres for å nå dem: de kjører i samme org.
Steg 3 av 6: Salesforce i midten, communityene rett under.
Identitet over. Identitetsleverandørene står øverst, de utviklere glemmer: én for interne brukere, kanskje en annen for partnere. AppExchange-pakker står også der oppe, skjøvet til høyre, fordi de er funksjoner som hentes inn i orgen, ikke bakkontorsystemer som utveksler data med den. Offentlige nettsteder står øverst til venstre.
Steg 4 av 6: identitet over, boksen utviklere glemmer.
Integrasjon, så bakkontoret, til høyre. Integrasjonslaget, en ESB eller iPaaS (eller MuleSoft, når det er navngitt), er en høy søyle rett til høyre for Salesforce. De interne systemene står bak den: ERP-ene, økonomi, ordrehåndtering, eldre systemer, datavarehuset. Nå leses siden fra venstre mot høyre: mennesker, Salesforce, integrasjon, bakkontor.
Kanaler under. Alt som har en direkte linje til kundene: email-to-case, web-to-lead, telefon, meldinger.
Data inn og ut, nederst til høyre. Eksterne datakilder, arkiver, datainnlastinger.
Data 360 til høyre, under integrasjonslaget. Brukerne kobler seg aldri til den, og tenanten kobler seg til mange bakenforliggende systemer, så den står sammen med rørleggerarbeidet, der de linjene holder seg korte: ved siden av de interne systemene, datavarehuset og dataene nederst til høyre. Datateam åpner riktignok skjermene, men de skjermene er i orgen: Data 360 er nær core (near-core), administrert på core og driftet utenfor core (modul 1). Én linje tilbake til Salesforce viser hvem som administrerer den. Hvor du plasserer boksen, bør fortelle historien om hva den gjør.
Ingenting av denne geometrien er hellig. Verdien av en konvensjon er at jeg ikke finner opp det visuelle språket på nytt hver gang, og at alle som har sett ett av diagrammene mine, kan lese det neste raskere.
Hold notasjonen enkel. Hvert system er et kort: navnet, rollen og et lite ikon som sier hva slags ting det er: et ERP, en database, en identitetsleverandør, en gruppe mennesker. Områdene jeg nettopp beskrev, tegnes som svake, merkede soner, så selve oppsettet er synlig. En tegnforklaring nederst sier hva hvert ikon og hver linje betyr.
Ikke legg for mye inni en boks. Bare på et veldig komplisert landskap åpner jeg Salesforce opp i delene sine (Sales Cloud og Service Cloud inni orgen, med piler mellom dem). Og ikke finn opp femten former med mindre hver av dem forteller leseren noe. Jeg vil at noen skal se på landskapet i tretti sekunder og begynne å forstå arkitekturen. Fancy hjelper ikke. Tydelig gjør det.
Ikke vent til detaljdesignet med å tenke på volum. En pil som bærer 500 produkter per natt og en som bærer 200 000 GPS-målinger om dagen, kan se helt like ut på landskapet. De er ikke det samme problemet. Så før du tegner en eneste pil, tell det som beveger seg. Start inventaret bak bildet med tallene: én rad per viktig datasett, med volumet. Nullene dukker kanskje aldri opp på pilene, men du må vite når du krysser inn i høye tall: tusenvis eller millioner i timen, hundretusenvis av transaksjoner, til og med titalls til hundrevis av transaksjoner i sekundet.
De tallene styrer mekanismen. Noen hundre poster per natt er en batch. Et kall noen venter på, kan være synkront, hvis volumet tillater det. Titalls til hundrevis i sekundet kan kreve hendelser, som platform events, i stedet for ett kall per post. Pilen ser lik ut; volumet bestemmer hva som bærer den, så før det inn i inventaret, der mekanismen velges.
Mekanismen kan til og med endre retningen på pilen. Send et par poster i minuttet, og Salesforce kan ganske enkelt kalle ut: pilen starter i Salesforce. Send langt flere, og Salesforce publiserer kanskje hendelser på hendelsesbussen i stedet; det eksterne systemet abonnerer og kaller inn for å hente dem, så nå starter pilen i den andre enden. Enda større, for eksempel en nattlig synkronisering av millioner av poster, og det er en batchprosess. Så kjenn tallene dine tidlig, når du begynner å designe mekanismene, for tallene kan tegne pilene på nytt.
Volum betyr noe to steder, av to grunner. På en datamodell trenger jeg det for å holde øye med store datavolumer og planlegge arkivering; del 2 går i dybden på det. På et systemlandskap styrer de store tallene i inventaret valget av integrasjonsmønster og mekanisme. Modul 6 setter ekte nuller på landskapet og inventaret til Steve Trucking. Med tallene i hånd tegner du pilene.
Når systemene er på plass, kobler du dem sammen, og landskapet blir arkitektur. En boks er et system; pilen viser hvem som tar initiativ til forbindelsen. Den starter i systemet som åpner forbindelsen og peker på det systemet den kaller: fra klient til server. Etiketten sier hva som flyttes, og hvilken vei.
Den regelen gjelder systemlandskap, der systemer snakker med systemer. På et dataflytdiagram følger pilen dataene, som du ville forvente. Ikke ta med deg landskapsregelen inn i andre diagrammer; den skaper bare forvirring.
Pilene er lagt inn. Hver boks står der den sto; hver pil starter i systemet som åpner forbindelsen, og etiketten sier hva som flyttes og hvilken vei.
Så hvis integrasjonslaget dytter produkter inn i Salesforce, går pilen fra integrasjonslaget til Salesforce, merket produkter inn. Hvis Salesforce kaller ut for å hente dem, starter pilen i Salesforce, fortsatt merket produkter inn. Samme data, en annen samtale, og den forskjellen forteller meg hvem som trenger påloggingsinformasjonen og hvem som må håndtere feilen. Salesforce sender ordren gjennom integrasjonslaget: ordrer ut. ERP-ets ordreoppfyllelse kommer tilbake: ordrestatus inn. Nå kan jeg se hvem som starter hver samtale, hvor data kommer inn i Salesforce og hvor de forlater det, hvilke flyter som krysser grenser, hvor eierskapet sannsynligvis ligger, og hvor jeg må spørre mer.
Og husk modul 1: hver gang jeg bare ser én flyt, blir jeg bekymret. På overordnet nivå avhenger en ordrer ut-pil av returflyter: kunder inn, produkter inn, priser. Ser du enda dypere, finnes returreisen: godkjenning, avvisning, status, et fakturanummer, en kansellering. Pilene gir meg noe konkret å utfordre.
Det er her landskapet slutter å være PowerPoint-kunst. Foran review board kan hvilken som helst pil utløse tre spørsmål, og jeg vil at du skal ha svarene:
Hvordan autentiserer den? OAuth, et sertifikat, en named credential, noe annet?
Er den synkron eller asynkron? Venter Salesforce på ERP-et, eller publiserer det og går videre? Hvor fort trenger virksomheten resultatet?
Hva er mekanismen? Et REST-kall, en hendelse, en fil, en meldingskø, gjennom MuleSoft eller direkte?
Og så: hva skjer når den andre siden er nede? Hver pil trenger en mekanisme. Kan du ikke forklare den, er linjen pynt.
Og «fire and forget» er ikke et svar. Det betyr som regel «jeg har ikke designet hva som skjer etter at det er avfyrt». Kom det frem? Ble det godtatt? Feilet det? Prøver det på nytt? Hvem vet at det står fast? Hva om samme melding kommer to ganger? Ingenting av det skal på landskapet, som da ville blitt uleselig. Men pilen skal få deg til å vite at de spørsmålene finnes.
Zoom inn på én pil, så finnes det en klient og en server, og hver eier sin halvdel. Klienten åpner forbindelsen: den trenger endepunktet og porten, henter først et token fra autentiseringsserveren, kaller protokollen og kontrakten serveren definerer, og velger om den skal vente. Bare klienten ser hele rundturen, så bare klienten kan prøve på nytt. Serveren lytter, definerer protokollen, kontrakten og payloaden, validerer det som kommer inn, og ser bare sin egen del. Når jeg tegner en pil, vet jeg allerede hvilken ende som er hvilken, og det forteller meg hvem som eier hvert av disse spørsmålene.
Én pil, zoomet inn: klienten håndterer, serveren definerer. Ingenting av dette skal på landskapet, men hver pil har det.
Snu nå pilen. Når ERP-et kaller Salesforce, er Salesforce serveren: det definerer API-ene, kjører sin egen autorisasjonsserver og bestemmer gjennom en External Client App og en integrasjonsbruker hva den som kaller, får gjøre. Samme spørsmål, andre siden.
Her er stedet der arkitekter ødelegger et godt diagram: de får én artefakt til å svare på alt. Landskapet får API-navn, payloads, nye forsøk, feilkøer, transformasjoner, hver callback, og snart kan ingen lese det. Ikke gjør det. Landskapet er det store bildet: systemene og de viktige flytene mellom dem.
Når jeg må forklare en interaksjon, tegner jeg et diagram til, men ikke for hver integrasjon. Hvis system A sender noe til B, eller til og med spør og får et svar, er den merkede pilen nok. Jeg vil ha en svømmebane når prosessen blir en samtale: A kaller B, B sjekker med C, C svarer, B lager noe og kaller A tilbake, en person godkjenner, et annet system tar over. Tommelfingerregelen min: mer enn én eller to runder fram og tilbake, så får sekvensen sin egen svømmebane. Pilene på landskapet; samtalen i svømmebanen.
Og legg merke til at en pil betyr noe annet der. På landskapet er en pil en forbindelse: hvem som åpner den, og hva som flyttes. I en svømmebane er hver pil én melding i en samtale, lest i rekkefølge: en forespørsel går den ene veien, et svar kommer tilbake den andre, og neste steg følger.
Når landskapet ser nesten ferdig ut, gå gjennom det, pil for pil. ERP til Salesforce: hva flyttes, hvem eier det, hvordan autentiserer den, hva er mekanismen, synkront eller asynkront, hvor oppdatert må det være? Så neste pil, og den neste. Det er her hullene dukker opp. «Å, vi fant aldri ut hvordan partneren faktisk sender det.» «Vi sender ordrer til ERP-et, men vi har ikke designet hvordan de avviste kommer tilbake.» Bra. Du fant det på tavla i stedet for i produksjon.
Bildet må forbli lesbart, så detaljene går i inventaret bak det. Du startet det med tallene; nå fullfører du det, én rad per viktig datasett eller flyt:
Kolonne
Hva jeg vil vite
Datasett
Kunde, produkt, ordre, levering, faktura
Type
Masterdata, referansedata, transaksjonsdata, analytiske data, ustrukturerte data
Derfor liker jeg denne artefakten: den hjelper meg å tenke. «Hvordan skal vi rapportere på tvers av Salesforce og ERP-et?» Det er spørsmålet fra modul 3: hvilket av diagrammene mine løser dette på en vakker måte? Landskapet. Hvis alt er på core, standardrapporter. Hvis dataene er i ERP-et og datavarehuset, ser du det med en gang. «Hvor bør denne kundeattributten håndteres som masterdata?» Se på hvilke systemer som bruker den og hvilket som allerede eier kunden. «Trenger Salesforce hver GPS-måling?» Hvem produserer den, hvem bruker den, hva er arbeidsbelastningen? Kanskje Salesforce trenger gjeldende posisjon, og en annen plattform tar vare på historikken. Landskapet gir deg ikke svaret. Det gir deg riktig utsyn over problemet.
Én disiplin til. I en eksisterende virksomhet tegner du det som finnes, ikke det du skulle ønske fantes. Regnearket som sendes på e-post hver fredag: tegn det. Partnerens CSV på en SFTP-server: tegn den. Integrasjonen som går utenom ESB-en av historiske grunner: tegn den. Folk som taster inn data på nytt mellom to systemer: vis det. Ikke rydd opp i virkeligheten mens du dokumenterer den. Du trenger dagens landskap før du designer mållandskapet, og det er det vi gjør for Steve Trucking i modul 6.
Utover eksamen: hva KI endrer. Landskapet er i ferd med å bli et kart for agenter. Hvis en agent svarer på «hvor er leveringen min?», må landskapet si om svaret kommer fra Salesforce, et partnersystem, telematikk, ERP-et eller en blanding. Agenter fjerner ikke systemgrenser; de gjør det enda viktigere å vite hvilket system som er autoritativt, og hvordan du når det trygt.
Hvilke systemer og brukergrupper som hører hjemme på landskapet, og hvordan plasseringen viser rollen deres.
Hvilke flyter som krysser systemgrenser, i hvilken retning, og hva som kommer tilbake.
Hvordan hver forbindelse autentiserer, hvilken mekanisme som bærer den, og om den er synkron, asynkron, batch eller føderert.
Når en merket pil er nok, og når en interaksjon trenger sin egen svømmebane.
Hva inventaret bak bildet registrerer: eier, arbeidsbelastning, volum, org, timing, autentisering, og kopiere, referere eller føderere.
Landskapet er ikke noe jeg tegner etter at arkitekturen er ferdig. Det er måten jeg finner arkitekturen på. Og når du tror det er ferdig, ikke beundre det. Gå gjennom det. Hver pil du ennå ikke kan forklare, viser deg hvor arbeidet er.
