跳转至

Governance processes（治理流程）

As you build and grow your Foundry Program team, we recommend implementing governance processes to manage and guide your organization's efforts. To assist you in creating governance processes, this page provides examples of strategic planning and governance checkpoints that can be adapted for your own use. These planning, review, and development stages can help prepare your team for the various responsibilties and activities involved in successful maintenance, use, and deployment of the Foundry platform within your organization.

:::callout{theme="neutral"} Note that the processes described on this page are suggestions and not requirements. We provide these as an example of one way in which you can structure governance processes, but your organization's needs will likely require customization of the processes described here. :::

Foundry Program planning

SteerCo meetings: Vision setting

  • Phase: 1+
  • Frequency: Quarterly
  • Owner: Head of Program
  • Attendees/Stakeholders: Program Manager, Executives/Senior Stakeholders, Domain Leads

Steering committee (SteerCo) meetings are regular meetings that are central to the high-level direction of the Foundry Program. The primary purpose of a SteerCo meeting should be to evaluate the strategic direction, scope, and cost of the Foundry platform as a whole. It is common for specific high-priority projects to be discussed during a SteerCo, but they should not be the sole focus of the meeting.

A sample agenda for a SteerCo meeting might include:

  • Review of live, in-development, and prospective use cases, along with the associated costs, development progress, and value to the organization.
  • Overview of changes to the user base (for example, the growth/decline in number of users or usage by group/use case).
  • Review/discuss the Foundry platform within the context of the organization's broader IT landscape and goals.

Development and roadmap review

  • Phase: 1+
  • Frequency: Monthly
  • Owner: Program Manager
  • Attendees/Stakeholders: Head of Program, Domain Leads

Development and roadmap reviews are meant to review the past month's progress and align on deliverables for the coming month and longer-term roadmap. This session is a forum for reviewing the progress of ongoing development initiatives, discussing opportunities for enhancements to existing use cases, and identifying and prioritizing opportunities for new use cases.

A sample agenda for each session might include:

  • Progress updates for ongoing development.
  • Assessment of business cases to determine and confirm use case value.
  • Assess and approve changes to project plans.
  • Making decisions based on the priority of deliverables/development.
  • Review and approve use case development strategy.
  • Review and suggest solutions for the issues critical to project success.

Active use case development

Standup

  • Phase: 1+
  • Frequency: Daily
  • Owner: Data Lead(s)
  • Attendees/Stakeholders: Ontology Lead(s), Use Case Lead, Data Governance Administrator (as needed)

Standup is a short (<30 min) daily call during which each member of a use case team provides a progress update.

Standup updates are typically limited to:

  • What was worked on during the previous day.
  • What will be worked on during the current day.
  • Review of any blockers preventing progress.

Sprint planning

  • Phase: 1+
  • Frequency: Bi-weekly
  • Owner: Data Lead(s)
  • Attendees/Stakeholders: Ontology Lead(s), Use Case Lead, Data Governance Administrator (as needed)

During sprint planning meetings, attendees review what was and was not completed from the previous sprint and decide what will be worked on in the upcoming sprint.

An example agenda includes:

  • Review of team deliverables/objectives.
  • Discussion of current blockers and changes in development priority.
  • Confirmation of team capacity for the upcoming sprint.
  • Confirm deliverable requirements and make any appropriate updates.
  • Assign size estimates, determine the sprint's contents, and assign work.

Platform governance

Project creation review

  • Phase: 1+
  • Frequency: Monthly
  • Owner: Head of Program (Phase 1), Head of Data Governance (Phase 2+)
  • Attendees/Stakeholders: Program Manager

New projects are suggested by users across the organization by submitting a creation request through a Project Creation Request Portal built by the program team. Those requests are then reviewed and either approved or denied from a Project Approval Inbox application, also built by the program team.

If a request is approved, the requested project is created, controlling for role assignment and group access in accordance to the details of the request. Project creation permissions for each Foundry space should be restricted to the central Platform Governance team; the roles that fill this team will evolve over time as platform governance grows more specific throughout the phases of development.

Project access review

  • Phase: 1+
  • Frequency: Ongoing
  • Owner: Head of Program (Phase 1), Head of Data Governance (Phase 2+)
  • Attendees/Stakeholders: Program Manager

