Steve Truckings landskap

🌐 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)

Bilden är skapad med AI

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

Modul 6 av 6 i kapitlet Förstå företagets data, kapitel 4 i kursen Data Architect. Varje modul står på egna ben. Föregående: Org-strategi är ett landskapsbeslut · Nästa: nästa kapitel, Datakvalitet och styrning

Frågan den här modulen besvarar: Vad berättar ett verkligt landskap för oss innan vi designar något?

Det här kapitlet har zoomat ut kameran: Salesforce som ett system bland många, typerna av data, systemen runt Salesforce, hur du ritar landskapet och org-strategi. Nu sätter vi ihop det på Steve Trucking. Men vi ska inte laga något än. Det är disciplinen: rita det som finns, gå igenom varje pil och se vad landskapet berättar.

Börja med det vi vet

Steve Trucking kör en Salesforce-org, i USA. Service Cloud hanterar ärenden från mottagare (Recipients) och detaljhandelspartner (Retail Partners); Field Service sköter besök, team (crews) och mobilappen; Experience Cloud ger detaljhandelspartnerna en portal, som i dag bara används för reklamationer och rapporter; Sales Cloud håller koll på partneravtal och anbud för nya distributionscentraler (DC). Så Salesforce hamnar i mitten.

Till vänster människorna: 45 trafikledare som sitter inne i detaljhandelspartnernas DC:n, ungefär 700 teammedlemmar på 330 lastbilar, 60 kundtjänsthandläggare, 40 personer inom drift, ekonomi och försäljning, och ungefär 300 användare hos detaljhandelspartnerna. Det säger oss redan något: det här är inget avdelnings-CRM. Det är en operativ plattform för större delen av verksamheten. Men det är fortfarande en enda ruta. Nu ska vi se vad som finns runt den.

Click to enlarge

Steve Trucking i dag, före en ordentlig implementering. Varje manifest landar i RouteDesk; trafikledarna knappar in rutter i Salesforce och klara stopp tillbaka, för hand; FleetLink saknar sin koppling.

Markera det som är fel

Det här är ett nuläge, före en ordentlig implementering, och det skriver jag på ritningen. Sedan öppnar jag färgpaletten. På ett landskap över ett färdigt system använder jag inte rött; på ett nuläge gör jag det. Rött markerar en dålig eller felaktig process, streckat markerar något som görs för hand, och röda prickar markerar en koppling som saknas. Att utelämna en pil säger också något. Inget av det är dekoration: varje röd linje är ett krav som väntar på att skrivas.

Tre partner, tre integrationer

De tre detaljhandelspartnerna skickar manifest på tre olika sätt, så rita var och en för sig.

Keystone lägger ett manifest som CSV på en SFTP-server varje eftermiddag, för leverans två dagar senare, och vill ha en statusfil tillbaka varje natt. Två pilar: manifest in som fil, initierad av Keystone, och status ut som fil, initierad av RouteDesk. Asynkront, med ett brett tidsfönster.

Redrock skickar manifest via ett REST API och förväntar sig statusuppdateringar via webhook när de händer. Två pilar, två mekanismer: Redrock anropar in med manifest via API:et, och RouteDesk anropar ut med status via webhooken. Nära realtid.

Brightwave skickar EDI-filer via ett nätverk hos en tredje part och förväntar sig EDI-statusmeddelanden tillbaka. Ett annat format, en annan mekanism.

Samma affärsbegrepp (manifest, leverans, status), tre helt olika integrationer. Förenkla inte ritningen för att du skulle vilja att de var konsekventa. Det är de inte. Det är nuläget.

Gå sedan igenom dem. Keystone: hur autentiserar SFTP-kopplingen, var landar filen, vad plockar upp den, hur vet vi att hela filen bearbetades, vad händer med en dålig rad, och hur får Keystone veta om en ändring före kvällens fil? Redrock: hur autentiserar API:et, vad händer när någon av sidorna ligger nere, vad räknas som en lyckad webhook, och vad händer om samma status kommer två gånger? Brightwave: vem driver EDI-nätverket, var sker översättningen, vilka kvittenser kommer tillbaka? Vi designar inte om något. Vi upptäcker frågorna. Det är landskapets jobb.

RouteDesk finns fortfarande kvar

