数据之道读书笔记-04面向“业务交易”的信息架构建设

数据之道读书笔记-04面向“业务交易”的信息架构建设

华为过去的信息架构建设主要是为了实现“信息化”或“业务上ERP”，信息架构往往隐藏在系统中、隐藏在IT功能下。对于大部分业务作业人员和管理者而言，他们的关注点更多聚焦在“功能是否完善”或“业务是在系统中完成还是手工完成”上。此时，对信息架构的要求仅限于支撑好各类IT系统的落地，或在一定范围内对IT建设提供指导。

随着企业数字化转型的推进，华为公司越来越认识到信息架构的价值并不应局限于“支撑IT建设落地”，而是更好地管理企业数据资产，更好地提升整个业务交易链条的效率，甚至基于信息架构重新审视业务边界的划分和整合。

---

4.1 信息架构的四个组件

企业在运作过程中，首先需要管理好人和物等“资源”，然后管理好各类资源之间的联系，即各类业务交易“事件”，再对各类事件的执行效果进行“整体描述和评估”，最终实现组织目标和价值。

以一个通用的工业企业运营为例（如图4-1所示），企业要管理关键的“员工、组织、产品、客户、供应商”等资源。在企业价值实现的过程中，企业会与客户签订销售合同，与供应商签订采购合同，组建各种交付项目，制定供应计划，财务部门会对成本、费用、收入进行核算，记录客户的应收、供应商的应付，建立合法合规的会计记账体系。然后，通过报告体系按月度、季度、年度发布各种经营、考核报告用于企业决策。

信息架构的目的就是定义好整个运作过程中涉及的各种人、事、物资源，并实施有效的治理，从而确保各类数据在企业各业务单元间高效、准确地传递，上下游流程快速地执行和运作。

华为在实践中构建了一套对业务运作数据进行有效管理的信息架构方法论，用于指导企业内部各部门的信息架构建设工作，让管理者、专家和员工之间有共同语言。

华为的企业级信息架构（Information Architecture）是指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范，包括数据资产目录、数据标准、企业级数据模型和数据分布四个组件，如图4-2所示。

4.1.1 数据资产目录

数据资产目录形成完善的企业资产地图，也在一定程度上为企业数据治理、业务变革提供了指引。基于数据资产目录可以识别数据管理责任，解决数据问题争议，帮助企业更好地对业务变革进行规划设计，避免重复建设。

数据资产目录分为5层，涵盖华为公司的所有业务数据资产，如图4-3所示。

L1为主题域分组，是描述公司数据管理的最高层级分类。业界通常有两种数据资产分类方式：基于数据自身特征边界进行分类和基于业务管理边界进行分类。华为公司为了强化企业内业务部门的数据管理责任，更好地推进数据资产建设、数据治理和数据消费建设，采用业务管理边界划分方式，即将L1主题域分组与流程架构L1相匹配，数据资产和华为业务GPO（全球流程责任人）相匹配，有利于更好地推进各项数据工作。

L2为主题域，是互不重叠的数据分类，管辖一组密切相关的业务对象，通常同一个主题域有相同的数据Owner。

L3为业务对象，是信息架构的核心层，用于定义业务领域重要的人、事、物，架构建设和治理主要围绕业务对象开展。同时，在企业架构（EA）的范畴内，信息架构（IA）也主要通过业务对象实现与业务架构（BA）、应用架构（AA）、技术架构（TA）的架构集成。

L4是逻辑数据实体，是指描述一个业务对象在某方面特征的一组属性集合。

L5为属性，是信息架构的最小颗粒，用于客观描述业务对象在某方面的性质和特征。

4.1.2 数据标准

数据标准是在企业范围内确保数据一致的关键，因此有必要多花一些篇幅来详细介绍。

数据标准定义公司层面需共同遵守的属性层数据含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦确定下来，就应作为企业层面的标准在企业内被共同遵守。