Project roles should be controlled such that only designated groups hold specific roles on projects. We recommend ensuring that groups are tied directly to the organization's identity provider (IdP) groups.

Access requests are reviewed and either approved or denied the request from the Project Approval Inbox. Upon request approval, the requestor's account is added to the group(s) with the appropriate role on the Project.

Depending on where groups are managed, this will require either adding the requestor's network account to the IdP group, or adding their Foundry account to the Foundry-specific group. We recommend that individual users are not granted roles directly on a Project.

Data permission administration review

  • Phase: 1+
  • Frequency: Ongoing
  • Owner: Head of Program (Phase 1), Head of Data Governance (Phase 2+)
  • Attendees/Stakeholders: Use Case Lead

Data permission administration in Foundry takes several forms, from controlling blanket access to datasets or entire pipelines, to controlling visibility of records within a dataset.

Data permission administration requirements for a particular use case should be scoped out as a part of the Project Creation Review process. Documenting and applying the appropriate data permissions takes place during Project development.

User enablement

Support team development

  • Phase: 1+
  • Frequency: Ongoing
  • Owner: Data Lead, Program Manager
  • Attendees/Stakeholders: Domain Leads, Data Governance Administrator, Use Case Lead

We recommend the creation of an internal support structure to assist with user issue triage, investigation, and resolution. This structure can be significantly impactful in retaining autonomy within your organization and in ensuring any issues that require Palantir involvement will have the required level of detail provided before escalation.

  • Phase 1/2: Support may be handled by the Foundry Program team
  • Phase 2+: We recommend establishing a dedicated internal Foundry Support team

Training development

  • Phase: 2+
  • Frequency: Ongoing
  • Owner: Education & Training Expert
  • Attendees/Stakeholders: Domain Lead(s), Use Case Lead

Palantir offers centralized training resources, but we recommend that Foundry Program teams also develop an internal training curriculum specific to each of the organization's use cases.

This includes developing and maintaining the documentation for each use case's data lineage and ontology components, as well as tutorials for how users should engage with core applications. Training mediums can include in-platform and external documentation (for example, interface tutorials and documentation), as well as recorded and in-person training/tutorials.

中文翻译

治理流程

在构建和发展您的 Foundry 项目团队时，我们建议实施治理流程来管理和指导组织的各项工作。为帮助您创建治理流程，本页面提供了战略规划和治理检查点的示例，您可以根据自身需求进行调整。这些规划、审查和开发阶段有助于您的团队为成功维护、使用和部署 Foundry 平台所涉及的各项职责和活动做好准备。

:::callout{theme="neutral"} 请注意，本页面描述的流程仅为建议，并非强制要求。我们将其作为构建治理流程的一种示例提供，但您的组织可能需要根据实际需求对这些流程进行定制。 :::

Foundry 项目规划

SteerCo 会议：愿景设定

  • 阶段： 1+
  • 频率： 每季度
  • 负责人： 项目主管
  • 参会者/利益相关方： 项目经理、高管/高级利益相关方、领域负责人

指导委员会会议是定期举行的会议，对 Foundry 项目的宏观方向至关重要。SteerCo 会议的主要目的应是评估整个 Foundry 平台的战略方向、范围和成本。在 SteerCo 会议上讨论特定的高优先级项目很常见，但这不应成为会议的唯一焦点。

SteerCo 会议的示例议程可能包括：

  • 审查已上线、正在开发和待开发的用例，以及相关成本、开发进度和对组织的价值。
  • 概述用户群的变化（例如，用户数量的增长/下降，或按群组/用例划分的使用情况）。
  • 在组织更广泛的 IT 格局和目标背景下，审查/讨论 Foundry 平台。

开发与路线图审查

  • 阶段： 1+
  • 频率： 每月
  • 负责人： 项目经理
  • 参会者/利益相关方： 项目主管、领域负责人

开发与路线图审查旨在回顾过去一个月的进展，并就未来一个月及更长期路线图的交付成果达成一致。该会议是一个讨论平台，用于审查正在进行的开发计划的进展，讨论现有用例的改进机会，以及识别和优先安排新用例的机会。

每次会议的示例议程可能包括：

  • 正在进行的开发的进度更新。
  • 评估业务案例以确定和确认用例价值。
  • 评估并批准项目计划的变更。
  • 根据交付成果/开发的优先级做出决策。
  • 审查并批准用例开发策略。
  • 审查并对项目成功至关重要的关键问题提出解决方案。