RouteDesk är det gamla skrivbordsverktyget för trafikledning och ruttplanering som trafikledarna använder i varje DC för att göra manifest till rutter. Det rymmer åtta års leveranshistorik, och det ska avvecklas. Rita det ändå. Ett vanligt misstag är att utelämna systemet ”som vi ska bli av med”. När då? Säg att svaret är arton månader. Då är det en del av arkitekturen i minst arton månader, och dess åtta års historik, ungefär fem miljoner leveranser, försvinner inte när applikationen gör det. Och titta på vad landskapet avslöjar: RouteDesk och Salesforce är inte sammankopplade. Teamen arbetar med sina stopp i Field Service-appen i Salesforce, men rutterna byggs i RouteDesk, så trafikledarna knappar in dem i Salesforce varje kväll och knappar sedan tillbaka de klara stoppen i RouteDesk så att det kan skicka status till partnerna. Ungefär 3 300 stopp om dagen, två gånger, för hand. Det är streckat och rött på ritningen. Det säger dig också att Redrocks webhook ”när de händer” inte riktigt är när de händer. Vad äger RouteDesk i dag? Vad är beroende av det? Vilken historik måste överleva det, och var: i Salesforce, i datalagret, i ett arkiv? Vi svarar inte än. Landskapet har just avslöjat frågorna.

FleetLink är en ö

FleetLink, telematikplattformen, får GPS från varje lastbil: ungefär 200 000 avläsningar om dagen, varje lastbil, varje minut den är igång. Och den är inte kopplad till någonting. Trafikledarna tittar på den på en separat skärm. Så rita FleetLink utan pilar. Ingen magisk integrationslinje för att vi tycker att det borde finnas en.

Räkna sedan nollorna: 200 000 om dagen är över 70 miljoner om året. Det är inte ”vi har GPS-data”. Det är en strömmande källa med många nollor, som ligger utanför Salesforce-upplevelsen. Behöver Salesforce 70 miljoner avläsningar om året? Förmodligen inte alla. Det är en designfråga för senare.

Ekonomi har sin egen sanning

Ekonomins ERP fakturerar varje detaljhandelspartner per leverans, installation och bortforsling, och betalar ut teamens incitament. Och leveransantalen når det via ett månatligt kalkylark. Rita kalkylarket. Ersätt det inte med en prydlig API-pil för att vi är arkitekter och vet bättre; det är en del av den nuvarande arkitekturen. Och när det väl är ritat kommer frågorna: vem gör det, från vilket system, vem kontrollerar det, vad händer om en leverans ändras efter att det skickats, och vems siffra vinner? Det hänger pengar på svaren.

Snowflake får en veckoexport

Snowflake rymmer analys för drift och ekonomi, matad av en veckoexport. Snowflake kan inte göra det själv; något i mitten gör det: ett schemalagt exportjobb, som körs utanför Salesforce, hämtar via Bulk API och laddar Snowflake. Var analysen bor följer var data bor, och Snowflake är redan det analytiska hemmet. Men tidpunkten säger oss också något. ”Vad hände förra månaden?” Då räcker ett veckoflöde. ”Var är den här leveransen just nu?” Där skulle jag inte börja i Snowflake. Samma företag, annan arbetslast, annan aktualitet, annat svar.

Identiteten når inte alla på samma sätt

Företagets identitetsleverantör hamnar ovanför Salesforce. Kontorspersonalen använder single sign-on. Men trafikledare och team loggar in med Salesforce-inloggningar. Så en enda förtroendelinje från IdP:n till Salesforce skulle dölja halva historien. Den verkliga frågan är vilka användare som loggar in via vilken väg, och den hör hemma på landskapet.

Mottagarens upplevelse har en lucka

SMS- och e-postleverantören skickar mottagarna ett generellt meddelande om att ”din leverans kommer i morgon” från RouteDesk. Det finns ingen spårningslänk. Samtidigt finns det ungefär 180 000 ärenden om året, och ungefär 60 % av dem är ”var är min leverans?”: runt 108 000 ärenden om året som ställer samma fråga. Lägg nu det bredvid FleetLink. Företaget vet var dess lastbilar är. Dess mottagare ringer hela tiden och frågar. Och systemet som vet är inte kopplat till det som svarar. Jag behöver inte designa lösningen än. Landskapet berättar redan historien.

Lägg nollorna i inventeringen

