Steve Trucking's Landscape

🌐 Also in 28 languages

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 6 of 6 in the chapter Understanding Enterprise Data, chapter 4 of the Data Architect course. Each module stands on its own. Previous: Org Strategy Is a Landscape Decision · Next: the next chapter, Data Quality and Governance

The question this module answers: What does a real landscape tell us before we design anything?

This chapter has been pulling the camera back: Salesforce as one system among many, the kinds of data, the systems around Salesforce, how to draw the landscape, and org strategy. Now let’s put it together on Steve Trucking. But we’re not going to fix anything yet. That’s the discipline: draw what exists, walk every arrow, and see what the landscape tells us.

Start With What We Know

Steve Trucking runs one Salesforce org, in the US. Service Cloud handles cases from Recipients and Retail Partners; Field Service runs appointments, crews and the mobile app; Experience Cloud gives Retail Partners a portal, used today only for claims and reports; Sales Cloud tracks partner contracts and bids for new DCs. So Salesforce goes in the middle.

On the left, the people: 45 dispatch coordinators working inside the Retail Partners’ DCs, about 700 crew members on 330 trucks, 60 customer-care agents, 40 operations, finance and sales staff, and about 300 Retail Partner users. That already tells us something: this isn’t a departmental CRM. It’s an operational platform for most of the business. But it’s still one box. Now let’s see what surrounds it.

Click to enlarge

Steve Trucking today, before a proper implementation. Every manifest lands in RouteDesk; coordinators rekey routes into Salesforce and completed stops back, by hand; FleetLink is missing its connection.

Mark What’s Wrong

This is a current state, before a proper implementation, and I say so on the drawing. Then I open up the palette. On a landscape of a finished system I don’t use red; on a current state I do. Red marks a bad or improper process, dashed marks something done by hand, and red dots mark a connection that’s missing. Leaving an arrow out says something too. None of it is decoration: every red line is a requirement waiting to be written.

Three Partners, Three Integrations

The three Retail Partners send manifests three different ways, so draw each one separately.

Keystone drops a CSV manifest on an SFTP server each afternoon, for delivery two days later, and wants a status file back each night. Two arrows: manifest in by file, opened by Keystone, and status out by file, opened by RouteDesk. Asynchronous, with a wide timing window.

Redrock sends manifests through a REST API and expects status updates by webhook as they happen. Two arrows, two mechanisms: Redrock calls in with manifests through the API, and RouteDesk calls out with status through the webhook. Near real time.

Brightwave sends EDI files through a third-party network and expects EDI status messages back. Another format, another mechanism.

Same business concepts (manifest, delivery, status), three completely different integrations. Don’t simplify the drawing because you’d like them to be consistent. They aren’t. That’s the current state.

Then walk them. Keystone: how does the SFTP connection authenticate, where does the file land, what picks it up, how do we know the whole file was processed, what happens to a bad row, and how does Keystone hear about a change before tonight’s file? Redrock: how does the API authenticate, what happens when either side is down, what counts as a successful webhook, what if the same status arrives twice? Brightwave: who runs the EDI network, where’s the translation, what acknowledgments come back? We’re not redesigning anything. We’re discovering the questions. That’s the landscape’s job.

RouteDesk Is Still There

RouteDesk is the legacy desktop dispatch and routing tool coordinators use in each DC to turn manifests into routes. It holds eight years of delivery history, and it’s scheduled to be retired. Draw it anyway. A common mistake is leaving off the system “we’re getting rid of.” When? Say the answer is eighteen months. Then it’s part of the architecture for at least eighteen months, and its eight years of history, about five million deliveries, don’t vanish when the application does. And look at what the landscape exposes: RouteDesk and Salesforce aren’t connected. Crews work their stops in Salesforce’s Field Service app, but the routes are built in RouteDesk, so coordinators rekey them into Salesforce every evening, then rekey the completed stops back into RouteDesk so it can send status to the partners. About 3,300 stops a day, twice, by hand. That’s dashed and red on the drawing. It also tells you Redrock’s “as they happen” webhook isn’t really as they happen. What does RouteDesk own today? What depends on it? What history must survive it, and where: Salesforce, the warehouse, an archive? We’re not answering yet. The landscape just exposed the questions.

FleetLink Is an Island

FleetLink, the telematics platform, gets GPS from every truck: about 200,000 readings a day, every truck, every minute it’s running. And it isn’t connected to anything. Coordinators look at it on a separate screen. So draw FleetLink with no arrows. No magic integration line because we think there should be one.

Then count the zeros: 200,000 a day is over 70 million a year. That’s not “we have GPS data.” It’s a streaming source with a lot of zeros, sitting outside the Salesforce experience. Does Salesforce need 70 million readings a year? Probably not all of them. That’s a design question for later.

Finance Has Its Own Truth