例如，合同是公司最重要的数据之一，因此有必要对合同编号制订统一的数据标准，包括编号的位数、具体的编码规则等，一旦合同编号数据标准制订下来，那么整个公司所有业务部门都必须共同遵守，除了数据Owner以外，任何部门都不允许自定义合同编号。如果随着业务发展需要对合同编号进行变更，那么相关需求也应该统一由数据Owner受理，统一制订变更方案。一旦不同业务环节各自定义，那么数据就无法在上下游业务之间快速流转，往往需要额外的人工转换和翻译，这会极大地增加不必要的人工成本、延长业务执行周期、降低业务效率。
表4-1展示了华为在数据治理早期阶段，各个BG的分类定义不统一问题。

以基础数据“运营商BG”为例，有的系统叫“carriernetwork”，有的系统叫“operator”，还有的系统叫“CNBG”，那么在统计“运营商BG”视角的财务报告时，数据处理人员需要将标识为“carrier network”“operator”“CNBG”的数据进行分类清洗和处理，而不能直接卷积得到结果，增加了额外的处理时间和投入。如果数据处理人员不清楚“运营商BG”这个数据在诸多系统中的名称不一致的情况，那么很可能在统计时丢失部分数据，导致最终报告的失真，最终可能误导决策。

华为公司对业务数据标准有严格的限定，每个数据标准应该覆盖以下三方面。
**业务视角要求：**用于统一业务侧语言和理解，明确定义每个属性所遵从的业务定义和用途、业务规则、同义词，并对名称进行统一定义，避免重复。
**技术视角要求：**对IT实施形成必要的指引和约束，包括数据类型、长度，如果存在多个允许值，则应对每个允许值进行明确的限定。
**管理视角要求：**明确各业务部门在贯彻数据标准管理方面应承担的责任，包括业务规则责任主体、数据维护责任主体、数据监控责任主体，因为很多情况下这些责任并不是由同一个业务部门来负责，所以必须在标准制订时就约定清楚。例如，“客户合同”中某些条款的规则制订者可能是财经部门，负责与客户达成约定并在系统中录入的可能是销售业务部门，而对整个客户合同数据质量进行跟踪、监控的可能是数据专业部门。

但是，企业的每个业务数据标准的定义和维护都需要一定的成本，很多大型企业的IT系统中可能存在上百万、上千万属性，即使去掉冗余、重复的部分，数据量也相当大，因此其实并不需要对IT系统内所有字段都进行定义。为了实现在统一定义的必要性和成本之间取得平衡，华为公司制订了数据标准规范，明确了在不同情况下哪些数据应该制订统一的标准。

描述业务对象的特有属性应作为本业务对象的属性进行定义，并明确业务数据标准。
引用其他业务对象的属性，如果属性值可随本业务对象确定和更改，就应作为本业务对象的属性进行定义，并明确业务数据标准。
引用其他业务对象的属性，如果属性值取自引用业务对象相应时点的数值且后续不变更，就应纳入本业务对象的数据标准范围，并明确相应取值规则。
引用其他业务对象的属性，如果属性值与引用业务对象同步，就不需要重新定义数据标准。
引用其他业务对象/逻辑数据实体的身份标识属性，应作为本业务对象的属性进行定义，但只能在业务数据标准中定义出处及引用规则，而不允许修改或重新定义该属性本身的业务含义及业务规则。

4.1.3 数据模型

数据模型是从数据视角对现实世界特征的模拟和抽象，根据业务需求抽取信息的主要特征，反映业务信息（对象）之间的关联关系。数据模型不仅能比较真实地模拟业务（场景），同时也是对重要业务模式和规则的固化。例如在某个物流业务数据模型中，“运输申付单”与“运输委托”建立一对一关系，而“运输委托”与“派送任务”建立多对多关系，那么这意味着业务部门可以根据发货效率和成本的考虑将“运输委托”拆成分多个“派送任务”，但“派送任务”必须在将一个运输委托完整执行后，才能申请向供应商付款。

4.1.4 数据分布

