先画全景图，再建 org
另有 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)
Data Architect 第 4 章，第 1 部分：成为数据架构师。上一章：Salesforce 数据架构。
我教 CTA 考生时，第一天之后的作业总是一样的。读情景。从一张空白画布开始画系统全景图。然后，只有在那之后，才尝试画数据模型。
大家对这个顺序感到意外。我们是数据架构师，难道不该从数据模型开始吗？我不这样做的原因是：如果我先画数据模型，我就已经决定了什么属于 Salesforce。如果我先画全景图，我就能看到所有应该影响这个决定的东西：拥有客户和产品的 ERP，回答五年期问题的数据仓库，决定谁能进来的身份提供商，每天下午发来一个文件的合作伙伴，还有那个大家都说正在退役的遗留系统。
第 2 章和第 3 章设计了 org：模型应该是什么样，以及它如何在 Salesforce 上存在。本章把镜头拉远，画出**在设计 org 之前，围绕在 org 周围的东西。**Salesforce 只是众多系统之一，而且很多时候，它并不是拥有数据的那一个。
图片由 AI 生成。
本章的思想
Section titled “本章的思想 ”- **全景图先行。**先找出系统，再找出它们之间流动的数据，然后是每一部分归谁所有。只有在那之后，才决定 Salesforce 的职责是什么。
- **一个箭头依赖其他箭头。**发往 ERP 的订单，需要客户、产品和价格先进来。每当我看到一个只有一条数据流的集成，我就开始担心了。
- **数据分为不同的类型，也分为不同的工作负载。**主数据、参考数据、交易数据、元数据、分析数据和非结构化数据，它们的变化、增长和使用方式各不相同；运营（OLTP）、分析（OLAP）和流式工作负载需要不同的归宿。org 经营业务；数据仓库和数据湖分析业务。
- **系统有角色，而不只是标志。**记录、互动、参考、洞察。“Salesforce 是我们的记录系统”：记录什么？
- **分析放在哪里，取决于数据放在哪里。**全都在核心之上：用标准报表。数据在其他存储里：用分析平台，当 Salesforce 数据要与数据仓库合并时，还要用数据仓库。
- **Data 360 是近核心（near-core）：**在核心之上管理，在核心之外托管。用户从不连接它，所以它和数据管道放在一起。
- **ERP 拥有的数据在本地读取，在受控的方式下写入，**并使用
erp_前缀，让结构显示出每个字段归谁所有。 - **在全景图上，箭头从打开连接的那个系统开始，**它的标签说明移动的是什么，以及朝哪个方向。两条数据流就是两个箭头；双向箭头只用于连接器。
- **每个箭头都有一个客户端和一个服务器，**各自负责自己的一半。这些都不放在全景图上，但每个箭头都有。
- **画箭头之前先数一数。**零的个数写进清单，由它们来选择机制：批处理、同步还是事件。
- **org 策略是全景层面的决定，**在最初的几分钟里就要做出：一个 org 还是多个，以及在哪里运行。
- **现状图要显示哪里不对。**红色表示糟糕的流程，虚线表示手工完成，红色点线表示缺失的东西。
Steve 的全景图布局
Section titled “Steve 的全景图布局 ”画系统全景图的方式有很多。这是我的方式，是我多年来不断打磨的，它读起来像一句话：左边的人进入中间的 Salesforce，通过上方的系统获得信任，通过下方的渠道获得服务，并与右边的后台系统相连。
| 位置 | 放什么 |
|---|---|
| 左边 | 人，从上到下：内部用户、合作伙伴、客户 |
| 中间 | Salesforce，一个朴素的方框，它的社区在下方紧贴着它 |
| 上方 | 身份提供商在 Salesforce 上方；AppExchange 往右挪；公共网站在左上角 |
| 右边 | 集成层，然后是内部系统：ERP、财务、数据仓库 |
| 集成层下方 | Data 360，近核心，和数据管道放在一起 |
| 下方 | 客户渠道：电子邮件、网页表单、电话、消息 |
| 右下角 | 数据进出：归档、数据加载、外部来源、合作伙伴 |
系统是放在浅色带标签区域里的卡片，每张卡片有一个图标，并有一个图例说明一切的含义。图背后有一份清单：对每个数据集或数据流，记录它的所有者、数据量、机制和时序、认证，以及是复制、引用还是联邦访问它。
模块 4 的全景图，加上了箭头。
本章的路线
Section titled “本章的路线 ”六个模块，每个都可以单独阅读。
- **Salesforce 只是众多系统之一。**为什么全景图要在那个方框之前，我一再看到的那种集成以及它所依赖的回流数据，一波一波到来的数据，以及核心、近核心和 Hyperforce。
- **企业数据的类型。**六种类型；创建、编辑、引用；OLTP 和 OLAP；实时、近实时和批处理；类别背后的四个问题。
- **Salesforce 周围的系统。**系统角色；ERP、数据仓库和湖仓；分析跟着数据走；MDM；集成和事件；开发人员会忘记的身份提供商；Data 360 位于何处。
- **画出系统全景图。**我的布局，从一张空白画布搭建起来；先数零的个数，再画箭头；从发起方开始的箭头；每个箭头背后的客户端和服务器，两个方向都有；为对话画泳道；图背后的清单。
- **org 策略是全景层面的决定。**从一个 org 开始；什么情况下有理由再建一个；选择的是区域，而不是提供商；由 GDPR 驱动拆分为 AMER 和 EMEA；第二个 org 增加了什么。
- **Steve Trucking 的全景图。**正式实施之前的今天，标出问题：装货清单落到 RouteDesk，路线被手工重新录入 Salesforce 再录回去，一座 GPS 数据孤岛，一份喂给财务的电子表格，以及每年 108,000 个“我的货到哪儿了？”的电话。
读完之后，用本章学习指南检查一下自己：一份备考清单、考试之外的习惯、必知术语，还有几道题。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- **哪些系统围绕着 Salesforce，**以及每个系统扮演什么角色。
- **哪个系统拥有每一类重要的数据，**在决定 Salesforce 保留多少之前。
- **每一个连接如何运作：**搬运什么，朝哪个方向，如何认证，多快，以及什么会回传。
- **有多少个 org，在哪里运行，**要最先决定，因为全景图上的其他一切都依赖于它。
- 对现状的理解是否足以设计一个目标状态。
**考试之外：**全景图正在变成一张智能体地图。在一个智能体能回答“我的货到哪儿了？”之前，得有人知道每个事实由哪个系统权威提供，它有多新，以及智能体可以如何访问它。每个模块的结尾都会讲 AI 为图中的那一部分带来了什么改变。
- Salesforce Architects，The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)（英文），查阅日期 2026-10-14。
- 给 CTA 考生的延伸阅读：Salesforce Architects 发布了它自己的图示指南，How to Build Salesforce Diagrams (opens in a new tab)（英文）。
下一章：数据质量与治理