白癜风克星 https://myyk.familydoctor.com.cn/2831/content_927369.html
前言
一场疫情，让银行数字化转型再次提上日程。“无接触银行”不再是战略规划中亮眼的提法，而是如今各银行经营中不得不面临的切实问题。而中台，作为数字化转型中最火热的概念，这两年在行业里风头无两。中台是数字化转型的一剂良药，还是另一个风投炒作的概念？银行应该做中台吗？盲目上马中台项目有什么后果？本文尝试给出一个答案。
为什么要做中台？
数据中台
打通数据孤岛
主流的观点认为，做数据中台是为了打通数据孤岛。在互联网企业确实可以理解，但是银行对于数据的应用很早就开始了。大行普遍年前后就建成了数据仓库，数据层面早已将烟囱系统打通，那么数据中台的意义何在？
银行确实在数据方面很早就开始了尝试，加上金融是个低频场景，因此在相当长的一段时间内，T+1甚至T+2的整合数据基本够用了，更多数据整合和加工为的是满足监管需求。
随着移动互联网时代的到来，用户行为、市场、监管都发生了变化，各类服务移动化的趋势下，用户的使用时间碎片化，金融，特别是支付、理财等行为也变成了中高频交易，并且随着互联网巨头的进入，市场变化不可同日而语，银行的危机感日渐增加。
业务需求响应再快，也赶不上市场、客户、监管的变化速度，而应用开发速度就更慢了，大银行半年左右，中小银行三个月左右是常态。应用系统上线后，传统的基于数仓、数据集市的数据采集和整合方式在时效性上已经很难满足要求。可以说，银行在打通数据孤岛方面，或者更全面的说，在数据加工、分析，及发挥数据价值方面，尝试得很早，但是效果不佳——既不快，也不好。
不快很好理解，即时效性达不到要求，利用最新的流数据处理，分布式ETL技术，数据中台可以更快的整合、加工数据。可是打通效果不好该如何理解呢？
业务数据化
有句话说得好，数据是物理世界在数字世界的投影。既然是投影，那么光源和视角的不同，可能投影的结果也不同。
举个例子，同样一个事件，比如客户刷卡消费，在财务视角看来，是一笔应收账款；在业务视角来看，是一笔客户消费，账户/卡活跃，积分增加；从科技角度来看，交易流水表增加一条记录，账户余额表修改一条记录。我们很难用数据去精确描述一个事件，或者说，在银行的实际使用场景中，每个部门看待同一个事件的角度就是不同的，各部门需要从不同的角度看待同一件事，以便更好的完成自己的职能。在这里，各部门其实都是数据的使用者，即数据用户，那么，我们可以得到一个结论：数据用户对于数据的需求各不相同。
这也是银行要打造数据集市的原因，数据仓库采用相对标准化的数据模型（如FS-LDM）将数据聚合了起来，但是仍然难以满足所有业务人员的需求。因此各部门都提出了自己的数据集市需求。
正如上节中提到的，随着市场变化越来越快，客户变化越来越快，业务需求已经越发追不上他们变化的速度了，而数据的采集和加工速度则更慢，难以支持数据决策。于是，各部门又经常提出各类报表和数据提取的需求，这些都是针对临时的、紧急的、监管要求的、营销统计的数据需求，虽然这些需求更加贴近业务需求，但是在分析和开发上通常也要花费不少时间。
现在，我们可以回答上一节末尾提出的问题：数据孤岛打通的效果不够好，指的是数据的业务友好度不够。
总结银行数据加工的现状，可以得出下图：
在我们传统的数据应用中，随着数据对于业务友好度的增加，其时效性也在减弱。而我们的目标，显然是数据又快又好。既然各部门的需求都不一样，为何不让业务自助分析数据呢？于是我们有了右上角的目标状态。但是这个理想状态和我们现在的数据应用中间有巨大的空隙，靠什么来填补？答案是数据中台。
业务中台
优化烟囱系统架构
银行的数据之所以很早就在进行打通的尝试，主要原因就在于产生数据的业务系统，长期存在重复建设和烟囱系统的问题。到底是什么原因，造成了这个现象。我们其实可以从软件工程中经典的康威定律中窥见一斑：
Organizationswhichdesignsystemsareconstrainedtoproducedesignswhicharecopiesofthe
转载请注明地址:http://www.1xbbk.net/jwbfz/3500.html