如果说前三个组件主要是从静态角度对数据、数据关系进行定义，那么数据分布则定义了数据产生的源头及在各流程和IT系统间的流动情况。数据分布组件的核心是数据源，指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证，作为企业范围内唯一数据源头被周边系统调用。华为公司规定所有业务数据必须认证数据源，并在公司范围内统一发布。为了更好地识别、管理数据在流程和IT系统间的流动，可以通过信息链、数据流来进行描述，体现某一数据在流程或应用系统中是如何被创建（Create）、读取（Read）、更新（Update）、删除（Delete）的。

4.2 信息架构原则：建立企业层面的共同行为准则

信息架构承载了企业如何管理数据资产的方法，需要从整个企业层面制订统一的原则，这些原则不仅是对数据专业人员的要求，也是对业务的要求，因为业务才是真正的数据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通过数据服务向各业务环节提供数据，各业务环节也有责任通过服务来合理获取数据，从而在整个企业层面实现数据的“一点定义、全局共享”。

4.3 信息架构建设核心要素：基于业务对象进行设计和落地

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

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

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

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

在进行信息架构设计时，架构师、业务代表、数据Owner通常会对业务对象的判定存在理解上的偏差，从而产生争议。数据治理部门需要制定一套确定性的规则，通过确定性的规则促进形成稳定的架构。华为通过以下四条原则来判定业务对象。
原则一：业务对象是指企业运作和管理中不可缺少的重要人、事、物
企业在设计业务对象时，围绕支持企业运作和管理的重要的人、事、物去识别。通常，一个业务对象会有相应的管理流程、管理组织，以及支持运作的IT系统。比如“客户”这个对象，企业通常会建立类似客户管理部这样的组织，会采购或者开发CRM客户管理系统来支撑客户管理，会建立客户信息管理的一系列流程和规范来确保客户信息的准确、合理、合规。为了避免管理上的冲突，业务对象通常在企业内只能有一个唯一的数据Owner，由数据Owner制定相关的架构、标准和管理规则，用于监控和提升数据质量。
原则二：业务对象有唯一身份标识信息
企业要对业务对象进行管理，需要对所有业务对象的实例进行编码，确保每个对象的实例在企业范围内都有唯一的标识。比如员工，企业需要为每个员工分配一个唯一的工号，如果工号出现重复，则可能引起管理上的混乱，比如工资错发，任务指令接收不到等。又比如产品，企业需要给每一种产品分配精确的分类编号，确保在研发组织内部、制造工厂、物流运输、销售回款各个部门和阶段，相同的产品使用唯一相同的编号，不同的产品绝不出现相同编号。企业的研发、生产、销售、核算各环节均采用产品的唯一编码进行标识和处理。
原则三：业务对象相对独立并有属性描述
业务对象需要通过大量属性来描述其各个方面的性质和特征，因此属性必定依附于某个业务对象而不可独立存在。比如“名称”是个属性，单纯地记录“名称”这个属性，无任何业务含义，因为“客户”有“名称”属性，“供应商”也有“名称”属性，“员工”也有“名称”属性。业务对象可以独立地存储、传输、使用，业务对象之间可以有关联、依赖关系，但不应有包含或从属关系。

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

原则四：业务对象可实例化
在现实世界中，业务对象有大量的实例存在，并可感知、可获取。以员工为例，就算是规模很小的企业，通常至少会有经理、业务员、会计等不同岗位的人员，每个员工的信息都可以视为一个实例；

而“员工入职类型”是对员工入职信息的一种分类，其本身是无法实例化的，因此“员工入职类型”这一基础数据应从属于员工业务对象下，而不能独立存在，员工业务对象Owner也应该同时负责“员工入职类型”数据的生命周期管理。

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

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

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

为了确保架构在落地过程中“不走形”，要控制好两个关键点：一个是概念模型与逻辑模型的一致性，主要通过逻辑数据实体的设计管理来实现；另一个是逻辑模型与物理模型的一致性，主要通过一体化建模管理来实现。

