企业级数据治理-数据架构才是核心

大家好，我是月聊IT。

今天接着跟大家聊一下数据治理，因为好久没有聊过这个话题了。为什么又接着聊数据治理呢？因为最近跟朋友交流，发现很多做主数据、做数据中台的项目，整个建设实施相当不顺利，或者说很多项目最终中途夭折。里面的原因难道仅仅是简单的IT系统不行吗？实际上，对于大部分数据平台建设项目最终失败，核心原因就是相关的数据规划咨询和数据治理能力不行。

对于数据治理框架模型，我原来发过相当多的文章和视频，方便大家理解。其实我是把整个DAMA（数据管理成熟度模型）的核心内容做了一些简化。简单来讲，数据治理一定包括静态的数据标准模型管理和动态的数据生命周期管理。数据标准模型、数据架构的设计是一大类，而数据全生命周期管理是另外一个大类。

这就是对数据治理关键内容的简单理解。

如果展开数据治理部分，它不仅包括数据全生命周期（生老病死）的管理，还包括组织责权利、安全、质量的管理。这就是核心的数据治理内容。

对于数据全生命周期，又可以进一步展开。

• 单个系统内的数据全生命周期，就是我们说的创建、审核、审批生效或变更废弃。
• 如果是跨多个系统的全生命周期，就一定会涉及数据的采集、集成、清洗、存储、分发，或者数据服务。

这样大家就更容易理解数据治理的具体内容。

数据治理一般分为广义和狭义：

• 狭义的数据治理仅涉及数据全生命周期、数据标准规范、流程、责权利、数据安全与质量管控。
• 广义的数据治理，在大架构里一定会涉及数据架构和数据模型的内容。

当我谈到数据架构的时候，又离不开企业架构和4A架构。

大家都知道，在4A架构里面，数据架构之前一定会涉及到企业业务价值链、价值流的分析，业务架构的规划设计。通过业务架构的规划设计，到了业务建模阶段，逐渐识别出关键的业务对象，然后再把这个业务对象转成数据对象，接着进入到数据对象里面的概念模型、逻辑模型和物理模型。

同时，对于数据架构在新的概念里面，我们是把OLTP的架构和OLAP的架构两者进行了融合整体的考虑。对于面向业务的架构，就是我刚才说的，怎么样去设计概念模型、逻辑模型。而对于面向数据分析的数据架构，就是我们常说的数据采集回来形成的最底层的贴源层。然后贴源层怎么样变成上面的DWD层和宽表层，宽表层再怎么样根据实际业务决策数据分析的目标要求，变成上面的数据维度分析层。这个是OLAP的内容。

所以说你要去做数据架构，这个事情一定离不开业务。

因为数据建模、数据架构规划设计的源头是业务。只有梳理分析清楚业务流程、业务活动、业务单元，才能够识别出关键的数据对象。这个时候进行的数据建模工作，才能够更好地支撑上层的业务运作，包括支撑端到端的业务流程，以及更上层的数据分析决策。如果不清楚企业核心的业务，要做业务架构、数据架构基本上寸步难行。

包括今年年初，我跟一个做数据治理项目的咨询规划团队在沟通交流的时候，也一直在强调这个观点。就是他们可能需要两类做数据类的咨询规划顾问：

• 第一类可能是偏数据治理相关的咨询顾问。这类顾问其实只要对数据治理整个标准规范、数据治理的全生命周期，包括组织架构责权力的设计比较清楚，就可以做这个工作。
• 但是还有一类就叫数据架构规划设计的咨询顾问。对于这类顾问，必须要有相应的业务域的经验，包括有相关的通过数据建模、数据架构设计来解决业务问题的经验。

这些业务问题往往就是我们说到的，类似于由于数据不实时、数据不一致、数据多点落地、数据没有一个标准，导致的端到端业务流里面出现的断点，包括更深层次的一些问题。类似于数据在业务流转过程中形成了不同的数据对象。由于数据对象颗粒度不一致，导致的业务端到端流程没办法自动映射的问题。

最早期我们在做电信运营商本身的整个项目端到端流程的时候，就经常会遇到这个问题。因为在项目端到端流程里面，会涉及到立项采购计划、采购需求、框架协议、采购订单、采购接收单、装箱单，包括库存的出入库订单，到现场的发运单，以及后续实际的转资单。如果在这些单据上，你没办法做到数据对象颗粒度的映射，那么很多时候很难实现物资在现场安装组装完成后的自动转资动作。

数据架构的设计必须基于对业务的理解。所以说来说去，我今天还是想强调一个点：

数据治理要做好，不只是一个简单的标准规范方面的事情，更核心的是数据架构规划设计的事情。而数据架构规划设计，仍然要以企业架构、业务架构为核心的指导思想，基于企业核心的价值链、价值流端到端的业务流程驱动，去识别核心的业务对象、数据对象，乃至数据对象之间的关联映射，这样来构建完整的数据标准数据模型。

这样形成的数据模型，才能够真正支撑上层的业务运作，才能支撑后续的业务分析决策，这才是我们做好数据治理工作的关键。

好了，今天关于数据治理的简单分享就到这里，希望对大家有所启发。