争议 | 中小银行有无必要建立数据中台?用什么标准判断一个企业是否需要构建中台?_JAVA

企业是否需要建立中台,有什么标准可以自我判断?中小银行有无必要建立数据中台?

用什么标准判断一个企业是否需要构建中台?不能为了建设而去建设。

例如中小银行面临数字化转型的关键时期,面临技术不够成熟,基础设施基础架构不够重视,是否有必要有数据中台的存在?但如果没有数据中台,感觉数据调度,数据治理,数据质量等无法全面把控好。

以上是社区会员@wanggeng 某银行 系统运维工程师、@mythwind 某银行 数据仓库工程师提出的两个问题的整合,下文来自twt社区众多同行实践经验分享,欢迎大家参与交流,各抒己见。


@zftang0809 合肥华宇随身软件 软件开发工程师:数据中台解决的问题可以总结为如下三点:效率问题:为什么应用开发增加一个报表,就要十几天时间?为什么不能实时获得用户推荐清单?当业务人员对数据产生一点疑问的时候,需要花费很长的时间,结果发现是数据源的数据变了,最终影响上线时间。协作问题:当业务应用开发的时候,虽然和别的项目需求大致差不多,但因为是别的项目组维护的,所以数据还是要自己再开发一遍。能力问题:数据的处理和维护是一个相对独立的技术,需要相当专业的人来完成,但是很多时候,我们有一大把的应用开发人员,而数据开发人员很少。


@Derek20 股份制银行 大数据架构师:

数据中台建设必要性的论证是每家机构必做的功课,目前没有一个成熟且可量化的论证方案。这次讨论交流中也有很多朋友在咨询,这里我结合金融数据中台的建设实践,分享一个论证方案的思路,供各位参考。

