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)
第 3 个模块，共 6 个，属于 Data Architect 课程第 4 章理解企业数据。每个模块都可以单独阅读。 上一篇：企业数据的类型 · 下一篇：画出系统全景图
**本模块回答的问题：**Salesforce 周围有什么，每个系统扮演什么角色？
上一个模块给数据分了类。现在我想把它放到某个地方，而这正是 Salesforce 架构师容易陷入麻烦的地方。我们了解 Salesforce，所以客户数据就意味着客户对象，订单数据就意味着订单，文档就意味着文件，分析就意味着报表。但企业买 Salesforce 并不是为了取代它拥有的其他一切。可能有一个负责财务和履约的 ERP，一个存着多年历史的数据仓库，一个集成平台，一个身份提供商，合作伙伴的系统，一个事件平台，一个 MDM 平台，以及连接其中几个的 Data 360。这份工作不是记住各种技术，而是理解每个系统承担什么职责。
不要从产品名称开始
Section titled “不要从产品名称开始 ”“我们有 SAP”告诉我的信息不够。Snowflake、MuleSoft、Tableau 或 Data 360 也一样。我想知道那个系统在这个架构中做什么：它拥有什么数据，读取什么，修改什么，谁在用它，什么依赖它，它宕机时会怎样。两家公司可以拥有完全相同的产品，架构却完全不同。
所以我按角色给系统贴标签。四种角色就能涵盖大部分情况：
- **记录系统：**维护某样东西权威版本的地方。
- **互动系统：**人们做事的地方。
- **参考系统：**一个系统去获取它需要但并不拥有的信息的地方。
- **洞察系统：**数据汇聚起来用于度量、分析和预测的地方。
一个平台可以扮演好几种角色，而且角色因数据而异。Salesforce 可能是个案的记录系统，是服务人员的互动系统，同时也是 ERP 所拥有的产品数据的消费者。所以当有人说“Salesforce 是我们的记录系统”时，把这句话说完：记录什么的系统？
ERP：后台有引力
Section titled “ERP：后台有引力 ”ERP 是你最常在 Salesforce 旁边看到的系统，负责财务、库存、采购、履约和计费。模块 1 的模式（客户和产品流入，订单流出）意味着 ERP 拥有产品，但销售人员仍然需要在 Salesforce 中用到它们。好的：把它们引进来。但复制数据并不会转移所有权。副本不是权威。
我的立场是：**ERP 拥有的数据在本地读取，在受控的方式下写入。**Salesforce 用户在他们工作的地方拿到数据，但 Salesforce 不能修改 ERP 拥有的东西。而且我会让这一点在结构中可见：ERP 的字段带有 erp_ 前缀，比如 erp_Product_Number__c，这样任何阅读这个对象的人都知道每个字段归谁所有、修改时要小心。前缀本身不执行任何东西；执行靠的是权限、验证和集成模式。它传达的是意图，是让权威系统图变得可见。
数据仓库、数据湖和湖仓
Section titled “数据仓库、数据湖和湖仓 ”运营系统经营业务；分析系统帮助理解业务。“给我看我未完成的业务机会”是一份 Salesforce 报表。“给我看所有渠道五年的销售、履约、退货、个案、库存和财务”则是另一个问题。
你会遇到三种分析存储。数据仓库存放为分析而准备的结构化数据。数据湖存放多得多、形式也更多样的数据，往往是原始数据。湖仓把两者结合起来：数据湖式的存储，数据仓库式的分析。要了解它们，因为它们会出现在全景图上。但我的经验是，**湖仓和数据网格在 Salesforce 项目中仍然比较小众。**典型的全景图是 CRM、ERP、一个数据仓库和一个集成层，再加上业务确实需要的其他平台。学习架构，而不是追逐术语。
分析放在数据所在的地方
Section titled “分析放在数据所在的地方 ”这是我最坚定的立场之一：**分析放在哪里，取决于数据放在哪里。**如果报表只需要客户、业务机会和销售人员，那全都在核心之上：用标准报表和仪表板。然后业务方要求加上 ERP 的发票。然后是产品成本。然后是数据仓库里五年的订单。然后是网站活动。到了某个时候，为了做报表把所有这些都拖进运营 CRM 就不再说得通了。一旦涉及其他数据存储，分析平台就变得必要：Tableau（包括构建在 Data 360 之上的 Tableau Next），或者在已经使用它的地方用 CRM Analytics。当 Salesforce 数据要与数据仓库合并时，它就必不可少。需求并不只是变复杂了；**是全景改变了这个问题应该在哪里回答。所以我从不以“用哪个分析工具？”开始。我以数据在哪里？**开始。
我也问 CTA 考生同样的问题：“我的哪张图能漂亮地解决这个问题？全景图。”如果你全都在核心之上，就用报表。如果你在其他存储库里有数据，我希望看到一个分析平台。在任何人打开报表构建器之前，全景图就回答了报表的问题。（产品名称会变；Salesforce 的分析如今处于什么位置，由 Data 360 那一章来讲。）
MDM：这个客户到底是谁？
Section titled “MDM：这个客户到底是谁？ ”现在假设客户信息分散在 Salesforce、ERP、电商、会员平台和一个合作伙伴系统里，而每一个都认为自己知道客户是谁。这就是主数据管理登场的地方：在各个系统之间建立并治理关键数据的权威身份。但 MDM 不是“一个主客户数据库”。难的问题是：哪个系统可以创建客户，每个系统拥有哪些属性，如何发现重复，哪个标识符存活下来，以及系统之间不一致时怎么办。第 6 章讲的全是这个。在这里，先认出这个角色：如果存在一个 MDM 平台，它可能是 Salesforce 与企业其余部分之间一个关键的权威。
集成层与事件
Section titled “集成层与事件 ”把每个系统都和其他每个系统直接相连，全景图很快就会变成一盘意大利面。这就是为什么企业要有一个集成层：一个 ESB（企业服务总线）或 iPaaS（集成平台即服务）。MuleSoft 是你在 Salesforce 全景图中最常遇到的。它充当中介，这样每个应用就不必去理解其他每一个应用。
但中间放一个 MuleSoft 方框，并不会让集成变好。我仍然想知道什么经过它、什么不经过，谁来转换数据，谁拥有契约，目标宕机时会怎样，它是同步还是异步，以及我们如何知道一条消息成功了。Integration Architect 课程会深入讨论；在这里，先把它认作一个独立的角色。
而且并非每个集成都是系统 A 调用系统 B。有时某件事发生了（一个订单被创建，一次配送改变了状态，一辆卡车驶入了某个区域），一个事件被发布出来，感兴趣的各方各自响应。流动中的事件也有基础设施：Salesforce 自己的事件能力、企业事件总线、其他消息机制。要画出承载数据的机制，而不只是数据库。
开发人员会忘记的系统：身份
Section titled “开发人员会忘记的系统：身份 ”有一个方框我总希望出现在全景图上，而开发人员却很少想到它：**身份提供商。**开发人员用用户名和密码直接登录他们的沙盒，所以在构建期间身份是看不见的。然后到了 UAT 或生产环境，突然就有了公司给员工用的单点登录，也许还有给合作伙伴的第二个提供商，给客户的社交登录。身份一直都是架构的一部分。只是开发人员还没看到它。
身份提供商（IdP）是认证用户并建立 Salesforce 所信任的身份的系统。它从第一天起就应该出现在全景图上，即使它要在发布流水线的后期才配置，因为谁能进来，决定了谁能接触到数据。
还有一个实际的问题：身份配置**可以部署，但不能完全部署。**SAML 单点登录配置和认证提供商都是 Metadata API 类型，所以它们可以随流水线迁移（SamlSsoConfig (opens in a new tab)，英文）。但认证提供商的使用者密钥不再在 Metadata API 的响应中返回（Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)，英文），而证书通常因环境而异。要为能迁移的部分和不能迁移的部分都做好计划。
按角色而不是标志来读全景图：每个系统拥有什么、读取什么、决定什么。
Data 360 放在哪里？
Section titled “Data 360 放在哪里？ ”Data 360 提出了一个很好的画图问题。我把它放在**右边、ESB 或 MuleSoft 的下方。**原因在于它的连接：用户从不直接连接它，而它会直接连接很多后端系统。所以它属于数据管道那一边，在那里这些连线保持很短，而不是和用户放在一起。把它画成又一个人们登录的界面，你讲的就是一个错误的故事。
管理员和数据团队确实会打开 Data 360 的界面，但这些界面在 org 里，在核心之上。真正干活的租户，它的数据和处理，运行在核心之外。这就是为什么我把它叫作近核心（near-core）：在核心之上管理，在核心之外托管（模块 1 解释了这些术语）。图跟着租户走：它和数据管道放在一起，有一条线连回管理它的 org。
用 Salesforce 自己的话说，它的功能包括零拷贝：一种数据联邦技术，让企业无需复制就能访问和查询数据（Zero Copy (opens in a new tab)，英文）。它的能力和连接器变化很快，所以由 Data 360 那一章来好好讲，而不是把这个模块变成一次产品导览。
把全景图当作职责来读
Section titled “把全景图当作职责来读 ”看一张全景图时，不要读标志，要读职责。ERP：它拥有什么？数据仓库：它回答什么问题？集成平台：它搬运什么？IdP：它认证谁？MDM：它治理什么身份？Data 360：它连接什么，为了什么？Salesforce：它实际上负责什么？一旦你能回答这些，方框就有了意义，而它们之间的箭头也会变得有趣得多。接下来，我们有意识地把它们画出来。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 每个系统扮演什么角色，超越它的产品名称。
- 对每一个重要的数据集，哪个系统是权威的，以及 Salesforce 在哪里只保留一份本地副本。
- ERP 拥有的数据是否在 Salesforce 中可用、写入受控，以及这种所有权如何在结构中体现出来。
- 根据数据所在的位置，分析应该放在哪里。
- 身份、集成、事件和主数据权威在全景图上位于何处。
一张有十个矩形的全景图还不是架构，只是一份清单。当你能指着每一个矩形说出它为什么在那里、它拥有什么、谁在用它、Salesforce 需要从它那里得到什么，以及误解它的角色会让什么出问题时，架构才开始。
- Salesforce Developers，Metadata API Developer Guide，SamlSsoConfig (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Winter ‘23 Release Notes，Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce，Zero Copy (opens in a new tab)（产品页面，英文），查阅日期 2026-10-14。
- Zhamak Dehghani，How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab)，martinfowler.com，2019（英文）。