Steve Truckings landskap

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

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 6 av 6 i kapitlet Forstå virksomhetens data, kapittel 4 i kurset Data Architect. Hver modul står på egne ben. Forrige: Org-strategi er en landskapsbeslutning · Neste: neste kapittel, Datakvalitet og styring

Spørsmålet denne modulen besvarer: Hva forteller et ekte landskap oss før vi designer noe som helst?

Dette kapitlet har trukket kameraet bakover: Salesforce som ett system blant mange, typene data, systemene rundt Salesforce, hvordan du tegner landskapet, og org-strategi. Nå setter vi det sammen på Steve Trucking. Men vi skal ikke fikse noe ennå. Det er disiplinen: tegn det som finnes, gå gjennom hver pil, og se hva landskapet forteller oss.

Start med det vi vet

Steve Trucking kjører én Salesforce-org, i USA. Service Cloud håndterer saker fra mottakere (Recipients) og detaljhandelspartnere (Retail Partners); Field Service kjører avtaler, team og mobilappen; Experience Cloud gir detaljhandelspartnerne en portal, som i dag bare brukes til reklamasjoner og rapporter; Sales Cloud holder oversikt over partnerkontrakter og anbud på nye distribusjonssentre (DC-er). Så Salesforce havner i midten.

Til venstre: menneskene. 45 utkjøringskoordinatorer som jobber inne i detaljhandelspartnernes DC-er, rundt 700 teammedlemmer på 330 lastebiler, 60 kundeserviceagenter, 40 ansatte i drift, økonomi og salg, og rundt 300 brukere hos detaljhandelspartnerne. Det forteller oss allerede noe: dette er ikke et CRM for én avdeling. Det er en driftsplattform for det meste av virksomheten. Men det er fortsatt én boks. La oss nå se hva som omgir den.

Click to enlarge

Steve Trucking i dag, før en ordentlig implementering. Hvert manifest havner i RouteDesk; koordinatorene taster rutene inn i Salesforce og fullførte stopp tilbake, for hånd; FleetLink mangler forbindelsen sin.

Marker det som er galt

Dette er en nåsituasjon, før en ordentlig implementering, og det skriver jeg på tegningen. Så åpner jeg fargepaletten. På et landskap av et ferdig system bruker jeg ikke rødt; på en nåsituasjon gjør jeg det. Rødt markerer en dårlig eller uriktig prosess, stiplet markerer noe som gjøres for hånd, og røde prikker markerer en forbindelse som mangler. Å utelate en pil sier også noe. Ingenting av dette er pynt: hver røde linje er et krav som venter på å bli skrevet.

Tre partnere, tre integrasjoner

De tre detaljhandelspartnerne sender manifester på tre forskjellige måter, så tegn hver av dem for seg.

Keystone legger et CSV-manifest på en SFTP-server hver ettermiddag, for levering to dager senere, og vil ha en statusfil tilbake hver natt. To piler: manifest inn som fil, åpnet av Keystone, og status ut som fil, åpnet av RouteDesk. Asynkront, med et vidt tidsvindu.

Redrock sender manifester gjennom et REST API og forventer statusoppdateringer via webhook etter hvert som de skjer. To piler, to mekanismer: Redrock kaller inn med manifester gjennom API-et, og RouteDesk kaller ut med status gjennom webhooken. Nesten sanntid.

Brightwave sender EDI-filer gjennom et tredjepartsnettverk og forventer EDI-statusmeldinger tilbake. Et annet format, en annen mekanisme.

De samme forretningsbegrepene (manifest, levering, status), tre helt forskjellige integrasjoner. Ikke forenkle tegningen fordi du skulle ønske de var konsistente. Det er de ikke. Det er nåsituasjonen.

Gå så gjennom dem. Keystone: hvordan autentiserer SFTP-forbindelsen, hvor havner filen, hva plukker den opp, hvordan vet vi at hele filen ble behandlet, hva skjer med en dårlig rad, og hvordan får Keystone vite om en endring før kveldens fil? Redrock: hvordan autentiserer API-et, hva skjer når en av sidene er nede, hva regnes som en vellykket webhook, og hva om samme status kommer to ganger? Brightwave: hvem driver EDI-nettverket, hvor skjer oversettelsen, hvilke kvitteringer kommer tilbake? Vi redesigner ingenting. Vi oppdager spørsmålene. Det er landskapets jobb.

RouteDesk er der fortsatt

