阿里要拆中台的消息，是20年12月下旬看见的。据说标志性事件是张勇在内网发布文章，表示他对阿里的中台并不满意，认为阿里的业务发展太慢，要把中台变薄，变得敏捷和快速。这距离他2015年年底在员工公开信中宣布对组织架构升级为“小前台，大中台”过去了5年，而在这5年里，中台概念早已不是阿里内部的一个名词，它成为近年来国内各个公司机构科技团队经常提及，乃至全力投入建设的方向。阿里这个消息一出，业界议论纷纷。
有趣的是，在看到这个消息的当天下午，就有好几位合作金融机构的部门领导给到微信，咨询的问题就一个：中台到底还值不值得投入建设，这个方向会不会走错了？关于这个问题的答案确实是见仁见智，下面是结合银行零售金融领域的实践，我个人的一些思考。
01 中台概念的兴起和本源
关于中台的概念，分类和应用，网上有非常多的介绍和解释。究其本源，中台概念最早出自于游戏公司，当时引入中台服务，就是为了提升游戏应用的创新效率，降低技术团队内的重复建设成本。提升效率，降低成本，多么熟悉的概念，每个从事金融领域工作的打工人，对三升两降应该都不陌生，每个科技人，一定也是天天听架构师们念叨着，解耦复用和不要重复造轮子。这种也许自打有狗那年就已经存在的问题，为什么在21世界的第2个10年，我们还要拿出一个叫中台的武器来解决呢？其实一直以来，为加强系统复用，提升整体研发效率，伴随着技术发展，科技解决方案也一直在演进。
首先是强调系统接耦合和科技模块复用。在各种设计模式思想的引导下，代码层面的模块复用思想，也拓展到系统层面。相比于在项目中每次实现相似功能模块，不如把系统模块拆分出来，并支持各类应用集成和调用。相关功能模块，往往以SDK的形式，集成在代码包中，通过标准的函数调用进行对接。
接下来是平台化和接口化。随着企业内项目越来越多，需求越来越复杂，模块解耦已经不能满足业务发展的需要。面向模块的管理工作越来越复杂，花费在模块去重分析上的资源，比完成模块设计开发的还要多。在这种背景下，将模块复用转为接口服务复用，并将企业内的服务汇集在统一平台上就成为了主流方案。一时间，企业内外多出了各种平台，而在平台化接口化的底层，是SOA的思想逐渐落地。各类消息中间件，如ESB，Dubbo等得到了广泛应用。企业内各个系统间采用Restful接口互联对接，成为了普遍的解决方案。
再后来，平台化接口化的服务也跟不上各类灵活多变的业务场景和服务模式的需求。对客户服务的敏捷迭代和快速创新，不能接受后台平台按月以上的迭代时间，而后台出于稳定性和共用性设计，也不能容忍频繁的调整修改。于是中台概念的推出，正好给出了答案，即在平台上层再抽象设计一层接口服务，一方面支撑多变的前台应用落地，另一方面又避免对后台的频繁修改，两全其美。当然，中台概念在发展阶段中，又衍生出很多其他的优势，比如支持服务开放，避免烟囱系统的构建，支撑全局的数据应用管理等等。
当然这些年中台概念能够这么火，远远不是因为它有这些潜在的好处。对于业界企业中的各种角色，中台有着无法抗拒的魔力。从某种意义上甚至可以说，中台有些被妖魔化了。
在管理者看来，中台是提升企业组织效率的关键。在传统定义上，业务团队和科技团队是需求和实现的关系，在企业内一个是负责营收的利润中心，另一个是负责支持的成本中心，两个团队互相合作，但目标价值体系总是略显不同。中台的出现，让原本处于中后台的科技团队更容易听到业务的炮火，做出更好支持业务的系统，而业务也更加能理解科技的能力和边界，提出更加靠谱的需求，两种角色团队的目标很容易趋同一致。于是，在各种中台建设方法论中，往往首当其中就是提出需要配合调整组织架构，也正是响应了这类诉求。
在业务人员看来，中台是解决业务发展瓶颈的良药。一直以来，业务受制于科技开发效率，无数次希望任何需求都能“明天上线”。然而，现实却是面对复杂的存量系统，和现有平台的稳定性风险，每个需求的设计，开发，测试总是要消耗大量的时间和成本。终于等到上线试用时，却往往又发现需求设计实现中存在偏差，需要再反馈再修改。整个过程的试错成本极高。如今听到中台的概念，终于可以做到避免后台重度开发，实现快速迭代快速上线，这实在是期盼已久的好事，必须同意快上。
在程序员看来，中台是职业发展的保证。为了保证技术的不断发展精进，每个阶段时间里程序员们总需要跟进新的技术热点来学习实践。最近几年来，对于企业应用服务，尤其是大型企业的系统，没有比中台更适合投入的方向了。概念很新且发挥空间很大，很多传统的框架方案套上了中台的概念，也变得非常酷炫。这也是最近几年各类中台层出不穷，让人眼花缭乱的一个原因。
所以，回归到原点客观来看，中台原本只是从科技侧出发，为提升效率，控制成本而产生的一个概念思路。后来背负上从组织架构设计到商业模式变革这么大的职责，实在是市场上各类角色不断丰富演绎的结果。看清本源，有利于让我们清晰思考，我们究竟为什么要做中台，我们还要不要继续做下去。
02 中台的适用性问题
在和很多金融机构沟通的过程中间，首先被问到的问题就是，中台有什么用，为什么我需要上中台？如果从上文分析的中台设计本源来说，相信所有的企业系统都需要提升效率，控制成本，看上去能够降本增效的中台是个包治百病的灵药。但另一方面，降本增效的办法也不限于中台一种，究竟处于什么状态的业务和系统需要用中台来升级呢？
首先，中台对系统水平有要求。提到中台，自然首先要有前台和后台。然而在很多企业的现有架构中，问题不在于要不要做中台，而是前台和后台都没有做区分，整个系统应用处于一个不解耦的单体中。很多情况下，架构设计人员甚至把前端页面或APP界面混淆为前台，计划在前端和后端之间嵌入中台，这都是对自身系统情况及中台概念没有充分理解的结果。
对于金融领域，尤其是银行零售业务领域，绝大多数的系统方案都能区分出前台和后台。因为在银行中，很早就有了账务核心系统和外围系统的概念。在很多情况下，我们都可以把核心系统看作后台，而把外围系统及对客应用看作前台，核心保持稳定，而外围系统要适应业务发展不断迭代创新。此时中台就可以是为了加速前台应用落地，节约应用建设成本而适用的方案。
第二，中台对业务模式有要求。中台不是变形金刚，它不能灵活高效的满足所有的业务场景需求，中台落地的基础是对业务模式的合理抽象。这点在这次阿里拆中台的例子里尤为明显。曾经阿里做的是相对固定生态里的业务创新，创新应用面向的客群，对应所需调用的后台服务是可以被概括总结出来的。因此基于固定的后台，建设各类中台，并基于中台服务进行拼装组合，就此实现前台创新应用的快速落地。而到了2020年底，随着市场上更多挑战者的出现，基于固有生态模式的创新已经不能满足市场竞争的要求，阿里需要的是自底向上，从后台到前台的整套服务方案的创新。此时相对固定的中台，反而成为了创新的制肘，中台资源的利用也就不再高效合理。
回到银行零售金融的场景，从发展历史来看，其业务场景是相对清晰的，比如绝大多数银行的零售业务都围绕存款，贷款，理财，信用卡等业务展开。服务流程是可被抽象的，主要可以从营销获客，业务办理，风控管理和运营服务等环节进行切入。在多年的业务积累中，各类创新，包括时下的数字化转型，也仍然是立足于这些业务场景和服务流程进行展开。因此，面向银行零售金融的中台建设，目前看并不会像阿里一样，出现中台妨碍创新业务方案落地效率的情况。
第三，中台对实现方式有要求。中台的建设不是一蹴而就的，同样中台的建设也不是一劳永逸的。在业务发展的过程中，要对中台的组件模块及其组织方式，进行持续性的迭代优化。只有采用适合业务场景的合理设计进行落地，才有可能真正满足业务日新月异的发展需求。在操作实践的过程中，最常出现的问题就是中台建设和前台业务需求脱节，中台只是闭门造车式的搭建模块服务，嗷嗷待哺的业务前台应用完全体会不到中台带来的价值。
还以银行零售金融举例。其业务中台模块的抽象，往往来自于原有零售金融前台应用公共模块的积累。其数据中台的服务，又往往来自于零售营销或风控业务所需的标签指标和模型服务。现在很多网上的中台案例，面向的是互联网电商场景。金融机构如果生搬硬套这些案例理论，上来就把订单，用户，商品，交易定为中台服务中心，是不能贴合实际业务应用需求的。所以很多中台实践，虽然花费了很大人力物力，换来的却是一套业务无法使用获利的方案，其问题并不出在中台理念本身，还是在中台的设计落地过程中实现方式出现了很大的偏差。
综上，中台不是万能的良药，它具有很明确的适用性。在市场逐渐看清中台的优势和局限后，我们既没有必要把中台思想奉为圭臬，也不需要把中台方案当成骗局一杆子扫进垃圾堆。对于银行零售金融业务来说，如果面对日趋频繁的业务方案创新需求，开发时间和科技成本已经成为主要的制约瓶颈，此时中台方案也许就是最合适的解决思路，而其成败的关键还在于能否采用合理可行的方案完成落地实现。
03 怎样才算实现了中台
在理解了中台设计的初衷和适用性后，另一个问题也时常被问及，即完成中台建设的标准是什么，有没有可以量化的指标集来衡量验证已经完成中台的搭建工作了呢。如果说中台建设是一个持续迭代的过程，那我们就从业务和科技的角度来分别看看如何衡量中台搭建的效果。
对于科技团队，工程效率是最直接的标准。同样的业务需求，在使用中台后，是否只需更短的时间和更低的成本就能够完成业务实现。技术架构是否得到统一，模块是否解耦并得到充分复用，技术团队内是否已经极少出现重复造轮子的情况，内外部的先进科技模块服务能否得到即插即用。科技团队负责人可以根据这些情况来进行判断分析中台建设的成熟度。
对于业务团队，在业务出现创新或者变化时，方案更新上线的时间是否明显缩短。曾经的中后台科技团队，是否已经和业务团队目标一致，把所需要用到的系统服务做了完善支持，甚至在业务发展前就已经做了提前设计。
当然，以上两点都是最基础的判断，考虑利用中台思想解决问题的出发点不同，企业可以回溯初心，看看是否已达到之前预期的要求。仍以银行零售金融为例，基于业务中台的业务方案是否变得更快上线，更灵活调整；基于数据中台的业务服务，是否消除了数据孤岛，做到了全生命周期的数据分析和管理；基于技术中台的科技系统，技术框架是否得到统一，内外部系统服务是否可以低侵入性集成等等。
在衡量中台建设成熟度的时候，应该牢记中台是手段，而不是目标。作为一种工具方案，中台是否成功的关键，不在于其本身架构设计是否高大上，而在于有没有完成初始的业务技术目标。黑猫白猫抓住老鼠就是好猫，如果真正实现了业务赋能提升，又何必纠结采用的技术方案是不是完全匹配中台建设方法论呢。
