画出系统全景图
另有 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)
第 4 个模块，共 6 个，属于 Data Architect 课程第 4 章理解企业数据。每个模块都可以单独阅读。 上一篇：Salesforce 周围的系统 · 下一篇：org 策略是全景层面的决定
**本模块回答的问题：**我如何画一张能显示数据去向的全景图？
给我一个新情景和一块空白的白板，我最先画的东西之一就是系统全景图。不求漂亮，不画每一个 API，也还不画数据模型。我想看到整个企业：用户是谁，涉及哪些系统，Salesforce 位于何处，它周围有什么，数据从哪里来、到哪里去。然后我要逐一走查那些箭头。一张好的全景图不是一幅方框的图画。它是一种暴露架构决定的方式。
从一张空白画布开始
Section titled “从一张空白画布开始 ”我会让 CTA 考生练习这个。读情景，然后开始画。不要等到在脑子里全部解决了再画；画图本身会帮你解决问题。这就是为什么第一天之后的作业是先开始画全景图，再尝试画数据模型。先画数据模型，你就已经假设了什么属于 Salesforce。先画全景图，你就能看到应该影响这个决定的那些系统。
从高处开始，然后逐层深入：先是整个企业，再在重要的地方看细节。
第 1 步，共 6 步：一张空白画布。只有区域。
Steve 的全景图布局
Section titled “Steve 的全景图布局 ”画系统全景图的方式有很多。这只是我的方式，是我多年来不断打磨的，我分享它，是为了让你看到如何快速搭起一张全景图。我在每一张 Salesforce 全景图上都用它，它读起来像一句话：左边的人进入中间的 Salesforce，通过上方的系统获得信任，通过下方的渠道获得服务，并与右边的后台系统相连。
**人在左边，从上到下：内部用户、合作伙伴、客户。还不需要每一个用户画像；足够回答谁在试图接触这个架构？**就行。每个群体都指向自己的入口：内部用户指向 Salesforce，合作伙伴指向合作伙伴社区，客户指向客户社区。系统不会独自存在。总有某个人或某样东西在试图使用它们。
第 2 步，共 6 步：谁在试图接触这个架构？
**Salesforce 在中间。**一个朴素的方框。不是因为 Salesforce 是企业的中心（我们刚花了三个模块说它不是），而是因为它是我围绕着做设计的那个系统。它是锚点。
**社区紧贴在它正下方。**合作伙伴社区和客户社区是独立的端点，所以它们有自己的方框。但它们紧贴着 Salesforce，因为要接触它们不需要任何集成：它们运行在同一个 org 里。
第 3 步，共 6 步：Salesforce 在中间，社区紧贴在它正下方。
**身份在上方。**身份提供商放在顶部，也就是开发人员会忘记的那些：一个给内部用户，也许另一个给合作伙伴。AppExchange 软件包也放在上面，往右挪一点，因为它们是被引入 org 的能力，而不是与它交换数据的后台系统。公共网站放在左上角。
第 4 步，共 6 步：身份在上方，这是开发人员会忘记的方框。
**集成在右边，再往右是后台。**集成层，即 ESB 或 iPaaS（如果点名了，就是 MuleSoft），是紧挨在 Salesforce 右边的一根高高的竖条。内部系统在它后面：各个 ERP、财务、订单管理、遗留系统、数据仓库。现在整页从左往右读：人、Salesforce、集成、后台。
第 5 步，共 6 步：先是集成，然后是后台。
**渠道在下方。**凡是与客户有直接联系的：邮件转个案（email-to-case）、网页转潜在客户（web-to-lead）、电话、消息。
**数据进出，在右下角。**外部数据源、归档、数据加载。
**Data 360 在右边，集成层的下方。**用户从不连接它，而它的租户会连接很多后端系统，所以它和数据管道放在一起，在那里这些连线保持很短：挨着内部系统、数据仓库和右下角的数据。数据团队确实会打开它的界面，但这些界面在 org 里：Data 360 是近核心，在核心之上管理，在核心之外托管（模块 1）。一条连回 Salesforce 的线表明谁在管理它。方框放在哪里，应该讲出它做什么的故事。
这些几何布局都不是神圣不可改变的。约定的价值在于，我不用每次都重新发明一套视觉语言，而看过我一张图的人，读下一张会更快。
第 6 步，共 6 步：整个布局，还没有箭头。之后的每一张全景图都保持这些位置。
区域里的卡片
Section titled “区域里的卡片 ”让表示法保持简单。每个系统都是一张卡片：它的名称、它的角色，以及一个说明它是什么东西的小图标：ERP、数据库、身份提供商、一群人。我刚才描述的那些区域画成浅色的带标签区域，这样布局本身就是可见的。底部的图例说明每个图标和每种线的含义。
不要在一个方框里塞太多东西。只有在非常复杂的全景图上，我才会把 Salesforce 拆开成几个部分（org 里的 Sales Cloud 和 Service Cloud，它们之间有箭头）。也不要发明十五种形状，除非每一种都在告诉读者一些东西。我希望有人看全景图三十秒，就开始理解这个架构。花哨帮不上忙。清楚才行。
把零的个数写进清单
Section titled “把零的个数写进清单 ”不要等到详细设计时才考虑数据量。一个每晚搬运 500 个产品的箭头，和一个每天搬运 200,000 条 GPS 读数的箭头，在全景图上看起来可能一模一样。它们不是同一个问题。所以在画任何一个箭头之前，先数一数移动的是什么。从数量开始建立图背后的清单：每个重要的数据集一行，写上它的数据量。零的个数也许永远不会出现在箭头上，但你需要知道什么时候进入了大数字：一小时几千或几百万，几十万笔交易，甚至每秒几十到几百笔交易。
这些数字决定机制。每晚几百条记录是批处理。有人在等待的调用可以是同步的，如果数据量允许的话。每秒几十到几百条可能需要事件，比如平台事件，而不是每条记录一次调用。箭头看起来是一样的；由数据量决定用什么来承载它，所以把它记在清单里，也就是选择机制的地方。
机制甚至可以改变箭头的方向。每分钟发送几条记录，Salesforce 可以直接向外调用：箭头从 Salesforce 开始。发送多得多的记录，Salesforce 可能改为在事件总线上发布事件；外部系统订阅，并调用进来取走它们，于是现在箭头从另一端开始。再大一些，比如每晚同步几百万条记录，那就是批处理过程。所以在开始设计机制时就要尽早知道你的数量，因为数量可能会重画箭头。
数据量在两个地方重要，原因各不相同。在数据模型上，我需要它来留意大数据量并规划归档；第 2 部分会深入讨论这一点。在系统全景图上，清单里的大数字决定集成模式和机制的选择。模块 6 会把真实的零的个数放到 Steve Trucking 的全景图和清单上。有了这些数量，再画箭头。
现在画出箭头
Section titled “现在画出箭头 ”系统就位后，把它们连起来，全景图就变成了架构。**方框是一个系统；箭头表示谁发起连接。**它从打开连接的那个系统开始，指向被它调用的那个系统：从客户端到服务器。标签说明移动的是什么，以及朝哪个方向。
这条规则是给系统全景图用的，在那里是系统在和系统对话。在数据流图上，箭头跟着数据走，正如你所预期的。不要把全景图的规则带到其他图里；那只会增加混乱。
箭头放进来了。每个方框都在原来的位置；每个箭头都从打开连接的系统开始，它的标签说明移动的是什么以及朝哪个方向。
所以，如果集成层把产品推送进 Salesforce，箭头就从集成层指向 Salesforce，标注产品进入。如果是 Salesforce 向外调用去取产品，箭头就从 Salesforce 开始，标签仍然是产品进入。同样的数据，不同的对话，而这个区别告诉我谁需要凭据，谁必须处理失败。Salesforce 通过集成层发送订单：订单发出。ERP 的履约信息回传：订单状态进入。现在我能看到每段对话由谁发起，数据从哪里进入 Salesforce、从哪里离开，哪些数据流跨越了边界，所有权大概在哪里，以及我需要在哪里多问一些。
还要记住模块 1：每当我只看到一条数据流，我就会担心。在高层视图上，一个订单发出箭头依赖回流数据：客户进入、产品进入、价格。再往深里看，还有回程：接受、拒绝、状态、发票号、取消。箭头给了我可以质疑的具体东西。
每一个箭头都需要一个机制
Section titled “每一个箭头都需要一个机制 ”在这里，全景图不再是 PowerPoint 里的装饰画。在评审会上，任何一个箭头都可能引来三个问题，我希望你都有答案：
- **它如何认证？**OAuth、证书、命名凭据，还是别的什么？
- **它是同步还是异步？**Salesforce 是等待 ERP，还是发布后继续做别的？业务需要多快拿到结果？
- **机制是什么？**REST 调用、事件、文件、消息队列，经过 MuleSoft 还是直连？
然后：另一端宕机时会怎样？**每一个箭头都需要一个机制。**如果你解释不了它，这条线就是装饰。
而“fire and forget”（发出即不管）不是答案。它通常意味着“我还没设计发出之后会发生什么”。它到达了吗？被接受了吗？失败了吗？会重试吗？谁知道它卡住了？同一条消息到达两次会怎样？这些都不放在全景图上，否则全景图就没法读了。但箭头应该让你知道这些问题是存在的。
把任何一个箭头放大，都有一个客户端和一个服务器，各自负责自己的一半。客户端打开连接：它需要端点和端口，先从认证服务器获取令牌，调用服务器定义的协议和契约，并选择是否等待。只有客户端能看到整个往返过程，所以只有客户端能重试。服务器负责监听，定义协议、契约和数据载荷，验证进来的东西，并且只看到它自己那一部分。当我画一个箭头时，我已经知道哪端是哪端，这就告诉了我每个问题归谁负责。
放大的一个箭头：客户端负责处理，服务器负责定义。这些都不放在全景图上，但每个箭头都有。
现在把箭头反过来。当 ERP 调用 Salesforce 时，Salesforce 就是服务器：它定义 API，运行自己的授权服务器，并通过一个 External Client App（外部客户端应用）和一个集成用户来决定调用方可以做什么。同样的问题，另一边。
Salesforce 作为服务器：同样的问题，由 Salesforce 回答服务器那一半。
箭头画在全景图上，对话画在泳道里
Section titled “箭头画在全景图上，对话画在泳道里 ”架构师毁掉一张好图的方式是：让一个产出物回答所有问题。全景图上加了 API 名称、数据载荷、重试、错误队列、转换、每一个回调，很快就没人看得懂了。不要这样。全景图是大图景：系统以及它们之间重要的数据流。
当我需要解释一次交互时，我会画第二张图，但不是为每个集成都画。如果系统 A 给 B 发了点东西，甚至问了一个问题并得到了答案，带标签的箭头就够了。当流程变成一场对话时，我才需要泳道：A 调用 B，B 向 C 核实，C 回答，B 创建了某样东西并回调 A，一个人审批，另一个系统接着处理。我的经验法则是：**超过一两次往返交互，这个顺序就要有自己的泳道。**箭头画在全景图上；对话画在泳道里。
还要注意，箭头在那里的含义不同。在全景图上，箭头是一个连接：谁打开它，移动的是什么。在泳道里，每个箭头是一段对话中的一条消息，按顺序读：一个请求往一个方向去，一个回复从另一个方向回来，然后是下一步。
全景图上三个箭头；泳道里六个步骤。在全景图上，箭头是一个连接；在泳道里，每个箭头是一条消息，按顺序排列。
逐一走查每个箭头
Section titled “逐一走查每个箭头 ”当全景图看起来基本完成时，逐个箭头地走查一遍。ERP 到 Salesforce：搬运的是什么，谁拥有它，如何认证，机制是什么，同步还是异步，必须多新？然后是下一个箭头，再下一个。缺口就是在这里出现的。“哦，我们从来没弄清楚那个合作伙伴到底是怎么发送的。”“我们把订单发给了 ERP，但还没设计被拒绝的订单怎么回来。”很好。你是在白板上发现了它，而不是在生产环境里。
在图的背后放一份清单
Section titled “在图的背后放一份清单 ”图必须保持可读，所以细节放进它背后的清单里。你已经用数量开了个头；现在把它补完，每个重要的数据集或数据流一行：
| 列 | 我想知道什么 |
|---|---|
| 数据集 | 客户、产品、订单、配送、发票 |
| 类型 | 主数据、参考数据、交易数据、分析数据、非结构化数据 |
| 所有者 | 谁拥有它的含义和生命周期？ |
| 记录系统 | 权威版本在哪里？ |
| 工作负载 | 运营、分析、流式 |
| 数据量 | 零的个数 |
| org | 如果有多个，是哪个 Salesforce org？ |
| 认证 | 连接如何建立信任？ |
| 机制和时序 | API、事件、文件、联邦访问；同步、异步、批处理 |
| 方式 | 复制它、引用它，还是联邦访问它？ |
现在有了两个产出物：全景图让我看到架构，清单让我追问架构。
ED-D42 背后的清单。箭头在全景图上看起来都差不多；由数据量决定用什么来承载每一个箭头。
全景图能回答问题
Section titled “全景图能回答问题 ”这就是我喜欢这个产出物的原因：它帮助我思考。“我们如何跨 Salesforce 和 ERP 做报表？”这是模块 3 里的问题：**我的哪张图能漂亮地解决这个问题？**全景图。如果一切都在核心之上，就用标准报表。如果数据在 ERP 和数据仓库里，你立刻就能看出来。“这个客户属性应该在哪里主控？”看看哪些系统用它，哪个系统已经拥有客户。“Salesforce 需要每一条 GPS 读数吗？”谁产生它，谁消费它，工作负载是什么？也许 Salesforce 需要的是当前位置，而由另一个平台保留历史。全景图不会直接交给你答案。它给你的是看待问题的正确视角。
在修复之前先画出现状
Section titled “在修复之前先画出现状 ”还有一条纪律。在一个已有的企业里，画出存在的东西，而不是你希望存在的东西。每周五用邮件发送的那份电子表格：画出来。合作伙伴放在 SFTP 服务器上的 CSV：画出来。因为历史原因绕过 ESB 的那个集成：画出来。在两个系统之间重新录入数据的人：标出来。不要在记录现实的同时把它美化。在设计目标全景图之前，你需要当前的全景图，而这正是我们在模块 6 中为 Steve Trucking 做的事。
**考试之外：AI 改变了什么。**全景图正在变成一张智能体地图。如果一个智能体要回答“我的货到哪儿了？”，全景图就必须说明答案来自 Salesforce、某个合作伙伴系统、车载远程信息、ERP，还是它们的组合。智能体不会消除系统边界；它们让知道哪个系统是权威的、以及如何安全地访问它，变得更加重要。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 哪些系统和用户群体属于全景图，以及它们的位置如何体现其角色。
- 哪些数据流跨越系统边界，朝哪个方向，以及什么会回传。
- 每一个连接如何认证，由什么机制承载，以及它是同步、异步、批处理还是联邦访问。
- 什么时候一个带标签的箭头就够了，什么时候一次交互需要自己的泳道。
- 图背后的清单要记录什么：所有者、工作负载、数据量、org、时序、认证，以及复制、引用还是联邦访问。
全景图不是我在架构完成之后才画的东西。它是我发现架构的方式。当你觉得它完成了时，不要欣赏它，去走查它。每一个你还解释不了的箭头，都在告诉你工作在哪里。
- 延伸阅读：Salesforce Architects 发布了它自己的图示指南，How to Build Salesforce Diagrams (opens in a new tab) 和 System Landscape (opens in a new tab)（英文），如果你准备参加 CTA 评审会，值得了解。