治理工具的思考

近期在调研业界数据治理的工具，期望在24年的数据治理工作中，能够通过一些工具或者技术手段解决目前银行的一些治理痛点问题。 目前的主要痛点体现在哪里呢？数据治理工作没有深入到前台业务系统的数据模型开发过程中，无法有效的管控新增的业务设计的数据模型是否遵守数据标准。当大数据后端发现问题时，已经为时已晚，要投入的改造成本巨大。

前期的处理手段：采购了专门的数据建模工具，期望通过使用工具来解决标准对齐，质量监控的问题。但是该模型工具的学习成本较高，且没有强有力的手段来推动科技研发侧强制使用。导致治理工作开展的第一步就卡壳，因而影响了后续的数据质量监控，评估和反馈。

目前数据治理工具上的一个核心痛点是：数据治理的工具没有嵌入到研发业务开发流程中。细分来讲，有三方面的不足：

• 首先是缺少行内正式的制度 - 缺少明确的条例将治理检验的工作嵌入到前端业务模型的开发过程中，没有在开发流程中嵌入数据治理的介入。
• 其次是缺少灵活好用的工具，可以在开发的设计环节和测试环节对数据模型进行标准、元数据以及数据质量进行检查，形成治理质量报告。
• 再次是缺少足够的治理人员参与到研发的审核评估流程中。
• 最后对于存量的历史数据，还缺少一个全面的摸底评估。

以上的工作需要逐步在24年进行逐项的落地。

行内系统的思考

目前行内的科技系统繁多，对数据治理开展是非常大的挑战。通过和几家厂商的沟通来看， 缺乏一个统一且灵活的数据开发底座是一个大问题。 如果有统一的数据开发底座，并能同时应用于系统侧和大数据侧，可以将数据治理的工作聚焦在一个基座上，降低未来的治理成本。 但是现实的问题是: 统一的数据开发底座需要投入的资源巨大，且涉及到繁杂的系统改造和对接。仅为了数据治理工作的开展，很难真正推动行内进行这方面的落地。 退而求其次，需要在行内推广API服务化的系统接口改造。通过API服务实现将数据治理标准规范推广到各业务系统中，并能进一步将检核的结果定期推送到数据治理平台。进而实现治理数据分析的互动。