整体思路:Step1 :数据中台的“能力“有哪些 -> Step2 :企业当前数据体系的“痛点“有哪些 -> Step3 :企业建设数据中台的技术储备是否满足 -> Step4 :数据中台”完整版“与”轻量版“的选择下面我简明扼要提一下每个论证环节的要点:论证环节 1 :数据中台的“能力“有哪些数据中台本质是通过数据技术统一标准和口径,对 “ 全域 ” 数据进行采集、加工、存储,治理形成一个口径统一的数据服务中间层,进而高效为业务层和决策层提供数据支撑。抽象几个关键词方便理解中台的“能力“:( 1 )数据质量治理的抓手(抓口径)、( 2 )数据出口治理的抓手(抓出口)、( 3 )数据服务的仓库(抓内容)、( 4 )高效迭代、高效运营(敏捷交付)。论证环节 2 :企业当前数据体系的“痛点“有哪些数据中台理念对大企业更具吸引力,可以对症很多企业成长到一定规模后的“数据病”。数据中台是否能够对症下药,需要我们架构师能够清晰分别和总结出各自企业的“数据病”症结。这里以金融机构的数据体系发展到数据仓库阶段时,举例分析所面临的“数据病”,以及论证环节 1 中总结的数据中台“能力”能否对症这些“痛点”:金融机构在目前的市场化阶段,各业务条线在一线经营上,为寻求新的增长点,提出了诸多个性化数据分析和服务的述求,在没有数据中台时,要满足诸多业务条线的数据需求,数据分析师需要在后台数据仓库上完成 T+1 的数据加工,然后将数据文件推送给各个业务前台系统,每个前台系统都维持一个小规模的数据团队,专门负责将数据文件转化为自己领域内的数据服务,实现业务述求。这种模式下痛点以及对数据中台架构选型的要求主要体现在以下几点:( 1 )痛点 1 :存储浪费大。数据以文件方式分发到各前台系统,均需要占用业务库宝贵的存储资源,尤其是通用场景数据(例如用户画像标签等),重复的资源浪费尤为突出,亟需集中化的存储和服务替代分散模式,体现在架构选型上,即需要 “ 云化的异构存储能力 ” 支撑;( 2 )痛点 2 :传递效率低。文件式数据传递链路以 T+1 批量为主,数据需要 “ 一股脑 ” 全部加载进本地数据库后方可使用,数据获取的效率远低于通过服务 “ 按需 ” 调用获取指定内容(例如指定客户信息、指定机构指标)。数据中台为了支持前端各具业务特色的数据应用场景,需要借助 “ 微服务 ” 解耦和组装;( 3 )痛点 3 :人力投入大。众多前台系统的数据转化工作收归沉淀在中台后,为了继续保持对业务场景迭代诉求的快速响应,就需要通过技术手段降本增效,提升中台持续交付能力。体现在技术诉求上,就是需要 “ 云化的部署运营能力 ” 支撑;论证环节 3 :企业建设数据中台的技术储备是否满足接下来要看,各位架构师所在的机构是否具备论证环节 2 中提到的数据中台“技术门槛”,例如包括“微服务”、“云化的异构存储能力”、“云化的部署运营能力”,概括出来就是目前另一个流行的理念“云原生”,数据中台的架构诉求与云原生有着“天然”的技术契合,这个在我另一篇发表过的文章中有详细阐述。这里将技术储备的要点,列出如下:争议 | 中小银行有无必要建立数据中台?用什么标准判断一个企业是否需要构建中台?_JAVA_02论证环节 4 :数据中台”完整版“与”轻量版“的选择分析清楚了 1-3 环节,那么我们基本具备了构建数据中台“完整版”的素材,这个“完整版”是一个包含一些列工具平台和管理规范的大工程,笔者所在机构构建的数据中台涵盖 Store 存储体系、 Service 服务体系、 Open 路由体系、 Plus 管理体系 4 大体系十余个子系统。但实际实践上,数据中台建设其实是有轻、重之分的,这时候就是考验我们架构师功底的时候,如何从庞大的体系中,抽取各家机构最关注的“轻量版”进行建设。举个例子,如果关注中台能力 1 “数据质量治理的抓手(抓口径)”,那么数据服务目录、数据指标管理两项功能模块就是必备功能;如果关注中台能力 4 “高效迭代、高效运营(敏捷交付) ” ,那么一套支持容器化运营的 devops 工作台、一组云原生底座则不可或缺。限于篇幅,不能完整展开每一项论证环节,各位架构师可以选取关注点,深入交流。


@Steven99  软件架构设计师:

中台的本质是复用,复用的目的是提高效率,减少投入,减少重复建设、提高可用性、降低耦合性、提升安全性等。需不需要中台,看企业自身的现状和发展规划。个人觉得,如果没有技术能力自主把控,还是先不要引入的好。数据治理做不好,中台更难做好,不是有个中台,就能做好数据治理,输出高质量数据了,相反,是做好了数据治理,有了高质量数据,才容易做中台。你看那几个大厂有谁中台做好了?没有吧,更多的吹嘘的成分,为什么?因为部门太多,系统太多,数据在企业内不规范不标准,没有实现高质量数据治理,去做中台,事倍功半。所以中台落地步骤和关系不要弄反了,否则会很累。数据调度,数据治理,数据质量是中台基础,建不建中台都不影响去完善这些事情。


@适者生存 人工智能(计算机视觉) 解决方案经理:

首先要明确的数据中台不是一个信息化产品,不是一套技术,而是一套对于数据的一套管理机制或是方法等。要不要建数据中台没有标准,企业应该就实际需求要定夺,同时还要看看企业现有的信息化基础,例如现在企业面临的问题、数据的积累程度、领导是否重视、信息化在企业中的定位。对于第二个问题——中小银行面临数字化转型 ,要实现数字化转型:1、首先要数字化,在中小银行发展的进程中,虽然不能和大型国有或是银行相比,但肯定也是有一定的信息化基础和很多业务系统的,数据也是有了一定的基础的积累的,2、其次是要通过数字化来驱动业务,如何来驱动?数据中台是一个不错的选择, 数据中台的核心就是让数据用起来 让数据发挥更大的价值,让数据具备生产力,来指导和引导银行业务。3、数据的重要性,数据现在已经被很多行业重视,和固定资产相对应的有了数据资产,如何形成数据资产,让这些资产来发展更大的价值,数据中台是必须的。4、数据中台的核心功能包括多源异构的数据的汇聚整合、数据的提炼加工(数据就和石油一样需要经过提炼之后才能使用)、数据资产的可视化(包括数据标准体系、元数据、数据治理、数据质量等)和数据的服务化(像水一样的对外提供服务,不需要为每个应用都单独建设管道和水龙头)。总结:此现状和需求下还是需要建设数据中台的。


