Het landschap van Steve Trucking

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 6 van 6 in het hoofdstuk Enterprisegegevens begrijpen, hoofdstuk 4 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Orgstrategie is een landschapsbeslissing · Volgende: het volgende hoofdstuk, Datakwaliteit en governance

De vraag die deze module beantwoordt: Wat vertelt een echt landschap ons voordat we iets ontwerpen?

Dit hoofdstuk heeft steeds uitgezoomd: Salesforce als één systeem van vele, de soorten data, de systemen rond Salesforce, hoe je het landschap tekent, en orgstrategie. Laten we het nu samenbrengen bij Steve Trucking. Maar we gaan nog niets repareren. Dat is de discipline: teken wat er bestaat, loop elke pijl door, en zie wat het landschap ons vertelt.

Begin bij wat we weten

Steve Trucking draait één Salesforce-org, in de VS. Service Cloud behandelt cases van ontvangers en retailpartners; Field Service regelt afspraken, ploegen en de mobiele app; Experience Cloud geeft retailpartners een portaal, dat vandaag alleen voor claims en rapporten gebruikt wordt; Sales Cloud volgt partnercontracten en biedingen voor nieuwe distributiecentra. Dus Salesforce komt in het midden.

Links de mensen: 45 planningscoördinatoren die in de distributiecentra van de retailpartners werken, ongeveer 700 ploegleden op 330 vrachtwagens, 60 klantenservicemedewerkers, 40 medewerkers van operations, finance en sales, en ongeveer 300 gebruikers bij retailpartners. Dat vertelt ons al iets: dit is geen afdelings-CRM. Het is een operationeel platform voor het grootste deel van het bedrijf. Maar het is nog steeds één vakje. Laten we nu zien wat het omringt.

Click to enlarge

Steve Trucking vandaag, vóór een goede implementatie. Elke vrachtlijst komt in RouteDesk terecht; coördinatoren typen routes met de hand over in Salesforce en voltooide stops terug; FleetLink mist zijn verbinding.

Markeer wat er mis is

Dit is een huidige situatie, vóór een goede implementatie, en dat zet ik op de tekening. Dan haal ik het palet tevoorschijn. Op een landschap van een af systeem gebruik ik geen rood; op een huidige situatie wel. Rood markeert een slecht of onjuist proces, gestreept markeert iets wat met de hand gebeurt, en rode stippen markeren een verbinding die ontbreekt. Een pijl weglaten zegt ook iets. Niets ervan is versiering: elke rode lijn is een eis die erop wacht om opgeschreven te worden.

Drie partners, drie integraties

De drie retailpartners sturen vrachtlijsten op drie verschillende manieren, dus teken elk ervan apart.

Keystone zet elke middag een CSV-vrachtlijst op een SFTP-server, voor levering twee dagen later, en wil elke nacht een statusbestand terug. Twee pijlen: vrachtlijst in per bestand, geopend door Keystone, en status uit per bestand, geopend door RouteDesk. Asynchroon, met een ruim tijdvenster.

Redrock stuurt vrachtlijsten via een REST-API en verwacht statusupdates per webhook zodra ze gebeuren. Twee pijlen, twee mechanismen: Redrock roept naar binnen aan met vrachtlijsten via de API, en RouteDesk roept naar buiten aan met status via de webhook. Bijna realtime.

Brightwave stuurt EDI-bestanden via een netwerk van een derde partij en verwacht EDI-statusberichten terug. Nog een formaat, nog een mechanisme.

Dezelfde bedrijfsbegrippen (vrachtlijst, levering, status), drie totaal verschillende integraties. Vereenvoudig de tekening niet omdat je zou willen dat ze consistent waren. Dat zijn ze niet. Dat is de huidige situatie.

Loop ze dan door. Keystone: hoe authenticeert de SFTP-verbinding, waar komt het bestand terecht, wat pakt het op, hoe weten we dat het hele bestand verwerkt is, wat gebeurt er met een foute rij, en hoe hoort Keystone van een wijziging vóór het bestand van vannacht? Redrock: hoe authenticeert de API, wat gebeurt er als een van beide kanten uitvalt, wat telt als een geslaagde webhook, wat als dezelfde status twee keer aankomt? Brightwave: wie beheert het EDI-netwerk, waar zit de vertaling, welke ontvangstbevestigingen komen terug? We herontwerpen niets. We ontdekken de vragen. Dat is de taak van het landschap.

RouteDesk is er nog

