Salesforce 只是众多系统之一
另有 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)
第 1 个模块，共 6 个，属于 Data Architect 课程第 4 章理解企业数据。每个模块都可以单独阅读。 下一篇：企业数据的类型
**本模块回答的问题：**为什么数据架构师要在设计 org 之前，先画出围绕 org 的东西？
我教 CTA 考生时，第一天之后的作业总是一样的。读情景。从一张空白画布开始画系统全景图。然后才尝试画数据模型。不是对象，也不是详细的集成：是全景图。在我们决定什么属于 Salesforce 内部之前，我想先看到围绕着 Salesforce 的是什么。
对很多 Salesforce 从业者来说，这是一次视角的转变。如果你的职业生涯一直是管理员或开发人员，Salesforce 自然就是你世界的中心。你打开设置，创建对象，构建 Flow，写 Apex，把其他系统集成进 Salesforce。一切似乎都从 org 开始。架构师必须把镜头拉远，因为在企业中，**Salesforce 只是众多系统之一，**而且很多时候，它并不是拥有数据的那一个。
先画全景图
Section titled “先画全景图 ”第 2 章构建了逻辑模型，第 3 章问了它如何在 Salesforce 上存在。现在我要把问题放大。在决定 Salesforce 应该拥有什么之前，我想先理解它周围的企业。已经有哪些系统？客户在哪里创建，产品在哪里定义，订单从哪里开始，发票在哪里生成？身份在哪里？分析在哪里进行，文档存放在哪里，历史放在哪里？哪些系统需要 Salesforce 的数据，Salesforce 又依赖哪些系统？
这些问题会改变架构。所以我从一张空白画布开始，把 Salesforce 放在中间，再画出它周围的一切。模块 4 会准确展示我是如何布局的。现在，教训很简单：在理解 org 必须生存其中的世界之前，不要设计 org。
Salesforce 常常不是记录系统
Section titled “Salesforce 常常不是记录系统 ”拿一个非常常见的企业来说：Salesforce 加上一个 ERP，也就是 SAP 或 Oracle 这样的企业资源计划系统，负责财务、产品、库存、采购和履约。现在问一个简单的问题：客户在哪里？
可能在 Salesforce，可能在 ERP，也可能两边都有，而事情正是从这里开始变得有趣。销售人员可能在 Salesforce 中把潜在客户作为客户来跟进，而一旦他们成为付费客户，ERP 才签发正式的客户编号。产品和价格？多半在 ERP。库存？几乎从不在 Salesforce。订单可能在 Salesforce 中录入、在 ERP 中履约；发票来自 ERP；服务在 Salesforce；分析则分散在 Salesforce 报表和数据仓库之间。突然之间，我们漂亮的 Salesforce 数据模型就不是企业数据模型了。它只是其中的一部分。
我一再看到的那种集成
Section titled “我一再看到的那种集成 ”我看到最多的集成是这样的：**客户、产品和价格从 ERP 流入 Salesforce，订单流出。**换成 SAP、Oracle 或任何其他 ERP，形状都一样。ERP 拥有客户和产品的黄金记录，所以这些数据流从右边来，流入 Salesforce。销售在 Salesforce 中成交，所以订单从那里开始，再回到 ERP 去履约、开票和记账。
这些数据流不只是集成。它们告诉我，企业认为真相在哪里。
单向箭头让我不安
Section titled “单向箭头让我不安 ”每当我看到一个只有一条数据流的集成，我就开始担心了。在高层视图上，有人画了一个箭头：订单从 Salesforce 到 ERP。好的。现在往深里看。如果我不知道 ERP 的客户、产品或价格，我怎么把订单发给它？订单必须关联到 ERP 已有的客户，每一行都必须是 ERP 已经在卖的 SKU。我不能为对面不存在的产品发送一个行项目。所以在这个订单箭头能工作之前，必须先有反方向的回流数据。
这就是我对每个箭头都会问的问题：**这条数据流依赖什么？**你能看到的高层箭头，通常需要你还没画出来的回流数据。
再往深里看，你会发现回程。Salesforce 发出一个订单。然后呢？它被接受了还是被拒绝了？发货了吗，部分发货了吗，被取消了吗？开票了吗？Salesforce 里有人需要知道吗？也许不需要。但总该有人问过。如果什么都不回传，好的。告诉我为什么。
企业不是一下子建成的
Section titled “企业不是一下子建成的 ”全景图之所以复杂，部分原因是没有人一次性把它们全建好。数据是一波一波到来的。先是文件：固定格式的记录，然后是 CSV 这样的分隔文件。然后是用于运营数据的关系数据库。然后是把数据汇集起来做分析的数据仓库。然后是 NoSQL 数据库，用于不适合整齐放进表里的文档、键值对和图。然后是用于海量原始和半结构化数据的数据湖，以及把两者结合起来的湖仓。事件流，比如 Kafka 或 Salesforce 事件总线，在数据发生时就移动它，而不是在夜间批处理中。而现在是联邦访问，数据不必先复制到一个地方，另一个平台就能使用它。
现在重点还不在技术，而在这一点：**新的一波很少会让旧的一波消失。**走进一家大企业，你会同时发现所有这些：关系数据库、ERP、Salesforce、数据仓库、数据湖、SFTP 投递、API、事件流、某人每周五仍在用邮件发送的电子表格，还有那个人人都不敢碰的系统，因为构建它的人六年前就退休了。这才是你要做架构的企业，而不是产品手册里的那一个。
不同的系统因不同的原因而存在
Section titled “不同的系统因不同的原因而存在 ”这也是为什么我从不从“我们怎么把所有数据都弄进 Salesforce？”开始。我为什么要让所有数据都在那里？Salesforce 也许是销售和服务人员与客户打交道的最佳场所。但这并不让它成为财务系统、企业数据仓库、遥测数据存储、文档档案库，或者公司产生过的每一次点击、每一个 GPS 读数和每一笔历史交易的归宿。
第 3 章针对一个 org 问的是**这些数据应该放在哪里？**在企业层面，同样的问题变得更大：有时 Salesforce 拥有数据，有时它保留一份副本，有时只是一个引用，有时它根本就不该有这些数据。
核心、核心之外与 Hyperforce
Section titled “核心、核心之外与 Hyperforce ”还有另一条边界需要理解：即使是“Salesforce”，也不是一个运行时加一个数据库。在第 3 章，核心之上指的是数据放在哪里：在你的桌上，在 org 自己的对象里。这里同样的词描述的是一个产品运行在哪里。你会听到架构师两种用法都用。
历史上，Core 运行时承载了平台的大部分。今天，Salesforce 把平台描述为由数百个独立的、元数据驱动的服务组成，而 Core 仍然是应用元数据唯一的记录系统（The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)，英文）。这就是为什么你会听到架构师说某项能力运行在核心之上或核心之外。
早在平台拆分成服务之前，这一点就很重要。我在课上问大家，为什么 Salesforce 收购 SteelBrick 来做报价，而不是 Apttus，我想要的答案很简单：SteelBrick 是 100% 构建在核心之上的。Flow 和触发器都在核心里，所以构建在那里的产品会随之获得平台的元数据、定制和自动化。那个报价产品后来让位给了 Revenue Cloud，但这个教训没有过时。然后是近核心（near-core），我用的例子是 Data 360。Data 360 不是核心。它的租户在核心之外：数据和处理数据的机制运行在它自己的湖仓里，在 org 的关系数据库旁边，而不是在里面（The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)，英文）。但你用来设置和控制它的界面显示在核心之上，在 org 里。所以我能给出的最精确的说法是：**在核心之上管理，在核心之外托管。**数据和处理都不在 Core 里运行；Core 上的界面控制着核心之外的租户。当然，还有那些因为根本不是 Salesforce 而在核心之外的一切。
我不太在意记住今年哪个产品运行在哪里，因为这会变；我在意的是这个习惯：一条边界可能影响数据流动、延迟、身份、集成和数据驻留。所以不要因为一个产品叫 Salesforce，就认为它的数据就挨着你的客户记录。去看实际的架构。
然后是 Hyperforce：Salesforce 为公有云构建、以代码定义的基础设施，而不是它传统的自建数据中心，让客户对数据驻留在哪里有更多选择（Salesforce Hyperforce: General Information and FAQ (opens in a new tab)，英文）。这很重要，模块 5 会再回到它。但基础设施架构不是企业数据架构。把一个 org 迁到公有云，并不能告诉你谁拥有客户、库存在哪里、分析在哪里运行，或者哪些数据可以跨境。Hyperforce 可以影响其中一些决定，尤其是数据驻留。它不能代替对全景的了解。
全景图要在那个方框之前
Section titled “全景图要在那个方框之前 ”所以这是一个习惯。有人交给你一个情景。不要开始构建 Salesforce 解决方案。先找出系统：ERP、身份提供商、数据仓库、集成平台、合作伙伴系统、客户渠道、文档存储。然后找出它们之间流动的数据：客户、产品、订单、发票、文档、事件、身份。然后问每一样归谁所有。只有在那之后，才决定什么属于 Salesforce。否则你就是在不知道一个方框连接着什么的情况下设计它。
第 1 步（共 3 步）：我们设计的 org，单独来看。从这里看，它就像整个世界。
第 2 步（共 3 步）：拉远镜头。Salesforce 是众多系统中的一个（第 4 模块会讲这种布局）。
第 3 步（共 3 步）：第一批箭头。客户、产品和价格从 ERP 进来，订单发出去：它们说明了企业认为真相存放在哪里。
全景图会改变数据模型
Section titled “全景图会改变数据模型 ”这就是它对数据架构师之所以重要的原因。第 2 章说客户是一个重要的实体。好的。然后全景图说 ERP 对客户是权威的。这就改变了物理模型。Salesforce 也许仍然会保留一个本地的客户记录，因为人们每天都在用它，但现在我们需要把 ERP 的标识符作为外部 ID；我们需要知道 Salesforce 可以修改哪些字段（我会用 erp_ 前缀标记 ERP 的字段，模块 3 会讲到）；ERP 的变更多快到达；Salesforce 能否在 ERP 知道之前就创建一个客户；以及两者不一致时会怎样。这些不是留给以后的集成问题，而是数据架构问题，是全景图把它们暴露了出来。
其中一个是这样咬人的。销售人员为一家大型饮料公司转换了潜在客户，创建了客户，赢下了这笔交易，然后这个客户被送到了 ERP。但公司和这家饮料公司已经做了多年生意，ERP 里早就有它了。现在有两个了。销售人员当初真的应该能创建这个客户吗？第 5 章和第 6 章会回到这个问题；全景图是你提前看到它到来的地方。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 哪些系统围绕着 Salesforce，以及每个系统扮演什么角色。
- 哪个系统拥有每一类重要的数据，在决定 Salesforce 保留多少之前。
- 什么流入 Salesforce，什么流出，以及什么会回传。
- Salesforce 应该拥有、复制、引用、联邦访问、归档还是不碰哪些数据。
- 哪些平台和基础设施的边界是重要的，而不是假设所有带 Salesforce 品牌的东西都在同一个地方。
从开发人员到架构师的转变，往往不是再学一项功能，而是学会什么时候不再盯着 Salesforce：把镜头拉远，跟着数据走，找到谁拥有真相，然后回来决定 Salesforce 的职责应该是什么。
- Salesforce Architects，The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)（英文），查阅日期 2026-10-14。