最初想到中台概念，是因为我所服务的产品在某方面与其他项目组的底层上有可公用的模块，但团队之间都在重复造轮子。我之费解有三点：
- 可公用模块是否可封装为组件，以供全公司使用？
- 重复造轮子时，难道没有考虑到人力成本和时间成本么？（从技术老大的角度看，出于什么原因我们没有推进这个事儿？）
- 中台需要做成什么样子？
在一个偶然的机会我和技术老大分享了我的疑问，他的回复让我成长了许多。那么快速分享一下我的收获吧。
【问1】可公用模块是否可封装为组件，以供全公司使用？
答案是肯定的。当公司的业务体量逐渐庞大，对接渠道种类日益繁多，点对点方式已不能满足企业的规模化成长速度，应用层需要一个自由灵活的对接方案，中台就是最好的办法之一。
【问2】重复造轮子时，难道没有考虑到人力成本和时间成本么？
首先，无法形成公用服务除了项目个体因素，也有历史政策上的影响。比如在成长型公司的初期，项目小、复杂度低，不需要功能完善的底层服务组件。有时公司鼓励团队间竞争，每个团队都想成就自己的价值，如果成功了可以推广至全公司，如果失败了则损耗相对小的人力、物力。
其次，随着公司的发展会接入更复杂庞大的项目，为了能尽快交付，团队内部虽然做了扎实的底层服务，但过于定制化并不适合内部推广。
再有，很多公有服务的搭建会产生长时间的、大量的内耗。谁来接这个任务、需求方向如何准确对标到不同的应用成为重大难题。
最后，企业发展的阶段性目标可能与构建底层公有服务的目标相悖。比如公司在某个阶段需要的是订单量（资本查收业绩判断估值），那么这个期间各团队首要解决的是如何快速交付项目、拿下订单，自然不会有投入精力到公有底层服务上。
【问3】中台需要做成什么样子？
中台属于服务型产品，让多样化的业务需求能够找到合适的技术对接方案。比如一家公司的上层业务有：零售、制造、金融、数据分析等板块。对技术的底层依赖有：广告投放、数据治理、内容管理、性能调度、策略编排等。中台是将技术能力按服务渠道和内容标准化输出，底层技术对于上层业务一视同仁，也就是：中台通过功能重组辅助业务产生价值，是闭环链的关键一节。
所以，中台无法为公司业务带来革命性变化，但它是一个可灵活支配的“阀门”。
既然中台强调服务。那么中台的发展就需要与企业的生命周期息息相关，在不同的场景下发挥不同的价值。通过下图可以很好的了解中台在生命周期中扮演的角色：
初期，中台的薄
在企业发展早期，几乎还没有形成严格意义的中台概念。受到企业资金、产品早期形态等制约，中台能力薄弱，企业甚至没有精力和动力专门研发中台。
中期，中台逐渐增厚
走向高峰期的过程中会产生非常多的业务需求。这个阶段，中台偏向定制化，产品部门对接多种需求不断迭代与设计，逐渐形成大而全的中台体系。不过大而全的其背后一定会伴随逻辑疏漏，组件与组件之间存在冗余。特别是随着企业在市场上趋于成熟，中台与业务的上下游关系更为紧密，成为公司核心框架中的一环。当外部市场环境发生变化时，企业若想做内部调整，会牵一发而动全身、捉襟见肘。厚重的服务成为严重阻碍。
后期，中台逐渐变薄
在企业迎来业绩低潮、面临衰退期时，管理者率先得到资本和市场的压力引发惶恐（普通员工几乎是无感知的），他们最渴望创新与突破。但是，这么庞大的企业架构谈创新非常难，就像基金经理调巨额基金的仓位一样困难和痛苦。
从高层角度看，冗余功能或业务会尽可能合并或替代，接纳更优质的市场机会。从各个事业部角度看，他们期望自己的需求能够得到快速响应以承托应用层的创新。
但中台不是一个好的创新工具。如上文讲述：中台是一个将能力标准化输出的工具。它无法快速响应创新业务，不适合做颠覆性工作。所以我们要将问题转化为：中台如何从服务的角度帮助业务应对快速变化的市场需求？
这个解决办法就是中台变薄。中台里部分功能必然要从主体剥离，形成自己的小生态。某种意义来说，是将部分标准化的能力抽象，让其可定制。这就好似一个大企业的生命周期中衍生出的很多小组织的生命周期，抽象出来的能力会伴随新的生命周期的业务成长，促其闭环。
结语：
我与技术老大的对话中，他对我们公司的中台倾向于“薄服务”。一番讲述后，让我一改前观：从公司和技术历史进程上教会我什么阶段应该做多大的事儿。也许你也曾说过：“我们的中台就是一个垃圾，东西不少用处不大”。我相信上文可以给你一个很清晰的解释。最后请先认清自己所在的领域，不要轻易否认其发展历史和阶段现状。
