中台的末路

　　中台的概念不绝于耳，众多公司忙着搭建中台，这些中台背后的问题，你了解吗？
　　从2015年开始，到2019年现在为止。各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主，是某些架构师和PM的新出路，各种割韭菜的讲中台的课程层出不穷。
　　当然，吹牛逼的时候大家都是拣好的说，苦逼的东西就只有内部人士知道。中台到底靠谱还是不靠谱，只凭各路英雄的演讲内容，那看起来是靠谱的。
　　先来看看这些公开的观点，再以我的视角还原＂中台＂的真相。
　　按照惯例，手动贴上文章的目录：
　　一、公开的观点
　　1.1 中台是什么
　　阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价中心等十几个中心，而共享业务事业部正是＂厚平台＂的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
　　——钟华，《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
　　中台实际上是通用业务的下沉。
　　企业在一个行业耕耘多年之后，一般都会形成一些公用的业务，而这些业务是可以像中间件那样进行下沉共享的。
　　再往前推一些，也就是比较早期人们常说的偏业务的基础服务，在概念上并不是创新。
　　1.2 为什么要做中台
　　中台解决了什么问题？
　　其实和把程序内的公用逻辑封装为Library差不多，就是尽量避免重复造轮子。一个轮子造100遍，对部门是没有任何好处的；一个系统造100遍，对企业自然是没什么帮助的。
　　早期的企业经常借鉴腾讯经验，鼓励内部竞争。但内部竞争的度往往不好把握，经常会出现＂所有部门都在造差不多的系统＂的现象。
　　中台从公司战略角度，将这些行为进行了规范化，公共的部分交给公共系统部门去做。
　　1.3 中台给企业带来的收益
　　1）工程方面
　　就像上面提到的，首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置，并在公共服务上快速高效迭代出新的业务。
　　2）数据方面
　　有了统一的用户、订单系统，就不会再有各种恶心的数据打通问题，不会有跨部门的数据墙。
　　有了统一的中台，也就有了统一的数据规范。
　　对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行定制开发，浪费人力。
　　3）创新方面
　　这一项目也很好地诠释了之前所说的＂点、线、面＂的理论，在＂点＂上根本感知不到的问题，在＂线＂和＂面＂的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新！
　　——钟华，《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
　　有了公共的中台，意味着有了相对全局的视角，更能发现单点观察难以发现的问题，在更大的业务层面进行一定的创新——听着很有道理。
　　二、真相
　　中台能解决问题么？是能解决的。
　　中台能解决所有问题么？那显然是不能的。
　　就像微服务架构一样，架构师吹牛的时候天花乱坠，你做起来却发现这条路上全都是坑。
　　2.1 技术方面
　　公用业务下沉，这个理念其实很朴素。
　　所有程序员都知道我们公用的逻辑要进行封装、抽象，变成Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。
　　1）难以应对 Cross cutting concern
　　根据中台进行系统拆分和部门调整之后，还是会遇到 cross cutting concern，什么是 cross cutting concern：
　　The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.
　　有些需求难以避免地会影响整个流程中的所有系统：
　　比如，从技术范畴进行的一些改造（如为了完成tracing，所有系统增加trace id，并在log中默认携带）。
　　比如，从业务范畴进行的i18n改造（注：i18n是国际化的意思，Internationalization去掉头尾的i和n刚好还剩下18个字符，程序员的智慧）。
　　这些改造需求一般天生就是跨系统、跨组、跨部门的，事情一带上＂跨＂的字眼，就不好搞了。
　　举一个典型的例子，某巨型互联网公司员工抱怨，在当前的微服务和中台架构前提下，做一个需求经常要改20+个模块，苦不堪言，连上线顺序都不一定搞得清楚。
　　当这20+个模块又是跨部门的时候，就更难了。想要推动其它部门做一些短期看起来没啥收益的事，太难了。
　　2）稳定性和灵活性的矛盾
　　对于一个系统来说，追求稳定性，那么必然会在修改和升级上较为消极；追求灵活性，那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一，在一定程度上就得放弃另一方面。
　　就像网友经常讲的不作死就不会死，没有代码才是真正的稳定之道。
　　Google程序员在Github上发起的行为艺术项目：nocode，没有 code，就没有bug——可谓弃疗的典范。
　　有很多中台系统被剥离之后，因为用户众多，一旦出现技术上的问题，影响面巨大。
　　从我的实际观察来看，中台部门的系统虽然初始立项的时候声势浩大，但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆＂垃圾＂，＂垃圾＂在转过几手之后，后来的人基本就不太想对原来的代码进行修改了。
　　可能有人会讲你可以重构啊。
　　嗯，重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有！在没有测试的情况下，我们可以根据过往的系统需求文档和 PRD来还原当时的业务场景，并进行测试补充。
　　但你又发现，中台的性质（大多偏技术项目，基本没什么PM把关或者出文档）使其基本没有什么靠谱的、详尽的文档。写的复杂的中台，连业务流程都理不清楚，还想写测试，别做梦了哦。
　　3）中台与前台的模糊业务边界、距离
　　在实际实践时，中台与FT的边界往往划得不清不楚。比如，用户服务、用户权益、用户在各种子系统中的状态，这些内容可能并不是用户服务本身关心的内容。
　　但往往需求也会提给用户服务，这时候用户服务就只是进行字段存储，而状态机变化则完全在外部。
　　如果对系统内的个别数据不进行管理，那么有其它接入方接入时，就无法解释清楚字段的含义和使用场景。
　　如果不接受这些不相干的数据接入，那么前台流程系统可能会在自己内部重新建立自己的数据系统，这部分系统又极有可能和中台有功能上的重叠。
　　如果想要把这些数据接管过来，那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部，这往往又会产生与中台与前台业务边界的冲突。
　　难以给出有效的边界，就意味着无穷无尽的撕逼。这便是很多中台的两难：我接不是，不接也不是。
　　如果去问那些中台业务部门的系统开发负责人：某些业务要不要你们来做，连这些人自己都说不清楚。
　　2.2 人方面
　　如果要做中台，那往往需要将业务部门的一部分系统进行下沉。
　　下沉并不仅仅是一个技术问题。
　　如果要把系统从一个部门变到另一个部门，这一定会带来人员的调动。从情感上来讲，人们都是讨厌这种部门变动的。因为＂领导＂会在部门调整中发生变化，同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。
　　也有些公司在调整中进行粗暴的系统交接，如果系统需要下沉，那我直接从原来的维护团队手里夺过来，交给中台部门来管理。
　　这一样会引起双方的反感：
　　交接方：这是我们加班加点，辛辛苦苦开发出来的系统，凭什么交给别人？奋斗了半年难道就是为了给别人摘桃子？
　　被交接方：这个系统原来的维护团队水平极低，代码就是一堆＂垃圾＂，他们不想搞了就随便扔给我们？凭什么啊？我们又不是接盘侠。
　　即使贵司运气好，在系统交接过程中没有出现问题，那交接后也不好说。被交接的系统在交接后往往陷入消极维护状态，这时候前台业务接入中台会比以往更加困难，这种困难使前台业务的不满积累到一定程度之后，会再次催生前台部门重新造一套新的自己的中台，而部分或全部放弃原来的中台。这样，原来的中台部门便会陷入尴尬的境地。
　　生存空间被挤压，人也自然很难待得下去，各公司的中台部门，人跑的比香港记者都快。
　　2.3 部门、公司、组织架构方面
　　1）跨部门沟通障碍、跨部门目标差异
　　进行部门划分之后，每个业务部门会有自己的一套目标体系。部门与部门的目标（KPI）一般是不相同的，如果相同的话，那也就没必要分多个部门了。
　　而部门与部门之间的目标在某种程度上甚至可能有冲突。
　　例如，A部门Feature Team较多，主要负责业务功能迭代，需要更强的灵活性；而B部门负责中台数据，主要关心系统稳定性，也就是前文提到的灵活性和稳定性的矛盾。
　　若此时出现cross cutting concern，两个部门需要在矛盾上取得一定程度的平衡，这种平衡在个别情况下是不可得的。
　　例如在一段时间内，中台部门的目标是提高某个商业指标，让公司更赚钱/省钱。这时候前台业务提来了新的需求，这种需求是能使流程开发更加灵活的，但与中台部门的KPI不在一个航道上。
　　中台部门显然要把需求排排优先级，把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪，不如自己实现了。
　　前台业务也有自己的理由：＂自闭环＂嘛，这词真是好用。
　　2）公司利益分配
　　毫无疑问，距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。
　　中台看起来是业务，但又是公共业务，既然是公共业务，那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中，中台的强大、便捷是重要原因。
　　这会导致什么问题呢？
　　没有人愿意接手中台项目，中台项目变成烫手的山芋。大佬无法在中台项目上获得红利，小弟们没法在中台项目上获得利益。中台功能确定以后，只有出事故的时候大家才想起你来。稳定运行是应该的，出事就是你的锅！
　　3）利润中心？其实是成本中心
　　最重要的是让信息中心部门从之前在企业中＂业务支持＂的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的＂既精通业务，又熟悉技术＂的复合型人才。
　　在接下来整个社会进入开放共享的时代，企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营，到那个时候，这个部门将成为企业最为宝贵的资产。
　　——钟华，《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
　　在大多数公司，中台部门和基础架构一样，会被当成是包袱而不是财富。可能有些人读到这里会不太爽。
　　我们来看看，科技公司是怎么看待员工的呢？
　　在DDD相关的书里提到两个概念：成本中心、利润中心。
　　技术对业务参与不强的情况下，技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标，必须不情不愿地花钱去养你们这些技术团队。
　　对应业务侧开发来说，想要改变老板的这种看法，需要让业务系统和业务人员之间进行强联动，将一部分业务人员变成系统人员架构中的业务专家角色，或者是研发人员自己变成一个业务领域专家，就是有些人常说的你得跟老板穿一条裤子。
　　从这方面来讲，大多公司的基础架构角色就比较尴尬。业务驱动的公司，基础架构并不是其致胜要素。所以不管你做的再好，只要公司没有用技术赚钱，那么这部分的支出就只能被当作单纯的成本。
　　当然了很多做基础的大佬也根本不在乎，公司只是个练兵场，练成了带小弟们跳槽就好。
　　中台也是一样的，从业务一线剥离到后方之后。中台离业务的距离越来越远。公司高层渐渐看不到继续对中台进行投入的价值，中台便渐渐变成了他们眼中纯粹的成本中心，是公司财务的包袱而不是财富。
　　2.4 行业方面
　　中台建设一般要考虑公司的实际情况，这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向，可能来自于行业内其它公司的模式挑战。
　　理论上来说，只要一个公司的业务系统架构建设完成了，便已经完成了一种架构上的固化。这时行业内如果有新的模式获得了成功，公司肯定要进行跟进，但是新的模式一定意味着对原有系统、架构的挑战。
　　试想，原来系统架构是针对线上交易设计的，突然有一天，O2O模式被证明有利可图，大多数公司都开始转向线下。原有的流程、模式当然想要复用，但是这时候复用的成本很可能比重新开发还要高。
　　眼睁睁看着竞争对手们甩掉包袱，轻装上阵，以更低的成本更短的时间攻城略地，挤压自己的生存空间。
　　这时候怎么办呢？
　　大多数公司给出的方案是成立新的业务部门，在新趋势新阵地冲锋陷阵。新部门肯定也要用到原来公司的老服务，又碰到了我们的老问题：跨部门合作，新部门的成功并不会让老部门多得到多少好处，配合自然不会太积极。
　　如果新部门的尝试获得了初步成功，得到了公司资源的倾斜，获得了有效的人力资源补充。之后又会带来新一轮重复造轮子，互相不合作，互相撕逼的腥风血雨。
　　——简直是一个轮回。
　　三、结语
　　经常有小伙伴说，国内某公司中台非常好，大家都在学。
　　嗯，我倒是想问问了，如果真的做的好，某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构，和好几朵云？
　　作为一个技术人员，在各种乌七八糟、花里胡哨的概念＂轰炸＂下，应该能够保持理智，不要被各种人带节奏。
　　最后，把曹大博客的slogan分享给大家：
　　If you don’t keep moving, you’ll quickly fall behind.
　　第一次读到的时候，振聋发聩，和大家共勉！