内容联合无法提供统一发布
Posted: Tue Dec 10, 2024 4:27 am
公司需要向客户提供准确的信息。但随着内容量的增长，实现这一目标变得越来越困难。一些供应商提出了一种称为内容联合的方法来解决这个问题。然而，内容联合加剧了管理大规模内容的复杂性，而不是解决它。
为什么大规模内容管理如此具有挑战性
大型企业可能拥有数十个 CMS，通常来自同一家供应商。这些 CMS 基于已使用二十年的相同架构，已显露出其老旧痕迹。它们以模板为中心的架构无法很好地扩展，并且难以适应新要求，例如集成新服务或将内容交付到新接触点。但由于这些 CMS 已嵌入企业结构中并依赖于发布内容，因此企业可能不愿意用他们目前使用的较新版本“拆除并替换”现有系统。
每个独立的 CMS 都成为一个孤岛，独立运行，不支持使用其他 CMS 的内容团队的需求。
传统 CMS 的缺点很明显，比如多渠道功能较弱。但这些 CMS 的垂直整合也产生了一些不太引人注意的问题。它们的单片架构规定了内容的创建、组合和交付到客户看到的用户界面的方式，这种架构僵化且难以定制，阻碍了企业快速在线推出新产品和服务的能力。
尽管 CMS 僵化和无序扩张的长期问题已被广泛认可，但解决这些问题的正确方法却并不那么明显。有人提出的一个概念是将这些不同的 CMS 联合起来，这样它们就不再孤立地运行。
联合内容：简史
联合是 IT 领域一个历史悠久的概念 俄罗斯手机号码数据库 只要您能准确地标记数据，就可以联合来自不同来源的数据。联合文档也很常见：门户网站已经这样做了几十年。一些 IT 专业人士认为内容也应该联合，因为从技术角度来看，各种资源的联合似乎都差不多。
几年前，网站内容管理书籍的作者 Deane Barker提出“未来可能是分布式的”，内容联合可能成为一种趋势。“如果一个单一的、集成的网站可以由一系列系统提供服务，每个系统都独立工作，会怎么样？”他问道。“如果您的 CMS 不产生任何内容会怎么样？”他将这种内容联合机制描述为“内容提供商管理系统”，它在提供内容的多个 CMS 之间进行调解，“以生成看起来像是来自单个实体的响应。”评论者建议用另一个术语来描述这个概念，即“API 网关”。IT 专家现在通常将这种方法称为内容联合，或更广泛地说，称为 API 联合。
从概念上讲，内容的最终用户永远不会意识到他们体验到的内容来自“独立工作”的独立 CMS。联合提供商不负责决定如何创建内容。其职责是使内容可供交付。其他 CMS 将用于创建内容。
企业被要求采纳一个未经检验的想法。自几年前首次提出内容联合的概念以来，一些供应商已将内容联合作为其核心价值主张的一部分引入其中。最初只是一个推测性的概念，现在已成为一种产品。
内容联合可以定位为一种工具或服务，既可以定位为一种特殊的 CMS，也可以定位为一种中间件应用程序。虽然内容联合不是一个定义明确的产品类别，但它现在被推销为解决内容孤岛这一顽固问题的解决方案。
联合孤岛的虚假承诺
所有大型组织都面临着由独立 CMS 管理的内容孤岛问题。据称，联合将以最小的努力迅速消除这些问题。内容联合的倡导者提出了一系列主张：
您可以继续使用熟悉的设置，无需更改流程或工具
无需将现有内容迁移到更好的平台
您现有的内容很好
您可以继续使用旧版 CMS - 它们的任何缺陷都会在其他地方得到修补
新的层将使您的内容管理现代化，而无需您进行任何返工
很容易看出这些承诺为何如此吸引人。大多数企业的内容运营都很分散，这阻碍了他们为客户提供服务和协调业务运营的能力。内容联合看起来是解决内容孤岛问题的一种简单方法。
表面上看，内容联合无需任何变更管理即可带来变更。不知何故，您可以在保持现状的同时享受到效率的大幅提升。
如果不付出努力就进行重大改变听起来不太现实，那是因为其中许多改变都是表面的、装饰性的，不会改变核心运营。
内容联合的承诺与需要开发内容来支持客户的现实之间存在巨大差距。
许多关于内容联合的说法都是由几乎没有直接开发和发布内容经验的工程师提出的。当您听到供应商交替使用数据和内容这两个术语时，这一点就显而易见了，好像它们是相同的一样。当供应商说“内容就是数据”时，要当心——这是一个强烈的信号，他们销售的是一种工程解决方案，而不是一种满足业务用户需求的解决方案。
有些供应商可能会建议你从“任何后端”将数据“加载”到他们的工具中，然后他们的工具就可以从那里获取数据，并决定将其发送给客户的位置。该工具就像一台搅拌机，将来自不同橱柜的原料混合成奶昔。
内容联合承诺提供存储在各种 CMS 中的所有内容的目录。但实际上，联合并没有真正告诉你那里有什么。它无法让你了解内容是什么，以及它是否是适合呈现给用户的内容。
当工程师谈论整合来自不同来源的内容时，他们其实是在鼓励将内容混合成糊状。他们不承认内容是有质感的：它由发挥不同作用的独特部分组成。他们没有解释这些部分是什么以及它们如何协同工作。
海量的数据无法为客户带来连贯的体验。杂乱无章的内容无法带来商业价值。
由于一系列实际原因，企业尚未采用内容联合。联合内容在操作上与联合数据不同。与简单的数据值不同，内容的含义取决于其上下文。大型组织不能将由不同团队独立创建的不同来源的内容混合在一起并期望其连贯一致。当内容来自不同来源时，每个来源都会独立开发该内容，而不会考虑它如何与在其他地方开发的内容协同工作。
内容孤岛不仅仅是一个可以通过 API 解决的工程问题，更是一个需要转型的结构性、组织性问题。
内容中包含的消息和信息并不是隐藏在某个后端系统中等待被提取的简单数据。它不像数据那样是交易的副产品。
作者创建内容是为了满足不同环境下读者的需求。他们计划如何将细节组合在一起以提供体验。来自不同系统的内容片段不能随意混合。这些不同的片段需要一个通用的内容模型，以便可以适当地匹配。但如果它们来自不同的 CMS，每个 CMS 都使用不同的内容模型，那么这些片段将不兼容。
治标不治本
内容联合在很多方面都与无头内容发布相反。联合的假设是您需要多个 CMS 来为单个网站提供内容。相比之下，无头 CMS 则相反，单个 CMS 可以支持多个网站。
多个 CMS 会带来问题，但解决方案并不是让所有 CMS 都服务于一个网站。企业总是会拥有多个网站。他们不需要的是他们目前拥有的 CMS 数量。
拥有多个独立的 CMS 是内容运营孤立的明显标志。如果团队使用不同的 CMS 来支持特定的客户体验，那么创建该内容的过程就会变得非常分散。
当企业拥有多个独立的 CMS，而这些 CMS 基本上做着同样的事情时，这表明这些 CMS 都无法满足利益相关者的不同需求。紧密耦合的单片 CMS 很难支持使用不同 UI 设计呈现不同内容的多个接触点。每个团队或部门都觉得他们需要自己的专用 CMS，因为他们需要定制 CMS 来满足他们的特定需求。每个 CMS 都必须单独管理，这给 IT 团队带来了麻烦。但问题比 IT 管理员更深。
多个内容团队各自独立工作，没有协调。每个团队都自行决定为其 CMS 支持的特定网站创建什么内容。连接他们的 CMS 不会让团队突然合作，为在不同网站和渠道之间移动的客户提供连贯的体验。各个团队仍将在各自的孤立环境中工作。
如果企业把几十个有问题的系统连接在一起，问题不仅不会消失，反而会使已有的问题进一步放大。
内容孤岛不仅仅是一个需要克服的技术问题。企业必须改变其开发和管理内容的方式。内容联合并不能解决内容运营碎片化的问题。
旧式 CMS 延续了旧式流程
企业面临的核心问题是，他们缺乏对所制作的所有内容的控制。他们缺乏共同的流程、共享的治理和整个企业遵循的统一的内容结构。不同的团队决定他们想要做什么，而很少考虑他们的工作需要如何与组织的其他部分整合。
如果企业希望更好地开发和交付内容，就不能继续进行分散的内容运营。当运营专注于单个网站或应用程序时，其流程是不可扩展的。由独立团队使用单独的 CMS 管理的分散流程将提供不集成的客户体验，并且无法实现运营效率。
孤立的内容操作会导致许多问题：
各个团队重复工作，每个团队都定义自己的流程和标准
可以更有效地集中管理的冗余任务，例如用户和帐户管理
缺少支持客户旅程场景的内容覆盖
不一致的信息是由不同的团队产生的，他们不知道其他团队正在产生什么
内容在细节或风格上不匹配
由于不同的团队遵循不同的标准和工作流程，导致输出质量参差不齐
单个团队如果单独行动，是无法取得更好成果的。
碎片化的内容运营对每个人来说都是一个问题。对于内容领导者来说，他们会干扰内容的治理。各个团队都在做自己的事情，这意味着部分内容存在以下风险：
事实细节不一致
讨论内容重复
存在多个版本，其中许多可能已过时
不符合企业品牌或法律准则
对于内容制作者来说，情况同样困难。他们所创建的内容存在缺陷，这是他们无法承担的责任，因为他们缺乏将自己的工作与更广泛的企业问题联系起来的能力。他们必须自己弄清楚需要什么内容以及如何最好地做到这一点，因为他们使用的 CMS 与组织中其他同事使用的 CMS 是隔离的。他们需要来自更大组织的更好支持。他们需要将他们的内容和所使用的流程与组织的其他部分联系起来。
联合内容债务并不能消除债务。内容联合只是一厢情愿的行为，因为它无法解决导致内容操作碎片化的结构性问题：
整体式 CMS 依赖于定义内容创建、组装和呈现的模板，这使得它们缺乏灵活性且难以定制
每个团队都决定需要自己的整体式 CMS 来生产他们所需的东西
不同 CMS 的激增导致内容运营的碎片化
尝试通过内容联合来修补碎片就像将胶带贴在结构不牢固的地基上一样。
具有讽刺意味的是，由于集中式、垂直集成的 CMS 固有的不灵活性，导致了内容创作的分散化，因为单一的 CMS 无法满足不同内容团队的需求。
当依赖许多不协调的 CMS 时，企业会面临多个潜在的故障点。所需的内容可能无法获得，因为它从未被预期过，因此从未被创建过。或者，不同的系统具有相同类型的内容，并且不清楚哪个版本是正确的选择。
内容联合干扰编排
孤岛不仅损害了内部效率，还损害了客户体验。客户无法在需要时获得相关内容。内容制作是各自为政的，导致向客户交付内容的过程很零散。
企业希望改进内容编排，使其内容交付更具相关性和及时性，但他们发现其内容尚未准备好。他们无法轻松地个性化、定制、优化和本地化其内容，因为其内容被困在供应商提供的模板中，这些模板在单片 CMS 中管理其内容。
随着组织引入更多网站、应用和其他接触点，多个 CMS 对客户体验的负面影响也越来越大。客户访问的接触点越来越多，但遇到的内容却无法跨渠道协同工作。
不幸的是，如果企业决定将来自不同 CMS 的内容混合在一起，而这些内容本来不应该同时出现在同一个屏幕上，那么内容联合将进一步暴露这些问题。内容联合不仅不会解决公司的核心问题，而且还可能使这些问题更加严重。
企业在利用来自多个 CMS 的内容时面临着巨大的编排障碍：
底层内容尚未准备好进行编排
协调决策的过程更加困难
内容联合将联合策略与治理要求相混淆，暗示联合可以绕过治理的需要。没有治理的联合是鲁莽的。
企业确实需要能够将其内容与其他类型的数据相结合，以便交付给客户。将内容与来自其他系统的其他数据或资产进行编排并汇集不同类型的信息会很有用，每种信息可能由专门的记录源管理。例如，企业可能将产品信息存储在单独的系统中，该系统作为该信息的记录源。
对于每个不同的数据域，应该只有一个记录源。否则，企业可能会向客户提供错误的数据。企业不应该为特定类型的信息或数据提供多个来源。这一原则更适用于内容；内容必须有一个单一的真实来源。而拥有内容单一真实来源的唯一可行方法是让所有企业内容在一个每个人都使用的平台上进行管理。
虽然许多 CMS 都有允许外部来源向其提供内容的 API，但此功能可能会被滥用。重要的不仅是内容存储在哪里，还有内容的开发地点。所有内容都应根据通用标准进行开发。
通过继续依赖单独管理的 CMS，企业发现现有问题和低效率变得更加根深蒂固。没有定义正确的内容制作流程。每个人都可以自由地以自己的方式做事。每个群体都可能将最终用户在体验混乱不清的内容时遇到的问题归咎于其他人。
理论上，内容联合应该有助于内容的协调。但实际上，情况恰恰相反。内容联合将暴露孤立内容中的不一致之处。
从多个 CMS 采购时，编排会变得有风险且困难。企业依赖多个 CMS 时无法提供精准的内容。每个 CMS 依赖不同的内容模型，并将以不同的方式描述内容。内容类型及其字段的名称可能不同，或者它们可能使用相同的名称来指代不同的东西，这使得很难知道正在组装什么。为了弥补这个问题，联合方法可以依赖唯一的 ID 来消除来自不同 CMS 的内容片段的歧义。但这些 ID 本身是没有意义的。那些试图从这些片段中创建拼凑物的人仍然需要检查它们以了解它们指的是什么。这项任务更加繁重，因为内容项分散在不同的地方，必须分别检查。
为什么大规模内容管理如此具有挑战性
大型企业可能拥有数十个 CMS，通常来自同一家供应商。这些 CMS 基于已使用二十年的相同架构，已显露出其老旧痕迹。它们以模板为中心的架构无法很好地扩展，并且难以适应新要求，例如集成新服务或将内容交付到新接触点。但由于这些 CMS 已嵌入企业结构中并依赖于发布内容，因此企业可能不愿意用他们目前使用的较新版本“拆除并替换”现有系统。
每个独立的 CMS 都成为一个孤岛，独立运行，不支持使用其他 CMS 的内容团队的需求。
传统 CMS 的缺点很明显，比如多渠道功能较弱。但这些 CMS 的垂直整合也产生了一些不太引人注意的问题。它们的单片架构规定了内容的创建、组合和交付到客户看到的用户界面的方式，这种架构僵化且难以定制，阻碍了企业快速在线推出新产品和服务的能力。
尽管 CMS 僵化和无序扩张的长期问题已被广泛认可，但解决这些问题的正确方法却并不那么明显。有人提出的一个概念是将这些不同的 CMS 联合起来，这样它们就不再孤立地运行。
联合内容：简史
联合是 IT 领域一个历史悠久的概念 俄罗斯手机号码数据库 只要您能准确地标记数据，就可以联合来自不同来源的数据。联合文档也很常见：门户网站已经这样做了几十年。一些 IT 专业人士认为内容也应该联合，因为从技术角度来看，各种资源的联合似乎都差不多。
几年前，网站内容管理书籍的作者 Deane Barker提出“未来可能是分布式的”，内容联合可能成为一种趋势。“如果一个单一的、集成的网站可以由一系列系统提供服务，每个系统都独立工作，会怎么样？”他问道。“如果您的 CMS 不产生任何内容会怎么样？”他将这种内容联合机制描述为“内容提供商管理系统”，它在提供内容的多个 CMS 之间进行调解，“以生成看起来像是来自单个实体的响应。”评论者建议用另一个术语来描述这个概念，即“API 网关”。IT 专家现在通常将这种方法称为内容联合，或更广泛地说，称为 API 联合。
从概念上讲，内容的最终用户永远不会意识到他们体验到的内容来自“独立工作”的独立 CMS。联合提供商不负责决定如何创建内容。其职责是使内容可供交付。其他 CMS 将用于创建内容。
企业被要求采纳一个未经检验的想法。自几年前首次提出内容联合的概念以来，一些供应商已将内容联合作为其核心价值主张的一部分引入其中。最初只是一个推测性的概念，现在已成为一种产品。
内容联合可以定位为一种工具或服务，既可以定位为一种特殊的 CMS，也可以定位为一种中间件应用程序。虽然内容联合不是一个定义明确的产品类别，但它现在被推销为解决内容孤岛这一顽固问题的解决方案。
联合孤岛的虚假承诺
所有大型组织都面临着由独立 CMS 管理的内容孤岛问题。据称，联合将以最小的努力迅速消除这些问题。内容联合的倡导者提出了一系列主张：
您可以继续使用熟悉的设置，无需更改流程或工具
无需将现有内容迁移到更好的平台
您现有的内容很好
您可以继续使用旧版 CMS - 它们的任何缺陷都会在其他地方得到修补
新的层将使您的内容管理现代化，而无需您进行任何返工
很容易看出这些承诺为何如此吸引人。大多数企业的内容运营都很分散，这阻碍了他们为客户提供服务和协调业务运营的能力。内容联合看起来是解决内容孤岛问题的一种简单方法。
表面上看，内容联合无需任何变更管理即可带来变更。不知何故，您可以在保持现状的同时享受到效率的大幅提升。
如果不付出努力就进行重大改变听起来不太现实，那是因为其中许多改变都是表面的、装饰性的，不会改变核心运营。
内容联合的承诺与需要开发内容来支持客户的现实之间存在巨大差距。
许多关于内容联合的说法都是由几乎没有直接开发和发布内容经验的工程师提出的。当您听到供应商交替使用数据和内容这两个术语时，这一点就显而易见了，好像它们是相同的一样。当供应商说“内容就是数据”时，要当心——这是一个强烈的信号，他们销售的是一种工程解决方案，而不是一种满足业务用户需求的解决方案。
有些供应商可能会建议你从“任何后端”将数据“加载”到他们的工具中，然后他们的工具就可以从那里获取数据，并决定将其发送给客户的位置。该工具就像一台搅拌机，将来自不同橱柜的原料混合成奶昔。
内容联合承诺提供存储在各种 CMS 中的所有内容的目录。但实际上，联合并没有真正告诉你那里有什么。它无法让你了解内容是什么，以及它是否是适合呈现给用户的内容。
当工程师谈论整合来自不同来源的内容时，他们其实是在鼓励将内容混合成糊状。他们不承认内容是有质感的：它由发挥不同作用的独特部分组成。他们没有解释这些部分是什么以及它们如何协同工作。
海量的数据无法为客户带来连贯的体验。杂乱无章的内容无法带来商业价值。
由于一系列实际原因，企业尚未采用内容联合。联合内容在操作上与联合数据不同。与简单的数据值不同，内容的含义取决于其上下文。大型组织不能将由不同团队独立创建的不同来源的内容混合在一起并期望其连贯一致。当内容来自不同来源时，每个来源都会独立开发该内容，而不会考虑它如何与在其他地方开发的内容协同工作。
内容孤岛不仅仅是一个可以通过 API 解决的工程问题，更是一个需要转型的结构性、组织性问题。
内容中包含的消息和信息并不是隐藏在某个后端系统中等待被提取的简单数据。它不像数据那样是交易的副产品。
作者创建内容是为了满足不同环境下读者的需求。他们计划如何将细节组合在一起以提供体验。来自不同系统的内容片段不能随意混合。这些不同的片段需要一个通用的内容模型，以便可以适当地匹配。但如果它们来自不同的 CMS，每个 CMS 都使用不同的内容模型，那么这些片段将不兼容。
治标不治本
内容联合在很多方面都与无头内容发布相反。联合的假设是您需要多个 CMS 来为单个网站提供内容。相比之下，无头 CMS 则相反，单个 CMS 可以支持多个网站。
多个 CMS 会带来问题，但解决方案并不是让所有 CMS 都服务于一个网站。企业总是会拥有多个网站。他们不需要的是他们目前拥有的 CMS 数量。
拥有多个独立的 CMS 是内容运营孤立的明显标志。如果团队使用不同的 CMS 来支持特定的客户体验，那么创建该内容的过程就会变得非常分散。
当企业拥有多个独立的 CMS，而这些 CMS 基本上做着同样的事情时，这表明这些 CMS 都无法满足利益相关者的不同需求。紧密耦合的单片 CMS 很难支持使用不同 UI 设计呈现不同内容的多个接触点。每个团队或部门都觉得他们需要自己的专用 CMS，因为他们需要定制 CMS 来满足他们的特定需求。每个 CMS 都必须单独管理，这给 IT 团队带来了麻烦。但问题比 IT 管理员更深。
多个内容团队各自独立工作，没有协调。每个团队都自行决定为其 CMS 支持的特定网站创建什么内容。连接他们的 CMS 不会让团队突然合作，为在不同网站和渠道之间移动的客户提供连贯的体验。各个团队仍将在各自的孤立环境中工作。
如果企业把几十个有问题的系统连接在一起，问题不仅不会消失，反而会使已有的问题进一步放大。
内容孤岛不仅仅是一个需要克服的技术问题。企业必须改变其开发和管理内容的方式。内容联合并不能解决内容运营碎片化的问题。
旧式 CMS 延续了旧式流程
企业面临的核心问题是，他们缺乏对所制作的所有内容的控制。他们缺乏共同的流程、共享的治理和整个企业遵循的统一的内容结构。不同的团队决定他们想要做什么，而很少考虑他们的工作需要如何与组织的其他部分整合。
如果企业希望更好地开发和交付内容，就不能继续进行分散的内容运营。当运营专注于单个网站或应用程序时，其流程是不可扩展的。由独立团队使用单独的 CMS 管理的分散流程将提供不集成的客户体验，并且无法实现运营效率。
孤立的内容操作会导致许多问题：
各个团队重复工作，每个团队都定义自己的流程和标准
可以更有效地集中管理的冗余任务，例如用户和帐户管理
缺少支持客户旅程场景的内容覆盖
不一致的信息是由不同的团队产生的，他们不知道其他团队正在产生什么
内容在细节或风格上不匹配
由于不同的团队遵循不同的标准和工作流程，导致输出质量参差不齐
单个团队如果单独行动，是无法取得更好成果的。
碎片化的内容运营对每个人来说都是一个问题。对于内容领导者来说，他们会干扰内容的治理。各个团队都在做自己的事情，这意味着部分内容存在以下风险：
事实细节不一致
讨论内容重复
存在多个版本，其中许多可能已过时
不符合企业品牌或法律准则
对于内容制作者来说，情况同样困难。他们所创建的内容存在缺陷，这是他们无法承担的责任，因为他们缺乏将自己的工作与更广泛的企业问题联系起来的能力。他们必须自己弄清楚需要什么内容以及如何最好地做到这一点，因为他们使用的 CMS 与组织中其他同事使用的 CMS 是隔离的。他们需要来自更大组织的更好支持。他们需要将他们的内容和所使用的流程与组织的其他部分联系起来。
联合内容债务并不能消除债务。内容联合只是一厢情愿的行为，因为它无法解决导致内容操作碎片化的结构性问题：
整体式 CMS 依赖于定义内容创建、组装和呈现的模板，这使得它们缺乏灵活性且难以定制
每个团队都决定需要自己的整体式 CMS 来生产他们所需的东西
不同 CMS 的激增导致内容运营的碎片化
尝试通过内容联合来修补碎片就像将胶带贴在结构不牢固的地基上一样。
具有讽刺意味的是，由于集中式、垂直集成的 CMS 固有的不灵活性，导致了内容创作的分散化，因为单一的 CMS 无法满足不同内容团队的需求。
当依赖许多不协调的 CMS 时，企业会面临多个潜在的故障点。所需的内容可能无法获得，因为它从未被预期过，因此从未被创建过。或者，不同的系统具有相同类型的内容，并且不清楚哪个版本是正确的选择。
内容联合干扰编排
孤岛不仅损害了内部效率，还损害了客户体验。客户无法在需要时获得相关内容。内容制作是各自为政的，导致向客户交付内容的过程很零散。
企业希望改进内容编排，使其内容交付更具相关性和及时性，但他们发现其内容尚未准备好。他们无法轻松地个性化、定制、优化和本地化其内容，因为其内容被困在供应商提供的模板中，这些模板在单片 CMS 中管理其内容。
随着组织引入更多网站、应用和其他接触点，多个 CMS 对客户体验的负面影响也越来越大。客户访问的接触点越来越多，但遇到的内容却无法跨渠道协同工作。
不幸的是，如果企业决定将来自不同 CMS 的内容混合在一起，而这些内容本来不应该同时出现在同一个屏幕上，那么内容联合将进一步暴露这些问题。内容联合不仅不会解决公司的核心问题，而且还可能使这些问题更加严重。
企业在利用来自多个 CMS 的内容时面临着巨大的编排障碍：
底层内容尚未准备好进行编排
协调决策的过程更加困难
内容联合将联合策略与治理要求相混淆，暗示联合可以绕过治理的需要。没有治理的联合是鲁莽的。
企业确实需要能够将其内容与其他类型的数据相结合，以便交付给客户。将内容与来自其他系统的其他数据或资产进行编排并汇集不同类型的信息会很有用，每种信息可能由专门的记录源管理。例如，企业可能将产品信息存储在单独的系统中，该系统作为该信息的记录源。
对于每个不同的数据域，应该只有一个记录源。否则，企业可能会向客户提供错误的数据。企业不应该为特定类型的信息或数据提供多个来源。这一原则更适用于内容；内容必须有一个单一的真实来源。而拥有内容单一真实来源的唯一可行方法是让所有企业内容在一个每个人都使用的平台上进行管理。
虽然许多 CMS 都有允许外部来源向其提供内容的 API，但此功能可能会被滥用。重要的不仅是内容存储在哪里，还有内容的开发地点。所有内容都应根据通用标准进行开发。
通过继续依赖单独管理的 CMS，企业发现现有问题和低效率变得更加根深蒂固。没有定义正确的内容制作流程。每个人都可以自由地以自己的方式做事。每个群体都可能将最终用户在体验混乱不清的内容时遇到的问题归咎于其他人。
理论上，内容联合应该有助于内容的协调。但实际上，情况恰恰相反。内容联合将暴露孤立内容中的不一致之处。
从多个 CMS 采购时，编排会变得有风险且困难。企业依赖多个 CMS 时无法提供精准的内容。每个 CMS 依赖不同的内容模型，并将以不同的方式描述内容。内容类型及其字段的名称可能不同，或者它们可能使用相同的名称来指代不同的东西，这使得很难知道正在组装什么。为了弥补这个问题，联合方法可以依赖唯一的 ID 来消除来自不同 CMS 的内容片段的歧义。但这些 ID 本身是没有意义的。那些试图从这些片段中创建拼凑物的人仍然需要检查它们以了解它们指的是什么。这项任务更加繁重，因为内容项分散在不同的地方，必须分别检查。