一、略说中台

二、到底什么是中台

三、怎样构建中台

 这种模式没有太多的历史技术和业务的包袱，在业务简单、参与的人比较少的时候，往往可以获得一个比较快的支付速度。但是随着项目的不端推进，业务变得越来越复杂，参与的团队会越来越多，这时候这种烟囱式的团队建设就会体现出很多的弊端。例如最为明显的就是功能重复建设以及维护会带来重复的投资。另外更深层次的问题在于，这种烟囱式的团队，团队之间的沟通和协作会非常困难。即不利于企业的业务经验沉淀，也不利于技术梯队的建设。在企业长期的发展过程中，就会体现出人力资源内耗严重，项目新需求研发越来越慢，交付的产品质量越来越低。
       例如阿里在09年就成立了共享事业部，尝试对于烟囱式团队进行改造。经过多年的摸索，才逐渐将平台化建设的思路给梳理清楚，并形成了中台这样一个具体的体系。 

 
 究其原因，是因为从需求到交付的整个过程中，要经历的部门越来越多，部门之间的沟通成本也越来越大。例如要开发一个完整的需求，需要找各个团队要人，而分配过来的人可能又不懂这一方面的业务，互相沟通就会消耗大量的资源。于是也有企业会按照业务线划分业务部门，甚至有的大型项目，也会以业务为单位，外包给不同的公司，组建跨多个公司的复杂团队。但是随着业务部门的划分，业务之间的沟通又变得更加艰难。在面对复杂业务时，无法及时做出变化，造成团队响应缓慢，跟不上业务变化，从而在互联网的竞争当中错失先机。

         而具体到我们所讨论的代码层面，烟囱式的团队必然造成烟囱式的开发。每个团队都按照自己的技术栈形成自己的代码库。这里面有大量的像JDBC连接池这样的重复的功能。代码量增多了，其中隐含的BUG也会增多。测试团队所要覆盖的用例也随之增多，运维团队需要保证的维护方案也跟着增多。这样，整个团队的工作量一直增加的同时，代码的交付速度与交付质量也就跟着下降了。

          如何打破这个问题呢？阿里的中台战略就提出需要打破部门之间的隔阂，将横向的烟囱式架构竖过来，以业务需求为单位形成一个个快速组合的需求团队。每个团队都直接面对客户。例如电商中，要开发购物车功能，就由产品经理牵头，组建购物车团队，负责整个功能的设计、开发与上线。购物车功能开发完后，团队就解散，去做其他的功能。而当购物车功能需要进行变更时，再重新组建起需求团队，团队成员对整个购物车功能都是相当熟悉的，团队之间的沟通也是非常顺畅的。并且，由于团队人员不断的经历不同的业务线，企业内部的部门信息墙也就自然的被打破了。然后再结合微服务的技术架构，每个团队可以自己维护自己的微服务。开发完成后，也可以自行打包，独立发布，不需要等待其他团队，这样交付速度自然就提升了。

 然而，组建这样的团队对成员的要求是非常高的。每个需求团队中都需要有一个或多个组织者，这些组织者必须即懂业务，又懂开发，甚至还要懂测试和运维。所以在阿里内部，诞生出了非常多的业务架构师，这些业务架构师不同于一般的架构师，即能讨论技术架构，又能设计业务框架，无论从哪个方面来说，都是牛人。这种模式虽然好，但是如果每个企业，每个团队都照这个标准来组建，那企业的人力成本就会过高。这样的团队建设是没办法真正落地的。那如何解决这个问题呢？解决问题的关键就在于中台。中台的本质就是提炼各个业务的共同需求，进行业务和系统抽象，进而形成通用可复用的业务模型，打造成组件化产品，形成系统化的能力输出，供各个业务部门使用。简单来说，就是业务需要什么业务，需要什么资源，可以直接找中台，不需要每次去改动自己的底层。例如，如果一个支付企业在电商、零售等行业已经形成了非常丰富的支付业务能力，支持了非常多的支付场景，就可以沉淀形成支付中台。后续如果需要开发团购业务，需求团队就完全不需要自己开发支付方面的功能模块，直接找中台要就行。而在团购业务发展过程当中，有可能出现一些新的业务场景，需求团队可以交由支付中台统一提供支持，这样支付中台又能够进一步扩展
自己支持的支付场景，以后在设计新的业务时，提供更全面的支付场景支持。这样，新业务的设计与开发可以像拼积木一样简单快速，而中台也能在业务实施过程中，不断吸收养分，逐渐壮大起来。整个中台体系在企业内就形成了一个良性循环。在中台建设过程中，数据中台、业务中台和技术中台往往是一个相辅相成的建设过程，针对不同类型的中台也会有不同的建设重点与思路。

四、设计一个可以落地的微中台