RouteDesk er det gamle skrivebordsverktøyet for utkjøring og ruteplanlegging som koordinatorene bruker i hvert DC for å gjøre manifester om til ruter. Det inneholder åtte års leveringshistorikk, og det skal fases ut. Tegn det likevel. En vanlig feil er å utelate systemet «vi skal kvitte oss med». Når da? La oss si svaret er atten måneder. Da er det en del av arkitekturen i minst atten måneder, og de åtte årene med historikk, rundt fem millioner leveringer, forsvinner ikke når applikasjonen gjør det. Og se hva landskapet avslører: RouteDesk og Salesforce er ikke koblet sammen. Teamene jobber med stoppene sine i Field Service-appen i Salesforce, men rutene bygges i RouteDesk, så koordinatorene taster dem inn på nytt i Salesforce hver kveld, og taster så de fullførte stoppene tilbake i RouteDesk, slik at det kan sende status til partnerne. Rundt 3 300 stopp om dagen, to ganger, for hånd. Det er stiplet og rødt på tegningen. Det forteller deg også at Redrocks «etter hvert som de skjer»-webhook ikke egentlig skjer etter hvert. Hva eier RouteDesk i dag? Hva er avhengig av det? Hvilken historikk må overleve det, og hvor: i Salesforce, i datavarehuset, i et arkiv? Vi svarer ikke ennå. Landskapet har bare avslørt spørsmålene.

FleetLink er en øy

FleetLink, telematikkplattformen, får GPS fra hver lastebil: rundt 200 000 målinger om dagen, hver lastebil, hvert minutt den er i gang. Og den er ikke koblet til noe som helst. Koordinatorene ser på den på en egen skjerm. Så tegn FleetLink uten piler. Ingen magisk integrasjonslinje fordi vi synes det burde vært en.

Tell så nullene: 200 000 om dagen er over 70 millioner i året. Det er ikke «vi har GPS-data». Det er en strømmende kilde med mange nuller, som ligger utenfor Salesforce-opplevelsen. Trenger Salesforce 70 millioner målinger i året? Sannsynligvis ikke alle. Det er et designspørsmål for senere.

Økonomi har sin egen sannhet

Økonomisystemet (ERP) fakturerer hver detaljhandelspartner per levering, installasjon og bortkjøring, og betaler incentiver til teamene. Og leveringstallene kommer dit gjennom et månedlig regneark. Tegn regnearket. Ikke bytt det ut med en ryddig API-pil fordi vi er arkitekter og vet bedre; det er en del av dagens arkitektur. Og når det først er tegnet, kommer spørsmålene: hvem lager det, fra hvilket system, hvem kontrollerer det, hva om en levering endres etter at det er sendt, og hvem sitt tall vinner? Det henger penger på svarene.

Snowflake får en ukentlig eksport

Snowflake inneholder analyse for drift og økonomi, matet av en ukentlig eksport. Det klarer ikke Snowflake selv; noe i midten gjør det: en planlagt eksportjobb, som kjører utenfor Salesforce, henter gjennom Bulk API og laster inn i Snowflake. Hvor analysen bor, følger av hvor dataene bor, og Snowflake er allerede det analytiske hjemmet. Men tidspunktet forteller oss også noe. «Hva skjedde forrige måned?» Da holder en ukentlig strøm. «Hvor er denne leveringen akkurat nå?» Da er ikke Snowflake der jeg ville begynt. Samme virksomhet, annen arbeidsbelastning, annen ferskhet, annet svar.

Identitet når ikke alle på samme måte

Virksomhetens identitetsleverandør plasseres over Salesforce. Kontoransatte bruker single sign-on. Men koordinatorer og team logger inn med Salesforce-brukernavn og passord. Så én tillitslinje fra IdP-en til Salesforce ville skjult halve historien. Det egentlige spørsmålet er hvilke brukere som logger inn gjennom hvilken vei, og det hører hjemme på landskapet.

Mottakeropplevelsen har et hull

SMS- og e-postleverandøren sender mottakerne en generell melding om at «leveringen din kommer i morgen» fra RouteDesk. Det finnes ingen sporingslenke. Samtidig er det rundt 180 000 saker i året, og rundt 60 % av dem er «hvor er leveringen min?»: omtrent 108 000 saker i året som stiller det samme spørsmålet. Sett det så ved siden av FleetLink. Selskapet vet hvor lastebilene er. Mottakerne fortsetter å ringe for å spørre. Og systemet som vet, er ikke koblet til det som svarer. Jeg trenger ikke designe løsningen ennå. Landskapet forteller allerede historien.

Før nullene inn i inventaret

