注：微信公众号不按照时间排序，请关注“亨利笔记”，并加星标以置顶，以免错过更新。
新书消息：
我们云原生实验室从事着联邦学习的 FATE / KubeFATE 等开源项目的研发，联邦学习解决的是机器学习中企业数据联合使用的问题，因此我们也很关注各类数据管理框架和技术。
《华为数据之道》对企业管理和使用数据做了系统的总结，其中有不少的原理值得借鉴。在征得出版社许可后，摘录部分章节分享给大家，本文为摘录的第3篇，感兴趣的读者可以点击图片购买图书作参考。
华为的数字化转型已经成为行业公认的标杆，最近的畅销书《华为数据之道》对华为的数字化转型方法和经验进行了系统性地披露。企业的数字化转型，最重要的是数据治理，其次是信息架构的建设，本文将通过《华为数据之道》这本书的内容来详细看一看华为的信息架构的组件、原则和核心要素，相信对其他企业搭建信息架构时会有帮助。
华为过去的信息架构建设主要是为了实现“信息化”或“业务上 ERP ”，信息架构往往隐藏在系统中、隐藏在 IT 功能下。对 于大部分业务作业人员和管理者而言，他们的关注点更多聚焦在 “功能是否完善”或“业务是在系统中完成还是手工完成”上。此时，对信息架构的要求仅限于支撑好各类 IT 系统的落地，或在一定范围内对 IT 建设提供指导。
随着企业数字化转型的推进，华为公司越来越认识到信息架构的价值并不应局限于“支撑 IT 建设落地”，而是更好地管理企业数据资产，更好地提升整个业务交易链条的效率，甚至基于信息架构重新审视业务边界的划分和整合。（本文来自公众号：亨利笔记 ）
信息架构的4个组件
企业在运作过程中，首先需要管理好人和物等“资源”，然后管理好各类资源之间的联系，即各类业务交易“事件”，再对各类事件的执行效果进行“整体描述和评估”，最终实现组织目标和价值。（本文来自公众号：亨利笔记 ）
华为在实践中构建了一套对业务运作数据进行有效管理的信息架构方法论，用于指导企业内部各部门的信息架构建设工作， 让管理者、专家和员工之间有共同语言。
华为的企业级信息架构（Information Architecture）是指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范，包括数据资产目录、数据标准、企业级数据模型和数据分布四个组件，如图1 所示。
图1 华为企业级信息架构的四个组件
信息架构的5个原则
信息架构承载了企业如何管理数据资产的方法，需要从整个企业层面制订统一的原则，这些原则不仅是对数据专业人员的要求，也是对业务的要求，因为业务才是真正的数据 Owner。所以，公司所有业务部门都应该共同遵从信息架构原则。
华为首先确定了“数据同源一致”的治理目标，围绕目标的实现，制定了五条架构原则。各业务领域和变革项目应按照架构原则设计其信息架构，并由 EAC（企业架构委员会）、IA-SAG（信息架构专家组）指导和监督各领域落实企业架构原则，在一套规则的约束下，共同建设一个企业级的信息架构。
原则一：数据按对象管理，明确数据 Owner
数据要发挥作用，必然会在多个 IT 系统和流程中流转，并且越是重要的数据资产，所流经的业务环节就越多。例如，产品、人员、客户的数据几乎在所有流程中都会涉及，客户合同数据也会在整个业务交易链条中流转，因此不应该以 IT 系统、业务流程边界来管理数据，而应该从数据本身出发，按对象进行数据全生命周期管理。（本文来自公众号：亨利笔记 ）
几乎所有的企业数据都是由业务产生的，IT 人员无法对数据的定义、质量负责，因此需要在公司层面确定数据 Owner。华为公司按照业务对象任命数据 Owner，并且每个数据都只能有唯一的数据 Owner。数据 Owner 要负责所辖领域的信息架构建设和维护，负责保障所辖领域的数据质量，承接公司各个部门对本领域数据的需求，并有责任建立数据问题回溯和奖惩机制，对所辖领域的数据问题及争议进行裁决，公司有权对不遵从信息架构或存在严重数据质量问题的责任人进行问责。
原则二：从企业视角定义信息架构
任何一个数据 Owner 都不只代表自己所辖业务范围的数据管理诉求，而是代表公司对数据进行管理。华为在数据治理实践中，为了拉通各部门所产生的数据结构和流转路径，实现数据在企业内共享和流通的目标，明确要求各业务领域都需站在企业的视角定义信息架构，充分考虑数据的应用场景、范围和用户群体，参考业界实践和主流软件包，平衡和兼顾 AS-IS（现状）和TO-BE（未来）诉求，在流程设计和 IT 实现中得到落实。（本文来自公众号：亨利笔记 ）
以前面的合同编号为例，销售部门作为数据 Owner 有责任定义合同信息架构，但不应只考虑销售环节对合同编号的管理诉求，而是应该综合考虑供应、交付、财经等各个环节对合同的诉求，合同在整个交易链条中延伸的范围就是相应数据 Owner 所综合覆盖的范围。在这个链条中，任何业务部门对合同编号的诉求，都可以提交给数据 Owner ；同时，合同数据 Owner 对所辖数据在整个企业范围内的架构的合理性和一致性负责，如果某个业务环节私自定义了合同信息架构，那么数据 Owner 有责任对该架构进行统一和整改。
原则三：遵从公司的数据分类管理框架
为了协同企业内各业务领域的数据治理，华为在实践中总结了各类数据的内在特性，制定了统一的数据分类管理框架，公司所有业务领域按照统一的分类框架进行数据治理。
原则四：业务对象结构化、数字化
华为在长期的数据治理过程中，制定了业务对象结构化、数字化的架构设计原则，实现数据处理效率的提升，构建数据的处理和应用能力，支撑业务管理。
业务对象内容包括业务结果、业务规则、业务过程，并应打造相应的数字化能力。（本文来自公众号：亨利笔记 ）
原则五：数据服务化，同源共享
随着企业业务规模的不断扩大，往往会随之产生大量的 IT 系统，这样很容易出现数据多源头的情况，导致数据不可信、不可管。为了有效地避免这些问题，华为制定了数据同源共享的架构原则，每一个数据有且只有单一数据源，数据使用方应从数据源获取数据，数据更改应在数据源进行。为了克服企业业务和 IT 的复杂性这一客观现实，华为公司持续推进数据服务建设，要求各数据 Owner 通过数据服务向各业务环节提供数据，各业务环节也有责任通过服务来合理获取数据，从而在整个企业层面实现数据的“一点定义、全局共享”。
信息架构建设核心要素：基于业务对象进行设计和落地
1.按业务对象进行架构设计
业务对象是指业务领域中重要的人、事、物对象。业务对象承载了业务运作和管理涉及的重要信息，是信息架构中最重要的管理要素。（本文来自公众号：亨利笔记 ）
业务对象同时还是业务和 IT 的关键连接点，也是实现 IA（信息架构）、BA（业务架构）、AA（应用架构）、TA（技术架构） 集成的关键要素。
以一个简化的交易场景为例（如图2所示），要完成一个交易，实现商业价值的兑现，企业内的某个子公司，需要与法人客户签订客户合同，在客户合同中，要明确交易的产品。在这个场景中，子公司、法人客户、客户合同、产品是企业需要管理和控制的核心对象，要作为业务对象进行管理。
݄
图2 业务对象和属性示例
在进行信息架构设计时，架构师、业务代表、数据 Owner 通常会对业务对象的判定存在理解上的偏差，从而产生争议。数据治理部门需要制定一套确定性的规则，通过确定性的规则促进形成稳定的架构。华为通过以下四条原则来判定业务对象。
原则一：业务对象是指企业运作和管理中不可缺少的重要人、事、物
企业在设计业务对象时，围绕支持企业运作和管理的重要的人、事、物去识别。通常，一个业务对象会有相应的管理流程、管理组织，以及支持运作的 IT 系统。比如“客户”这个对象，企业通常会建立类似客户管理部这样的组织，会采购或者开发 CRM 客户管理系统来支撑客户管理，会建立客户信息管理的一系列流程和规范来确保客户信息的准确、合理、合规。为了避免管理上的冲突，业务对象通常在企业内只能有一个唯一的数据Owner，由数据 Owner 制定相关的架构、标准和管理规则，用于监控和提升数据质量。
原则二：业务对象有唯一身份标识信息
企业要对业务对象进行管理，需要对所有业务对象的实例进行编码，确保每个对象的实例在企业范围内都有唯一的标识。比如员工，企业需要为每个员工分配一个唯一的工号，如果工号出现重复，则可能引起管理上的混乱，比如工资错发，任务指令接收不到等。又比如产品，企业需要给每一种产品分配精确的分类编号，确保在研发组织内部、制造工厂、物流运输、销售回款各个部门和阶段，相同的产品使用唯一相同的编号，不同的产品绝不出现相同编号。企业的研发、生产、销售、核算各环节均采用产品的唯一编码进行标识和处理。
原则三：业务对象相对独立并有属性描述
业务对象需要通过大量属性来描述其各个方面的性质和特征， 因此属性必定依附于某个业务对象而不可独立存在。比如“名称” 是个属性，单纯地记录“名称”这个属性，无任何业务含义，因为“客户”有“名称”属性，“供应商”也有“名称”属性，“员工”也有“名称”属性。业务对象可以独立地存储、传输、使用， 业务对象之间可以有关联、依赖关系，但不应有包含或从属关系。（本文来自公众号：亨利笔记 ）
以“销售订单”为例，“销售订单”通常包含两个方面的信息。一方面是销售订单中所销售产品的公共信息，比如归属的订单编号、订单名称、订单总价等，这类信息集中起来形成一个叫“订单头”的逻辑数据实体。另一方面是销售订单中某个产品的个性化信息，一个销售订单通常会销售多种产品，每种产品的价格和数量可能不一样，这些信息需要用另一个逻辑数据实体来记录，并用一个“订单编码”属性来表示这些明细的销售产品归属于该销售订单里，同时不同产品按不同“订单行号”展示。而“订单行号”是无法独立存在的，企业能够确保所有“订单编码”不会重复，但无法确保所有“订单行号”不会重复，并且这也没有必要，因为任何订单行都是隶属于某个订单的。因此从这个例子可以看出，订单行是无法作为一个独立的业务对象而存在的，必须归属于“销售订单”这个业务对象。（本文来自公众号：亨利笔记 ）
原则四：业务对象可实例化
在现实世界中，业务对象有大量的实例存在，并可感知、可获取。以员工为例，就算是规模很小的企业，通常至少会有经理、业务员、会计等不同岗位的人员，每个员工的信息都可以视为一个实例；而“员工入职类型”是对员工入职信息的一种分类，其本身是无法实例化的，因此“员工入职类型”这一基础数据应从属于员工业务对象下，而不能独立存在，员工业务对象Owner 也应该同时负责“员工入职类型”数据的生命周期管理。
图3 业务对象示例：销售订单
2.按业务对象进行架构落地
信息架构向 IT 侧落地的主要交付件是数据模型。数据模型本身有相对比较成熟的方法体系支撑，不同企业之间可能名称存在差异，但本质差别不大。华为公司将数据模型分为三层：概念数据模型、逻辑数据模型、物理数据模型，如图4所示。
图4 数据模型分层框架
概念数据模型是通过业务对象及业务对象之间的关系，从宏观角度分析和设计的企业核心数据结构。逻辑数据模型是利用逻辑数据实体及实体之间的关系，准确描述业务规则的逻辑实体关系。物理数据模型是按照一定规则和方法，将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关系等内容，如实转换为数据库软件能识别的物理数据实体关系。
为了确保架构在落地过程中“不走形”，要控制好两个关键点：一个是概念模型与逻辑模型的一致性，主要通过逻辑数据实体的设计管理来实现；另一个是逻辑模型与物理模型的一致性， 主要通过一体化建模管理来实现。
（1）逻辑数据实体设计
逻辑数据实体本质上是对描述业务对象的众多属性的归类， 业务对象无法直接指导 IT 系统的物理实现，也无法基于业务对象来审视物理设计是否满足业务需求，因此需要通过逻辑数据实体及相应的逻辑数据模型来指导 IT 系统层面的数据设计。在设计逻辑数据实体时，可参考如下几条主要规则。
1）逻辑数据实体不能脱离业务对象独立存在，因此某个逻辑数据实体一定是用来描述一个特定的业务对象的，业务对象与逻辑数据实体的关系是一对一或一对多，不允许多对一的情况出现。
2）描述业务对象不同业务特征的密切相关的一组属性集合， 可以设计为一个逻辑数据实体。（本文来自公众号：亨利笔记 ）
3）逻辑数据实体设计要遵循第三范式。在设计一个业务对象的逻辑数据实体时，每个逻辑数据实体的属性不要重复定义， 不应包含其他逻辑数据实体中的非关键字类型的属性。
4）提供数据服务或跨业务领域使用的基础数据，要单独设计逻辑数据实体。描述业务对象的若干属性，如果能够组合起来形成独特价值的数据服务，满足下游的数据消费需求，可以设计成一个逻辑数据实体。
5）两个业务对象间的关系也可以设计成关系型逻辑数据实体，在数据资产目录中，可按业务发生的时间先后顺序，归属于后出现的业务对象。
（2）一体化建模管理
华为公司过去长期存在信息架构与 IT 开发实施“两张皮” 的现象，数据人员和 IT 开发实施人员缺乏统一和协同，数据架构遵从无法进行实质、有效管理，信息架构资产和产品实现的物理表割裂、不匹配，同时各种数据模型资产缺失。
●针对应用系统设计应遵从信息架构设计的政策要求，在相关项目、产品的流程中，缺乏显性化的且有实操指导的角色和活动。（本文来自公众号：亨利笔记 ）
●信息架构设计大多集中在变革项目层的设计输出和领域层的例行刷新，未与系统落地有效拉通。
●IT 产品聚焦在版本交付，产品级的数据模型与数据字典缺少有效看护和及时维护。
为了解决这个问题，华为推行了一体化模型设计（如图 4-7 所示），不仅在工具上实现了一体化设计和开发，而且在机制上形成了信息架构设计与 IT 开发实施的有效协同。通过一体化设计不仅确保了元数据验证、发布和注册的一致性，而且实现了产品数据模型管理和资产可视。同时，由于促成了产品元数据的持续运营，进而能够持续对物理模型进行规范，如整改、清理各类作废表等。
●产品逻辑模型和物理模型一体化设计，元数据管理和数据模型管理融合；
●构建数据标准池，实体属性只能从数据标准池选择；
●产品元数据和数据库自动比对和验证；
●产品元数据发布认证和信息资产打通；
●基于交易侧产品元数据自助入湖。
在企业数字化转型过程中，企业信息架构的定位、内涵和管理方式都在不断地演进。信息架构的定位发生了根本性的变化，不再是对准 IT 功能或实现，而是对准整个企业的业务管理目标；信息架构的内涵也进行了极大的扩展，不再只是聚焦于进入类似 ERP 系统的结构化数据，而是对准整个企业在业务中产生的各种结构化数据、非结构化数据、内外部数据、过程类数据、规则类数据、IoT 数据等；信息架构的管理方式也发生了颠覆性的改变，不再是抽象化的、预先定义好的、一次定义覆盖所有场景的标准，而是全量的、实时产生的、满足差异化要求的，甚至是随需定义的标准。
在这样的背景下，需要对原有信息架构框架和方法论不断进行审视和优化，可能两年前刚刚确定的框架已经不能满足要求， 甚至一年前发布的架构规则就要重新修订。在企业实现数字化转型的过程中，信息架构管理的结构、技术、组件、标准可能永远不会稳定，永远在进化。
感兴趣的读者可以点击图片购买图书作参考。
要想了解云原生、区块链和人工智能等技术原理，请立即长按以下二维码，关注本公众号亨利笔记 （ henglibiji )，以免错过更新。
