【华为数据之道学习笔记】4-3信息架构建设核心要素：基于业务对象进行设计和落地

4.3.1 按业务对象进行架构设计

业务对象是指业务领域中重要的人、事、物对象。业务对象承载了业务运作和管理涉及的重要信息，是信息架构中最重要的管理要素。

业务对象同时还是业务和IT的关键连接点，也是实现IA（信息架构）、BA（业务架构）、AA（应用架构）、TA（技术架构）集成的关键要素。

以一个简化的交易场景为例，要完成一个交易，实现商业价值的兑现，企业内的某个子公司，需要与法人客户签订客户合同，在客户合同中，要明确交易的产品。在这个场景中，子公司、法人客户、客户合同、产品是企业需要管理和控制的核心对象，要作为业务对象进行管理。

在进行信息架构设计时，架构师、业务代表、数据Owner通常会对业务对象的判定存在理解上的偏差，从而产生争议。数据治理部门需要制定一套确定性的规则，通过确定性的规则促进形成稳定的架构。

华为通过以下四条原则来判定业务对象。

原则一：业务对象是指企业运作和管理中不可缺少的重要人、事、物

企业在设计业务对象时，围绕支持企业运作和管理的重要的人、事、物去识别。通常，一个业务对象会有相应的管理流程、管理组织，以及支持运作的IT系统。比如“客户”这个对象，企业通常会建立类似客户管理部这样的组织，会采购或者开发CRM客户管理系统来支撑客户管理，会建立客户信息管理的一系列流程和规范来确保客户信

息的准确、合理、合规。为了避免管理上的冲突，业务对象通常在企业内只能有一个唯一的数据Owner，由数据Owner制定相关的架构、标准和管理规则，用于监控和提升数据质量。

原则二：业务对象有唯一身份标识信息

企业要对业务对象进行管理，需要对所有业务对象的实例进行编码，确保每个对象的实例在企业范围内都有唯一的标识。比如员工，企业需要为每个员工分配一个唯一的工号，如果工号出现重复，则可能引起管理上的混乱，比如工资错发，任务指令接收不到等。又比如产品，企业需要给每一种产品分配精确的分类编号，确保在研发组织

内部、制造工厂、物流运输、销售回款各个部门和阶段，相同的产品使用唯一相同的编号，不同的产品绝不出现相同编号。企业的研发、生产、销售、核算各环节均采用产品的唯一编码进行标识和处理。

原则三：业务对象相对独立并有属性描述

业务对象需要通过大量属性来描述其各个方面的性质和特征，因此属性必定依附于某个业务对象而不可独立存在。比如“名称”是个属性，单纯地记录“名称”这个属性，无任何业务含义，因为“客户”有“名称”属性，“供应商”也有“名称”属性，“员工”也有“名称”属性。业务对象可以独立地存储、传输、使用，业务对象之间可以有关联、依赖关系，但不应有包含或从属关系。

以“销售订单”为例，“销售订单”通常包含两个方面的信息。一方面是销售订单中所销售产品的公共信息，比如归属的订单编号、订单名称、订单总价等，这类信息集中起来形成一个叫“订单头”的逻辑数据实体。另一方面是销售订单中某个产品的个性化信息，一个销售订单通常会销售多种产品，每种产品的价格和数量可能不一样，这些信息需要用另一个逻辑数据实体来记录，并用一个“订单编码”属性来表示这些明细的销售产品归属于该销售订单里，同时不同产品按不同“订单行号”展示。而“订单行号”是无法独立存在的，企业能够确保所有“订单编码”不会重复，但无法确保所有“订单行号”不会重复，并且这也没有必要，因为任何订单行都是隶属于某个订单的。因此从这个例子可以看出，订单行是无法作为一个独立的业务对象而存在的，必须归属于“销售订单”这个业务对象。

原则四：业务对象可实例化

在现实世界中，业务对象有大量的实例存在，并可感知、可获取。以员工为例，就算是规模很小的企业，通常至少会有经理、业务员、会计等不同岗位的人员，每个员工的信息都可以视为一个实例；而“员工入职类型”是对员工入职信息的一种分类，其本身是无法实例化的，因此“员工入职类型”这一基础数据应从属于员工业务对象

下，而不能独立存在，员工业务对象Owner也应该同时负责“员工入职类型”数据的生命周期管理。

4.3.2 按业务对象进行架构落地

信息架构向IT侧落地的主要交付件是数据模型。数据模型本身有相对比较成熟的方法体系支撑，不同企业之间可能名称存在差异，但本质差别不大。华为公司将数据模型分为三层： 概念数据模型、逻辑 数据模型、物理数据模型。

概念数据模型是通过业务对象及业务对象之间的关系，从宏观角度分析和设计的企业核心数据结构。
逻辑数据模型是利用逻辑数据实体及实体之间的关系，准确描述业务规则的逻辑实体关系。
物理数据模型是按照一定规则和方法，将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关系等内容，如实转换为数据库软件能识别的物理数据实体关系。

为了确保架构在落地过程中“不走形”，要控制好两个关键点：

一个是概念模型与逻辑模型的一致性，主要通过逻辑数据实体的设计管理来实现；
另一个是逻辑模型与物理模型的一致性，主要通过一体化建模管理来实现。

1. 逻辑数据实体设计

逻辑数据实体本质上是对描述业务对象的众多属性的归类，业务对象无法直接指导IT系统的物理实现，也无法基于业务对象来审视物理设计是否满足业务需求，因此需要通过逻辑数据实体及相应的逻辑数据模型来指导IT系统层面的数据设计。在设计逻辑数据实体时，可参考如下几条主要规则。

1）逻辑数据实体不能脱离业务对象独立存在，因此某个逻辑数据实体一定是用来描述一个特定的业务对象的，业务对象与逻辑数据实体的关系是一对一或一对多，不允许多对一的情况出现。

2）描述业务对象不同业务特征的密切相关的一组属性集合，可以设计为一个逻辑数据实体。

3）逻辑数据实体设计要遵循第三范式。在设计一个业务对象的逻辑数据实体时，每个逻辑数据实体的属性不要重复定义，不应包含其他逻辑数据实体中的非关键字类型的属性。

4）提供数据服务或跨业务领域使用的基础数据，要单独设计逻辑数据实体。描述业务对象的若干属性，如果能够组合起来形成独特价值的数据服务，满足下游的数据消费需求，可以设计成一个逻辑数据实体。

5）两个业务对象间的关系也可以设计成关系型逻辑数据实体，在数据资产目录中，可按业务发生的时间先后顺序，归属于后出现的业务对象。

2. 一体化建模管理

华为公司过去长期存在信息架构与IT开发实施“两张皮”的现象，数据人员和IT开发实施人员缺乏统一和协同，数据架构遵从无法进行实质、有效管理，信息架构资产和产品实现的物理表割裂、不匹配，同时各种数据模型资产缺失。

针对应用系统设计应遵从信息架构设计的政策要求，在相关项目、产品的流程中，缺乏显性化的且有实操指导的角色和活动。信息架构设计大多集中在变革项目层的设计输出和领域层的例行刷新，未与系统落地有效拉通。IT产品聚焦在版本交付，产品级的数据模型与数据字典缺少有效看护和及时维护。

为了解决这个问题，华为推行了一体化模型设计（如图所示），不仅在工具上实现了一体化设计和开发，而且在机制上形成了信息架构设计与IT开发实施的有效协同。通过一体化设计不仅确保了元数据验证、发布和注册的一致性，而且实现了产品数据模型管理和资产可视。同时，由于促成了产品元数据的持续运营，进而能够持续对物理模型进行规范，如整改、清理各类作废表等。