Steve Trucking 的全景图
另有 28 种语言版本
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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 6 个模块，共 6 个，属于 Data Architect 课程第 4 章理解企业数据。每个模块都可以单独阅读。 上一篇：org 策略是全景层面的决定 · 下一篇：下一章数据质量与治理
**本模块回答的问题：**在我们设计任何东西之前，一张真实的全景图能告诉我们什么？
这一章一直在把镜头拉远：Salesforce 只是众多系统之一，数据的类型，Salesforce 周围的系统，如何画全景图，以及 org 策略。现在我们在 Steve Trucking 上把它们串起来。但我们还不打算修复任何东西。这就是纪律：画出存在的东西，走查每一个箭头，看看全景图告诉了我们什么。
从我们知道的开始
Section titled “从我们知道的开始 ”Steve Trucking 有一个 Salesforce org，在美国。Service Cloud 处理来自收货人和零售合作伙伴的个案；Field Service 管理预约、配送小组和移动应用；Experience Cloud 给零售合作伙伴提供了一个门户，目前只用于索赔和报表；Sales Cloud 跟踪合作伙伴合同和新配送中心的投标。所以 Salesforce 放在中间。
左边是人：在零售合作伙伴的配送中心里工作的 45 名调度协调员，330 辆卡车上大约 700 名配送小组成员，60 名客户服务人员，40 名运营、财务和销售人员，以及大约 300 名零售合作伙伴用户。这已经告诉了我们一些东西：这不是一个部门级的 CRM。它是覆盖大部分业务的运营平台。但它仍然是一个方框。现在我们来看看它周围有什么。
正式实施之前的 Steve Trucking 现状。每一份装货清单都落到 RouteDesk；协调员手工把路线重新录入 Salesforce，再把完成的停靠点录回去；FleetLink 缺少它的连接。
标出哪里不对
Section titled “标出哪里不对 ”这是一个现状，在正式实施之前，我会在图上写明这一点。然后我把调色板打开。在一个已完成系统的全景图上，我不用红色；在现状图上我会用。红色标出糟糕或不当的流程，虚线标出手工完成的事情，红色点线标出缺失的连接。不画某个箭头本身也说明了一些东西。这些都不是装饰：每一条红线都是一条等着被写下来的需求。
三个合作伙伴，三种集成
Section titled “三个合作伙伴，三种集成 ”三个零售合作伙伴用三种不同的方式发送装货清单，所以要把每一个分开画。
Keystone 每天下午把一份 CSV 装货清单放到一台 SFTP 服务器上，用于两天后的配送，并希望每晚收到一份回传的状态文件。两个箭头：装货清单以文件方式进来，由 Keystone 发起；状态以文件方式出去，由 RouteDesk 发起。异步，时间窗口很宽。
Redrock 通过一个 REST API 发送装货清单，并期望状态一发生变化就通过 webhook 收到更新。两个箭头，两种机制：Redrock 通过 API 调用进来送装货清单，RouteDesk 通过 webhook 向外调用送状态。近实时。
Brightwave 通过一个第三方网络发送 EDI 文件，并期望收到回传的 EDI 状态报文。又一种格式，又一种机制。
同样的业务概念（装货清单、配送、状态），三种完全不同的集成。不要因为你希望它们一致就把图简化。它们不一致。这就是现状。
然后走查它们。Keystone：SFTP 连接如何认证，文件落在哪里，什么去拾取它，我们怎么知道整个文件都被处理了，坏的一行会怎样，Keystone 如何在今晚的文件之前得知一个变更？Redrock：API 如何认证，任何一方宕机时会怎样，什么算一次成功的 webhook，同一个状态到达两次会怎样？Brightwave：谁运营 EDI 网络，转换在哪里做，会回传什么确认？我们没有重新设计任何东西。我们在发现问题。这正是全景图的工作。
RouteDesk 仍然在那里
Section titled “RouteDesk 仍然在那里 ”RouteDesk 是遗留的桌面调度和路线规划工具，各个配送中心的协调员用它把装货清单变成路线。它存着八年的配送历史，而且已经计划退役。照样把它画出来。一个常见的错误是漏掉那个“我们正在淘汰的”系统。什么时候淘汰？假设答案是十八个月。那么它至少在十八个月里都是架构的一部分，而它八年的历史，大约五百万次配送，不会随着应用消失而消失。再看看全景图暴露了什么：RouteDesk 和 Salesforce 并没有连起来。配送小组在 Salesforce 的 Field Service 应用里处理他们的停靠点，但路线是在 RouteDesk 里建的，所以协调员每天晚上把路线重新录入 Salesforce，然后再把完成的停靠点录回 RouteDesk，好让它向合作伙伴发送状态。每天大约 3,300 个停靠点，录两遍，全靠手工。这在图上是红色虚线。它还告诉你，Redrock 那个“一发生变化就发送”的 webhook 其实并不是一发生变化就发送。RouteDesk 今天拥有什么？什么依赖它？哪些历史必须在它之后存续下来，存到哪里：Salesforce、数据仓库、某个档案库？我们还不回答。全景图只是把问题暴露了出来。
FleetLink 是一座孤岛
Section titled “FleetLink 是一座孤岛 ”车载远程信息平台 FleetLink 接收每辆卡车的 GPS：每天大约 20 万条读数，每辆卡车，行驶中的每一分钟。而它没有和任何东西相连。协调员在一块单独的屏幕上看它。所以把 FleetLink 画出来，不带任何箭头。不要因为我们觉得应该有一条集成线，就凭空画一条。
然后数一数零：每天 20 万条，一年就超过 7,000 万条。这不是“我们有 GPS 数据”。这是一个有很多零的流式数据来源，位于 Salesforce 体验之外。Salesforce 需要每年 7,000 万条读数吗？多半不需要全部。这是一个留给以后的设计问题。
财务有它自己的真相
Section titled “财务有它自己的真相 ”财务 ERP 按每次配送、安装和拉走旧货向每个零售合作伙伴开票，并支付配送小组的激励。而配送数量是通过一份月度电子表格到达它那里的。把这份电子表格画出来。不要因为我们是架构师、懂得更多，就把它换成一个整洁的 API 箭头；它是当前架构的一部分。一旦画出来，问题就来了：谁制作它，从哪个系统来，谁核对它，如果一次配送在表格发出后发生了变化会怎样，以谁的数字为准？答案关系到钱。
Snowflake 每周收到一次导出
Section titled “Snowflake 每周收到一次导出 ”Snowflake 存放运营和财务分析数据，由每周一次的导出供数。Snowflake 自己做不到这一点；是中间的某样东西在做：一个运行在 Salesforce 之外的计划导出作业，通过 Bulk API 拉取数据并加载到 Snowflake。分析放在哪里，取决于数据放在哪里，而 Snowflake 已经是分析的归宿了。但时序也告诉了我们一些东西。“上个月发生了什么？”每周一次的数据完全够用。“这次配送现在在哪里？”Snowflake 就不是我会开始找的地方。同一个企业，不同的工作负载，不同的新鲜度，不同的答案。
身份并非以同样的方式覆盖每个人
Section titled “身份并非以同样的方式覆盖每个人 ”企业身份提供商放在 Salesforce 上方。办公室员工用单点登录。但协调员和配送小组用 Salesforce 凭据登录。所以从 IdP 到 Salesforce 只画一条信任线，会把一半的故事藏起来。真正的问题是哪些用户通过哪条路径登录，而这属于全景图。
收货人体验有一个缺口
Section titled “收货人体验有一个缺口 ”短信和电子邮件服务商从 RouteDesk 给收货人发送一条通用的“您的货明天送到”消息。没有跟踪链接。与此同时，每年大约有 18 万个个案，其中大约 60% 是“我的货到哪儿了？”：**每年大约 108,000 个个案在问同一个问题。**现在把它和 FleetLink 放在一起。公司知道它的卡车在哪里。它的收货人却不停地打电话来问。而知道答案的系统，和回答问题的系统，并没有连起来。我还不需要设计解决方案。全景图已经在讲这个故事了。
把零的个数写进清单
Section titled “把零的个数写进清单 ”现在数一数移动的是什么。和模块 4 一样，零的个数不放在箭头上；它们放进图背后的清单里，等我们做设计时，它们会决定机制。每年大约一百万次配送，每天大约 3,300 次，每年增长 30%；每次配送大约 1.6 个行项目；每次大约八次状态更新，所以今天是每年八百万次状态更新；每年四五百万张照片，目前存在配送小组成员自己的手机上；每天大约 20 万条 GPS 读数；每年大约 18 万个个案。一个标注“配送状态”的箭头不是偶尔才有的一条消息。方框告诉你存在什么。箭头告诉你什么在移动。零的个数告诉你，你的假设能否经得起现实的考验。
Steve Trucking 全景图背后的清单：数据量就写在它将决定的机制旁边。
还没有目标架构，而我已经能看到重要的数据在哪里，它是哪类数据，它流动得多快，以及各个系统如何交换它。
**考试之外：AI 改变了什么。**假设 Steve Trucking 构建了一个智能体，来回答收货人的“我的货到哪儿了？”。它应该问哪个系统？Salesforce 知道预约，FleetLink 知道卡车在哪里，合作伙伴的装货清单定义了这次配送。当前的全景图就是智能体的地图，而在智能体能安全地回答之前，架构师必须知道每个事实由哪个系统权威提供，以及它有多新。把智能体指向错误的来源，过时的数据就会变成一个自信的答案。
读懂痛点，先别急着修
Section titled “读懂痛点，先别急着修 ”退后一步看。三个合作伙伴，三种集成风格。一个存着八年历史的遗留调度工具，协调员每天把 3,300 个停靠点重新录入 Salesforce，再录回去。一个每天 20 万条读数、却没连起来的车载远程信息平台。财务根据一份月度电子表格来统计配送。分析数据落后一周。有些用户用单点登录，有些不用。没有跟踪链接，每年 108,000 个个案在问货到哪儿了。而这一切每年都在增长 30%。
一张图里有这么多架构信息。诱惑是开始修复它。不要。还不要。我希望你能坦然地让一张现状图保持难看，因为有时现状就是难看的。重点不是用干净的图让谁刮目相看，而是对现实形成共同的理解。边记录边重新设计，你就会失去基线。之后我希望能说：这是当时存在的，这是我们解决的问题，这是我们改变的东西，以及为什么。第 6 章开始就所有权和身份做出决定，检查点 1 则把第 1 部分串起来。Integration Architect 课程会深入设计合作伙伴的数据流。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”在这个阶段，架构师并不是在决定目标架构。要决定的是对现状的理解是否足以设计一个目标架构：
- 今天实际存在哪些系统、用户群体、数据存储和外部合作伙伴。
- 什么数据跨越每一条重要的边界，朝哪个方向，多频繁，通过什么机制。
- 运营、分析、流式、历史和非结构化数据现在放在哪里。
- 哪些数据流承载的数据量最大，值得尽早关注。
- 哪些缺口、手工步骤、孤立的系统、不清晰的权威和不一致的模式，要变成明确的设计问题。
这一章从一个想法开始：**在设计 org 之前先画全景图。**如果我从 Steve Trucking 的数据模型开始，我可能会在对象和关系上花好几个小时，而与此同时，FleetLink 带着每天 20 万条读数待在外面，RouteDesk 存着八年的历史，三个合作伙伴说着三种语言，财务在用一份电子表格，每年十万个个案在问货到哪儿了。这些不是对象模型的问题，而是企业数据的问题。把难看的集成、那份电子表格、那个据说正在退役的系统都画出来。写下零的个数。走查每一个箭头。然后你才准备好去改变它。
- Steve Trucking 的简介，第 2–4 节，以及它的全景图。