@某银行 技术经理:本人作为在大、中小型银行都有过经历的人,对这一问题的理解谈下自己的看法。第一,相比大型银行,中小银行的科技力量是相对薄弱的,甚至有很多是不具备对现有技术架构,特别是中台架构理解的很透彻的,盲目的上,会导致技术的跨越和人才梯队的断层。第二,中小银行的科技部门始终在中小银行的地位不高,用技术的力量去驱动业务系统的全面转型,存在难度。但如果不实施数据中台,需要补课的东西就更多,我的建议是,在数据中台上还是要推动,起码要从业务架构上进行中长期的规划,数据架构马上就要开始梳理,技术选型同步就要开展,新建系统必须要打破数据壁垒,逐步往“数据中台”里迁移。


@biocy 五八到家信息技术有限公司 系统架构师:

个人觉得以上“技术不够成熟”“基础设施基础架构不够重视”都不是实施数据中台的理由,要想把控数据调度、治理、质量,应该有系统化的管理办法,技术部门内部就可以决策了。至于数据中台的实施,要有非做不可的必要前提、要得到技术一把手的支持、要有清晰的组织结构划分,不然就肯定得不到好的结果(条件齐备了也要看实施质量)。举个现实中遇到的例子,两个业务部门一方做事开放,另一方做事保守 ,单单一个数据权限审批流程的设计,就能让双方冲突。所以首先亮出遇到的问题,看看单纯依靠技术的解决方案是什么、实施成本有多高,再对比看看是否要放大到做数据中台。

@Steven99

你的想法我可能不赞同,这是很多公司都在搞的运动式中台建设,很难坚持下去。我们觉得要认识到中台的本质,坚持不断复用,迭代,可以从一个团队,一个部门,潜移默化中走向企业级中台,这样代价最小,成本最低,也最容易推进,唯一一点,就是有个人能清晰认识并坚持做下去。

@biocy:

是否能坚持下去,要看kpi在谁的身上,“运动式中台建设”很形象,如果一把手的意志不能贯彻执行,说明绩效分解是无效的,还是管理问题。单从一个团队一个部门去横向影响他人,大家的出发点和目标都对不齐,会白白浪费资源。中小企业在没成长起来时,是不可能知道未来的业务全貌的,提前拆分复用不见得适用于未来,要活在当下解决问题。

@mythwind:

个人感觉中小银行,有一部分很难坚持做下去,从上到下都不够重视,真的很难从技术部门搞这个。但中台决策感觉对中小银行特别有用,尤其面临业务能力欠缺。我自己觉得,一定要有上层的主推,技术在主导中虽然占据了一定的位置,但是并没有那么重要,关键是数据质量问题。个人感觉,中小银行,没有决策层的大力主导,很难行得通。

@biocy:

是的,中台战略是企业级战略,不是用了什么技术就建成中台了,而是要解决企业经营问题。不知道大家的企业高层中有没有EMT,战略问题必须自上而下协同进行。

@Steven99:

是啊,中小银行面临着现实的生存压力,等成长起来了再去做成本高昂,所以中台建设很关键还在管理层的认知和坚持。从下往上很难,所以很多人认为只有大企业才需要中台,可能是因为到了不得不建中台的地步,但其实中小企业去逐步实现复用,建中台反而更平滑,更高效,更节省成本。不过从下往上很难不代表没有机会,但能否成功可能要看企业实际和发展情况而定。