1. 逻辑数据实体设计
逻辑数据实体本质上是对描述业务对象的众多属性的归类，业务对象无法直接指导IT系统的物理实现，也无法基于业务对象来审视物理设计是否满足业务需求，因此需要通过逻辑数据实体及相应的逻辑数据模型来指导IT系统层面的数据设计。在设计逻辑数据实体时，可参考如下几条主要规则。
1）逻辑数据实体不能脱离业务对象独立存在，因此某个逻辑数据实体一定是用来描述一个特定的业务对象的，业务对象与逻辑数据实体的关系是一对一或一对多，不允许多对一的情况出现。

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

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

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

5）两个业务对象间的关系也可以设计成关系型逻辑数据实体，在数据资产目录中，可按业务发生的时间先后顺序，归属于后出现的业务对象。
2. 一体化建模管理
华为公司过去长期存在信息架构与IT开发实施“两张皮”的现象，数据人员和IT开发实施人员缺乏统一和协同，数据架构遵从无法进行实质、有效管理，信息架构资产和产品实现的物理表割裂、不匹配，同时各种数据模型资产缺失。

针对应用系统设计应遵从信息架构设计的政策要求，在相关项目、产品的流程中，缺乏显性化的且有实操指导的角色和活动。
信息架构设计大多集中在变革项目层的设计输出和领域层的例行刷新，未与系统落地有效拉通。
IT产品聚焦在版本交付，产品级的数据模型与数据字典缺少有效看护和及时维护。
为了解决这个问题，华为推行了一体化模型设计（如图4-7所示），不仅在工具上实现了一体化设计和开发，而且在机制上形成了信息架构设计与IT开发实施的有效协同。通过一体化设计不仅确保了元数据验证、发布和注册的一致性，而且实现了产品数据模型管理和资产可视。同时，由于促成了产品元数据的持续运营，进而能够持续对物理模型进行规范，如整改、清理各类作废表等。

基于良好的一体化建模架构，不仅可以打通设计和物理实现，而且能够对设计、发布、管理运营等完整生命周期进行融合管理，包括：
产品逻辑模型和物理模型一体化设计，元数据管理和数据模型管理融合；
构建数据标准池，实体属性只能从数据标准池选择；
产品元数据和数据库自动比对和验证；
产品元数据发布认证和信息资产打通；
基于交易侧产品元数据自助入湖。

4.4 传统信息架构向业务数字化扩展：对象、过程、规则

本章前面提到，华为公司的信息架构最初是为了满足“信息化”和“业务上ERP”过程中提出的数据管理要求，但随着数字化转型的深入，发现既有信息架构已经无法满足自身业务需要，主要体现在以下几个方面。
1）大量业务和作业所产生的数据并没有完整地被管理
很多情况下，并不是所有业务和作业所产生的数据都在系统中承载，因为大量IT系统中已经承载的数据，往往都是为了满足流程的标准化需要而存在的。例如，每个与客户签订的合同都非常复杂，包括诸多的条款，华为公司签订的合同通常会有上百页内容，但信息架构往往只定义了数百个数据属性，IT系统中也只承载了这部分内容，而大量的数据是以文档的形式存在的。当要对某个合同进行签订前的评审时，如果想基于过去已签订的合同的条款进行基线参考和验证，那么是无法通过自动化手段高效实现的，只能通过人工翻阅历史合同来实现，完整性和准确性都无法保障，而且效率很低。
2）大量业务过程没有形成可视、可管理的数据
业务在执行某个具体活动时是有大量作业过程的，但这部分数据往往并没有得到管理。例如，过去只记录了物流各个节点的实际到达信息，但缺乏过程信息记录，假如想实时了解具体的物流状态，只能通过电话、邮件一次次询问，增加大量沟通成本，并且信息的及时性也得不到保障。
3）大量业务规则缺乏管理、无法灵活使用
在业务执行中存在大量规则，但绝大部分规则都缺乏有效管理，往往只能通过文件和文档管理，即使有部分规则固化到了IT系统中，也是无法灵活调整的。例如，有业务人员经常抱怨，由于每年都会发布一些文件来制订业务规范，因此自己不知道哪些是最新的，以及多个历史规范之间是否有重叠和矛盾；另外，如果想基于业务变化对规则进行刷新，但这些规则都固定在IT代码中，IT系统动辄需要数个月才能完成修改，而此时业务可能又发生了新的变化。