活跃用例开发

每日站会

  • 阶段： 1+
  • 频率： 每日
  • 负责人： 数据负责人
  • 参会者/利益相关方： 本体负责人、用例负责人、数据治理管理员（根据需要）

每日站会是一个简短的（<30 分钟）每日电话会议，用例团队的每位成员在会上提供进度更新。

站会更新通常限于：

  • 前一天完成的工作。
  • 当天计划完成的工作。
  • 审查阻碍进展的任何障碍。

冲刺规划

  • 阶段： 1+
  • 频率： 每两周
  • 负责人： 数据负责人
  • 参会者/利益相关方： 本体负责人、用例负责人、数据治理管理员（根据需要）

在冲刺规划会议期间，参会者审查上一个冲刺中已完成和未完成的工作，并决定在即将到来的冲刺中要完成的工作。

示例议程包括：

  • 审查团队交付成果/目标。
  • 讨论当前的障碍和开发优先级的变更。
  • 确认团队在即将到来的冲刺中的容量。
  • 确认交付成果要求并进行适当的更新。
  • 分配规模估算，确定冲刺内容，并分配工作。

平台治理

项目创建审查

  • 阶段： 1+
  • 频率： 每月
  • 负责人： 项目主管（阶段 1），数据治理主管（阶段 2+）
  • 参会者/利益相关方： 项目经理

组织中的用户通过项目团队构建的项目创建请求门户提交创建请求，从而提出新项目建议。这些请求随后在同样由项目团队构建的项目审批收件箱应用程序中进行审查，并予以批准或拒绝。

如果请求获得批准，则会创建所请求的项目，并根据请求的详细信息控制角色分配和群组访问权限。每个 Foundry 空间的项目创建权限应仅限于中央平台治理团队；随着平台治理在开发的各个阶段变得更加具体，组成该团队的角色将随着时间的推移而演变。

项目访问审查

  • 阶段： 1+
  • 频率： 持续进行
  • 负责人： 项目主管（阶段 1），数据治理主管（阶段 2+）
  • 参会者/利益相关方： 项目经理

应控制项目角色，使得只有指定的群组在项目中拥有特定角色。我们建议确保群组直接与组织的身份提供者群组关联。

访问请求在项目审批收件箱中进行审查，并予以批准或拒绝。 请求批准后，请求者的帐户将被添加到在项目中具有适当角色的群组中。

根据群组的管理位置，这需要将请求者的网络帐户添加到 IdP 群组，或者将其 Foundry 帐户添加到特定于 Foundry 的群组。我们建议不要直接授予个人用户在项目上的角色。

数据权限管理审查

  • 阶段： 1+
  • 频率： 持续进行
  • 负责人： 项目主管（阶段 1），数据治理主管（阶段 2+）
  • 参会者/利益相关方： 用例负责人

Foundry 中的数据权限管理有多种形式，从控制对数据集或整个管道的全面访问，到控制数据集中记录的可见性。

特定用例的数据权限管理要求应在项目创建审查过程中确定范围。记录和应用适当的数据权限在项目开发期间进行。

用户赋能

支持团队建设

  • 阶段： 1+
  • 频率： 持续进行
  • 负责人： 数据负责人、项目经理
  • 参会者/利益相关方： 领域负责人、数据治理管理员、用例负责人

我们建议建立一个内部支持结构，以协助用户问题的分类、调查和解决。该结构对于在组织内保持自主性，以及确保任何需要 Palantir 参与的问题在升级前都提供所需的详细信息，具有显著影响。

  • 阶段 1/2： 支持工作可由 Foundry 项目团队处理
  • 阶段 2+： 我们建议建立一个专门的内部 Foundry 支持团队

培训开发

  • 阶段： 2+
  • 频率： 持续进行
  • 负责人： 教育与培训专家
  • 参会者/利益相关方： 领域负责人、用例负责人

Palantir 提供集中式培训资源，但我们建议 Foundry 项目团队也针对组织的每个用例开发内部培训课程。

这包括为每个用例的数据沿袭和本体组件编写和维护文档，以及关于用户应如何与核心应用程序交互的教程。培训媒介可以包括平台内和外部文档（例如，界面教程和文档），以及录播和现场培训/教程。