（1）打通数据孤岛

主流的观点认为，做数据中台是为了打通数据孤岛。在互联网企业确实可以理解， 但是银行对于数据的应用很早就开始了。大行普遍 2008 年前后就建成了数据仓库，数据层面早已将烟囱系统打通，那么数据中台的意义何在？

银行确实在数据方面很早就开始了尝试，加上金融是个低频场景，因此在相当长的一段时间内，T+1 甚至 T+2 的整合数据基本够用了，更多数据整合和加工为的是满足监管需求。

随着移动互联网时代的到来，用户行为、市场、监管都发生了变化，各类服务移动化的趋势下，用户的使用时间碎片化，金融，特别是支付、理财等行为也变成了中高频交易，并且随着互联网巨头的进入，市场变化不可同日而语，银行的危机感日渐增加。

业务需求响应再快，也赶不上市场、客户、监管的变化速度，而应用开发速度就更慢了，大银行半年左右，中小银行三个月左右是常态。应用系统上线后，传统的基于数仓、数据集市的数据采集和整合方式在时效性上已经很难满足要求。可以说，银行在打通数据孤岛方面，或者更全面的说，在数据加工、分析，及发挥数据价值方面，尝试得很早，但是效果不佳——既不快，也不好。

不快很好理解，即时效性达不到要求，利用最新的流数据处理，分布式 ETL 技术， 数据中台可以更快的整合、加工数据。可是打通效果不好该如何理解呢？

（2）业务数据化

有句话说得好，数据是物理世界在数字世界的投影。既然是投影，那么光源和视角的不同，可能投影的结果也不同。

举个例子，同样一个事件，比如客户刷卡消费，在财务视角看来，是一笔应收账款；在业务视角来看，是一笔客户消费，账户/卡活跃，积分增加；从科技角度来看，交易流水表增加一条记录，账户余额表修改一条记录。我们很难用数据去精确描述一个事件，或者说，在银行的实际使用场景中，每个部门看待同一个事件的角度就是不同的，各部门需要从不同的角度看待同一件事，以便更好的完成自己的职能。在这里，各部门其实都是数据的使用者，即数据用户，那么，我们可以得到一个结论：数据用户对于数据的需求各不相同。

这也是银行要打造数据集市的原因，数据仓库采用相对标准化的数据模型（如FS-LDM）将数据聚合了起来，但是仍然难以满足所有业务人员的需求。因此各部门都提出了自己的数据集市需求。

正如上节中提到的，随着市场变化越来越快，客户变化越来越快，业务需求已经越发追不上他们变化的速度了，而数据的采集和加工速度则更慢，难以支持数据决策。于是，各部门又经常提出各类报表和数据提取的需求，这些都是针对临时的、紧急的、监管要求的、营销统计的数据需求，虽然这些需求更加贴近业务需求，但是在分析和开发上通常也要花费不少时间。

现在，我们可以回答上一节末尾提出的问题：数据孤岛打通的效果不够好，指的是数据的业务友好度不够。

总结银行数据加工的现状，可以得出下图：

在我们传统的数据应用中，随着数据对于业务友好度的增加，其时效性也在减弱。而我们的目标，显然是数据又快又好。既然各部门的需求都不一样，为何不让业务自助分析数据呢？于是我们有了右上角的目标状态。但是这个理想状态和我们现在的数据应用中间有巨大的空隙，靠什么来填补？答案是数据中台。

（1）优化烟囱系统架构

——Melvin Conway(1967)

换句话说，就是组织的沟通方式，决定了其设计的系统架构。回想银行内部的沟通方式，我们不难发现这些现象：以部门为中心，以部门 KPI 为导向，部门墙现象严重，跨部门沟通协作及其困难。由于 A 部门管理的 A 系统无法配合改造，为了实现相似的功能，B 部门只好新建一个 B 系统，这种情况屡见不鲜。这种种现象导致了银行信息系统的建设和管理都是面向部门的，换句话说，形成了烟囱式架构。

因此，中台的建设，必须包含组织架构的相应调整。否则，如果我们把中台具象为一个具体的产品，仍然按照原来归属某一部门或业务条线管理的话，无非是又增加了一个大烟囱而已。

那么，烟囱式架构到底带来什么问题呢？

对外，可能造成同一机构的不同产品、不同渠道，对客服务的体验不一致，甚至账号不互通，每用一个产品还需要客户新注册、开户，体验极差。

对内，成本高，可能造成重复建设，浪费本就紧张的科技资源，挤占排期时间， 激化内部矛盾；烟囱系统产生的数据，形成数据孤岛，为后期统计分析带来极大的困难，进而造成数出多门，甚至错误数据导致错误决策的严重后果；模块无法复用，经验无法共享，烟囱系统各自独立，无法复用其他烟囱的模块或经验，哪怕他们高度相似。

