中台是业务复杂性的救世主。是某些架构师和 PM 的新出路。各种割韭菜的讲中台的课程层出不穷。
当然，吹牛逼的时候大家都是拣好的说；苦逼的东西就只有内部人士知道，中台是靠谱还是不靠谱。只凭各路英雄的演讲内容，那看起来是靠谱的。
先来看看这些公开的观点：
中台是什么
阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战
中台实际上是通用业务的下沉，企业在一个行业耕耘多年之后，一般都会形成一些公用的业务，而这些业务是可以像中间件那样进行下沉共享的。
再往前推一些，也就是比较早期人们常说的偏业务的基础服务。在概念上并不是创新。
为什么要做中台
中台解决了什么问题？
其实和把程序内的公用逻辑封装为 library 差不多，就是尽量避免重复造轮子。一个轮子造 100 遍，对部门是没有任何好处的。一个系统造 100 遍，对企业自然是没什么帮助的。早期的企业经常借鉴腾讯经验，鼓励内部竞争。但内部竞争的度往往不好把握，经常会出现“所有部门都在造差不多的系统”的现象。
中台从公司战略角度，将这些行为进行了规范化。公共的部分交给公共系统部门去做。
中台给企业带来的收益
工程方面
就像上面提到的，首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置，并在公共服务上快速高效迭代出新的业务。
数据方面
有了统一的用户、订单系统，就不会再有各种恶心的数据打通问题，不会有跨部门的数据墙。
有了统一的中台，也就有了统一的数据规范。
对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行订制开发，浪费人力。
创新方面
这一项目也很好地诠释了之前所说的“点、线、面”的理论，在“点”上根本感知不到的问题，在“线”和“面”的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新！
钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战
有了公共的中台，意味着有了相对全局的视角，更能发现单点观察难以发现的问题。在更大的业务层面进行一定的创新。听着很有道理。
真相
中台能解决问题么？是能解决的。中台能解决所有问题么？那显然是不能的。
就像微服务架构一样，架构师吹牛的时候是天花乱坠的，你做起来却发现一条路上全都是坑。
技术方面
公用业务下沉，这个理念其实很朴素。所有程序员都知道我们公用的逻辑要进行封装，进行抽象，变成 Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。
难以应对 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 改造。
这些必然会涉及到中台和前台系统的改造。cross cutting concern 如果这么好应对的话，那也就不会变成一个概念了。
举一个典型的例子，某巨型互联网公司员工抱怨，在当前的微服务和中台架构前提下，做一个需求经常要改 20+ 个模块，苦不堪言，连上线顺序都不一定搞得清楚。
稳定性和灵活性的矛盾
对于一个系统来说，追求稳定性，那么必然会在修改和升级上较为消极；追求灵活性，那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一，在一定程度上就得放弃另一方面。
就像傻屌网友经常讲的不做死就不会死，没有代码才是真正的稳定之道。在 Github 上 Google 程序员发起的行为艺术项目：nocode，没有 code，就没有 bug。可谓弃疗的典范。
中台与前台的模糊业务边界、距离
在实际实践时，中台与 FT 的边界往往划得不清不楚。比如比如用户服务，用户权益，用户在各种子系统中的状态，这些内容可能并不是用户服务本身关心的内容。但往往需求也会提给用户服务，这时候用户服务就只是进行字段存储。而状态机变化则完全在外部。
如果对系统内的个别数据不进行管理，那么有其它接入方接入时，便无法解释清楚字段的含义和使用场景。如果不接受这些不相干的数据接入，那么前台流程系统可能会在自己内部重新建立自己的数据系统，这部分系统又极有可能和中台有功能上的重叠。如果想要把这些数据接管过来，那么中台又需要梳理了解所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部。这往往又会产生与中台与前台业务边界的冲突。难以给出有效的边界，就意味着无穷无尽的撕逼。这便是很多中台的两难。我接不是，不接也不是。
如果去问那些中台业务部门的系统开发负责人，某些业务要不要你们来做。连这些人自己都说不清楚。
人方面
如果要做中台，那往往需要将业务部门的一部分系统进行下沉。下沉并不仅仅是一个技术问题。如果要把系统从一个部门变到另一个部门，这一定会带来人员的调动。从情感上来讲，人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化，同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。
也有些公司在调整中进行粗暴的系统交接，如果系统需要下沉，那我直接从原来的维护团队手里夺过来，交给中台部门来管理。这时候一样会引起双方的反感：
即使贵司运气好，在系统交接过程中没有出现问题。那在交接后也不好说。被交接的系统极有可能在交接后陷入消极维护状态。这时候前台业务接入中台会比以往更加困难，这种困难使前台业务的不满积累到一定程度之后，会再次催生前台部门重新造一套新的自己的中台，而部分或全部放弃原来的中台。这样原来的中台部门便会陷入尴尬的境地。
君不见，各公司的中台部门，人跑的比香港记者都快。
部门、公司、组织架构方面
跨部门沟通障碍、跨部门目标差异
进行部门划分之后，每个业务部门会有自己的一套目标体系。部门与部门的目标(KPI)一般是不相同的，如果相同的话，那也就没必要分多个部门了。
而部门与部门之间的目标在某种程度上甚至可能有冲突，例如 A 部门 Feature Team 较多，主要负责业务功能迭代，需要更强的灵活性。而 B 部门负责中台数据，主要关心系统稳定性。也就是前文提到的灵活性和稳定性的矛盾。这时候出现了 cross cutting concern，两个部门需要在矛盾上取得一定程度的平衡。这种平衡在个别情况下是不可得的。
例如在一段时间内，中台部门的目标是提高某个商业指标，让公司更赚钱/省钱。这时候前台业务提来了新的需求，这种需求是能使流程开发更加灵活的，但与中台部门的 KPI 不在一个航道上。这时候中台部门显然要把需求排排优先级，把任务排排主次。这时候前台部门的感观便是中台在需求支持上实在是龟速，不如自己实现了。
前台业务也有自己的理由：“自闭环”嘛，这词真是好用。
公司利益分配
毫无疑问，距离业务近的地方比距离业务远的地方能分到更多公司增长的红利。中台看起来是业务，但又是公共业务，既然是公共业务，那基本上没办法分享到任一单一业务成功的结果。纵使其成功的原因中，中台的强大、便捷是重要原因。
这会导致什么问题呢？没有人愿意接手中台项目，中台项目变成烫手的山芋。大佬无法在中台项目上获得成果，小弟们没法在中台项目上获得利益。中台功能确定以后，只有出事故的时候大家才想起你来。稳定运行是应该的。出事你就背锅吧。
利润中心？其实是成本中心
最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营，到那个时候，这个部门将成为企业最为宝贵的资产。
钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战
在大多数公司，中台部门和基础架构一样。一定程度上会被当成是包袱而不是财富。可能有些人读到这里会不太爽。我们来看看，科技公司是怎么看待员工的呢？
在 DDD 相关的书里提到两个概念：成本中心、利润中心。技术对业务参与不强的情况下，技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标，必须不情不愿地花钱去养你们这些技术团队。对应业务侧开发来说，想要改变老板的这种看法，需要让业务系统和业务人员之间进行强联动，将一部分业务人员变成系统人员架构中的业务专家角色，或者是研发人员自己变成一个业务领域专家。从这方面来讲，大多公司的基础架构角色就比较尴尬。业务驱动的公司，基础架构并不是其致胜要素。所以不管你做的再好，只要公司没有用技术赚钱，那么这部分的支出就只能被当作单纯的成本。
中台也是一样的，从业务一线剥离到后方之后。中台很可能离业务的距离越来越远。这时候从公司的角度来看可能渐渐感觉看不到继续对中台进行投入的价值。对待中台的态度便渐渐变成了纯粹的成本中心。是公司财务的包袱而不是财富。
行业方面
中台建设一般是要考虑公司的实际情况的，这样建设出来的系统一般可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向，可能来自于行业内其它公司的模式挑战。
理论上来说，只要一个公司的业务系统架构建设完成了，便已经完成了一种架构上的固化。这时行业内如果有新的模式获得了成功。公司肯定要进行跟进。但是新的模式一定意味着对原有系统、原有架构的挑战。试想，原来系统架构是针对线上交易设计的，突然有一天，O2O 模式被证明有利可图，大多数公司都开始转向线下。原有的流程、模式当然想要复用，但是这时候复用的成本很可能比重新开发还要高。眼睁睁看着竞争对手们甩掉包袱，轻装上阵，以更低的成本更短的时间攻城略地，挤压自己的生存空间。
怎么办呢？你说呢？
结语
经常有小伙伴说，国内某公司中台非常好，大家都在学。嗯，我倒是想问问了，如果真的做的好，某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构，和好几朵云？
本文作者:Cao ChunHui 来源:网络收集
CIO之家 www.ciozj.com 微信公众号:imciow