Tell nå det som beveger seg. Som i modul 4 skal ikke nullene på pilene; de skal i inventaret bak bildet, der de vil styre mekanismene når vi designer. Rundt en million leveringer i året, rundt 3 300 om dagen, med 30 % vekst i året; rundt 1,6 leveringslinjer per levering; rundt åtte statusoppdateringer per levering, altså åtte millioner statusoppdateringer i året i dag; fire til fem millioner bilder i året, i dag på teamenes egne telefoner; rundt 200 000 GPS-målinger om dagen; rundt 180 000 saker i året. En pil merket «leveringsstatus» er ikke en melding nå og da. Boksene forteller deg hva som finnes. Pilene forteller deg hva som beveger seg. Nullene forteller deg om antakelsene dine overlever virkeligheten.

Click to enlarge

Inventaret bak Steve Truckings landskap: volumet ved siden av mekanismen det vil styre.

Ingen målarkitektur ennå, og jeg kan allerede se hvor de viktige dataene bor, hvilken type de er, hvor fort de beveger seg og hvordan systemene utveksler dem.

Utover eksamen: hva KI endrer. Tenk deg at Steve Trucking bygger en agent som skal svare på en mottakers «hvor er leveringen min?». Hvilket system skal den spørre? Salesforce kjenner avtalen, FleetLink vet hvor lastebilen er, og partnerens manifest definerte leveringen. Det nåværende landskapet er agentens kart, og før agenten kan svare trygt, må arkitekten vite hvilket system som er autoritativt for hvert faktum, og hvor oppdatert det er. Pek en agent mot feil kilde, og utdaterte data blir et selvsikkert svar.

Les smerten, ikke fiks den ennå

Ta et skritt tilbake. Tre partnere, tre integrasjonsstiler. Et gammelt utkjøringsverktøy med åtte års historikk, og koordinatorer som taster 3 300 stopp om dagen inn i Salesforce og tilbake. En telematikkplattform med 200 000 målinger om dagen, frakoblet. Økonomi som teller leveringer fra et månedlig regneark. Analyse som ligger en uke etter. Single sign-on for noen brukere, ikke for andre. Ingen sporingslenke, og 108 000 saker i året som spør hvor en levering er. Alt sammen med 30 % vekst i året.

Det er mye arkitektur fra ett bilde. Fristelsen er å begynne å fikse det. Ikke gjør det. Ikke ennå. Jeg vil at du skal være komfortabel med å la et diagram over nåsituasjonen være stygt, for noen ganger er nåsituasjonen stygg. Poenget er ikke å imponere noen med en ren tegning; det er en felles forståelse av virkeligheten. Redesigner du mens du dokumenterer, mister du utgangspunktet. Senere vil jeg kunne si: dette er det som fantes, dette er problemet vi løste, dette er det vi endret, og hvorfor. Kapittel 6 begynner å ta beslutninger om eierskap og identitet, og Kontrollpunkt 1 setter sammen del 1. Kurset Integration Architect designer partnerflytene i dybden.

Hva en arkitekt bestemmer her

På dette stadiet bestemmer ikke arkitekten målarkitekturen. Beslutningen er om nåsituasjonen er godt nok forstått til å designe en:

• Hvilke systemer, brukergrupper, datalagre og eksterne partnere som faktisk finnes i dag.
• Hvilke data som krysser hver viktig grense, i hvilken retning, hvor ofte og med hvilken mekanisme.
• Hvor de operative, analytiske, strømmende, historiske og ustrukturerte dataene bor nå.
• Hvilke flyter som bærer mest volum og fortjener oppmerksomhet tidlig.
• Hvilke hull, manuelle steg, frakoblede systemer, uklare autoriteter og inkonsekvente mønstre som blir eksplisitte designspørsmål.

Dette kapitlet startet med én idé: tegn landskapet før du designer orgen. Hvis jeg hadde startet med datamodellen til Steve Trucking, kunne jeg brukt timevis på objekter og relasjoner mens FleetLink sto utenfor med 200 000 målinger om dagen, RouteDesk holdt på åtte års historikk, tre partnere snakket tre språk, økonomi brukte et regneark, og hundre tusen saker i året spurte hvor en levering var. Det er ikke spørsmål om objektmodellen. Det er spørsmål om virksomhetens data. Tegn de stygge integrasjonene, regnearket, systemet du visstnok skal fase ut. Skriv ned nullene. Gå gjennom hver pil. Da er du klar til å endre det.

Les mer

• Briefen for Steve Trucking, del 2–4, og landskapsdiagrammet der.