The finance ERP invoices each Retail Partner per delivery, install and haul-away, and pays crew incentives. And delivery counts reach it through a monthly spreadsheet. Draw the spreadsheet. Don’t replace it with a tidy API arrow because we’re architects and know better; it’s part of the current architecture. And once it’s drawn, the questions come: who makes it, from which system, who checks it, what if a delivery changes after it’s sent, and whose number wins? Money is attached to the answers.

Snowflake Gets a Weekly Export

Snowflake holds operations and finance analytics, fed by a weekly export. Snowflake can’t do that itself; something in the middle does: a scheduled export job, running outside Salesforce, that pulls through the Bulk API and loads Snowflake. Where analytics lives follows where the data lives, and Snowflake is already the analytical home. But the timing tells us something too. “What happened last month?” A weekly feed is fine. “Where is this delivery right now?” Snowflake isn’t where I’d start. Same enterprise, different workload, different freshness, different answer.

Identity Doesn’t Reach Everyone the Same Way

The corporate identity provider goes above Salesforce. Office staff use single sign-on. But coordinators and crews log in with Salesforce credentials. So one trust line from the IdP to Salesforce would hide half the story. The real question is which users sign in through which path, and that belongs on the landscape.

The Recipient Experience Has a Gap

The SMS and email provider sends Recipients a generic “your delivery is tomorrow” message from RouteDesk. There’s no tracking link. Meanwhile there are about 180,000 cases a year, and about 60% of them are “where’s my delivery?”: roughly 108,000 cases a year asking the same question. Now put that next to FleetLink. The company knows where its trucks are. Its Recipients keep calling to ask. And the system that knows isn’t connected to the one answering. I don’t need to design the solution yet. The landscape is already telling the story.

Put the Zeros in the Inventory

Now count what moves. As in module 4, the zeros don’t go on the arrows; they go in the inventory behind the picture, where they’ll drive the mechanisms when we design. About a million deliveries a year, about 3,300 a day, growing 30% a year; about 1.6 line items each; about eight status updates each, so eight million status updates a year today; four to five million photos a year, currently on crews’ own phones; about 200,000 GPS readings a day; about 180,000 cases a year. An arrow labeled “delivery status” isn’t an occasional message. The boxes tell you what exists. The arrows tell you what moves. The zeros tell you whether your assumptions survive reality.

Click to enlarge

The inventory behind Steve Trucking’s landscape: volume beside the mechanism it will drive.

No target architecture yet, and I can already see where the important data lives, what kind it is, how fast it moves and how the systems exchange it.

Beyond the exam: what AI changes. Suppose Steve Trucking builds an agent to answer a Recipient’s “where’s my delivery?” Which system should it ask? Salesforce knows the appointment, FleetLink knows where the truck is, the partner’s manifest defined the delivery. The current landscape is the agent’s map, and before the agent can answer safely, the architect has to know which system is authoritative for each fact and how current it is. Point an agent at the wrong source and stale data becomes a confident answer.

Read the Pain, Don’t Fix It Yet

Stand back. Three partners, three integration styles. A legacy dispatch tool holding eight years of history, and coordinators rekeying 3,300 stops a day into Salesforce and back. A telematics platform with 200,000 readings a day, disconnected. Finance counting deliveries from a monthly spreadsheet. Analytics a week behind. Single sign-on for some users, not others. No tracking link, and 108,000 cases a year asking where a delivery is. All growing 30% a year.

That’s a lot of architecture from one picture. The temptation is to start fixing it. Don’t. Not yet. I want you comfortable leaving a current-state diagram ugly, because sometimes the current state is ugly. The point isn’t to impress anyone with clean drawing; it’s a shared understanding of reality. Redesign while you document and you lose the baseline. Later I want to say: this is what existed, this is the problem we solved, this is what we changed, and why. Chapter 6 starts making decisions about ownership and identity, and Checkpoint 1 puts Part 1 together. The Integration Architect course designs the partner flows in depth.

What an Architect Decides Here

At this stage the architect isn’t deciding the target architecture. The decision is whether the current state is understood well enough to design one:

• Which systems, user populations, data stores and external partners actually exist today.
• What data crosses each important boundary, in which direction, how often and by what mechanism.
• Where the operational, analytical, streaming, historical and unstructured data lives now.
• Which flows carry the most volume and deserve early attention.
• Which gaps, manual steps, disconnected systems, unclear authorities and inconsistent patterns become explicit design questions.

This chapter started with one idea: draw the landscape before you design the org. If I’d started with Steve Trucking’s data model, I could have spent hours on objects and relationships while FleetLink sat outside with 200,000 readings a day, RouteDesk held eight years of history, three partners spoke three languages, finance used a spreadsheet, and a hundred thousand cases a year asked where a delivery was. Those aren’t object-model questions. They’re enterprise data questions. Draw the ugly integrations, the spreadsheet, the system you’re supposedly retiring. Write down the zeros. Walk every arrow. Then you’re ready to change it.

Explore

• The Steve Trucking brief, sections 2–4, and its landscape diagram.