很多人一听到数据架构，第一反应是数据库设计，或者数据仓库分层。我们天天说的数据架构，到底是在架构什么？
简单来说，就是让业务说的话，IT能听懂；让IT做的系统，业务能用上。
简单说，数据架构要回答四个问题，企业有哪些数据？这些数据叫什么？它们什么关系？最后存在哪儿、怎么流转？ 不讲虚的，直接上干货，今天就把数据架构设计的方法论给大家讲清楚。
一、先搞清楚数据架构到底是什么
很多企业在推数字化转型的时候，都会提到企业架构（EA）。企业架构通常包含四个子集：业务架构（BA）、数据架构（DA）、应用架构（AA）、技术架构（TA） 。
这四个架构不是并列关系，而是有明确的上下游逻辑。业务架构定义了企业怎么运作，数据架构承接业务架构的数据需求，应用架构依据业务对象规划功能，技术架构则依据数据模型设计存储方案。
说白了，数据架构是连接业务和IT的桥梁。它不是纯技术的事，也不是纯业务的事，它负责把业务语言翻译成IT能理解和实现的结构。
那数据架构具体包含什么？用过来人的经验告诉你，一套完整的数据架构，必须覆盖四个组件：数据资产目录、数据标准、数据模型、数据分布。
二、数据架构的四大组件
1、数据资产目录
数据资产目录解决的是一个最基本的问题，企业有哪些数据，谁负责这些数据。很多企业做数据治理，数据说不清楚，责任落不下去。
数据资产目录采用分层结构来组织数据，从上到下分为五层：
- L1 业务域：公司最顶层的数据分类，对应公司最高层面关注的业务领域，比如销售领域、供应链领域、财务领域。
- L2 主题域：互不重叠的高层面数据分类，用于管理其下一级的业务对象，同时划定数据责任人的管辖范围。
- L3 业务对象：这是整个目录体系的核心。业务对象是业务领域中重要的人、事、物，比如销售订单、客户合同、发货单。它是数据管理的基本单元，是业务和IT之间的关键连接点。
- L4 逻辑数据实体：描述业务对象某种业务特征的属性集合，指导IT系统开发与系统集成。
- L5 属性：描述所属业务对象的性质和特征，明确标准与规则，确保数据全流程可用。
其中，L3业务对象的识别是整个数据架构设计中最难、最关键的一步。一个合格的业务对象，必须满足四个特征：在企业运营和管理中不可缺少；具有唯一身份标识信息；相对独立并有属性描述；一般为主数据和事务数据，存在具体实例。
2、数据标准
数据标准解决的是语言不统一的问题。这个问题在大企业里极其普遍。
同一个字段，销售部门叫客户类型，IT系统叫Customer Type，财务系统里又是另一个叫法。各个系统各说各话，数据交互失败，业务运营受影响。你懂我意思吗？
数据标准从业务、技术、管理三个视角来定义一个属性的要求和规格。
- 业务视角包括业务定义及用途、业务规则
- 技术视角包括数据类型、数据长度、允许值
- 管理视角包括业务规则责任主体、数据维护责任主体
数据标准的核心价值在于统一规则、统一定义、明确责任人、支持标准重用。建立了统一数据标准之后，任何应用系统、流程文件都应该遵守这套标准。标准变更时，业务流程给数据标准工作提供信息，应用系统也可以提供它们所使用的标准情况，整个体系形成联动。
3、数据模型
数据模型解决的是数据关系的问题，各个业务对象之间是什么关系，数据怎么组织。数据模型分三个层次：
- 概念数据模型（CDM） ：从业务角度描述各业务对象之间的关系，是对现实世界中具体人、事、物之间关系的抽象。主要用于业务沟通与对标，无范式化要求。
- 逻辑数据模型（LDM） ：描述各逻辑数据实体之间关系的数据模型，承载业务逻辑，是概念数据模型的细化设计。每个实体需列出业务属性，满足三范式要求，需确定标识符（主键）。
- 物理数据模型（PDM） ：关系型数据库能够识别的实现层数据模型，需完整涵盖逻辑数据模型所定义的业务范围，体现表和表之间的关系，包括表、字段、主键、外键等，同时需要考虑数据库特性和性能进行设计。
我一直强调，概念数据模型是数据架构规划阶段最重要的输出之一。它建立了统一的数据模型，有效整合数据，实现数据的标准化和开放共享，最终达到数据的可信、可理解、可管、可用。
4、数据分布
数据分布解决的是数据在哪里、怎么流转的问题。简单来说，数据分布是数据在业务流程和IT系统上流动的全景视图，帮助你识别数据的来龙去脉，定位数据问题的根源。
数据分布包含三个子组件：
- 数据源：定义数据产生的IT系统源头，是业务上首次正式发布某项数据的应用系统，经过数据管理专业组织认证，作为唯一数据源头被周边系统调用。
- 数据流：描述某一数据在应用系统中如何被创建、读取、更新、删除（CRUD），主要用于数据质量的根因分析，指导系统集成。
- 信息链：是一个指定范围内的端到端流程，或流程中的活动间信息流的表述，包括信息被创建、读取、更新、删除的全过程。
单靠规划和人工梳理远远不够，往往需要专业的数据集成工具做支撑，承接数据源对接、数据流同步、信息链梳理可以借助FineDataLink实现，数据流转和管理更高效。
三、设计数据架构，要遵守哪些原则
1、数据按对象管理，明确数据责任
数据在业务活动中产生并记录，管理的基本单元是业务对象，而不是字段，也不是表。
为什么要强调这一点？因为很多企业的数据问题，表面上是数据质量差，根本原因是责任不清。一份数据，销售说是IT的事，IT说是业务的事，最后谁都不管。数据按对象管理，就是要把每一个业务对象的数据责任落到具体的人和部门身上。 谁的业务对象，谁就是数据Owner，负责这份数据的定义、质量和维护。
这条原则贯穿整个数据资产目录的设计，L2主题域的划分要求每个主题域有且只有一个数据责任人，L3业务对象同样需要明确责任人并正式发布确认。
2、以企业全局视角定义数据架构
数据架构不是某个部门的内部工作，它必须基于企业全局视角来建立。
数据架构的价值，恰恰在于它跨越了部门边界。 数据标准要在企业层面统一，业务对象的定义要在企业层面达成共识，数据模型要能支撑跨领域的数据流转。任何局部视角做出来的数据架构，都只能解决局部问题，无法在企业生态中真正发挥作用。
3、遵从公司数据分类管理框架
很多企业按照部门来划分数据，销售的数据归销售，财务的数据归财务。但问题是，一份客户数据，销售要用，财务要用，服务也要用，它不属于任何一个部门，它属于企业。
按数据特性分类，才能真正实现数据的跨部门共享和复用。 主数据、事务数据、报表数据，各有各的管理方式和治理要求，混在一起管只会越管越乱。
4、业务对象结构化、数字化
根据业务需求，建立业务对象的结构化、数字化架构，提升业务对数据的处理和应用能力。很多企业的数据存在大量非结构化内容，备注字段里塞了关键信息，合同条款用自由文本描述，这些数据人能看懂，但系统处理不了，分析用不上。
业务对象结构化，就是要把业务运作中真正重要的信息，用明确的属性、标准的格式固定下来。
5、数据服务化，同源共享
定义单一数据源，通过数据服务化，实现同源共享，保证跨流程、跨系统的数据一致。通过FineDatalink把统一的数据源封装成标准化 API，可以供各业务系统按需调用，实现数据服务化。其他所有系统需要这份数据，都从这个源头获取，而不是各自维护一份副本。
四、数据架构规划的四个步骤
数据架构规划分四个步骤：
1、规划数据资产目录 L1-L3
这是整个数据架构设计的起点。先规划L1业务域，L2主题域和L3业务对象的规划可以同步进行。
- L1业务域的划分，需要从核心业务领域、职能管控域和数据自身的类型等方面综合考虑。如果企业有业务架构，参考业务架构，分析业务能力框架、业务流程架构，识别顶层业务能力作为业务域设计的输入；如果没有业务架构，则参考组织架构，从组织架构中分析业务范围，识别顶层业务能力。
- L2主题域的划分，业界通用两种方法：划分法（自上而下） 和聚合法（自下而上） 。划分法是根据企业价值链、业务架构、业界实践等输入，对企业关键的人、事、物、地及其关系进行识别与抽象，最终通过头脑风暴与业务广泛讨论后完成主题域设计。聚合法是以识别的业务对象为基础，选取核心业务对象作为主题域，其他对象根据业务相关性归属到对应的主题域。实际项目中，划分法用得更多。
- L3业务对象的识别是最难的部分。需要从五个维度进行分析：分析本领域业务架构和组织架构、分析主要业务场景、分析流程活动及输入输出、分析本领域现有IT系统模型、分析本领域主流软件包模型。识别出候选业务对象后，还需要经过合理性验证、完整性验证、集成性验证三轮验证，最终确定业务对象清单并明确责任人。
2、定义业务术语
业务术语定义的前提是业务对象已经确定。业务术语是对数据资产目录中业务对象在企业内的统一定义，消除歧义，为数据资产梳理提供标准的业务含义和规则。
3、设计概念数据模型
选取本领域业务对象和相关业务对象，分析业务对象之间的关系，设计概念数据模型。这一步要基于不同主题域，把该主题域下的业务对象（包含需要调用的其他主题域的业务对象）进行关联。
4、规划数据源
选取业务对象，根据概念数据模型及应用架构，规划数据源。需要从数据资产目录中选择业务对象规划数据源，基于流程架构分析业务对象在流程之间的流向，识别数据在流程上的创建点，基于应用架构分析业务对象在IT产品之间的流向，识别数据在IT产品上的创建点，最后分析数据创建点的IT系统是否符合数据源原则。
五、总结
做完这一套，能带来什么？我总结了数据架构的四点核心价值：
- 厘清数据资产，落实数据责任：通过数据资产目录规划，明确企业有什么数据、谁负责，实现数据管理的责权利落地。
- 统一数据语言，消除理解歧义：通过制定业务术语，使对数据的理解在企业层面达成一致，提高沟通效率。
- 理解数据关系，识别业务需求：通过规划数据模型，帮助重新理解数据之间的关系，识别潜在的业务需求。
- 支撑数据共享，提升数据质量：通过定义数据源头，实现数据的集成与共享，消除数据冗余，为数据质量的提升规划目标。
数据架构设计不是一件一次性的事，它需要随着业务的变化持续迭代。数据资产目录解决有什么和谁负责，数据标准解决叫什么和怎么定义，数据模型解决是什么关系，数据分布解决在哪里和怎么流转。 这套东西做扎实了，数据治理、数据质量、系统集成，很多问题都会迎刃而解。根子上的问题解决了，后面的事才有章可循。