RouteDesk is de verouderde desktoptool voor planning en routering die coördinatoren in elk distributiecentrum gebruiken om vrachtlijsten in routes om te zetten. Hij bevat acht jaar leveringshistorie, en hij staat gepland om uitgefaseerd te worden. Teken hem toch. Een veelgemaakte fout is het systeem weglaten “waar we vanaf gaan”. Wanneer? Zeg dat het antwoord achttien maanden is. Dan is het minstens achttien maanden deel van de architectuur, en zijn acht jaar historie, ongeveer vijf miljoen leveringen, verdwijnen niet als de applicatie verdwijnt. En kijk wat het landschap blootlegt: RouteDesk en Salesforce zijn niet verbonden. Ploegen werken hun stops af in de Field Service-app van Salesforce, maar de routes worden in RouteDesk gebouwd, dus coördinatoren typen ze elke avond over in Salesforce, en typen daarna de voltooide stops terug in RouteDesk zodat die status naar de partners kan sturen. Ongeveer 3.300 stops per dag, twee keer, met de hand. Dat is gestreept en rood op de tekening. Het vertelt je ook dat de webhook van Redrock, “zodra ze gebeuren”, niet echt zodra ze gebeuren is. Waarvan is RouteDesk vandaag eigenaar? Wat is ervan afhankelijk? Welke historie moet hem overleven, en waar: Salesforce, het datawarehouse, een archief? We beantwoorden het nog niet. Het landschap heeft de vragen net blootgelegd.

FleetLink is een eiland

FleetLink, het telematicaplatform, krijgt gps-data van elke vrachtwagen: ongeveer 200.000 metingen per dag, elke vrachtwagen, elke minuut dat hij rijdt. En het is met niets verbonden. Coördinatoren kijken ernaar op een apart scherm. Dus teken FleetLink zonder pijlen. Geen magische integratielijn omdat we vinden dat die er zou moeten zijn.

Tel dan de nullen: 200.000 per dag is meer dan 70 miljoen per jaar. Dat is niet “we hebben gps-data”. Het is een streamingbron met veel nullen, die buiten de Salesforce-ervaring staat. Heeft Salesforce 70 miljoen metingen per jaar nodig? Waarschijnlijk niet allemaal. Dat is een ontwerpvraag voor later.

Finance heeft zijn eigen waarheid

Het financiële ERP factureert elke retailpartner per levering, installatie en afvoer van oude spullen, en betaalt de bonussen van de ploegen. En leveringsaantallen bereiken het via een maandelijkse spreadsheet. Teken de spreadsheet. Vervang hem niet door een nette API-pijl omdat we architecten zijn en het beter weten; hij is deel van de huidige architectuur. En als hij getekend is, komen de vragen: wie maakt hem, uit welk systeem, wie controleert hem, wat als een levering verandert nadat hij verstuurd is, en wiens getal wint? Er hangt geld aan de antwoorden.

Snowflake krijgt een wekelijkse export

Snowflake bevat de analytics van operations en finance, gevoed door een wekelijkse export. Snowflake kan dat niet zelf; iets in het midden doet het: een geplande exporttaak, die buiten Salesforce draait, via de Bulk API ophaalt en Snowflake laadt. Waar analytics staat, volgt waar de data staat, en Snowflake is al het analytische thuis. Maar de timing vertelt ons ook iets. “Wat gebeurde er vorige maand?” Een wekelijkse feed is prima. “Waar is deze levering nu?” Snowflake is niet waar ik zou beginnen. Dezelfde enterprise, een andere workload, een andere actualiteit, een ander antwoord.

Identiteit bereikt niet iedereen op dezelfde manier

De identiteitsprovider van het bedrijf komt boven Salesforce. Kantoorpersoneel gebruikt single sign-on. Maar coördinatoren en ploegen loggen in met Salesforce-inloggegevens. Dus één vertrouwenslijn van de IdP naar Salesforce zou het halve verhaal verbergen. De echte vraag is welke gebruikers via welk pad inloggen, en dat hoort op het landschap.

De ervaring van de ontvanger heeft een gat

De sms- en e-mailprovider stuurt ontvangers een algemeen bericht “je levering komt morgen” vanuit RouteDesk. Er is geen trackinglink. Ondertussen zijn er ongeveer 180.000 cases per jaar, en ongeveer 60% daarvan is “waar blijft mijn levering?”: zo’n 108.000 cases per jaar met dezelfde vraag. Zet dat nu naast FleetLink. Het bedrijf weet waar zijn vrachtwagens zijn. Zijn ontvangers blijven bellen om het te vragen. En het systeem dat het weet, is niet verbonden met het systeem dat antwoordt. Ik hoef de oplossing nog niet te ontwerpen. Het landschap vertelt het verhaal al.

Zet de nullen in de inventaris

