承接上文《业务对象数字化和Palantir Ontology (中)》，本文继续结合华为数字化转型、企业架构（EA）及Palantir 本体论，阐述 EBPM 方法论对业务对象数字化的理解。

Palantir 的本体模型是基于「业务对象」构建的，主要由「对象类型」、「属性」、「关系类型」、「操作类型」四部分构成。在前序文章中，已介绍了「对象类型」、「属性」这两个构成要素。如上图红色箭头所示，在 Palantir 的方法论中特别强调基于业务对象构建的「本体模型」必须能 “取到数”，这个 “必须” 不仅是建模的要求，而且已经内嵌到 Palantir系统的功能界面上了。也就是说，“建模” 与 “取数” 是同步完成的工作。在Palantir 的逻辑中，“取不到数” 的「本体模型」不建也罢！

上图所示是Palantir 中创建一个「业务对象」的功能界面，红色箭头所示的位置就是分配可取到值的「数据源表」的地方。

如上图所示，由于在<元数据>界面上已经分配了本业务对象的数据源表，所以，在创建一个「业务对象」的<属性>页签的界面上，每创建一个属性都“必须”与数据源表中的一个具体数据项绑定，由于数据源表中采集并记录了实例数据，所以在 Palantir 「本体模型」的构建过程中就已经确保能取到数了。

EBPM 方法论认为Palantir 最大的特色是落实了“数据+模型”驱动的理念，真正构建了一个“数字孪生”的「本体模型」。Palantir 在方法论上其实并没有什么大的创新，其最大创新是在应用层面，即把 “数字孪生” 的理念真的落实了，真的干了，还干成了！

01—业务对象的 “关系类型”

本小节继续介绍 ontology 本体模型四大构成要素之“关系类型”。

如上图中红色字体所示，在Palantir 官网上的本体模型 (ontology) 示例中，机场、航班、航空公司、飞机、延误五个业务对象类型 (object type) 相互之间用“动词”构成了以下七组关系类型。

「机场」与 「航空公司」：作为枢纽

「航班」与 「机场」：出发

「航班」与 「机场」：抵达

「航空公司」与 「航班」：运营

「航班」与 「延误」：被延误

「飞机」与 「航班」：执飞

「航空公司」与 「飞机」：拥有

如上图所示，“关系类型”是元模型，而“关系”是实例数据。比如：

关系类型：「航空公司」与「航班」：运营

关系：【航空公司：中国国际航空公司（CA）】运营【航班：CA1501】

总之，由于在「对象类型」之间用“动词”定义了“关系类型”；因此在“实例数据”间也赋予了业务逻辑，而不仅仅是一堆数据。

上图所示是本小节中介绍的机场、航班、航空公司、飞机、延误五个业务对象类型 (object type) 相互之间用“动词”构成的七组关系类型在 Palantir 的业务对象管理器（Ontology Manager）中完成构建后的系统功能界面。可以看到，所谓的 “动词” 是在关系类型的名称中体现的。

在 Palantir 中还有一种描述关联"动词“ 的方案是在属性的名称中加入“动词”，比如 “出发机场” 这个属性名称中包含了动词 “出发” 和业务对象“机场”。这种描述方法对于属性名称的命名提出了很高的要求，也很难适应复杂的场景。比如，有的场景下 “抵达机场” 是指 “备降机场”，最为正确的动词是 “备降” 而非 “抵达”。所以，构建一个新的 "关系类型” 为 “飞机-机场（备降）” 是较为合理的方案，总不能为了这点区别在实例数据库中再构建一张存储实例数据的 ”数据源表“。

02—业务对象的 “操作类型”

本小节继续介绍 ontology 本体模型四大构成要素之“操作类型”。首先需明确，在「对象类型」上定义的「操作类型」是针对「对象实例」而言的，是基于「实例数据」的「操作类型」。

上图所示是 Palantir中针对一个「对象类型」定义「操作类型」的功能界面。在Palantir中的「操作类型」可以分为两大类：

1）一类是 Palantir 系统的内置操作，最常见的是针对「对象实例」增删改查即 CRUD 行为：

Create（创建）：创建该「对象类型」新的对象实例。可指定需要设置的属性，并定义必填项和默认值。

Modify（修改）: 修改已有「对象实例」的属性，可选择允许修改的属性，避免误改关键信息。

Delete（删除）：删除「对象实例」及其所有关联属性，删除操作通常是不可逆的，需严格控制权限，常配合审计日志使用。

Link/Unlink（关联/解除关联）：在两个对象类型之间建立或移除关系，可限制可关联的对象范围和关系基数（一对一、一对多等）。

上图中红色箭头所指的 “权限” 页签中，可以设置哪些用户 / 组可以执行创建、修改、删除和关联操作。

2）第二类是自定义操作类型（Custom Action Types）

除了标准操作，Palantir 还支持通过功能(Functions) 或流程(Workflows) 定义高度定制化的操作，以满足复杂业务逻辑。

