最近在和客户交流过程中，经常听到客户主动提出数据治理，有无数据治理的解决方案？让我不得不重新思考下数据治理这个概念为何突然很火。

数据治理（Data Governance）是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发起并推行，关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程。

简单来说就是建立一套完整的对数据进行管控的方法，规范，流程，制度，责权利等。但是这个并不是什么新鲜的东西，早在多年前我谈MDM主数据管理平台和解决方案的时候，里面有一个专门的章节就是谈数据治理管控体系。

里面涉及到数据质量管理，数据标准，数据安全，组织体系建设，数据生命周期管理等各个方面的内容。当你看数据治理的时候你可以看到仍然是讲的这些内容。

为何数据治理这个概念兴起？

还是先看下数据治理这个概念为何会兴起。

首先要先谈下数据的作用越来越受到重视，特别是当前谈的数字化转型过程中，更加强调了数据驱动，而底层数据模型的标准化，数据的完整性和一致性又直接影响到能否真正数据驱动，数据能否发挥应有的数据价值和服务能力。

包括在谈中台建设的时候也专门分为了业务中台和数据中台，数据中台重点则是形成统一的数据服务能力，既实时的支撑业务运作，又能够用于传统的数据分析和决策。

数据受到重视，但是也暴露了数据层面的问题，典型的就是数据本身没有标准体系，小到一个物料编码，大到一个数据申请变更流程。其次就是数据多点落地，导致的数据在多个系统不一致，各个系统可能都只管理一小部分数据导致的无法体现完整数据视图问题。

比如下面这个图：

一个简单的组织人员数据在整个企业都存在编码不统一，一些数据在HR系统管理，一些又在门户系统的管理，而且两者管理的范围还存在重叠。

如此明显的数据管理类问题将直接导致数据后续的价值服务能力。

所以再次强调下我谈过的多次的一个观点，解决数据问题不是简单地建设一个数据中台，或MDM技术平台就能够解决的，更加重要的是数据治理规范体系建设，数据模型建设，数据实施，而这些都属于数据治理范畴。

所以从这个层面来讲，数据治理不是一个新概念，而是一个已经存在很久的老概念。当谈数据治理的时候更加强调的是咨询规划，方案和实施能力；而不是简单地卖一个软件平台或产品。同时数据治理更容易从企业本身的数据问题驱动出发思考，而不是是自我的产品驱动出发。当客户认可你的数据治理方案的时候，再来谈产品层面的事情。

有时候我们去做售前产品交流，一开始就将你的主数据平台有什么功能，数据中台有什么能力，但是企业为何需求这些能力，这些能力本身什么关系往往并没有讲解清楚。这就是典型的产品驱动思维。

其次，原来谈得多的主数据管理这个概念，这几年谈得多的是数据中台这个概念。对于主数据管理这个概念本身实际无法包括完整的数据模型，动态可共享数据方面能力，因此并不能完全覆盖企业数据治理方面的内容。而对于数据中台这个概念，本身又太强调了技术平台属性，导致前面谈的数据治理能力在数据中台中台被弱化，包括中台这个概念本身也逐步成为了软件供应商导出忽悠的代名词。

因此在这种场景下，提数据治理这个概念是一个好的思路。

也就是说你不论是规划建设主数据，还是大数据平台，还是数据中台，还是数据服务能力开放等都涉及到数据治理，那么就先把数据治理思路给你讲清楚，然后再根据你的需求制定迭代演进路线，再给你推荐合适的产品或服务。

数据治理体系和框架是如何的？

在前面谈数据治理的文章中我提到，可以将数据治理理解为静态+动态两个视角完成了对数据的基础管理体系建设。但是对于数据治理包括了数据管理体系和数据价值创造体系。

基于这个思考重新构建完整的数据治理框架如下：

在整个框架体系中，我们将数据治理分为三层：

支撑体系层（组织，技术标准规范，流程）

管理体系层（静态模型+动态生命周期）

价值体系层（共享+数据应用）

在支撑体系层包括了数据治理的驱动源头，即数据治理组织体系和责权利建设，在明确这个后本身也分解为静态和动态两部分支撑。静态支撑包括了技术体系，标准体系，规范体系；而动态支撑包括流程执行体系，绩效评估体系等。

在管理层首先要关注静态和动态两个维度。对于静态核心是数据架构，在数据架构中本身包括了数据模型和元数据两个部分内容。该动态部分核心是数据生命周期管理，其中包括了数据创建，变更，废弃等流程管理。同时围绕静态和动态生命周期还需要做好数据质量管理，数据安全管理两个纵向维度内容。

在数据管理层做好后，需要对数据能力进行集成和共享，将数据服务能力开放为更多的应用服务，进一步实现数据价值，即数据应用层。即数据应用层包括了数据集成共享，数据服务开放，数据应用分析三个关键内容。

所以谈数据治理，核心还是静态数据模型和动态数据生命周期两条主线，将上面的框架图再简化，可以看到如下一个核心架构。