因此，华为公司在传统信息架构的基础上，提出了面向数字化转型的扩展：对象数字化、过程数字化、规则数字化，并打造与之相应的能力。
1）对象数字化
对象数字化的目标是建立对象本体在数字世界的映射。这种映射不是传统意义上基于流程要求的少量数据的管理，而是管理某个对象的全量数据，如图4-8所示。

以产品研发和设计为例，信息架构过去只管理产品数据进入ERP管道所必需的少量内容，如产品编码、描述、BOM清单等，而基于对象数字化则需要建立完整的数字孪生（Digital Twin），也要管理与之相应的完整信息架构。过去，供应部门经常抱怨产品研发部门所提供的“重量”“体积”信息不准确，而研发部门又没有足够的人力在产品进入生产环节前精准测量每个产品、部件、元器件。但是，实际上研发在设计过程中会多次产生并使用这些重量和体积信息，因为这对研发设计也同样重要。在推行对象数字化后，就可以通过数据感知等手段在设计的各个环节记录上述这些数据，并按项目编码进行更新，这样就可以向供应环节提供准确并且全量的数据。
2）过程数字化
仅仅管理好结果还不够，有时我们需要把作业过程记录下来，了解过程进度或者反过来改进结果。这种记录首先是不干预业务活动的，并且能够自动记录（例如，车辆行驶中自动监控是否存在交通违规）。

过程数字化要实现业务活动线上化，并记录业务活动的执行或操作轨迹，一般通过观测数据来实现轨迹记录，如图4-9所示。

以前面举过的物流场景为例，华为公司通过推进业务过程数字化，实现供应链对各类物流状态的实时感知和可视，大幅缩减了发货后反复人工沟通的成本。
3）规则数字化
规则数字化的目的是把复杂场景下的复杂规则用数字化手段进行管理。良好的规则数字化管理，应该能实现业务规则与IT应用解耦，所有关键业务规则数据要实现可配置，能够根据业务的变化灵活调整，如图4-10所示。

同样以物流场景为例，通常业务希望基于计划对各个环节的物流任务进行监控和预警，这需要大量的预警规则。例如，某个部件的物流周期是1周，当5天后要交付而对应物流还未发货，则应该预警。但是，不同物料、不同场景、不同国家的供应能力往往是有差异的，并且随着环境经常动态变化，这就需要将对应的规则数据从IT应用中解耦出来，单独定义这类数据资产的信息架构，从而使之能够灵活调整。这样，不同国家的业务人员就可以根据需要随时调整规则，而不用对现有IT系统进行大的改动，最大程度地满足业务灵活性的要求。

4.5 本章小结

在企业数字化转型过程中，企业信息架构的定位、内涵和管理方式都在不断地演进。信息架构的定位发生了根本性的变化，不再是对准IT功能或实现，而是对准整个企业的业务管理目标；信息架构的内涵也进行了极大的扩展，不再只是聚焦于进入类似ERP系统的结构化数据，而是对准整个企业在业务中产生的各种结构化数据、非结构化数据、内外部数据、过程类数据、规则类数据、IoT数据等；信息架构的管理方式也发生了颠覆性的改变，不再是抽象化的、预先定义好的、一次定义覆盖所有场景的标准，而是全量的、实时产生的、满足差异化要求的，甚至是随需定义的标准。

在这样的背景下，需要对原有信息架构框架和方法论不断进行审视和优化，可能两年前刚刚确定的框架已经不能满足要求，甚至一年前发布的架构规则就要重新修订。在企业实现数字化转型的过程中，信息架构管理的结构、技术、组件、标准可能永远不会稳定，永远在进化。