多组织生态系统

现代企业和操作系统是相互关联的生态系统的一部分；例如，一个国家的政治不稳定可能对另一个国家的股市产生重大影响，而一个行业的材料短缺可能影响其他需求产品的价格和可用性。

此外，如果组织在完全孤立的情况下存在和运营，它们将面临资源和收入损失、创新和发现速度变慢、效率降低以及重复他人已经犯过的错误的风险。非集成系统会阻碍组织的有效性，因为它们需要在组织内部和外部进行手动的临时数据共享，从而可能在安全性和数据治理方面造成重大风险。

组织可能花费过多时间请求、整理和规范化必要数据，而不是理解和利用数据做出更好的决策。

这就是组织和整个行业可以从成为生态系统的一部分中获益的地方。

在生态系统中，组织可以安全地相互共享数据和应用程序。有效的供应链、药物发现和质量控制都是信息共享带来的好处的例子。

例如，能够更早发现和适应上游供应链中断的零售商可能能够在保持营运资金较低的同时产生更多收入。在这个假设场景中，生态系统中的制造商和供应商可以获得有关零售商库存不足的洞察，从而使他们能够优化制造计划以提高盈利能力和库存管理。跨组织的数据和应用共享可以使所有相关方受益。

解决方案

Palantir Foundry 使多个组织能够在一个共同的平台上安全地以标准化的数据格式和应用接口进行数据共享，从而实现跨组织生态系统。Foundry 在提供生态系统所需的安全性、数据管理和应用要求方面具有良好的交付记录，并已在航空、汽车、金融和制药行业实现了互利合作和数据共享。

通常，生态系统利益相关者可以包括企业、供应商、应用开发者和行业内的其他参与者。每个参与者都完全拥有自己的空间和数据治理，并保持对共享内容和保密内容的精确控制。

Foundry 通过自动化和标准化将来自任意数量自定义系统的共享整合为一种集中格式，解决了数据访问、协调和协作的关键挑战。超越历史模型，其中数据需要一个中央控制点，Foundry 可以划分权限，使每个参与者控制自己的空间和数据治理，完全控制共享内容和每个组织的保密内容。

生态系统模型的类型

Foundry 支持多种不同类型的跨组织生态系统模型，随着生态系统的增长，这些模型通常会结合使用。以下是一些常见的例子。

市场生态系统

在市场生态系统模型中，一个组织引入了一个生态系统，让同一市场的其他组织加入，作为互利创新的桥梁。

例如，一个领先的制药客户可以创建一个市场生态系统，以（1）汇集研究数据以获得更强大的结果，（2）识别合作开发新药的机会。

市场生态系统图

Foundry 通过设置私有和共享空间实现市场生态系统模型。组织可以在其私有空间内的项目中构建私有管道和应用程序，在这些空间中，组织可以定义共享的数据，并通过手动导出或自动化数据管道创建可共享的数据集。这些数据集可以由多个参与方在共享空间中的联合项目中使用。强制性控制如组织权限标记使得审计和控制数据集访问变得容易；数据所有者可以查看哪些组织及其内部用户拥有数据集访问权限。

可以通过像 Contour 和 Code Workbook 这样的应用程序在共享空间中进行协作分析。如果参与者选择使用一个通用的Ontology，可以在共享数据资产之上利用像 Object Explorer、Quiver 和 Vertex 这样的应用程序。

客户生态系统

客户生态系统允许组织以多种方式提供更好的产品和服务。在这种情况下，主办组织可能会选择采用客户和供应商生态系统模型。客户和供应商生态系统的好处和配置是相似的。

供应商生态系统

客户和供应商可以共享关于其服务或产品的数据，这些数据可能是其他生态系统成员过去无法访问的。这种数据共享不仅允许所有参与方更多地了解产品的运行并随着时间的推移进行改进，还可以带来售后服务，如预测问题或加速故障排除。例如，一个飞机制造商（供应商）可能会为其客户（航空公司）提供一个应用程序，以便对飞机零件保修索赔做出决策。

其次，组织可以通过基于客户或供应商数据构建的数字产品来补充现有产品和服务。在这种情况下，一个飞机制造商（供应商）可能会为其客户（航空公司）提供一个应用程序，以便对改进航班时间表做出决策。

供应商和客户生态系统图

