承接上文 《TOGAF、华为及EBPM对于业务对象的理解》，本文专题讨论一下 “业务架构” 中的 “业务对象” 和 “数据架构” 中的 “业务对象” 是如何对应的。
先重复一下上文中的结论：
1） “业务对象” 是企业不可缺少的重要的人、事、物，承载了业务运作和管理决策涉及的重要信息。
2）“业务对象” 来源于 “业务架构”，在 “业务架构” 中以 “管理记录” 也就是 “业务信息（信息载体）” 的形式得到有形化的体现。
3）由于 “业务对象” 是连接 “业务架构”、“数据架构” 的关键要素，因此在 “数据架构” 中也存在。
4） “数据架构” 中的 “业务对象” 与 “业务架构” 中的 “业务对象” 是一回事，所以应保持一致。
总之，“业务对象” 隐身在 “能力架构”中，并通过 “管理记录” 或者说 “业务信息（信息载体）” 得到显性化的呈现。
01
—
“业务对象” 在 BA 和 DA 中涉及的管理要素
在上图所示的 10 版本的《TOGAF 企业架构内容元模型图》中 “业务对象” 在 “业务架构BA” 和 “数据架构DA” 中主要涉及三类管理要素，即：
- 业务能力（包含了业务对象）
- 业务信息
- 数据实体
在 TOGAF 中，“业务能力” 包含了 “业务对象”；而 “业务信息” 是 “业务对象” 的有形化呈现；“数据实体” 直接对接 “业务信息”，也就是间接对接了 “业务对象”。
在上图所示的《TOGAF 企业架构内容元模型图》中将 “业务能力”、“业务信息” 和 “数据实体” 三类要素元模型的关系用粗红线标识出来，可以更为清晰地看出这三者之间的关系，主要是以下两组关系：
- “业务能力（业务对象）” 使用 “业务信息”；“业务信息” 被 “业务能力（业务对象）” 使用。
- “数据实体” 实现 “业务信息”；“业务信息” 被 “数据实体” 影响。
总之，就 TOGAF 而言，无论是在 “业务架构” 还是在 “数据架构” 中 ，“业务对象” 都没有作为独立的管理要素直接显性化在架构模型中。
在上图所示的《EBPM 企业架构元模型关系图》中 “业务对象” 作为一个独立的要素在 “数据架构” 中得到了呈现。这是华为等大量企业在构建 “数据架构” 中的常见做法。
为什么要这么做呢？原因很简单：否则太不直观啊！
通过 “数据实体” 找到 “管理记录（业务信息/信息载体）”；然后再找到 “业务能力”；然后再从 “业务能力” 中解析出 “业务对象”。这是一条逻辑链路，不是一个直观的可视化呈现。比如，通过《客户类别分析报告》这个 “管理记录（业务信息/信息载体）” 找到对应的 “业务能力”《客户类别管理》；然后解析出 “业务对象”《客户类别》。这是需要靠人的思考来实现的。特别是最后一步，从 “业务能力” 中解析出 “业务对象” 完全凭借人的解读。总之，太不直观！
数据治理本质上是为业务管理服务的，“数据实体” 究竟在记录、描述和分析哪些 “业务对象” 是数据治理首先要搞清楚的基本信息。因此，为了直观地表现这个逻辑关系，在企业架构建模实践中，华为等企业都直接将 “业务对象” 在 “数据架构” 中显性化出来了，以便于后续数据治理工作的展开。
综上，在企业架构建模实践中，由于 “业务架构” 中的 “能力架构 ” 已经包含了 “业务对象”，所以不再单独显性化 “业务对象” 这个要素。但是，在 “数据架构” 中为了直观显示 “数据实体” 与 “业务对象” 的关系，所以会单独显性化 “业务对象” 这个要素。
02
—
数据架构中的 “业务对象“
下面讨论一下如何在 “数据架构” 中显性化 “业务对象”。
如上图所示，最简单直接的方式就是将 “业务架构” 中的 “业务对象” 照搬到 “数据架构” 中。
但问题没有那么简单。在 “业务架构” 中 “业务对象” 架构并不是显性化存在的，是内含在 “能力架构” 中的。所以，不存在照搬的可能性。
那么，将 “能力架构” 照搬到 “数据架构” 中作为 “业务对象” 可不可以呢？逻辑上可以，但业务能力的名称是由 “业务对象+动词” 构成的，因此还需要从 “业务能力” 的名称中剥离出 “业务对象” 的名称。总之，也不能直接照搬。
如上图所示，EBPM 方法论认为最佳的方案是将 “管理记录（业务信息）” 严格按 “业务对象” 进行命名和分类，然后将 “管理记录（业务信息）架构” 照搬到 “数据架构” 中作为 “业务对象”。
这种方案有两个关键前提：
1）全面梳理并构建 “管理记录（业务信息）” 架构。
2）“管理记录（业务信息）” 架构与 “业务能力” 架构完全对应，但是将 “业务能力架构” 名称中的 “动词” 去掉，提炼出 “业务对象” 的名称作为各级 “管理记录（业务信息）” 的名称。
事实上，现在很多企业往往就是先收集管理记录（表、证、单、书、系统界面），然后再从这些管理记录中来提炼 “业务对象” 并进一步构建 “数据架构” 的。
这里还衍生出一个新的问题，就是很多人会将 “管理记录” 和“业务对象” 等同起来，认为是一回事。比如，认为《客户类别分析报告》是一个 “业务对象”。这是一种错误的认知，《客户类别分析报告》中的《客户类别》才是“业务对象”；而《客户类别分析报告》只是《客户类别》这个 “业务对象” 的有形化呈现。同时，《客户类别定义报告》是《客户类别》这个“业务对象” 另一个有形化呈现。总之，对于一个 “业务对象”，通常会有1个或多个管理记录进行有形化呈现。
EBPM 方法论推荐的最佳方案固然是好的。但 “理想很丰满，现实很骨感”。这个方案是以企业梳理并构建了完整的 “管理记录（业务信息）架构” 和 “业务能力架构” 为前提条件的。但是，如上图所示，很多企业往往是在没有这两个架构的前提下构建 “数据架构” 的。
比如，很多情况下， “数据架构” 是通过数据治理项目来构建的，与 “业务架构” 项目并不直接发生关系或者根本没有 “业务架构” 的项目。因此，根本不存在照搬 “管理记录（业务信息）” 的可能性。
如上图所示，在没有 “能力架构” 和 “管理记录（业务信息）” 架构的前提下通过数据治理项目构建 “数据架构” 时，“业务对象” 是如何产生呢？这就只能通过项目组去收集企业常用的管理记录（表、证、单、书、系统界面）和关键绩效（本质上也是存在于管理记录中的），然后人为提炼的 “业务对象” 了。而在提炼 “业务对象” 时，由于没有一套严谨和自洽的架构逻辑，所以往往偏粗或者颗粒度粗细不一。上图所示就是常见的 “业务对象” 提炼结果。
总结一下本文的观点。
1）“数据架构” 和 “业务架构” 应该打通，而不是各做各的。
2）“数据架构” 和 “业务架构” 打通的连接点有两个：一是采用一致的 “业务对象” ；二是 “数据实体” 与 “管理记录（业务信息）” 进行关联。
3）在 “业务架构” 构建了 “能力架构” 和 “管理记录（业务信息）架构” 的前提下，照搬 “管理记录 (业务信息)架构” 作为 “数据架构” 中的 “业务对象” 是 EBPM 方法论推荐的最简洁的建模方案。
文章来源：流程管理道可道微信公众号