到底什么是数据架构，如何管理，谁来负责？

到底什么是数据架构，如何管理，谁来负责？

理解概念是理解数据管理的第一步，很多概念我们知道，但内涵却不清楚，或者你以为清楚，这类澄清概念的文章可以很好的帮到你！

源于数据治理周周谈 ，作者徐康

随着数据治理工作的深入，数据标准的理念逐步为人所知、所识。但是，数据架构是什么，如何管理，谁来负责，还没有形成一致的共识。早前，在技术领域，系统架构、应用架构、信息架构相对为人了解，近年来一些企业级架构师也开始提出业务架构等概念。就数据架构而言，实践还呼唤一些理论的澄清，理论也亟需实践的反馈。

关于数据架构，本公号曾用“一句话”的方式来说明，包括提出数据架构管理是贯彻和维护数据治理的职能单元，和数据资产互为HOW和WHAT的关系。今天我们再谈数据架构，主要是想谈谈近期工作推进过程的当下，对于数据架构的新的理解和认识。

图 1 企业架构划分

数据架构是什么？此前有多重解读和方案。但是随着业界理论体系的不断完善，以及企业级数据治理工作的不断深入，目前的领先企业、数据治理组织、甚至包括监管当局的理论准备工作已经逐步收敛到四个方向，即：

• 数据资产目录

• 数据标准

• 数据模型

• 数据分布

以上，可以称为数据架构体系的“四个基本内容”。而作为数据架构的制定、管理和维护者，企业的数据架构部门需承担对应的职责，具体而言应该包括：

• 梳理企业的数据资产

• 制定数据标准并持续维护

• 建立数据模型，包括概念模型、逻辑模型和物理模型

• 管控数据分布，包括数据源头和流向

这其中，数据模型是数据架构的重要抓手，也是数据架构管理体系构建的基础和连通其他架构管理措施的纽带。

表1 数据架构行业参考

 

01 数据架构的管理价值

DAMA-DMBOK认为，数据架构是企业架构的一部分。从企业运作的角度来说，数据架构定义了企业运作过程中所涉及到的各类对象和其治理模式；从数据资产的角度来说，数据架构是管理数据资产的蓝图；从数据管理的角度来说，数据架构是企业各部门的共同语言，是数据管理的高层视角。

在企业管理中，往往会面临这样的问题，业务部门和技术部门在自说自话，对于同样的业务对象，我有我的话术，你有你的流程，大家隔着一层窗户纸，拖累了企业的运作效率，也削减了企业的数据竞争力。在业务战略和技术实现之间建立起一座畅通的桥梁，捅破这层窗户纸，是数据架构的本质目标，也是它的核心价值。成熟的数据架构，可以迅速地将企业的业务需求转换为数据和应用需求，能够管理复杂的数据和信息并传递至整个企业，在数据层面保证业务和技术的一致性，最终为企业改革、转型和提高适应性提供支撑。

02 数据架构四个基本内容的解析

DMBOK对于数据架构的阐述是抽象的、理论化的，是对全行业数字化转型的普适法则。在不同的语境下，对于数据架构应有不同的“解签”，这里不妨看看全国金融标准技术委员会的意见。在《金融数据能力建设指引》中，金标委认为数据架构应该包含元数据管理，建立创建、存储、整合和控制元数据的一系列流程；也包括构建数据模型，将业务经营、管理和决策中遇到的数据需求结构化；以及数据分布和数据集成，明确数据责任人、管控数据流、制定数据标准，达成组织内各系统各部门的数据互联互通。

华为等企业作为大数据时代的互联网行业先锋者，也对数据架构有自己的理解，但其范围也不会越出数据标准、数据流、数据建模等内容。我们更加关注的，是数据架构体系里各个组件的结构内容及其存在的意义，这里从数据架构的四个基本内容展开来说。

图 2 数据架构的四个基本内容

1.数据资产目录

数据资产目录，也是企业的数据资产地图，是企业数据治理的指引。一般而言，数据资产目录可以分为五个层级：

• 主题域分组

• 主题域

• 业务对象

• 实体

• 属性 

主题域和主题域分组用于描述企业数据管理的分类依据和集群边界。主题域是互不重叠的数据分类，管理一组密切相关的业务对象，通常同一主题域有相同的数据主人。主题域分组则是依据业务管理边界对于主题域的分组，是描述公司数据管理的顶级分类。

业务对象是数据架构的搭建的基石，是业务领域中重要的人、事、物在数据架构中的代理，数据架构建设和治理是围绕着业务对象和对象间的关系展开的，而实体则是描述业务对象在某方面特征的一类属性集合，而属性则用于描述业务对象在某方面的性质和特征。

数据架构的其他组件，无论是数据标准的制定，数据模型的建立还是数据分布的管控，无一不是建立在数据资产目录的基础之上的，并以其为中心和出发点。同时，数据资产目录是企业数据资产的宏观概述，确定了数据架构的外层边界和核心骨架。

2.数据标准

数据标准要求企业各部门、各群组使用统一化、标准化的语言描述数据，是实现企业数据一致性的关键。然而，对于传统的大型企业，例如数字化转型过程中的商业银行，实现数据标准统一绝非易事，它既要有面向未来的对象和属性的命名规范，也要有面对过去的留存数据的规划和既有逻辑的整合；它既要适应业务部门的工作习惯，也要符合技术部门的开发原则。在这样的语境下，数据标准并非孤立一体，而需要演变为渐进的、多面的体系，这个体系应该包括：