其实，银行也很早就开始烟囱式架构的治理，比如在渠道层，新建渠道整合平台， 在用户层，新建 ECIF 系统，所以说，银行并不是中台战略的追随者，而深感数据孤岛、烟囱式架构之痛的银行人，一直是中台战略的践行者，只是没有把这些尝试体系化、结构化而已。

（2）支持前台快速迭代

前文提到，市场、用户和监管的变化速度，远远快过业务系统迭代的速度，为了抹平这个差异，我们需要让业务系统，尤其是前端面向客户的系统尽量的敏捷。这也是目前业界流行的“小前台、大中台”提法的由来。

中台的故事，在国内起源于阿里，而其核心思想，来源于一家游戏公司（SUPER CELL），相比游戏行业，甚至电商行业的业务领域，银行的业务要复杂得多。因此在谈到业务中台时，我们难免会有疑虑：银行的业务系统，真的有那么多可以复用的功能模块吗？

我们不必照搬互联网企业的中台思路，仔细梳理银行业务流程，我们不难发现， 银行对于同类客户的产品，流程虽不同，功能多相似。以零售对客产品为例，站在用户视角，功能可以抽象为：注册、绑卡开户、充值提现、转账、购买赎回等， 站在机构视角，还可细化出反欺诈、数据采集、客户打标、交叉销售等。由于银行一直以来大多数依赖第三方供应商的成熟产品，为了应对不同银行的需求，这类产品通常是“大而全”的，包含了所有必须和非必须的流程和功能。这就导致直销银行、手机银行、微信银行等等渠道，都重复实现了类似的功能。

其实微服务的思想就是将大的系统，拆分为小的应用和服务，高内聚、低耦合， 发布有价值的服务，即可被使用和共享的服务。而高内聚、低耦合也一直是银行设计架构的基本原则。因此，我们可以看到，银行的架构设计、微服务体系、中台架构一脉相承，都是为了共享功能下沉复用，减少重复造轮子的现象。

这带来的好处，就是新建应用的时候，可以通过已有成熟模块的组装，实现快速上线，从而加快业务系统的迭代，真正实现“小前台”，更好更快的相应市场、客户和监管的变化。

综上所述，中台建设是银行进行数字化转型的关键举措，势在必行。

2019 年被称作中台元年，一时间，各种中台概念、各种形式的中台方案如雨后春笋一般层出不穷。目前，中台并没有一个放之四海而皆准的标准定义，根本原因， 在于中台并不是一个标准化的产品，根据每个企业自身的情况，中台的建设方案可能千差万别。

不过，可以达成共识的，是中台的特点，它是企业共享能力、共享数据的组织或平台，并且具备业务属性，能够实现业务价值，有响应的组织架构支撑。

 上一节我们探讨了做数据中台的原因，由此我们可以给出数据中台的使命，是为了打通数据孤岛、实现业务数据化，让数据更快更好的产生价值。

结合数据中台的使命，我们可以将其分为狭义的数据中台和广义的数据中台。

狭义的数据中台，指的是一套数据应用和工具，包括分布式 ETL、数据资产管理、数据标签管理、数据沙箱、自助分析平台、元数据管理、数据质量管理等等，底层则已现有的数仓、大数据平台等为数据源，为企业提供数据资产管理的能力， 并持续挖掘数据价值，持续提供数据智能服务。

广义的数据中台，则在狭义的数据中台基础之上，包含了顶层数据战略，数据治理体系以及数据管理及运营、数据文化培养和组织架构支撑，是一套持续管理和运营的体系。

可以这么说，狭义的数据中台，是专为达成数据中台的使命而打造，一类是让数据更快的处理、整合、加工，比如分布式 ETL 工具。随着传统数据被大数据平台逐步替代，ETL 工具对于大数据平台的适配也需要与时俱进，支持分布式计算、弹性计算，并且减少开发量。

另一类是让数据更好的产生业务价值，比如数据标签管理，自助分析平台等。数据标签大家都在用，但是真正深度使用的企业都会感觉：建好容易用好难，如果没有一套标签管理系统，标签是否重复加工，标签的使用率、准确性等都无从掌控，业务部门想要针对近期营销活动新建一个标签，还得走开发流程，时效性也难以保证。

数据标签管理系统就是为了解决数据标签的使用问题而建立。自助分析平台则是方便业务人员自助进行数据分析、加工、探索的平台，它与数据沙箱结合，直接将去隐私话的生产数据提供业务人员分析，使数据更快的产生价值， 支撑关键决策。

广义的数据中台，则是辅助狭义数据中台达成使命的机制，虽然看起来都很“虚”，但是却是数据中台成功落地的必要保障。

没有数据战略，在推进数据中台建设，甚至建成后的日常运营中，难以沟通协调各部门利益，缺少“尚方宝剑”。没有数据治理体系，数据管理无凭无据，无章可循，很容易造成 Garbage In-Garbage Out 的现象。

但是这里必须澄清一点，在银行信息系统这样复杂的环境中，数据质量的问题永远存在。因此，“等数据治理好了，等数据质量控制好了，我们再开始做数据应用，做数据中台”，这种想法是不切合实际的，因为不存在数据质量控制好了，数据治理好了的那一天，这是一个持续的过程，好到什么程度算好？谁来决定这个标准？