Tel nu wat er beweegt. Net als in module 4 gaan de nullen niet op de pijlen; ze gaan in de inventaris achter de tekening, waar ze de mechanismen sturen als we ontwerpen. Ongeveer een miljoen leveringen per jaar, ongeveer 3.300 per dag, met 30% groei per jaar; ongeveer 1,6 leveringsitems per levering; ongeveer acht statusupdates per levering, dus vandaag acht miljoen statusupdates per jaar; vier tot vijf miljoen foto’s per jaar, nu op de eigen telefoons van de ploegen; ongeveer 200.000 gps-metingen per dag; ongeveer 180.000 cases per jaar. Een pijl met het label “leveringsstatus” is geen incidenteel bericht. De vakken vertellen je wat er bestaat. De pijlen vertellen je wat er beweegt. De nullen vertellen je of je aannames de werkelijkheid overleven.

Click to enlarge

De inventaris achter het landschap van Steve Trucking: het volume naast het mechanisme dat het zal sturen.

Nog geen doelarchitectuur, en ik kan al zien waar de belangrijke data staat, wat voor soort het is, hoe snel het beweegt en hoe de systemen het uitwisselen.

Voorbij het examen: wat AI verandert. Stel dat Steve Trucking een agent bouwt om de vraag “waar blijft mijn levering?” van een ontvanger te beantwoorden. Welk systeem moet hij vragen? Salesforce kent de afspraak, FleetLink weet waar de vrachtwagen is, de vrachtlijst van de partner definieerde de levering. Het huidige landschap is de kaart van de agent, en voordat de agent veilig kan antwoorden, moet de architect weten welk systeem gezaghebbend is voor elk feit en hoe actueel het is. Richt een agent op de verkeerde bron en verouderde data wordt een zelfverzekerd antwoord.

Lees de pijn, repareer haar nog niet

Doe een stap terug. Drie partners, drie integratiestijlen. Een verouderde planningstool met acht jaar historie, en coördinatoren die 3.300 stops per dag overtypen in Salesforce en terug. Een telematicaplatform met 200.000 metingen per dag, niet verbonden. Finance die leveringen telt uit een maandelijkse spreadsheet. Analytics een week achter. Single sign-on voor sommige gebruikers, niet voor andere. Geen trackinglink, en 108.000 cases per jaar die vragen waar een levering is. Alles groeit 30% per jaar.

Dat is veel architectuur uit één tekening. De verleiding is om te beginnen met repareren. Doe het niet. Nog niet. Ik wil dat je het prima vindt om een diagram van de huidige situatie lelijk te laten, want soms is de huidige situatie lelijk. Het gaat er niet om iemand te imponeren met een schone tekening; het gaat om een gedeeld begrip van de werkelijkheid. Herontwerp terwijl je documenteert en je verliest de nulmeting. Later wil ik kunnen zeggen: dit bestond er, dit is het probleem dat we oplosten, dit is wat we veranderden, en waarom. Hoofdstuk 6 begint beslissingen te nemen over eigenaarschap en identiteit, en Checkpoint 1 brengt Deel 1 samen. De cursus Integration Architect ontwerpt de partnerstromen in de diepte.

Wat een architect hier beslist

In deze fase beslist de architect niet over de doelarchitectuur. De beslissing is of de huidige situatie goed genoeg begrepen is om er een te ontwerpen:

• Welke systemen, gebruikersgroepen, dataopslag en externe partners er vandaag echt bestaan.
• Welke data elke belangrijke grens oversteekt, in welke richting, hoe vaak en met welk mechanisme.
• Waar de operationele, analytische, streaming, historische en ongestructureerde data nu staat.
• Welke stromen het meeste volume dragen en vroeg aandacht verdienen.
• Welke gaten, handmatige stappen, losgekoppelde systemen, onduidelijke zeggenschap en inconsistente patronen expliciete ontwerpvragen worden.

Dit hoofdstuk begon met één idee: teken het landschap voordat je de org ontwerpt. Als ik met het datamodel van Steve Trucking begonnen was, had ik uren aan objecten en relaties kunnen besteden terwijl FleetLink buiten stond met 200.000 metingen per dag, RouteDesk acht jaar historie bewaarde, drie partners drie talen spraken, finance een spreadsheet gebruikte, en honderdduizend cases per jaar vroegen waar een levering was. Dat zijn geen vragen over het objectmodel. Het zijn vragen over enterprisegegevens. Teken de lelijke integraties, de spreadsheet, het systeem dat je zogenaamd uitfaseert. Schrijf de nullen op. Loop elke pijl door. Dan ben je klaar om het te veranderen.

Verder lezen

• De briefing van Steve Trucking, secties 2–4, en het landschapsdiagram.