• 业务术语

• 数据标准

• 数据字典

业务术语是有业务部门提出的、对于自身业务活动的提炼，最终形成的企业各部门认可的业务词汇。业务术语代表了数据标准的初级形式，通过标准编码、业务定义、分类分级和质量规范，业务术语得以升华为数据标准。在数据标准的基础上，技术部门为了对数据模型进行管控而产生了表结构和字段定义规范，即是所称的数据字典。

数据标准的统一对于数据架构的意义，不亚于语言的统一对于国家的意义。纵向上，数据标准消化了存量的历史数据，赋予他们以新的解读、应用和价值；横向上，数据标准沟通了部门内的条线和组织，也沟通了部门间的职能和团队，消解了由业务集群造成了数据跨集群的重复和歧义。数据标准的建设，让企业所容纳的数据真正成为了企业所拥有的资产。

3.数据模型

数据模型是最为外界所熟知的数据架构的组件，它是数据视角下对现实世界规则的抽象与概括，根据业务需求抽取信息的主要特征，反映业务对象之间的关联关系。从概念抽象，到物理固化，数据模型有三个阶段：

• 概念模型

• 逻辑模型

• 物理模型

其中概念模型基于真实世界的关系语意，数据需求的提出者将所需的业务对象和业务流程表达厘清、简化和抽象，并表达为“实体-关系”（E-R）图，它的实现代表了自然语言的退场；逻辑模型则是技术侧对于概念模型的解读，数据逻辑在此时替代了实体关系；物理模型则是逻辑模型的落地，是对于真实数据库表的描述，包含了表、视图、字段、数据类型等等要素，物理模型的达成代表了业务流程与实体关系已经被固化为了数据库中的表关系，可以被使用、验证、加工和维护，自此完整的数据模型正式达成。

从某种意义上来说，数据模型是数据架构最重要的产出物，它完成了业务需求从自然语言到数据语言的转化。

4.数据分布

如果说数据架构的前三个组件是从静态角度对数据、数据关系进行了定义，那么数据分布则动态地定义了数据产生的源头和数据在各流程、各系统间的流动情况。管控数据的流动，需从三个方面入手：

第一是数据源头，物理上是数据源，主体上是数据主人，管理上是数据责任。数据源头需要把控数据质量，拥有源数据标准制定的权利，可以提请业务术语的新增、修订和废止，同时也是数据的责任主体；

第二是管控部门，管控部门是企业内的数据管理部门，承接自数据源头，传递到数据的消费者，是企业数据流的中间人。管控部门负责协调数据标准的制定，维护业务需求到数据实现的通路；

第三是管控流程，也就是控制数据的流向。已经建立标准、明确源头的数据需在企业各组织、部门间保持一致，数出同源；数据在生命周期中的流动路径、数据的取用须遵循数据安全的原则。

作为数据架构的最后一个部分，数据分布的意义在于使得已经被规整的企业数据真正被使用，表现出价值，同时也保证数据在使用过程中不变形、数据在生命周期中可以被维护。数据分布的加入，数据架构得以理论完备，并且有了“生命”。

03 数据架构的设计和管理

在拎清数据架构的组件之后，更加实际的问题是如何设计数据架构，实现理论的落地。无疑，数据架构的设计因行业而异，也因企业而异，但是也有一些共性和原则。总结而言无非是：面向业务对象进行架构设计，以及面向业务对象实现架构落地。

所谓面向业务对象进行架构设计，即是企业数据架构的设计应当以业务对象为基石，展现业务对象的属性特征，描摹业务对象间的关联关系。脱离业务对象的架构设计是无意义的，它因无法指导企业运作、无法辅助企业成长而失去了自身的意义。面对业务对象的架构设计，基点在于确定业务对象，参照的标准是：成为业务对象的实体须有唯一的标识信息、有属性描述、可实例化。

面向业务对象实现架构落地则是针对数据模型而言的，因为数据架构最为重要的交付产物就是数据模型。为了确保架构在落地过程中不变形，从数据模型的定义与结构来看，必须保证：其一，概念模型须与逻辑模型一致，这主要通过逻辑模型从数据实体出发而实现；其二，逻辑模型须与物理模型一致，这要求技术部门建模管理一体化，严格遵照逻辑模型的结构设计物理表。

04 结语

自此，我们完整阐述了数据架构的定义、作用、结构和方法论。随着企业数字化转型的风口愈演愈烈，云技术的成熟，以及一些头部公司企业级数据建设的成功，数据管理越来越成为各个行业企业管理的热门词汇，而不同企业对于数据管理、数据架构的认识也不尽相同。这篇文章，从数据架构的行业共识出发，到一个特定的、相对成熟完备的数据架构拆解，再到简谈数据架构的落地结尾，是希望从一定的高度展现数据架构的全貌和脉络，不仅说数据架构是什么，也说数据架构能做什么；不仅说数据架构的作用，也说达成目标的途径；这既是我们对于数据架构的理解，也可以成为企业团队构建数据架构时的一点方向和过程中的参照，其中更多的细节，值得我们在实践中不断思考和改进。