那么，什么是功能(Functions) 和流程(Workflows) ？

在上图所示的 《EBPM 企业架构元模型关系图》中，“流程”就是「业务架构」中的「流程」和「活动」两类要素定义的内容；Palantir中的“功能”是指“系统功能”，也就是《EBPM 企业架构元模型关系图》中的「应用组件」和「应用服务」。

Palantir 中的功能 (Functions)或流程 (Workflows) ，通常是通过编写TypeScript/Java 函数或配置低代码工作流来实现的。注意，是手工编写功能或配置工作流，包括回写的功能。比如：

配置业务流程：在业务对象上配置可触发的流程。比如“航班取消流程”、“保险理赔流程”、“数据变更流程”等。

配置批量操作功能：批量增、删、改实例数据的功能，避免手动逐个操作，提升效率，同时保证数据一致性。

调用外部系统：如果不能通过直接在 Palantir 平台上配置功能或流程来完成相关操作，Palantir 平台还支持通过 API 调用各类外部系统的功能或流程。

03—「本体模型」与 「企业架构」的同与不同

1）Ontology 与 EA 模型的相同之处

如上图所示，Palantir 业务对象模型中的「对象类型」、「属性」、「关系类型」与 EBPM 数据架构模型中的「业务对象」、「数据实体」、「实体属性」本质上没有什么大的区别。两者都是先识别和定义企业中的业务对象，然后描述业务对象的属性及关联关系，从逻辑到方法都没什么大的区别，可以认为建模细节上有所区别，但本质上就是一回事。

如上图所示，Palantir 业务对象模型中的「操作类型」与EBPM 业务架构模型中的「流程」、「活动」和应用架构中的「应用组件」、「应用服务」本质上也没有什么大的区别，都是在定义针对此业务对象可以触发的流程以及完成流程活动时可调用的系统组件及服务。从这一点来说，「Ontology 本体模型」 比「数据实体模型」的内涵要广，已经包含了业务架构和应用架构中的内容；但「Ontology 本体模型」又比完整的「企业架构」的内容要少，主要是缺失了业务架构中更为丰富的业务逻辑，比如战略模型、端到端流程、业务能力、管理记录等要素。

有一点需要特别指出，构建「Ontology本体模型」与构建「企业架构模型」目前主要都是由企业架构师人工完成的，AI 大模型与这个过程没有什么关系。而构建完成的 “业务对象数字孪生体” 是喂给 AI 大模型的上下文，即本体模型是 AI智能体的输入。构建完成的 “业务对象数字孪生体” 不仅管理人员、业务人员会看，今后更主要的是给 AI 大模型看。

2）Ontology 与 EA 模型的不同之处

对比「Ontology 本体模型」 与「企业架构模型」，上图红框内所示的「对象实例」部分是企业架构模型所欠缺的。可能有人也会争论，说企业架构模型也包含这部分的内容，但这部分没有被强调更没有被严格实现是肯定。

总之，EBPM 方法论认为「Ontology 本体模型」的最大特色就是在系统功能层面上已经强制要求业务对象元模型必须与实例数据源绑定，所以「Ontology 本体模型」是真正意义上的业务对象的 “数字孪生” 体。

以下这段话来自 Palantir 的官网：

Rather than being an abstract data model, the Ontology maps each ontological concept to an organization's actual data, enabling this data asset to power real-world applications. 本体并非抽象的数据模型，它将每一个本体概念映射到企业的真实数据之上，使这些数据资产能够支撑实际业务应用。

所谓 “映射到企业的真实数据之上”，就是在构建本体模型时直接绑定有实例数据的数据集。所以，”数据映射” 是 Palantir 的最大特色，也是其后续那些让人惊艳的应用效果的关键所在。

04—业务对象的数字化

最后，我们再来回顾一下华为关于《业务对象数字化》的论述：对象数字化的目标是在数字世界中建立物理对象的数字映射。这种映射不是传统意义上基于流程要求的少量数据的映射，而是这个对象的全量、全要素的数据映射，使得对象在数字世界与物理世界中趋于一致。

基于本系列文章的分析，可以发现「企业架构模型」主要侧重于元模型的构建，并没有完整落实 “数据+模型” 的理念；而「Ontology 本体模型」侧不仅有业务对象的「元模型」，而且从系统功能层面上直接绑定了 “实例数据”，有 “模型” 就一定有 “数据”，这两者是同步完成。在此基础上，「Ontology 本体模型」还构建了基于业务对象的 “操作类型”，可以基于取到的数据进行分析和决策，并通过 “操作类型” 执行分析和决策的结果，进而构成了针对业务对象的数字化管理闭环。

至此，我们完整介绍了 EBPM 方法论关于《业务对象数字化》的理解。EBPM 方法论认为 「Ontology 本体模型」是真正实现了业务对象 “数字孪生” 体构建的实践方法，实现了华为提出的业务对象数字化的目标。