高校数据治理需全员共同参与
数据治理不能只是自上而下的顶层设计，也应该有自下而上的底层需求。
在数字校园建设时期，高校信息化建设的关注点在于整合数据资产，打通数据孤岛，建立数据中心，统一数据的抽取和推送等工作[1]。随着数字化3.0时代的到来，需要建设更加智能、灵活的校园数据生态[2]。
在数字校园向智慧校园过渡时期，各高校在数字化转型过程中逐步发现了校内业务系统数据的重要性，因此将数据资产纳入学校的统一管理和规划工作中。在数字校园建设打通的基础上，智慧校园建设更需要整合全校数据，协同全局业务。
数据治理现状
在智慧校园建设时期，高校必不可少地需要关注全校数据和全局方案，更加侧重搭建能够涵盖全校业务范围的建设架构。
在高校信息化建设迈向数字化转型的过渡时期，大数据分析、师生画像、数据驾驶舱等可视化数据的建设成为现阶段的一大亮点。
然而当面对全校数据时，我们发现各个业务系统的数据均存在偏差，几乎没有一个系统的数据可以完全标准和正确。高质量的数据分析和数据挖掘，是建立在有效可靠的数据基础上的。
因此，在智慧校园建设中，针对全校数据梳理、统一标准等问题，需要首先进行组织架构、身份权限、人员基础信息等数据的梳理，即数据治理工作[3]。
数据治理的起点，通常需要面对两个问题，全校数据资产的梳理和数据规范标准的制订。
在最初开展数据治理工作时，我们期望能够通过对业务系统业务和数据的了解，将多个系统所用的数据字段整合到一起，同时还规划了一套全校多系统适用的组织架构编码规则。
但是在数据治理项目逐步推进的过程中，我们发现越来越多的问题堆积到一起，从而使最终的目标变得迷茫起来。可见，数据治理的终点应该是一项长期稳定运行的基础建设项目。
在数据治理工作的初期阶段，我们面临来自架构、方案、技术等的诸多难题，出现了起步难、起步慢甚至绕弯路等情况。将问题进行大致总结，简单介绍如下：
第一，不同的业务系统对于业务数据的产生和定位不同，从整体来看，任何一个可以产生原始数据的业务系统都应该被当做数据源来看待。
由于业务管理和部门运营的特殊性，导致部分业务部门无法调整定位。因此，数据治理的最终目的可能会出现分歧。
在整合全校数据资产的过程中，或多或少会触碰到多套校内组织机构、一人多岗、一人多身份等问题，而不是将全校业务系统的数据简单地叠加到一起形成庞大冗余的超级大表。
第二，在数据治理过程中，花大力气处理了冗余数据、脏数据等，但是却在数据循环使用过程中发现其价值体现不出来。
技术层面认为需要按照统一标准调整的数据，在业务层面却认为此类数据价值较低。
相反，在业务层面意义重大的数据，却在数据治理起始阶段无法引起足够重视，容易造成效率低下的问题。
第三，对于问题数据的界定，很多时候并不能只通过数据治理平台来确定，因为有些错误、滞后的数据，在数据治理平台是无法反映出来的。
数据治理的粒度应根据问题数据的不同进行划分，数据不全、字段缺失、标准不一等问题可以通过平台级别的筛选来进行校对，但是数据的真实性、准确性、有效性等问题，还应针对每条数据进行逐一确定。
第四，数据治理的过程，是一个长期积累的过程，既需要整理数据，更需要梳理数据资产。
在数据共享时，往往会出现前期对需要共享字段评估不足的情况。在数据治理工作中，通常仅以某个下游系统所需数据字段为需求，向数据源头要求开放字段。
这种相对固定的数据对接思路除会带来以下多个问题以外，甚至还会产生更多的对接费用：
当下游系统所需数据发生变化时，无法灵活调整已做好的接口或中间库以响应数据的变化；
当其他业务系统需要复用源头数据时，只能以已同步的数据为准，无法调整个性化的所需字段，进而导致每接入一个系统都需要做一次对接工作；
最初对接时，若按照源头系统数据字段1:1全部复制进入数据中心，再加上数据治理等工作，这势必对数据治理和数据共享工作带来巨大的压力。
解决思路和方案
针对以上问题，在长期的数据治理和共享工作过程中，根据如何更加灵活、有弹性地进行数据管理、怎样更好地融合到智慧校园建设中这一标准，本文大致总结了几点应对思路，结合具体逻辑架构，简单介绍如下：
1.人员身份管理平台
在定义数据源头时，不应过度依赖权威数据源，各个业务系统数据在逻辑层面打通的情况下，应当相互验证、相互校对，并应建立一种机制，能够在源头数据无法调整和修改时，及时干预和调整，以保证下游系统接收数据的正确性和准确度。
同时，针对校内多个业务部门，应当有区别地调整和管理不同场景下的业务数据，形成多套组织架构和人员管理，并根据不同的场景和业务需求，进行数据的推送。
需要按照全校数据资产统一编码规则对组织架构和人员进行梳理和编码后，根据应用场景的不同，再对多版本数据进行有效管理和维护。详细架构图如图1所示。
图1 引入人员数据管理平台
和师生个人页面后的架构
数据治理需要遵循“价值驱动、按需治理”的原则[3]，当需要使用部分数据时，再去源头查询、治理。这样做看上去是在进行重复工作，但实际上是利用现有条件在闭环过程中的数据治理，在局部生态环境中理清数据，逐步扩大范围，最终达到全部数据得以治理的效果。
从图1中可以看出，数据的流向由源头系统流经治理平台后，存储至数据中心，再通过筛选和过滤汇总至人员身份管理平台。经过多版本数据的推送，给到下游业务系统。
在使用业务系统的具体过程中，逐步发现源头数据中存在的数据错误、数据不全等问题之后，可以通过人员身份管理平台予以介入，并进行细微调整；更可以将不同业务场景下的数据问题汇总起来反馈给数据源，精确定位到问题数据后再进行调整。
在重复多次流转过程后，形成源头数据——数据治理平台——数据中心——人员身份管理平台——业务系统——源头数据的数据流的内部循环，从而实现了数据治理的闭环，有助于发现问题数据，并且能够给予及时的处理。
图1 引入人员数据管理平台
和师生个人页面后的架构
在图1所示架构中，有几点需要特别说明：
在人员身份管理平台中，主要管理的核心是“人”而不是组织架构，通过每个人身上所有的信息、属性、标签来生成新的聚合，从而形成不同的组织和架构。
人员身份管理平台的介入，并不是意味着弱化或取代数据中心的地位。人员身份管理平台，是在可视化的业务层面明确人员关系和组织架构，数据中心是在数据层面确定数据的汇总和流向，在具体使用过程中，两个平台的功能在本质上是不同的。
可以通过人员身份管理平台来处理人员基础信息，调整人员数据，尤其是针对多版本数据的处理，但这并不是与数据源系统抢夺权威地位，也不是盲目矫正数据信息，而是根据学校内部业务具体场景来实现不同架构管理的灵活应对方案。
尤其是当数据源系统不能第一时间响应时，可以在人员数据管理平台临时调整人员数据，形成多版本数据，当源头数据准确时，人员数据管理平台便可自动感知，将手动调整的数据和源头同步的数据合并成同一版本数据，不需要人工再进行单独处理。
2.流程驱动数据管理
为确保单条数据真实性、准确性和有效性，需要师生个人作为数据主体参与其中，共同维护。借助流程引擎，驱动数据治理[4]，尤其是已经部署过网上办事大厅的学校，可以考虑在数据治理平台节点后、数据中心或人员身份管理平台的节点旁挂一个流程，在保证核心数据字段的基础上，嵌入允许师生修改个人信息的可视化表单，自动带出由网办数据库存储的人员基础数据，通过提交申请——审核的方式，收集到最新的师生个人数据。
经过审核后的数据流向数据中心或人员身份管理平台，并且根据是否与源数据一致而标识不同的数据状态，最终将更新后的数据和状态汇总至人员身份管理平台数据库中，再根据不同场景下的不同数据版本，推送到业务系统中去，完成最小粒度的数据清洗。
当师生在业务系统中发现个人基础数据不准确时，只需要登录办公系统查看个人页面，便可以完善和校对个人信息，修改表单并提交审核，从而完成用户端的数据采集工作，使得正确数据进入到数据流转过程中。
将细小粒度的数据校对交给师生自己处理，既能够让全校人员参与进来，也能够将信息中心和业务部门工作人员和业务系统厂商从庞杂的数据工作中解脱出来。
将人员基础数据适当暴露在师生面前，由系统管理员管理数据的模式转变为个人维护数据的方式，将孤立的旁观者转变为数据的维护者，既增加了师生的参与感，也使得数据信息更加融合和完善，进而促进数据流转的良性循环。
3.引入中间件
在数据不断积累的过程中，可以结合数据治理过程梳理数据资产，进一步形成数据资产目录。在掌握业务系统数据资产目录后，可以考虑在内网环境下引入一种中间件，与数据治理平台结合，多业务系统配合，实现业务数据无感知的采集和动态调整。详细架构图如图2所示。
图2 引入中间件后的架构
系统之间数据对接的模式，由最初的网状结构转变为目前常见的星型结构，即数据中心——业务系统的模式[5]。
在引入中间件后，或许给未来数据集成带来了新的模式——环型结构。将中间件插入至业务系统的前后端之间，对于业务系统本身而言，数据层和应用层的数据交互（增删改）均可以被中间件采集到，不必再去考虑接口对接及数据同步的细节问题。
中间件可以直接面向业务数据本身，屏蔽掉业务系统内部的复杂逻辑和操作步骤，直接切入至系统的数据层和逻辑层之间来获取数据。
这种数据集成方式，类似于切片一样将中间件插入业务系统，多个业务系统的集成便形成了一种环形域。这种环形结构的外边缘，定义了数据治理和数据共享的边界，在水平范围内覆盖到的系统，均可以自动进入到数据治理的范围内。在垂直方向上，中间件均以透明、无感的方式存在，对业务系统本身数据不做任何干预和调整。
作为中间件的植入，要面对异构数据库的多样性，和不同业务系统数据标准。因此，在最初定义中间件时便需要定义一个明确统一的标准，以及对应的接口。
中间件的植入，对于业务系统本身而言，在一定程度上破坏了原有系统自身的封装，更需要将已有的代码对照中间件的标准进行转换，或根据差异性做出对照表，实现标准的统一化管理。
跟传统数据对接需要提供接口或视图的方式相比，引入中间件后，需要业务厂商根据自己系统的具体情况，在中间件平台进行注册，有助于数据资产的梳理和管控。
中间件基于PaaS平台架构，介入到分布式系统中，与业务系统形成共生关系，共同适应全校的数据生态环境，构成良好的循环体系。
经过近两年的摸索和实践，我们发现数据治理这个全校性质的工作，是一项需要全员共同参与的工作。
这就意味着，数据治理不能只是自上而下的顶层设计，也应该有自下而上的底层需求，只有当顶层设计和底层需求相遇时，才能将架构设计与实施落地完美结合。
如何有效解决南北向数据分层流向的问题，涉及到对数据的逐层规划和管控，尤其是依据整体架构中各层数据定位不同的情况，还应有针对数据中心行列级别的数据安全和数据加密、确定数据安全等级、多维数据的采集和使用等问题的解决措施。
同时需要格外关注跨平台数据同步所需的时间周期，在减少拥挤的情况下，实现增量同步，缩短数据共享时间，增加过程效益。至于提高东西向水平流向的效率问题，更多的则是需要明确数据治理的动力和目的，逐步形成带权责的二维资产表，增强数据可用性，与流程相结合，提高数据服务意识，明确业务驱动需求。
多版本数据的管理、流程驱动和中间件的加入，对数据治理本身起到了补充和促进作用，有效促使智慧校园建设数据共享循环利用。
将源头治理的思想转变为分段治理、分层梳理和分域治理，在解决痛点的同时优化结构，在循环治理的过程中加强反馈。
经过长期积累和迭代，才能更好地完成底层数据治理工作，有效支撑更多上层应用。基于全校师生的协同合作和各个业务系统厂商的通力配合，才能实现更加融合、高效、赋能、动态的智慧校园生态建设。
参考文献
[1]崔天慧.校园数据共享平台的设计与实现(D)山东：山东大学2019.10.20.
[2]张亚勤.数字化3.0时代到来(J)中国工业和信息化2020.12.016：94-96.
[3]魏楚元.高校数据治理应始终坚持价值导向(J)中国教育网络2020.112020年11月刊：18-21.
[4]王珂，王小军，郝喆.基于数据治理的智慧校园建设路径(J)信息技术与信息化2021.92021.09.037：127-130.
[5]钱红兵，李艳丽.中国人民大学数据共享中心演进之路(J)中国教育网络2020.112020年11月刊：59-61.
作者：崔天慧（山东交通学院信息化建设与管理中心）
责编：陈荣
投稿、转载或合作，请联系：eduinfo@cernet.com
往期推荐
欢迎分享、在看与点赞
积极留言，更会有意外惊喜~