本附件为eahome原创21页可编辑PPTX文件。
如仅用于阅读学习，可选择价格更低的 PDF版本，地址为：https://eahome.com.cn/13965.html
上一期，我们回答了一个比较具体的问题：华为的数据资源目录如何从L1设计到L5。
数据资源目录解决的是企业数据如何分类、如何分层、如何形成统一的数据资产视图。按照华为的方法，可以从L1业务域、L2主题域、L3业务对象，一直细化到L4逻辑数据实体和L5属性，把散落在不同业务、不同系统中的数据重新按照业务逻辑组织起来。
目录解决“企业有什么数据”，继续往下还要回答：这些数据是什么意思？彼此是什么关系？从哪里产生？经过哪些系统？最终流向哪里？
一、数据架构是企业级的数据蓝图
DAMA更强调企业数据需求和数据资产管理蓝图；TOGAF关注组织的逻辑和物理数据资产及其结构；IBM更多从数据来源、存储、流动和使用的角度进行解释；华为则强调以结构化方式描述业务运作和管理决策所需要的数据及其关系。
数据架构是从企业整体视角，对数据资产的组织、定义、关系和流动方式进行设计，形成承接业务需求并指导IT建设的数据蓝图。
数据架构关注的是跨业务、跨组织、跨系统的数据。客户、合同、订单、设备、供应商这些数据对象，不能长期由不同系统各自定义、各自维护，而需要在企业层面形成统一认识。
企业有哪些数据只是第一步，还要继续明确这些数据如何分类、如何定义、彼此是什么关系。
客户和合同是什么关系，合同和订单是什么关系，设备和组织是什么关系，这些都属于数据架构的设计内容。
数据架构最终要落实到应用系统、接口、数据库、数据平台和数据服务。
业务提出数据需求，数据架构形成统一设计，再由应用架构和技术架构落实。因此，数据架构处理的是企业级的数据设计问题，其范围明显高于某一个系统的数据库设计。
二、数据架构连接业务与IT
业务架构定义企业的业务能力、业务活动和业务对象，说明企业做什么业务、业务如何运作。
例如，客户管理需要客户数据，合同管理需要合同数据，供应链管理需要供应商、采购订单、库存和物流数据。
数据架构承接这些业务需求，把业务语言进一步转化为可以统一设计和管理的数据结构。
客户属于哪个业务域和主题域；客户是不是企业级业务对象；客户包含哪些逻辑数据实体和属性；“客户”在企业内部如何定义；客户和合同、订单是什么关系；客户数据由哪个系统产生；哪些系统可以使用这些数据。
这些内容明确以后，应用架构才能进一步确定哪些系统负责创建、维护和使用客户数据，技术架构再确定数据如何存储、集成和运行。
因此，业务架构、数据架构、应用架构和技术架构之间存在一条清晰的承接关系：
业务架构提出数据需求，数据架构形成数据设计，应用架构落实数据处理，技术架构提供运行支撑。
这也是数据架构在企业架构中的核心作用：向上承接业务，向下指导应用和技术。
如果这层架构缺失，系统建设很容易进入各自为政的状态。
同一个客户在不同系统里有不同定义，同一个订单在多个系统重复维护，接口越来越多，数据口径越来越乱。系统数量增加了，企业对数据的控制能力反而下降了。
三、数据架构包含四个核心组件
结合华为的数据架构方法，可以把数据架构的核心内容归纳为四个部分：
数据资产目录、数据标准、数据模型、数据分布。
（1）数据资产目录：企业有什么数据
华为采用的典型结构是：L1业务域 → L2主题域 → L3业务对象 → L4逻辑数据实体 → L5属性。
业务域是企业顶层的数据分类；主题域是业务域下面相对独立的数据主题；业务对象是企业经营过程中重要的人、事、物；逻辑数据实体描述业务对象某一类业务特征；属性继续描述数据实体的具体性质。
例如：客户域 → 客户主题 → 客户 → 客户基本信息 → 客户名称、客户编码、客户类型……
通过这种方式，企业的数据从系统字段逐步还原为具有业务含义的数据资产。
目录建立以后，企业才能真正回答几个基础问题：有哪些核心数据？属于哪个业务领域？数据颗粒度到什么程度？由哪个部门负责？
所以，数据资源目录的直接作用就是：把企业的数据家底看清楚。
（2）数据标准：数据到底是什么意思
企业里面经常出现这样的情况：财务部门有自己的“客户”，营销部门也有自己的“客户”；不同系统都有“合同金额”，但统计范围不同；多个系统都有“设备状态”，状态代码却完全不同。
一项完整的数据标准通常需要明确：业务术语、业务定义、业务规则、数据格式、允许值以及相关责任主体。
比如“客户”到底指已经签订合同的交易对象，还是包括潜在客户；“合同金额”到底含税还是不含税；“性别”字段允许使用哪些标准代码。
同一个数据，在企业内部应该有同一个含义。
标准统一以后，业务沟通、系统集成、数据共享和质量管理才有共同基础。
（3）数据模型：数据之间是什么关系
目录解决分类，标准解决定义，接下来还需要处理数据之间的结构关系。
企业中的客户、合同、订单、产品、设备、组织并不是孤立的数据对象，它们之间存在稳定的业务联系。
例如：一个客户可以签订多个合同，一个合同可以形成多个订单，一个订单包含多个产品。
通常可以分成三个层次：概念数据模型从业务层面描述核心业务对象及其关系。
逻辑数据模型继续细化到数据实体、属性、标识符及实体之间的关系。
物理数据模型进一步落实到数据库中的表、字段、主键、外键和索引等具体结构。
三个层次逐步把业务世界转换成可以落地实施的数据结构。
概念模型帮助业务和IT形成共同理解，逻辑模型沉淀企业级数据设计，物理模型指导具体系统实现。
因此，数据模型的价值不只是画一张ER图，而是把企业核心数据对象及其关系真正理清楚。
（3）数据分布：数据在哪里、如何流动
一项数据可能在某个业务环节产生，在一个系统中创建，再被多个业务流程和下游系统持续使用。
华为把数据分布进一步拆分为三个重要内容：信息链、数据流和数据源。
信息链从业务视角描述数据在业务流程中的创建、读取、更新和删除。
数据流从IT视角描述数据在应用系统之间如何产生、传递、加工和使用。
数据源则明确某项数据第一次正式产生，并能够对外提供的权威系统。
把三部分串起来，就可以完整描述一项数据的流转路径：
业务环节 → 应用系统 → 数据交换 → 数据落点。
例如，一笔客户订单可能由营销环节创建，在CRM系统形成，通过接口进入ERP，再进入数据平台，最后进入主题库和经营分析报表。
数据从哪里来的？哪个系统是权威来源？中间经过了哪些系统？为什么两个报表数字不一致？数据质量问题应该找谁？
到这里，华为数据架构四个核心组件之间的关系已经非常清楚：
数据资产目录回答“有什么数据”；数据标准回答“数据是什么意思”；数据模型回答“数据之间是什么关系”；数据分布回答“数据在哪里、如何流动”。
目录看家底，标准统一语言，模型理清关系，分布看清流转。
四、数据架构最终解决的是企业级数据设计问题
企业遇到的很多数据问题，看上去各不相同，沿着数据架构往下分析，往往能够找到比较明确的原因。
企业有几百套系统，却说不清究竟有哪些核心数据，首先需要解决数据资产目录问题。
同一个“客户”“设备”“合同金额”，不同部门有不同解释，需要解决数据标准问题。
同一份客户、合同、订单数据在多个系统重复建设，需要重新检查数据模型和数据源规划。
一项数据出了问题，找不到从哪里产生、经过哪些系统和加工环节，需要梳理数据分布。
厘清数据资产、统一数据语言、理清数据关系、促进数据共享、支撑数据治理、指导IT建设。
做好数据架构之后，企业对数据的认识会发生一个很重要的变化。
过去看数据，更多是站在系统视角：CRM有什么表，ERP有什么字段，数据仓库里有什么数据。
数据架构建立以后，企业开始站在业务和企业整体视角看数据：有哪些核心业务对象，这些对象由哪些数据描述，标准是什么，相互之间有什么关系，权威来源在哪里，又被哪些业务和系统使用。
数据由此从“系统里的数据”，逐步成为真正可以统一设计和管理的企业数据资产。
这也解释了上一期为什么要专门讨论数据资源目录L1-L5的设计。
从业务域、主题域、业务对象，一直梳理到逻辑数据实体和属性，本质上是在建立企业级数据架构的第一块基础——统一的数据资产视图。
在这个基础上，再继续建立数据标准、数据模型和数据分布，四类架构成果之间相互关联、相互校验，企业的数据蓝图才逐步完整。
企业有什么数据？这些数据是什么意思？数据之间是什么关系？数据在哪里、如何流动？
这四个问题看似基础，却决定了企业的数据能不能真正统一起来。
企业的数据规模越大、系统越多、业务越复杂，越需要在系统建设之前把这些问题回答清楚。否则，今天通过接口解决的数据问题，明天还会以新的重复建设、新的数据孤岛和新的口径冲突重新出现。
数据资源目录是起点，数据标准、数据模型和数据分布共同把这张蓝图补完整。数据架构最终要建立的，就是企业对数据的一套统一认识、统一设计和统一表达。
这也是企业后续开展数据治理、数据共享、数据平台建设以及数据资产化工作的基础。
五、什么是数据架构？eahome原创21页可编辑PPTX
自2026年起，所有内容均为EA之家原创，享有内容版权，盗版必究。2026年之前部分案例来源于各文库类平台，如有标错或文章所使用的图片文字链接等涉及侵权，请尽快与我们联系处理，谢谢。
EA之家 »
一篇看懂什么是数据架构：四个核心组件与华为实践案例，eahome原创21页可编辑PPTX文件。
