从2015年到2019年，各大公司都在吹捧中台概念。看来中台是业务复杂度的救世主，也是一些架构师和PM的新出路。各种关于中泰的割韭菜课程层出不穷。当然，说到吹牛，大家都选择说出来，其中的硬道理只有圈内人知道。中台靠谱不靠谱，从各路大侠的言论内容来看，似乎靠谱。我们先看看这些舆论，再从我的角度还原“中国台湾”的真相。手动贴文章目录：众泰的公众看法是什么？阿里巴巴集团前端业务的公共通用业务已经入驻这个事业部，包括用户中心、产品中心、交易中心、测评中心等十几个中心。共享业务部是“厚平台”的真实体现，为阿里巴巴各项前端业务提供相应服务中心领域内最专业、最稳定的业务服务。钟华。《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》中台其实就是通用服务的下沉。一个行业经过多年的深耕，企业一般会形成一些公共服务，这些服务可以像中间件一样在下沉共享。再往前推一点，就是人们早期常说的面向业务的基础服务。概念上不创新。为什么需要中台？中台解决什么问题？其实类似于把程序中的公共逻辑封装成一个库，就是尽可能避免重新造轮子。造轮子100次对部门没有任何好处。一个系统建100次自然对企业没有帮助。早期的公司往往借鉴腾讯的经验，鼓励内部竞争。但内部竞争的程度往往难以把握，“各部门都在建设相似的系统”的现象时有发生。从公司战略的角度，中泰对这些行为进行了规范，将公共部分交给了公共系统部门。中台给企业带来的好处①工程化如前所述，首先，有效减少了重复造轮子、重复建制的现象。有相对统一的业务汇聚定位，新业务可以在公共服务上快速高效迭代。②数据方面有了统一的用户和订单系统，就不会再有恶心的数据对接问题，也不会有跨部门的数据墙。有了统一的中台，就会有统一的数据规范。对于大数据相关的需求，可以从一个相对独特的数据口进行业务迭代，无需每个部门定制开发，浪费人力。在创新方面，本项目也很好地诠释了前面提到的“点、线、面”理论。在“点”上根本感知不到的问题，在“线”和“面”的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，带来真正的商业价值给企业。这是一个很好的创新！钟华。《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》有了公共中台，就意味着有了全局视角，更能发现单点观察难以发现的问题。在更大的业务层面上进行一定的创新。这说得通。中台真相中台能否解决问题？它可以。中国和台湾能解决所有问题吗？很明显不是。就像微服务架构一样，当架构师吹牛的时候，你会发现路上满是坑。在技??术上，公共服务下沉的概念很简单。程序员都知道，我们常用的逻辑需要封装、抽象，变成一个Library。中台的本质其实就是在一定程度上推广这种简单的理念。（注：新瓶装旧酒）①横切关注难处理中台进行系统拆分和部门调整后，仍然会遇到横切关注。什么是横切关注点：横切关注点是一个适用于整个应用程序的关注点，它会影响整个应用程序。例如：日志记录、安全性和数据传输是应用程序几乎每个模块都需要的关注点，因此它们是横切关注点。影响整个过程中的所有系统。比如技术领域的一些改造（比如，所有系统为了完成trace，都会添加traceid，默认携带在log中）。比如从业务类进行的国际化改造。（注：i18n是国际化的意思，国际化去掉了开头和结尾的i和n，只剩下18个字符，程序员的智慧。）这些转型需求一般是跨系统、跨组、跨部门诞生的。一个“跨”字，做事不容易。（码农桃花源注：别人的站你能做主吗？）举个典型的例子，一家互联网巨头的员工抱怨说，在现在的微服务和中台架构的前提下，往往需要改20+个模块做一个需求，惨不忍睹，连上线的顺序都不一定清楚。当这20+个模块是跨部门的时候，就更难了。推动其他部门去做短期内似乎没有什么好处的事情，实在是太难了。②稳定性与灵活性的矛盾对于一个系统来说，如果追求稳定性，那么在修改升级上必然会更加被动；如果你追求灵活性，你会在功能迭代上更加激进。这两个方面的矛盾本来就难以调和。追求其中之一，到了一定程度，就不得不放弃另一个。就像网友们常说的，不死就不会死。没有代码才是稳定的真正途径。谷歌程序员在GitHub上发起的行为艺术项目：noCode，没有代码，没有bug。可谓是放弃的典范。很多中台系统剥离后，由于用户量大，一旦出现技术问题，影响巨大。从我的实际观察来看，虽然在立项之初中台部门的系统庞大，但基本上没有人关注这些公共系统的代码质量或测试质量。最后只是大家分享了一堆“垃圾”。“垃圾”转了几次之后，后来的人基本都不想修改原来的代码了。有人可能会说你可以重构。那么，重构的前提是系统有完整的测试用例和可以运行的测试。其实一般是没有的！在没有测试的情况下，我们可以根据过去的系统需求文档和PRD（注：ProductRequirementsDocument，产品需求文档）还原当时的业务场景，补充测试。但是你也发现，中台的性质（多为技术项目，基本没有PM检查或文档）使得它基本上没有可靠详细的文档。写个复杂的中台，连业务流程都不清楚，还想写个测试，别做梦了。③模糊的业务边界和中台与前台的距离在实际操作中，中台与FT的边界往往是模糊不清的。比如各个子系统中的用户服务、用户权限、用户状态，这些内容可能并不是用户服务本身关心的内容。但往往需求也是提供给用户的服务。此时用户服务只做字段存储，状态机的变化完全是外部的。如果不对系统中的个人数据进行管理，那么当其他访问方访问时，就无法清楚地解释字段的含义和使用场景。如果不接受这些不相关的数据访问，前端处理系统可能会在自身内部重新建立自己的数据系统，这部分系统很可能与中端存在功能重叠。如果要接管这些数据，那么中台需要梳理所有的业务场景。或者说，所有修改数据的逻辑都需要集中在中台内部，这样往往会造成中台与前台业务边界的冲突。很难给出一个有效的边界，这意味着无尽的撕裂。这就是很多中台的困境：接受不了，接受不了。如果你去问中台业务部门的系统开发负责人：你要不要做某些业务，连这些人自己都说不出来。在人这边，如果要做中台，往往需要下沉业务部门的一部分系统。下沉不仅仅是一个技术问题。如果要把系统从一个部门改到另一个部门，这必然会带来人员的转移。在情感上，人们讨厌这种部门变动。因为部门调整时“领导”会发生变化，同事往往会随着部门调整而离职。没有人愿意只留下自己来填补原地的空缺。也有部分企业在调整过程中进行粗略的系统交接。如果系统需要降级，那我就直接从原来的维护组拿过来，交给中台部门管理。这也会引起双方的反感：交接方：这是我们加班加点苦心开发的系统。为什么要把它交给别人？难不成我们挣扎了半年，就是为了给别人摘桃子？交接方：原系统维护团队水平极低，代码只是一堆“垃圾”。如果他们不想做，他们就把它扔给我们？为什么？我们不是索取者。就算你的公司运气好，系统交接过程中没有问题，交接之后就不好说了。移交后的系统往往在移交后陷入被动维护状态。这时候前端业务接入中台就会比较困难。这种困难使得前台业务的不满情绪在一定程度上积累，会再次促使前台部门重建一套新的自己的中台，部分或全部放弃原有的中台。这样一来，原本的中台部门就会陷入尴尬的境地。生存空间被挤压，自然很难让人留下来。各个公司的中台部门，人跑得比香港记者还快。部门、公司、组织架构①跨部门沟通障碍和跨部门目标差异部门划分后，每个业务部门都会有自己的一套目标体系。部门和部门的目标（KPI）一般是不一样的。如果相同，则无需划分多个部门。部门之间的目标甚至可能存在一定程度的冲突。比如A部门有较多的FeatureTeam，主要负责业务功能迭代，需要更大的灵活性。B部门负责中台的数据，主要关心系统的稳定性，也就是上面说的灵活性和稳定性的矛盾。如果此时出现交叉关注，两个部门需要在矛盾中取得一定程度的平衡，而这种平衡在个别情况下是不具备的。比如一段时间内，中台部门的目标是提高某项业务指标，让公司更赚钱/更省钱。这时候，前端业务带来了新的需求。这个需求可以让流程开发更加灵活，但是和中台部门的KPI不在一个通道上。中台部门显然需要分清需求，分清任务。前端部门会觉得中台支持一个需求这么慢，那么啰嗦，还不如自己去实现。前端业务也有自己的道理：“自闭环”，这个词真的很好用。②公司利益的分配毫无疑问，离企业近的地方比远离企业的地方更能分享到公司成长的成果。中泰看似是一家企业，但同时也是一家大众企业。既然是公共事业，基本上没有办法分享任何一个单一事业成功的红利。即使在其成功的原因中，中泰的强大和便捷也是重要的原因。这会造成什么问题？没有人愿意接手中期项目，中期项目成了烫手山芋。老板们在中台项目中拿不到分红，小弟们在中台项目中也拿不到好处。中台功能确定后，只有出事了，人家才会想起你。稳定运行是应该的，出事都是你的错！③利润中心？其实就是成本中心。最重要的是让信息中心部门从企业内部“业务支持”的组织职能转变为基于企业核心业务和数据的组织职能。运营团队，这个团队将更快更好地支持业务发展，逐步掌握企业的核心业务和数据，逐步培养出企业最紧缺的“业务精通、技术精通”的复合型人才。当整个社会进入开放共享时代，企业的最大价值将基于这些核心业务和数据进行开放运营。到那时，这个部门将成为企业最宝贵的资产。钟华。《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》在大多数公司，中台部门和基础设施一样，会被视为一种负担，而不是一种财富。有些人读到这里可能会感到不舒服。我们来看看，科技公司是如何看待员工的？DDD（码农桃花源注：领域驱动设计）相关书籍中提到了两个概念：成本中心和利润中心。当技术对业务的参与度不高时，技术部门基本上会被视为成本中心。也就是说，如果老板想要达到他的目的，他必须忍痛花钱支持你的技术团队。对于业务端开发，如果要改变老板的看法，就需要在业务系统和业务人员之间做一个强联动，把一些业务人员变成系统人员结构中业务专家的角色，或者研发人员他们自己。要想成为业务领域的专家，也就是有些人常说的要给老板穿一条裤子。从这个角度来看，大多数公司的基础设施角色都比较尴尬。对于一家以业务为导向的公司而言，基础设施并不是其制胜因素。所以不管你做得多好，只要公司不靠技术赚钱，那这部分支出就只能算是简单的成本。当然，很多做基础的大老板根本不在乎。公司只是一个训练场，训练完带领小弟们跳槽就够了。（码农桃花源注：请带上！）中台也是如此，从一线业务剥离到后方。大陆与台湾的距离，离商业越来越远。公司高层逐渐看不到继续投资中台的价值，中台在他们眼中逐渐成为一个纯粹的成本中心，这对公司的财务来说是一种负担，而不是财富的负担。在行业方面，中台建设一般需要考虑公司的实际情况，让这样搭建的系统能够应对公司一段时间内的业务变化。但是，企业的压力有时并不是来自于自身的业务方向，而是可能来自于行业内其他企业的模式挑战。从理论上讲，只要一个公司的业务系统架构完成，就完成了一种架构固化。这时候，如果行业内有新模式成功，企业就必须跟进。但新模式必然意味着对原有系统和架构的挑战。试想一下，原来的系统架构是为在线交易而设计的。突然有一天，O2O模式证明有利可图，大多数企业开始转向线下。当然，原来的流程和模型都想复用，但是这个时候复用的成本很可能比重新开发的成本要高。看着参赛选手卸下包袱，轻装上阵，以更低的成本、更短的时间攻城掠地，挤压自己的生存空间。这个时候怎么办？大多数企业给出的解决方案是，成立新的业务部门，在新趋势、新岗位上奋勇向前。新部门还要用原公司的老服务，又遇到了我们的老问题：跨部门合作。新部门的成功，不会给老部门带来多少好处，合作自然不会太积极。（码农桃花源注：公司内部工作是利益驱动的）如果新部门的尝试初见成效，将从公司资源上倾斜，人力资源有效补充。之后又会出现新一轮的重新造轮子，互相不合作，互相撕逼。简直就是一次轮回。结束语经常有朋友说，国内某公司在中国和台湾都很好，大家都在学习。那么我想问一下，如果真的做好了，某公司旗下的金融公司和电商公司还需要两套一模一样的基础设施，几台云？妈的！）作为技术人员，在各种乱七八糟、噱头十足的概念“轰炸”下，应该能保持理智，不至于被各种人牵着鼻子走。最后，跟大家分享一下曹达博客的Slogan：不继续前进，很快就会落后。
