Spørgsmålet, dette modul besvarer: Hvordan tegner jeg et landskab, der viser, hvor dataene går hen?
Giv mig et nyt scenarie og en tom whiteboard, og noget af det første, jeg tegner, er systemlandskabet. Ikke smukt, ikke hvert API, ikke datamodellen endnu. Jeg vil se virksomheden: hvem brugerne er, hvilke systemer der er involveret, hvor Salesforce står, hvad der omgiver det, hvor data kommer fra, og hvor de går hen. Og så vil jeg gå pilene igennem. Et godt landskab er ikke et billede af kasser. Det er en måde at afsløre arkitektoniske beslutninger på.
Jeg får CTA-kandidater til at øve det her. Læs scenariet, og begynd så at tegne. Vent ikke, til du har løst det hele i hovedet; tegningen hjælper dig med at løse det. Derfor er hjemmeopgaven efter første dag at starte landskabet, før man giver et første bud på datamodellen. Tegn datamodellen først, og du har allerede antaget, hvad der hører hjemme i Salesforce. Tegn landskabet først, og du kan se de systemer, der bør forme den beslutning.
Start højt oppe, og bor dig så ned: hele virksomheden først, så detaljerne, hvor de betyder noget.
Der er mange måder at tegne et systemlandskab på. Det her er bare min måde, en jeg har finpudset gennem mange år, og jeg deler den, så du kan se, hvordan man hurtigt sætter et sammen. Jeg bruger den til hvert eneste Salesforce-landskab, 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.
Mennesker til venstre, oppefra og ned: interne brugere, partnere, kunder. Ikke alle personas endnu; nok til at svare på hvem prøver at nå denne arkitektur? Hver gruppe peger på det sted, hvor den kommer ind: interne brugere til Salesforce, partnere til partnercommunityet, kunder til kundecommunityet. Systemer eksisterer ikke af sig selv. Nogen, eller noget, prøver at bruge dem.
Salesforce i midten. Én enkel kasse. Ikke fordi Salesforce er virksomhedens centrum (vi har lige brugt tre moduler på at sige, at det ikke er), men fordi det er det system, jeg designer omkring. Det er ankeret.
Communities lige under det, så de rører. Et partnercommunity og et kundecommunity er separate endepunkter, så de får deres egne kasser. Men de står op ad Salesforce, fordi intet skal integreres for at nå dem: de kører i den samme org.
Trin 3 af 6: Salesforce i midten, communities lige under det.
Identitet øverst. Identitetsudbyderne kommer øverst, dem, udviklere glemmer: én til interne brugere, måske en anden til partnere. AppExchange-pakker kommer også derop, skubbet til højre, fordi de er funktioner, der hentes ind i org’en, ikke back office-systemer, der udveksler data med den. Offentlige websites står øverst til venstre.
Trin 4 af 6: identitet øverst, kassen, udviklere glemmer.
Integration og derefter back office til højre. Integrationslaget, en ESB eller iPaaS (eller MuleSoft, når det er navngivet), er en høj bjælke lige til højre for Salesforce. De interne systemer står bag den: ERP’erne, økonomi, ordrestyring, gamle systemer, datavarehuset. Nu læses siden fra venstre mod højre: mennesker, Salesforce, integration, back office.
Kanaler nederst. Alt, der har en direkte linje til kunderne: email-to-case, web-to-lead, telefon, beskeder.
Data ind og ud, nederst til højre. Eksterne datakilder, arkiver, dataindlæsninger.
Data 360 til højre, under integrationslaget. Brugerne forbinder sig aldrig til det, og dets tenant forbinder sig til mange back end-systemer, så det står sammen med rørføringen, hvor de linjer forbliver korte: ved siden af de interne systemer, datavarehuset og dataene nederst til højre. Datateams åbner godt nok dets skærme, men de skærme er i org’en: Data 360 er tæt på core (near-core), administreret på core og hostet uden for core (modul 1). Én linje tilbage til Salesforce viser, hvem der administrerer det. Hvor du sætter kassen, skal fortælle historien om, hvad den gør.
Intet af denne geometri er helligt. Værdien af en konvention er, at jeg ikke opfinder det visuelle sprog på ny hver gang, og at alle, der har set ét af mine diagrammer, kan læse det næste hurtigere.
Hold notationen enkel. Hvert system er et kort: dets navn, dets rolle og et lille ikon, der siger, hvilken slags ting det er: et ERP, en database, en identitetsudbyder, en gruppe mennesker. De områder, jeg lige har beskrevet, tegnes som svage, navngivne zoner, så selve layoutet er synligt. En signaturforklaring nederst siger, hvad hvert ikon og hver linje betyder.
Put ikke for meget ind i en kasse. Kun på et meget kompliceret landskab åbner jeg Salesforce op i sine dele (Sales Cloud og Service Cloud inde i org’en, med pile imellem dem). Og opfind ikke femten former, medmindre hver af dem fortæller læseren noget. Jeg vil have, at nogen kan se på landskabet i tredive sekunder og begynde at forstå arkitekturen. Fancy hjælper ikke. Klart gør.
Vent ikke på det detaljerede design med at tænke på volumen. En pil, der bærer 500 produkter om natten, og en, der bærer 200.000 GPS-målinger om dagen, kan se præcis ens ud på landskabet. De er ikke det samme problem. Så før du tegner en eneste pil, så tæl, hvad der bevæger sig. Start oversigten bag billedet med tallene: én række pr. vigtigt datasæt med dets volumen. Nullerne dukker måske aldrig op på pilene, men du skal vide, hvornår du krydser over i høje tal: tusinder eller millioner i timen, hundredtusinder af transaktioner, ja selv ti til hundrede transaktioner i sekundet.
De tal styrer mekanismen. Et par hundrede poster om natten er en batch. Et kald, nogen venter på, kan være synkront, hvis volumen tillader det. Ti til hundrede i sekundet kan kræve hændelser, som platform events, i stedet for ét kald pr. post. Pilen ser ens ud; volumen afgør, hvad der bærer den, så notér den i oversigten, hvor mekanismen bliver valgt.
Mekanismen kan endda ændre pilens retning. Send et par poster i minuttet, og Salesforce kan simpelthen kalde ud: pilen starter ved Salesforce. Send langt flere, og Salesforce publicerer måske i stedet hændelser på event bus’en; det eksterne system abonnerer og kalder ind for at hente dem, så nu starter pilen i den anden ende. Endnu større, f.eks. en natlig synkronisering af millioner af poster, og så er det en batchproces. Så kend dine tal tidligt, når du begynder at designe mekanismerne, for tallene kan tegne pilene om.
Volumen betyder noget to steder, af to grunde. På en datamodel skal jeg bruge den til at holde øje med store datamængder og planlægge arkivering; del 2 går i dybden med det. På et systemlandskab styrer de store tal i oversigten valget af integrationsmønster og mekanisme. Modul 6 sætter rigtige nuller på Steve Truckings landskab og dets oversigt. Med tallene i hånden: tegn pilene.
Når systemerne er på plads, så forbind dem, og landskabet bliver til arkitektur. En kasse er et system; pilen viser, hvem der tager initiativ til forbindelsen. Den starter ved det system, der åbner forbindelsen, og peger på det, den kalder: klient til server. Etiketten siger, hvad der bevæger sig, og i hvilken retning.
Den regel gælder for systemlandskaber, hvor systemer taler med systemer. På et dataflowdiagram følger pilen dataene, som du ville forvente. Tag ikke landskabsreglen med over i andre diagrammer; det skaber bare forvirring.
Pilene sat ind. Hver kasse står, hvor den stod; hver pil starter ved det system, der åbner forbindelsen, og dens etiket siger, hvad der bevæger sig, og i hvilken retning.
Så hvis integrationslaget skubber produkter ind i Salesforce, går pilen fra integrationslaget til Salesforce med etiketten produkter ind. Hvis Salesforce kalder ud for at hente dem, starter pilen ved Salesforce, stadig med etiketten produkter ind. Samme data, en anden samtale, og den forskel fortæller mig, hvem der skal have legitimationsoplysningerne, og hvem der skal håndtere fejlen. Salesforce sender ordren gennem integrationslaget: ordrer ud. ERP’ets ordreudførelse kommer tilbage: ordrestatus ind. Nu kan jeg se, hvem der starter hver samtale, hvor data kommer ind i Salesforce, og hvor de forlader det, hvilke flows der krydser grænser, hvor ejerskabet sandsynligvis ligger, og hvor jeg skal spørge mere.
Og husk modul 1: hver gang jeg kun ser ét flow, bliver jeg bekymret. På det overordnede niveau afhænger en pil med ordrer ud af returflows: kunder ind, produkter ind, priser. Kig endnu dybere, og der er returrejsen: accept, afvisning, status, et fakturanummer, en annullering. Pilene giver mig noget konkret at udfordre.
Det er her, landskabet holder op med at være PowerPoint-kunst. Ved review boardet kan enhver pil udløse tre spørgsmål, og jeg vil have, at du har svarene:
Hvordan autentificerer den? OAuth, et certifikat, en named credential, noget andet?
Er den synkron eller asynkron? Venter Salesforce på ERP’et, eller publicerer det og fortsætter? Hvor hurtigt har forretningen brug for resultatet?
Hvad er mekanismen? Et REST-kald, en hændelse, en fil, en beskedkø, gennem MuleSoft eller direkte?
Og så: hvad sker der, når den anden side er nede? Hver pil skal have en mekanisme. Hvis du ikke kan forklare den, er linjen pynt.
Og »fire and forget« er ikke et svar. Det betyder som regel »jeg har ikke designet, hvad der sker efter affyringen«. Kom den frem? Blev den accepteret? Fejlede den? Bliver den prøvet igen? Hvem ved, at den sidder fast? Hvad hvis den samme besked kommer to gange? Intet af det kommer på landskabet, som så ville blive ulæseligt. Men pilen skal få dig til at vide, at de spørgsmål findes.
Zoom ind på en hvilken som helst pil, og der er en klient og en server, og hver ejer sin halvdel. Klienten åbner forbindelsen: den skal kende endepunktet og porten, henter først et token fra autentificeringsserveren, kalder den protokol og kontrakt, serveren definerer, og vælger, om den vil vente. Kun klienten ser hele rundturen, så kun klienten kan prøve igen. Serveren lytter, definerer protokollen, kontrakten og payloaden, validerer det, der kommer ind, og ser kun sin egen del. Når jeg tegner en pil, ved jeg allerede, hvilken ende der er hvilken, og det fortæller mig, hvem der ejer hvert af de spørgsmål.
Én pil, zoomet ind: klienten håndterer, serveren definerer. Intet af det kommer på landskabet, men hver pil har det.
Vend nu pilen om. Når ERP’et kalder Salesforce, er Salesforce serveren: det definerer API’erne, kører sin egen autorisationsserver og bestemmer via en External Client App og en integrationsbruger, hvad den, der kalder, må gøre. Samme spørgsmål, den anden side.
Her er det sted, hvor arkitekter ødelægger et godt diagram: de lader ét artefakt svare på alt. Landskabet får API-navne, payloads, genforsøg, fejlkøer, transformationer, hvert eneste callback, og snart kan ingen læse det. Lad være. Landskabet er det store billede: systemerne og de vigtige flows mellem dem.
Når jeg skal forklare en interaktion, tegner jeg et andet diagram, men ikke for hver integration. Hvis system A sender noget til B, eller endda spørger og får et svar, er den navngivne pil nok. Jeg vil have en swim lane, når processen bliver til en samtale: A kalder B, B tjekker med C, C svarer, B opretter noget og kalder A tilbage, en person godkender, et andet system fortsætter. Min tommelfingerregel: mere end en eller to udvekslinger frem og tilbage, og sekvensen får sin egen swim lane. Pile på landskabet; samtalen i swim lanen.
Og læg mærke til, at en pil betyder noget andet der. På landskabet er en pil en forbindelse: hvem åbner den, og hvad bevæger sig. I en swim lane er hver pil én besked i en samtale, læst i rækkefølge: en forespørgsel går den ene vej, et svar kommer tilbage den anden vej, og det næste trin følger.
Når landskabet ser nogenlunde færdigt ud, så gå det igennem, pil for pil. ERP til Salesforce: hvad bevæger sig, hvem ejer det, hvordan autentificerer den, hvad er mekanismen, synkron eller asynkron, hvor aktuelt skal det være? Så den næste pil, og den næste. Det er her, hullerne viser sig. »Nå, vi fandt aldrig ud af, hvordan partneren faktisk sender det.« »Vi sender ordrer til ERP’et, men vi har ikke designet, hvordan de afviste kommer tilbage.« Godt. Du fandt det på whiteboardet i stedet for i produktion.
Billedet skal forblive læseligt, så detaljerne kommer i oversigten bag det. Du startede den med tallene; gør den nu færdig med én række pr. vigtigt datasæt eller flow:
Kolonne
Hvad jeg vil vide
Datasæt
Kunde, produkt, ordre, levering, faktura
Type
Masterdata, referencedata, transaktionsdata, analytiske data, ustrukturerede data
Det er derfor, jeg kan lide dette artefakt: det hjælper mig med at tænke. »Hvordan rapporterer vi på tværs af Salesforce og ERP’et?« Det er spørgsmålet fra modul 3: hvilket af mine diagrammer løser det her smukt? Landskabet. Hvis alt er på core, standardrapporter. Hvis dataene er i ERP’et og datavarehuset, kan du se det med det samme. »Hvor skal denne kundeattribut mastres?« Se, hvilke systemer der bruger den, og hvilket der allerede ejer kunden. »Har Salesforce brug for hver GPS-måling?« Hvem producerer den, hvem forbruger den, hvad er arbejdsbelastningen? Måske har Salesforce brug for den aktuelle position, og en anden platform gemmer historikken. Landskabet giver dig ikke svaret. Det giver dig det rigtige blik på problemet.
Én disciplin mere. I en eksisterende virksomhed skal du tegne det, der findes, ikke det, du ville ønske fandtes. Regnearket, der mailes hver fredag: tegn det. Partnerens CSV på en SFTP-server: tegn den. Integrationen, der går uden om ESB’en af historiske grunde: tegn den. Folk, der taster data ind igen mellem to systemer: vis det. Ryd ikke op i virkeligheden, mens du dokumenterer den. Du skal have det nuværende landskab, før du designer mållandskabet, og det er det, vi gør for Steve Trucking i modul 6.
Ud over eksamen: hvad AI ændrer. Landskabet er ved at blive et agentkort. Hvis en agent svarer på »hvor er min levering?«, skal landskabet sige, om svaret kommer fra Salesforce, et partnersystem, telematik, ERP’et eller en blanding. Agenter fjerner ikke systemgrænser; de gør det endnu vigtigere at vide, hvilket system der er autoritativt, og hvordan man når det sikkert.
Hvilke systemer og brugergrupper der hører hjemme på landskabet, og hvordan deres placering viser deres rolle.
Hvilke flows der krydser systemgrænser, i hvilken retning, og hvad der kommer tilbage.
Hvordan hver forbindelse autentificerer, hvilken mekanisme der bærer den, og om den er synkron, asynkron, batch eller fødereret.
Hvornår en navngiven pil er nok, og hvornår en interaktion skal have sin egen swim lane.
Hvad oversigten bag billedet registrerer: ejer, arbejdsbelastning, volumen, org, timing, autentificering og kopiere, referere eller føderere.
Landskabet er ikke noget, jeg tegner, når arkitekturen er færdig. Det er sådan, jeg finder arkitekturen. Og når du tror, det er færdigt, så lad være med at beundre det. Gå det igennem. Hver pil, du endnu ikke kan forklare, viser dig, hvor arbejdet er.
