Multi-organization ecosystems（多组织生态系统）¶
Modern businesses and operating systems are part of an interconnected landscape; for instance, political instability in one country can have a significant effect on the stock market of another, while material shortages in one industry can impact the price and availability of other in-demand products.
Furthermore, if organizations exist and operate in complete silos, they face costs in terms of lost resources and revenue, slower paths to innovation and discovery, decreased efficiency, and the risk of repeating mistakes others have already made. Organizational effectiveness can be impeded by non-integrated systems that require manual ad-hoc data sharing both within and outside of the organization, which can create significant risks in security and data governance.
Organizations can spend too much time requesting, collating, and normalizing necessary data, instead of understanding and acting on data to make better decisions.
This is where organizations and entire industries can benefit from being part of an ecosystem.
In an ecosystem, organizations can securely share data and applications with one another. Effective supply chains, drug discovery, and quality control are all examples of processes that benefit from information sharing.
For instance, retailers that can detect and adapt to upstream supply chain disruptions earlier may be able to generate more revenue while keeping working capital low. In this hypothetical scenario, manufacturers and vendors within the same ecosystem could receive insights into low retailer inventory, enabling them to optimize their manufacturing scheduling to improve profitability and inventory-keeping. Cross-organizational data and application sharing can benefit all parties involved.
Solution¶
Palantir Foundry enables cross-organizational ecosystems in which multiple organizations are able to securely share data in a standardized data format and application interfaces in a common platform. Foundry has a proven record of delivery on the security, data management, and application requirements needed to power ecosystems across the aviation, automotive, finance, and pharmaceuticals industries and enable mutually beneficial collaboration and data sharing.
Typically, ecosystem stakeholders can include enterprises, vendors, app developers, and other participants in an industry. Each party completely owns their own space and data governance, and maintains precise control over what’s shared with whom, and what remains private.
Foundry addresses the key challenges of data access, harmonization, and collaboration by automating and standardizing sharing from any number of custom systems into one centralized format. Moving beyond the historical model where data needed a central point of control, Foundry can divide permissions such that every party controls their own space and data governance, with complete control over what is shared with whom and what is private to each organization.
Types of ecosystem models¶
Foundry supports several different styles of cross-organizational ecosystem models, which are often combined as the ecosystem grows. Below are a few common examples.
Market Ecosystem¶
In the market ecosystem model, one organization introduces an ecosystem for others in the same market to join, acting as the conduit for mutually beneficial innovation.
For example, a leading pharmaceuticals client could create a market ecosystem to (1) pool research data for more robust results and (2) identify opportunities to partner in developing a new drug.
Market Ecosystem diagram
Foundry enables the market ecosystem model through the setup of private and shared spaces. Organizations can construct private pipelines and applications in projects within their private space, within which organizations can define which data is shared, as well as create sharable datasets through manual exports or automated data pipelines. These datasets can be used by multiple parties in joint projects in the shared space. Mandatory controls such as organizational markings make it easy to audit and control access to datasets on a granular level; data owners can see which organizations and the users within them have dataset access.
Collaborative analysis can be conducted in the shared space through applications like Contour and Code Workbook. If participants choose to use a common ontology, applications like Object Explorer, Quiver, and Vertex can be leveraged on top of the shared data asset.
Client Ecosystem¶
A client ecosystem allows organizations to offer better products and services in several ways. In this context, a host organization may elect to adopt both a client and vendor ecosystem model. The benefits and configuration of client and vendor ecosystems are similar.
Vendor Ecosystem¶
Clients and vendors can share data about their services or products that other ecosystem members may not have had access to in the past. This data sharing allows all parties to not only learn more about the product in operation and improve it over time, but can also lead to post-sale services such as the ability to anticipate problems or accelerate troubleshooting. For example, an aircraft manufacturer (vendor) might offer its clients (airlines) an app to make decisions about aircraft part warranty claims.
Second, organizations can complement existing products and services with digital offerings such as apps built upon the client or vendor’s data. In this instance, an aircraft manufacturer (vendor) might offer its clients (airlines) an app to make decisions about improving flight schedules.
Vendor and Client Ecosystem diagram
Third-party ecosystem¶
A third-party ecosystem model is when app developers, data providers or service providers are invited to contribute to the platform resources that are used by the existing ecosystem participants. Developers can develop, sell, and deploy the apps or data they bring to the platform to members of the ecosystem, since all participants are using a common ontology (see key elements below). The host of the ecosystem has the option to certify those developers, their data, and their apps, or facilitate a more informal approach by facilitating connections between developers and potential clients in the ecosystem.
This model tends to be most valuable when there is already an established network of different organizations in the ecosystem. Therefore, the third-party ecosystem model tends to evolve over time.
3rd Party Ecosystem model
Common features of ecosystem models¶
The host organization will typically be the owner of the Foundry enrollment (that is, a contractual framework with Palantir defining the license and billing) and positioned as a facilitator. Through this enrollment, the host organization can onboard other organizations, whether they be clients, other market participants, third parties, or vendors; all are considered partners in the ecosystem. Foundry supports the ecosystem model by providing a shared space where the host organization is able to share Foundry applications, like Workshop modules, while members are able to provide their own data and share select data with the host organization.
By defining a common ontology, the host organization can be sure that members are able to leverage provided applications, regardless of the source system and data formats that each individual member has. Members can construct pipelines to transform their own proprietary data into the common data model in their private spaces. Common data transformation pipelines can be made into templates by the host organization to allow for fast onboarding.
Organizations often work with multiple clients, third party app providers, and vendors at a time. Vendors, for example, are often competing against one another to either offer the best product to the host organization, members, or others who are not on the platform. Data security and governance are critical for this ecosystem model. Members need to be confident that they can secure, administer, and control their own data in order to effectively participate. Data in Foundry is secured and access-controlled through mandatory controls to ensure that data that should be shared can be accessed by the intended organization(s) and the data which should not be shared remains inaccessible to users outside of the owner organization.
Key elements of an ecosystem model¶
Listed below are the elements common to all ecosystem models with an example from the airline industry in the diagram below.
Common ontology¶
In order to fully benefit from the power of a connected network, every organization in the ecosystem must use the same schema - known in Foundry as an ontology - to represent real-world entities and their relations. Ecosystem participants can either use an industry standard or define their own ontology. An ontology is versioned in Foundry to enable incremental development (for instance, one entity at a time based on demand) such that improvements and input from a single ecosystem participant can benefit all participants. Note that using the same schema does not require that participants use the same source systems or raw data formats. )
Pipeline templates¶
Foundry provides a suite of data integration tools, such as Data Connection and Code Repositories, that enable pipeline building and transformation of data from various source systems and formats into a common data model. This means that participants in an ecosystem do not have to use the same source systems to be able to use a common data model. If there are commonalities in input data formats or input systems, the ecosystem host can define logic for integrating them once and share it with the participants within Foundry. For common source systems such as Salesforce and SAP, the host or user can leverage HyperAuto to accelerate the transformation of input data to the common ontology schema.
Applications¶
Applications are a way of using a combination of Foundry native tools to create a unique way of addressing a use case across ecosystem participants. Thanks to having a common ontology, ecosystem hosts can offer two types of apps:
- Pool participant data to increase the data scale for better modeling and apply lessons learned from the data back to the participants’ datapoints (for instance, to anticipate part faults for a single aircraft based on data from aircrafts of all airlines). Participant data pools are governed by data and security configurations agreed to by all participants and are often anonymized or aggregated.
- Deploy an app on a participant’s private data (for example, Flight Schedule Improvements based on a single airline’s data).
Security and governance¶
With several organizations being present on a single platform, ecosystems require the highest level of platform and data security for all participants. Designed with this security in mind, Foundry has an array of tools that ensure the safety of both collaborative spaces that all ecosystem participants can access, as well as private spaces where only one or a subset of organizations have access and the ability to collaborate. These security tools include enrollments, spaces, and mandatory controls such as organization markings and security markings.
Want more information on this use case pattern? Looking to implement something similar? Get started with Palantir. ↗
中文翻译¶
多组织生态系统¶
现代企业和操作系统是互联互通格局中的一部分；例如，一个国家的政治不稳定可能对另一个国家的股市产生重大影响，而一个行业的原材料短缺则可能影响其他热门产品的价格和供应。
此外，如果组织完全在孤岛中存在和运作，它们将面临资源与收入损失、创新与发现路径缓慢、效率降低以及重复他人已犯错误的风险。非集成系统要求组织内外进行手动临时数据共享，这可能在安全和数据治理方面带来重大风险，从而阻碍组织效能。
组织可能会花费过多时间请求、整理和标准化必要数据，而不是理解数据并据此采取行动以做出更明智的决策。
这正是组织和整个行业可以从成为生态系统一部分中获益的地方。
在生态系统中，组织可以安全地相互共享数据和应用程序。高效的供应链、药物发现和质量控制都是受益于信息共享的流程示例。
例如，能够更早检测并适应上游供应链中断的零售商，可能能够在保持较低营运资本的同时创造更多收入。在这种假设场景中，同一生态系统内的制造商和供应商可以获取零售商库存较低的洞察，从而优化其生产排程以提高盈利能力和库存管理。跨组织的数据和应用程序共享可以使所有相关方受益。
解决方案¶
Palantir Foundry 支持跨组织生态系统，使多个组织能够在通用平台上以标准化数据格式和应用程序接口安全地共享数据。Foundry 在安全、数据管理和应用程序需求方面拥有经过验证的交付记录，这些需求是推动航空、汽车、金融和制药行业生态系统以及实现互利协作和数据共享所必需的。
通常，生态系统利益相关者可以包括企业、供应商、应用程序开发者以及行业中的其他参与者。每一方完全拥有自己的空间和数据治理权，并精确控制与谁共享什么内容以及保留什么内容为私有。
Foundry 通过自动化和标准化从任意数量的自定义系统到一个集中格式的共享，解决了数据访问、协调和协作的关键挑战。超越传统的数据需要中央控制点的模式，Foundry 可以划分权限，使每一方控制自己的空间和数据治理，完全控制与谁共享什么内容以及每个组织私有什么内容。
生态系统模型的类型¶
Foundry 支持多种不同风格的跨组织生态系统模型，随着生态系统的发展，这些模型通常会组合使用。以下是一些常见示例。
市场生态系统¶
在市场生态系统模型中，一个组织引入一个生态系统，供同一市场的其他组织加入，充当互利创新的渠道。
例如，一家领先的制药客户可以创建一个市场生态系统，以（1）汇集研究数据以获得更稳健的结果，以及（2）识别合作开发新药的机会。
市场生态系统示意图
Foundry 通过设置私有和共享空间来实现市场生态系统模型。组织可以在其私有空间内的项目中构建私有管道和应用程序，在其中组织可以定义哪些数据被共享，并通过手动导出或自动化数据管道创建可共享的数据集。这些数据集可以在共享空间中的联合项目中被多方使用。强制性控制（如组织标记）使得在细粒度级别上审计和控制对数据集的访问变得容易；数据所有者可以查看哪些组织及其用户拥有数据集访问权限。
协作分析可以通过 Contour 和 Code Workbook 等应用程序在共享空间中进行。如果参与者选择使用通用本体（ontology），则可以在共享数据资产之上利用 Object Explorer、Quiver 和 Vertex 等应用程序。
客户生态系统¶
客户生态系统允许组织以多种方式提供更好的产品和服务。在这种背景下，主办组织可以选择同时采用客户和供应商生态系统模型。客户和供应商生态系统的优势和配置是相似的。
供应商生态系统¶
客户和供应商可以共享关于其服务或产品的数据，这些数据其他生态系统成员过去可能无法访问。这种数据共享不仅使所有方能够更多地了解产品在运行中的情况并随时间改进产品，还可以带来售后服务的可能性，例如预测问题或加速故障排除。例如，一家飞机制造商（供应商）可以为其客户（航空公司）提供一个应用程序，用于做出关于飞机部件保修索赔的决策。
其次，组织可以通过数字产品（例如基于客户或供应商数据构建的应用程序）来补充现有产品和服务。在这种情况下，一家飞机制造商（供应商）可以为其客户（航空公司）提供一个应用程序，用于做出关于改进航班时刻表的决策。
供应商和客户生态系统示意图
第三方生态系统¶
第三方生态系统模型是指邀请应用程序开发者、数据提供商或服务提供商为平台贡献资源，这些资源被现有生态系统参与者使用。开发者可以开发、销售和部署他们带到平台的应用程序或数据给生态系统成员，因为所有参与者都使用通用本体（参见下文关键要素）。生态系统的主办方可以选择认证这些开发者、他们的数据和应用程序，或者通过促进开发者与生态系统中潜在客户之间的联系来采用更非正式的方法。
当生态系统中已经存在不同组织的既定网络时，这种模型往往最有价值。因此，第三方生态系统模型往往会随着时间的推移而演变。
第三方生态系统模型
生态系统模型的共同特征¶
主办组织通常是 Foundry enrollment（即与 Palantir 定义许可和计费的合同框架）的所有者，并充当促进者。通过此 enrollment，主办组织可以引入其他组织，无论是客户、其他市场参与者、第三方还是供应商；所有这些都被视为生态系统中的合作伙伴。Foundry 通过提供一个共享空间来支持生态系统模型，主办组织可以在其中共享 Foundry 应用程序（如 Workshop 模块），而成员可以提供自己的数据并与主办组织共享选定的数据。
通过定义通用本体，主办组织可以确保成员能够利用提供的应用程序，无论每个成员拥有何种源系统和数据格式。成员可以构建管道，将其专有数据转换为其私有空间中的通用数据模型。主办组织可以将通用数据转换管道制作成模板，以实现快速引入。
组织通常同时与多个客户、第三方应用程序提供商和供应商合作。例如，供应商之间经常相互竞争，以向主办组织、成员或平台外的其他人提供最佳产品。数据安全和治理对于这种生态系统模型至关重要。成员需要确信他们能够保护、管理和控制自己的数据，以便有效参与。Foundry 中的数据通过强制性控制进行保护和访问控制，以确保应共享的数据可以被目标组织访问，而不应共享的数据对所有者组织之外的用户保持不可访问。
生态系统模型的关键要素¶
以下列出了所有生态系统模型共有的要素，并在下图中以航空业为例进行说明。
通用本体¶
为了充分受益于互联网络的力量，生态系统中的每个组织必须使用相同的模式——在 Foundry 中称为本体（ontology）——来表示现实世界的实体及其关系。生态系统参与者可以使用行业标准或定义自己的本体。本体在 Foundry 中进行版本控制，以实现增量开发（例如，根据需求一次一个实体），使得单个生态系统参与者的改进和输入可以使所有参与者受益。请注意，使用相同的模式并不要求参与者使用相同的源系统或原始数据格式。
管道模板¶
Foundry 提供了一套数据集成工具，例如 Data Connection 和 Code Repositories，这些工具支持构建管道并将来自各种源系统和格式的数据转换为通用数据模型。这意味着生态系统中的参与者不必使用相同的源系统即可使用通用数据模型。如果输入数据格式或输入系统存在共性，生态系统主办方可以定义一次集成逻辑，并在 Foundry 内与参与者共享。对于 Salesforce 和 SAP 等常见源系统，主办方或用户可以利用 HyperAuto 来加速将输入数据转换为通用本体模式。
应用程序¶
应用程序是一种使用 Foundry 原生工具组合的方式，以创建独特的方法来解决跨生态系统参与者的用例。由于拥有通用本体，生态系统主办方可以提供两种类型的应用程序：
- 汇集参与者数据以增加数据规模，从而实现更好的建模，并将从数据中学到的经验应用于参与者的数据点（例如，基于所有航空公司的飞机数据预测单个飞机的部件故障）。参与者数据池受所有参与者同意的数据和安全配置管理，并且通常是匿名化或聚合的。
- 在参与者的私有数据上部署应用程序（例如，基于单个航空公司数据的航班时刻表改进）。
安全与治理¶
由于多个组织存在于单一平台上，生态系统需要为所有参与者提供最高级别的平台和数据安全。基于这种安全理念设计，Foundry 拥有一系列工具，确保所有生态系统参与者都可以访问的协作空间以及只有单个或部分组织可以访问和协作的私有空间的安全性。这些安全工具包括 enrollments、空间以及强制性控制，例如组织标记和安全标记。
想要了解更多关于此用例模式的信息？希望实施类似方案？开始使用 Palantir。↗