目录
4.数据中台的四大特征是统一治理、统一计算、统一服务、统一分析
01、数据治理、数据管理与数据管控
在日常工作中,数据“治理”、“管理”和“管控”常常被“混搭”。这种混搭,在不同的文件、报告、沟通层面,可能造成对数据工作的歧义,具体到谁来做、做什么、怎么做,特别需要概念层面澄清。
1.数据治理
是什么:事实上,治理面对的更多是战略层面、组织层面、制度层面的事务,是“make sure it’s be doing”,确立“什么样的决策需要在什么层级制定”。所以,数据治理是一个相对高阶的概念。
谁来做:对应的是一个“数据治理委员会”级别的机构,由这个委员会来建立数据治理的整体组织架构,定义责任主体,落实工作机制。
2.数据管理
是什么:“管理”是对“治理”的贯彻,是通过一系列实际落地的办法去实现“治理”目标的具体过程,是操作和实施层面的概念。
谁来做:数据管理对应的是一个以“数据管理部”级别的职能部门+各个相关职能部门的矩阵化组织。通过内建组织机构和工作机制,有牵头、有配合、有主责、有落实,在各自的职能领域去完成数据管理的具体任务,包括企业级层面的数据标准化、数据资产管理,业务领域层面的数据规范化、数据质量改进等等。
3.数据管控
是什么: “管控”是对“管理”要求在业务过程、产品设计、开发实现层面的具体实施。管控离不开“制度”+“规范”+“工具”+“考核反馈”,每一个管控机制,都应该有一个PDCA的管理循环。
谁来做:数据管控的落地,制度设计和规范定义层面,需要数据管理部门牵头推进,同时,也需要技术部门的工具和系统能力支撑,才能“管得了,管得住,管到位”。
如上图,清洁源头数据就是一个数据治理目标,数据标准管理办法、数据质量管理办法就是帮助实现治理目标所制定的管理制度,在开发过程中的标准管控、在运行阶段的质量管控就是在实际工作当中实现标准、质量管理的具体措施和手段。
02、系统架构、应用架构和数据架构
随着企业信息化程度的不断提升,以及有关方面对企业数字化转型的不断深入,“架构”成为热词。这个时候,无论是业务部门还是技术部门,往往会提到好几个架构术语,包括系统架构、应用架构。同时,随着数据治理工作推进,数据架构也映入眼帘,但是他们之间的关系仍然需要不断澄清。
1.系统架构
系统架构是一个相对技术化的专有定义,特指信息系统的物理设施+软件模块+功能组件的关系定义,狭义或低阶的系统架构范围可以是一个或一套业务或技术功能的系统,即所谓的功能级或部门级系统架构;广义或高阶的系统架构可以涵盖到企业级、全领域,形成企业级系统架构。相对而言,系统架构偏IT系统的实施层面,内容多包括软件、硬件、网络、协议等方面。
2.应用架构
应用架构的定义会更加突出“应用导向”,虽然系统架构也会陈述一些IT作业和功能的相互调用关系,但是这些内容是IT实施层面对业务需求层面的具体化,因此反而不容易被业务人员在自己的语言体系内掌握,这时候,需要一种业务化的架构解释,这个就是应用架构。今年以来,随着付晓岩等业界大咖的不断宣(who)传(you),业务架构一词也浮出水面,业务架构转型,企业级业务(应用)架构规划设计,分领域组件和分层体系的规划建设也不断在理论层面被丰富,在实践层面被完善。
3.数据架构
数据架构是一个古老而又年轻的概念。说古老,在于从IT系统诞生开始,就伴随着软件编码+数据结构,数据是软件的基本功,表结构设计是很多软件设计的第一步。说年轻,在于数字化转型以来,数据的体量规模、质量要求已经从TB发展到PB再到EB,一些领域已经到了ZB,量变带来质变,简单的表结构管理已经无法满足需要,数据架构管理应运而生。目前,数据架构管理的理论体系初步构建,在DAMA、信通院、金融科技标准化委员会的不断推动下,数据架构的标准化表述已经趋于统一,基本覆盖如下四个方面:数据标准管理、数据模型管理、数据资产管理、数据分