从2015年开始，到2019年现在为止。各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主，是某些架构师和PM的新出路，各种割韭菜的讲中台的课程层出不穷。
当然，吹牛逼的时候大家都是拣好的说，苦逼的东西就只有内部人士知道。中台到底靠谱还是不靠谱，只凭各路英雄的演讲内容，那看起来是靠谱的。
阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价中心等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
企业在一个行业耕耘多年之后，一般都会形成一些公用的业务，而这些业务是可以像中间件那样进行下沉共享的。
其实和把程序内的公用逻辑封装为Library差不多，就是尽量避免重复造轮子。一个轮子造100遍，对部门是没有任何好处的；一个系统造100遍，对企业自然是没什么帮助的。
早期的企业经常借鉴腾讯经验，鼓励内部竞争。但内部竞争的度往往不好把握，经常会出现“所有部门都在造差不多的系统”的现象。
就像上面提到的，首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置，并在公共服务上快速高效迭代出新的业务。
对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行定制开发，浪费人力。
这一项目也很好地诠释了之前所说的“点、线、面”的理论，在“点”上根本感知不到的问题，在“线”和“面”的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新！
有了公共的中台，意味着有了相对全局的视角，更能发现单点观察难以发现的问题，在更大的业务层面进行一定的创新——听着很有道理。
所有程序员都知道我们公用的逻辑要进行封装、抽象，变成Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。
比如，从技术范畴进行的一些改造（如为了完成tracing，所有系统增加trace id，并在log中默认携带）。
比如，从业务范畴进行的i18n改造（注：i18n是国际化的意思，Internationalization去掉头尾的i和n刚好还剩下18个字符，程序员的智慧）。
举一个典型的例子，某巨型互联网公司员工抱怨，在当前的微服务和中台架构前提下，做一个需求经常要改20+个模块，苦不堪言，连上线顺序都不一定搞得清楚。
当这20+个模块又是跨部门的时候，就更难了。想要推动其它部门做一些短期看起来没啥收益的事，太难了。
对于一个系统来说，追求稳定性，那么必然会在修改和升级上较为消极；追求灵活性，那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一，在一定程度上就得放弃另一方面。
Google程序员在Github上发起的行为艺术项目：nocode，没有 code，就没有bug——可谓弃疗的典范。
从我的实际观察来看，中台部门的系统虽然初始立项的时候声势浩大，但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆“垃圾”，“垃圾”在转过几手之后，后来的人基本就不太想对原来的代码进行修改了。
嗯，重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有！在没有测试的情况下，我们可以根据过往的系统需求文档和 PRD来还原当时的业务场景，并进行测试补充。
但你又发现，中台的性质（大多偏技术项目，基本没什么PM把关或者出文档）使其基本没有什么靠谱的、详尽的文档。写的复杂的中台，连业务流程都理不清楚，还想写测试，别做梦了哦。
在实际实践时，中台与FT的边界往往划得不清不楚。比如，用户服务、用户权益、用户在各种子系统中的状态，这些内容可能并不是用户服务本身关心的内容。
如果对系统内的个别数据不进行管理，那么有其它接入方接入时，就无法解释清楚字段的含义和使用场景。
如果不接受这些不相干的数据接入，那么前台流程系统可能会在自己内部重新建立自己的数据系统，这部分系统又极有可能和中台有功能上的重叠。
如果想要把这些数据接管过来，那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部，这往往又会产生与中台与前台业务边界的冲突。
如果要把系统从一个部门变到另一个部门，这一定会带来人员的调动。从情感上来讲，人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化，同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。
也有些公司在调整中进行粗暴的系统交接，如果系统需要下沉，那我直接从原来的维护团队手里夺过来，交给中台部门来管理。
即使贵司运气好，在系统交接过程中没有出现问题，那交接后也不好说。被交接的系统在交接后往往陷入消极维护状态，这时候前台业务接入中台会比以往更加困难，这种困难使前台业务的不满积累到一定程度之后，会再次催生前台部门重新造一套新的自己的中台，而部分或全部放弃原来的中台。这样，原来的中台部门便会陷入尴尬的境地。
进行部门划分之后，每个业务部门会有自己的一套目标体系。部门与部门的目标（KPI）一般是不相同的，如果相同的话，那也就没必要分多个部门了。
例如，A部门Feature Team较多，主要负责业务功能迭代，需要更强的灵活性；而B部门负责中台数据，主要关心系统稳定性，也就是前文提到的灵活性和稳定性的矛盾。
若此时出现cross cutting concern，两个部门需要在矛盾上取得一定程度的平衡，这种平衡在个别情况下是不可得的。
例如在一段时间内，中台部门的目标是提高某个商业指标，让公司更赚钱/省钱。这时候前台业务提来了新的需求，这种需求是能使流程开发更加灵活的，但与中台部门的KPI不在一个航道上。
中台部门显然要把需求排排优先级，把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪，不如自己实现了。
最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。
在大多数公司，中台部门和基础架构一样，会被当成是包袱而不是财富。可能有些人读到这里会不太爽。
中台建设一般要考虑公司的实际情况，这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向，可能来自于行业内其它公司的模式挑战。
理论上来说，只要一个公司的业务系统架构建设完成了，便已经完成了一种架构上的固化。这时行业内如果有新的模式获得了成功，公司肯定要进行跟进，但是新的模式一定意味着对原有系统、架构的挑战。
我分享一下公司的物联中台情况，1、客户方面都是资源型获取的，隐形利益是关键，中台价值当然也会关心，但不值一提，因为金主一无所知。2、实际使用部署上受到强势的如dahua、haikang等巨头不合作3、如智慧校园项目，智慧周期一般1-5期，可以说不差钱，年年搞都行，但都各自为政，系统多个独立，存量设备品牌越来越杂，大集成的概念估计这几年将要提出，趋势摆在这里，迟早的事。 不专业，仅供参考，路过随便说一嘴，勿砸砖
文章分析很透彻，指出了中台建设中遇到过的很多必须面临的实际问题。我司在中台建设过程中，也经历过诚如笔者所提的成本中心、包袱等问题困扰。
个人认为，透过现象看本质，从技术角度讲“中台”还是一套信息化系统、一副工具。工具的作用是提高人的工作效率，企业的信息系统则是满足企业的业务需求，提高企业运作的整体效率。
在不同的阶段、不同的时期，需要的工具也大不相同。诚如原始时代石器就能满足需求，但在工业时代蒸汽机才能满足基本需求是一样的。电脑才开始普及的年代，企业业务发展的渠道比较单一、简单的时候，可能一个excel都是很先进的信息化系统了。随着业务的发展，进销存、erp、mes、oa慢慢的进入企业的信息化采购清单。从线下到线上，oms成了必选项。再到O2O、OAO，随着业务的发展，中台建设又成了企业必须要考虑的。
中台的出现和发展有它必然的时代和需求环境，它要完成的也是它某一阶段的历史使命。企业在不断发展，信息系统就要不断适配其发展需求，所有的信息系统都将成为过去式，别指望一个中台能用到世界末日。
中台不是一个放之四海而皆准的东西，每一个企业都有自身的业务的特殊情况，别人的经验可以借鉴，但不可能照单全抄的，就像佳沛奇异果和品胜充电宝的信息系统肯定是不同的，虽然都是销售商品。
正确看待和解决中台建设过程中的问题，笔者所列的问题，不仅仅是中台，很多也是企业信息化必然面临的问题，诸如：技术和业务部门的扯皮、业务前置或后置的矛盾。这些问题只有想办法去解决和克服，才能让企业发展不被束缚，发挥信息系统——中台应有的价值和作用，进而用好这一工具，发挥它最大的效能。
人人都是产品经理（是以产品经理、运营为核心的学习、交流、分享平台，集媒体、培训、社群为一体，全方位服务产品人和运营人，成立9年举办在线+期，线+场，产品经理大会、运营大会20+场，覆盖北上广深杭成都等15个城市，在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监，他们在这里与你一起成长。