第三方生态系统

第三方生态系统模型是指应用开发者、数据提供者或服务提供者被邀请为现有生态系统参与者使用的平台资源做出贡献。开发者可以开发、销售和部署他们带入平台的应用或数据给生态系统成员，因为所有参与者都使用一个通用的Ontology（见下文关键元素）。生态系统的主持人可以选择认证这些开发者、他们的数据和应用，或者通过促进开发者和生态系统中潜在客户之间的联系来促进更非正式的方法。

这种模型通常在生态系统中已经建立了不同组织的网络时最有价值。因此，第三方生态系统模型往往会随着时间的推移而演变。

第三方生态系统模型

生态系统模型的共同特征

主办组织通常是 Foundry 注册的所有者（即，与 Palantir 定义许可和计费的合同框架）并作为促进者。通过此注册，主办组织可以引入其他组织，无论是客户、其他市场参与者、第三方还是供应商；所有这些都被视为生态系统的合作伙伴。Foundry 通过提供一个共享空间来支持生态系统模型，在该空间中，主办组织能够共享 Foundry 应用程序，如 Workshop 模块，同时成员能够提供自己的数据并与主办组织共享选定的数据。

通过定义一个通用的Ontology，主办组织可以确保成员能够利用提供的应用程序，而不管每个成员的源系统和数据格式如何。成员可以构建管道，将他们自己的专有数据在其私有空间中转换为通用数据模型。通用数据变换管道可以由主办组织制成模板，以便快速入驻。

组织通常同时与多个客户、第三方应用提供者和供应商合作。例如，供应商通常相互竞争，以便为主办组织、成员或不在平台上的其他人提供最佳产品。数据安全和治理对于这种生态系统模型至关重要。成员需要确信他们可以安全地管理和控制自己的数据，以便有效参与。Foundry 中的数据是通过强制性控制进行安全和访问控制的，以确保应该共享的数据可以被预期的组织访问，而不应共享的数据对所有者组织之外的用户保持不可访问。

生态系统模型的关键元素

以下列出了所有生态系统模型的共同元素，并在下图中提供了航空行业的示例。

通用Ontology

为了充分利用连接网络的力量，生态系统中的每个组织都必须使用相同的模式 - 在 Foundry 中称为 Ontology - 来表示现实世界的实体及其关系。生态系统参与者可以使用行业标准或定义自己的Ontology。在 Foundry 中，Ontology 是版本化的，以便实现增量开发（例如，基于需求逐个实体开发），从而使单个生态系统参与者的改进和输入能够惠及所有参与者。请注意，使用相同的模式并不要求参与者使用相同的源系统或原始数据格式。

管道模板

Foundry 提供了一套数据集成工具，如数据连接和代码仓库，支持管道搭建和将各种来源系统和格式的数据变换为通用数据模型。这意味着生态系统的参与者不必使用相同的来源系统就能使用通用数据模型。如果输入数据格式或输入系统具有共性，生态系统主持人可以定义一次集成逻辑并在 Foundry 中与参与者共享。对于常见来源系统如 Salesforce 和 SAP，主持人或用户可以利用 HyperAuto 加速将输入数据转换为通用Ontology模式。

应用程序

应用程序是结合使用 Foundry 原生工具以独特方式解决生态系统参与者应用案例的一种方式。由于具有通用的Ontology，生态系统主持人可以提供两种类型的应用程序：

• 汇集参与者数据以增加数据规模以便更好地建模，并将从数据中学到的经验应用回参与者的数据点（例如，基于所有航空公司的飞机数据预测单架飞机的零件故障）。参与者数据池由所有参与者同意的数据和安全配置进行管理，并且通常是匿名或聚合的。
• 在参与者的私有数据上部署一个应用程序（例如，基于单个航空公司的数据改进航班时间表）。

安全性和治理

由于多个组织在一个平台上存在，生态系统需要为所有参与者提供最高级别的平台和数据安全性。Foundry 以此安全性为设计目标，提供了一系列工具，确保所有生态系统参与者可以访问的协作空间以及只有一个或部分组织可以访问和协作的私有空间的安全。这些安全工具包括注册、空间和强制性控制，如组织权限标记和安全权限标记。

想了解更多关于此应用案例模式的信息？想要实施类似的项目？开始使用 Palantir。↗