Räkna nu det som rör sig. Precis som i modul 4 hamnar nollorna inte på pilarna; de hamnar i inventeringen bakom bilden, där de styr mekanismerna när vi designar. Ungefär en miljon leveranser om året, ungefär 3 300 om dagen, med 30 % tillväxt per år; ungefär 1,6 leveransrader var; ungefär åtta statusuppdateringar var, alltså åtta miljoner statusuppdateringar om året i dag; fyra till fem miljoner foton om året, i dag på teamens egna telefoner; ungefär 200 000 GPS-avläsningar om dagen; ungefär 180 000 ärenden om året. En pil märkt ”leveransstatus” är inget enstaka meddelande. Rutorna säger dig vad som finns. Pilarna säger dig vad som rör sig. Nollorna säger dig om dina antaganden överlever verkligheten.

Click to enlarge

Inventeringen bakom Steve Truckings landskap: volymen bredvid mekanismen den kommer att styra.

Ingen målarkitektur än, och jag ser redan var viktiga data bor, vilken typ de är, hur snabbt de rör sig och hur systemen utbyter dem.

Bortom provet: vad AI ändrar. Anta att Steve Trucking bygger en agent som ska svara på en mottagares ”var är min leverans?”. Vilket system ska den fråga? Salesforce känner till besöket, FleetLink vet var lastbilen är, partnerns manifest definierade leveransen. Det nuvarande landskapet är agentens karta, och innan agenten kan svara säkert måste arkitekten veta vilket system som är auktoritativt för varje fakta och hur aktuellt det är. Rikta en agent mot fel källa så blir inaktuella data ett självsäkert svar.

Läs av smärtan, laga den inte än

Ta ett steg tillbaka. Tre partner, tre integrationsstilar. Ett gammalt trafikledningsverktyg med åtta års historik, och trafikledare som knappar in 3 300 stopp om dagen i Salesforce och tillbaka. En telematikplattform med 200 000 avläsningar om dagen, frånkopplad. Ekonomi som räknar leveranser från ett månatligt kalkylark. Analys som ligger en vecka efter. Single sign-on för vissa användare, inte för andra. Ingen spårningslänk, och 108 000 ärenden om året som frågar var en leverans är. Allt växer med 30 % om året.

Det är mycket arkitektur ur en enda bild. Frestelsen är att börja laga. Gör inte det. Inte än. Jag vill att du ska vara bekväm med att låta ett nulägesdiagram vara fult, för ibland är nuläget fult. Poängen är inte att imponera på någon med en snygg ritning; det är en gemensam förståelse av verkligheten. Designar du om medan du dokumenterar förlorar du utgångsläget. Senare vill jag kunna säga: det här fanns, det här är problemet vi löste, det här är vad vi ändrade, och varför. Kapitel 6 börjar fatta beslut om ägarskap och identitet, och Kontrollpunkt 1 sätter ihop del 1. Kursen Integration Architect designar partnerflödena på djupet.

Vad en arkitekt bestämmer här

I det här skedet bestämmer arkitekten inte målarkitekturen. Beslutet är om nuläget är tillräckligt väl förstått för att designa en:

• Vilka system, användargrupper, datalager och externa partner som faktiskt finns i dag.
• Vilka data som korsar varje viktig gräns, i vilken riktning, hur ofta och med vilken mekanism.
• Var operativa, analytiska, strömmande, historiska och ostrukturerade data bor nu.
• Vilka flöden som bär mest volym och förtjänar uppmärksamhet tidigt.
• Vilka luckor, manuella steg, frånkopplade system, oklara auktoriteter och inkonsekventa mönster som blir uttryckliga designfrågor.

Det här kapitlet började med en idé: rita landskapet innan du designar orgen. Om jag hade börjat med Steve Truckings datamodell kunde jag ha lagt timmar på objekt och relationer medan FleetLink stod utanför med 200 000 avläsningar om dagen, RouteDesk höll åtta års historik, tre partner talade tre språk, ekonomi använde ett kalkylark och hundra tusen ärenden om året frågade var en leverans var. Det är inte frågor om objektmodellen. Det är frågor om företagets data. Rita de fula integrationerna, kalkylarket, systemet som du påstås avveckla. Skriv ner nollorna. Gå igenom varje pil. Sedan är du redo att ändra det.

Utforska vidare

• Steve Truckings brief, avsnitt 2–4, och dess landskapsdiagram.