在这个核心架构逻辑里面，既要考虑完整的数据模型，又需要构建数据从采集集成，到清洗入库，后续变更废弃的完整生命周期管理。

数据治理平台和差异点分析

首先看下一个数据治理平台一般包括哪些功能。引用了国内某一数据服务厂商的数据治理工具来看下具体功能包括：

元数据管理：包括元数据采集、血缘分析、影响分析等功能

数据标准管理：包括标准定义、标准查询、标准发布等功能

数据质量管理：包括质量规则定义、质量检查、质量报告等功能

数据集成管理：包括数据处理、数据加工、数据汇集等功能

数据资产管理：包括数据资产编目、数据资产服务、数据资产审批等功能

数据安全管理：包括数据权限管理、数据脱敏、数据加密等功能

数据生命周期管理：包括数据归档、数据销毁等功能

主数据管理：包括主数据申请、主数据发布、主数据分发等功能

在这些功能里面可以看到大部分都是传统的MDM主数据管理平台就具备的功能。具体的参考功能架构如下：

在这个架构图里面可以看到，在底层数据存储增加了异构数据和大数据的采集和集成能力，也就是数据底座可以依托在大数据技术平台上。

而在上层则围绕数据资产管理这个核心形成了数据服务共享和数据服务能力开放体系，这个也是对原有的MDM主数据管理的一个提升，实际这部分内容在数据中台中是一个关键分层，即数据服务和能力开放层。

其次，还有一个关键点就是数据治理的数据模型实际应该包括三层，即元数据，主数据和ODS共享数据。这样就对传统的MDM主数据的数据管理范畴进行了扩展。

特别是在微服务拆分下，构建一个完整的可共享的ODS库往往是提供数据价值服务的一个关键内容，这个内容传统应用架构下往往在构建BI系统才去解决，但是BI系统的构建往往都是为数据分析决策服务，而不是去实时满足业务运作。因此在当前数据治理里面，应该增加对于共享动态数据的管理内容。

上图来源为数聚治理平台架构

简单总结，在软件平台提供上核心差异为：

其一是增加数据服务共享和能力开放

其二是在数据范畴上增加共享动态数据管理

其三是底层平台上兼容部分大数据平台的能力

从治理工具到数据架构规划

其次，既然谈数据治理，一般都会涉及到咨询规划方面的内容，即规划先行，最后再通过数据治理工具或平台将咨询规划的内容进一步落地。

而对于数据治理方面的规划，仍然是可以沿用传统企业架构规划思想，从业务流程驱动的角度来规划业务架构和数据架构。

企业数据架构是指企业实施全面的企业运营数据的管理和控制，实现数据在搜集之后的分析，从企业的整体视角了解企业、客户和市场，通过数据更好地支撑企业运营。企业数据架构规划的目标就是打破信息孤岛，实现企业信息数据共享；应用与数据分离，实现数据从部门到企业的提升；建立数据转换为价值的体系，让数据发挥出企业核心资源的效用，实现数据的增值。

企业架构规划始终围绕流程和数据两个核心内容展开，业务架构规划的重点是流程和业务功能，而数据架构规划的重点则是数据，在业务朝IT实现的转换过程中，业务架构规划将分解和对应到应用系统功能，而数据架构对应到数据库分析和设计。

数据架构包括静态和动态两个方面的内容。静态部分的内容重点在于数据模型、主数据定义，共享动态数据和所有业务相关的业务对象数据的分析和建模。而动态部分的重点则是数据全生命周期的管控和治理。因此，不能单纯地将数据架构理解为纯粹静态的数据模型。在业务架构中对数据架构的映射重点是主数据和核心业务对象，而应用架构中对信息模型的映射则进一步转换到逻辑模型和物理模型，直到最终的数据存储和分布。

数据架构与业务、应用的映射涉及几个矩阵分析，在业务架构阶段重点的是业务对象和业务流程、业务组件、业务功能间的类CRUD矩阵分析；而应用架构阶段重点则会是逻辑或物理模型对象和具体的应用模块或应用功能间的矩阵分析。两者关注层面不同，前者重点是主数据的识别和业务组件的分析，而后者的重点是应用功能模块的划分和模块间集成接口的初步分析。

对于数据集成分析，根据前面的思路也分解为两个层面的内容，一个是业务层面的分析，一个是应用和IT实现层面的分析。前者重点是理清业务流程或业务域之间的业务对象集成和交互，后者的重点是数据如何更好地共享或通过类似BI工具或ESB平台来实现数据的集成和交互。

在数据的全生命周期管理中，包括了单业务对象数据全生命周期，它往往和流程建模中的单个工作流或审批流相关；也包括跨多个业务域数据对象的全生命周期，体现的是多个业务对象数据之间的转换和映射，它往往是和端到端的业务流程BPM相关。数据虽然是静态层面的内容，但数据的生命周期或端到端的数据映射往往间接地反映了流程。