我们认为，数据质量很重要，需要持续改善，但是不影响数据中台建设， 应该以用促治，在使用场景中有针对性的开展数据质量管理和数据治理。

没有数据管理及运营，数据应用的价值无法持续产出，甚至会出现便宜甚至错误。缺乏数据文化，则会造成数据应用没人会用，没人想用，没人愿意相信数据结论， 没人愿意尝试数据驱动，没人愿意基于数据决策。没有组织架构支撑，则会让数据中台这样跨部门的体系难以推行，最终胎死腹中。

同样，业务中台也可分为狭义与广义，狭义的业务中台，指的是由多个共享中心组成的服务整合平台，通过梳理各业务系统共性的功能，在每个中心里将服务拆分、共享。我们建议，可以按风控中心、产品中心、用户中心和旅程中心等维度整合共享，底层的数据能力由数据中台提供。

广义的业务中台则包含了支撑各中心运营的组织架构和体制机制。正如前文提到， 没有组织支撑，中台不过是另一个大烟囱。每个业务中台的子中心，都应有对应 的组织支撑，可以是虚拟的，也可以是实体的，最好由业务+科技+风险+数据的 综合人员构成，小团队作战模式，以产品使用率、稳定性、客户满意度等为 KPI， 为业务中台保驾护航。

风控中心管理全行所有的风控模型，以及对客产品交易、账户层面的动态安全策略，以底层机器学习平台为支撑，共享全行风险管理能力。产品中心管理全行所有渠道的产品，控制购买额度、购买条件，灵活上下架等。

用户中心基于数据中台打通的全行用户信息，建立用户成长体系、权益体系，管理用户标签画像，分析用户行为轨迹，为旅程中心完成客户全渠道一致体验打下基础。

旅程中心以用户视角出发，以用户体验为最终目标，梳理、贯穿各渠道流程，整合、复用各渠道功能，最终达成全渠道客户体验统一。

了解了中台是什么，最后，我们来看看中台不是什么，或者说，中台的边界在哪里。 

首先，中台不是银弹。

没有银弹：没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步

——《人月神话》

软件工程领域的“圣经”《人月神话》早就提出了没有银弹的说法，中台也不例外。不要妄想通过中台，解决企业内部一切的数字化问题。即使是上文提到的广义中台，也仅仅是包含了企业数字化转型中，与数据、业务中台相关的组织和机制，但是仍然无法涵盖一个组织在数字化转型过程中遇到的各种问题。中台与其他新技术体系一样，可以帮助企业降本增效，但是如何选择业务方向，如何团结一心，如何切入市场，如何找到目标用户等等，都是企业在中台之外还需要努力的方向。

其次，中台不是一个可以买来的即插即用产品。

不必为了做中台而做中台，也不必大干快上，一起步就是一个五年大工程。由于中台与企业内部的数据、业务系统高度相关，虽然有相对标准化的产品可以预先研发，但是更多的工作，在于中台与存量系统的对接、优化。

最后，中台不是一个筐，别什么都往里装。

当一个新技术体系难以明确定义时，最常见的现象就是边界模糊，什么都可以放进去。最典型的例子就是“大数据”了。虽然有类似“5V”的定义，但是大数据的定义从来没有统一，这也导致现在只要提到数据，都会冠以“大数据”之名。实质上，大家所指的绝大多数数据，并非是“大数据”，都是“小数据”。

概念的模糊，使得炒作时，无数企业挤破头往里冲，也导致行业发生合规风险时， 与“大数据”沾边的企业都风声鹤唳，草木皆兵。这种现象，对于行业的发展弊大于利。

因此，我们必须厘清中台的边界：无共享，不中台；无业务，不中台；无组织， 不中台。

没有共享能力、数据的整合，不算中台；没有直接服务于业务，产生业务价值， 不算中台；没有组织支撑，仍然服务于某个部门，不算中台。 

行文至此，希望解答了大家心中的疑问。简言之，做了中台不见得就是数字化领军企业，不做中台也不见得就是古典互联网时代的落后作坊。关键是认清自身的数字化现状，拟定数字化目标，制定数字化路径，优选场景，实现价值。中台只是这条道路上，一套切实可行的行动方案。糟糕的公司治理，三天打鱼两天晒网的战略定位，部门银行的组织架构，即时搭建了中台，也徒有其表，如此，中台是砒霜。

坚定的战略，清晰的目标，合理的组织架构，搭配中台，可以使数据更快更好的发挥其价值，业务模块更好的融合，用户体验得以更好的提升，如此，中台是蜜糖。

(欢迎大家加入数据工匠知识星球获取更多资讯。)

了解更多精彩内容

长按，识别二维码，关注我们吧！

数据工匠俱乐部

微信号：zgsjgjjlb

专注数据治理，推动大数据发展。