01 | 来龙去脉：中台为什么这么火？
请订阅文章所属专栏。
精选留言(60)
亚东 置顶我14年到17年在美资金融公司，就经历过中台实施。当时给我的印象非常深刻，所有的核心计算都在engine层，实现了数据即服务的设计，而前端使用组件式开发。产品经理只要组合一下就是一个全新的产品。一开始也非常痛苦，后面的非常有力地支持了公司的业务发展。在之后公司全面使用AWS云服务，在对客户的服务上非常弹性化。从科技服务金融，变成科技促进金融。作者回复: 亚东，你好~
我看到了你很多的留言，说的都很有道理，最后一条留言来集中回复感谢一下（倒叙看的留言……）
看得出来你是实际参与和思考过这个概念的，从结果上来看也非常高兴看到确实也突围了一开始非常痛苦和挣扎的时期，看到了最终的效果，其实是非常难得的。
中台要以用户为中心，用产品化的思维来构建，确实是我近两年的一个感受特别深的点，很高兴在很多方面我们的理解都是一致的，也没什么补充，最后还是感谢一下你的认真回答和分享，有机会我们继续交流~2019-10-08 2 17
毛毛我理解的中台，是把一个业务拆分成多个模块，然后把模块设计成通用的，其他业务可以直接集成使用。这些模块一般有数据收集、AB测试、推荐系统、广告系统等等。作者回复: 毛毛，你好~ 这么理解没毛病，但是我觉得还是想小了，这也是我们一开始轻敌了的原因，感觉不就是把共性业务一抽，往平台里一放，前边一接就ok了，结果碰到的问题非常多哈，后边也会讲到一些常见问题和困难，看看我们这边有没有遇到过~ 我看你后边也留言了，我们到时候再展开~
2019-09-25 3 17
一步我理解的中台是把通用的基础的组件或者服务抽离出来，等下次再使用的时候可以快速的集成，但是有个疑问如果只是这样的话，和中间件或者微服务又有什么区别呢？2019-09-28 2 13
zzz333最后一点才是最重要的，这两年尽在说互联网寒冬，没有像之前o2o，区块链之类的大规模热点，所以大家的战略都往广积粮方向走。大白话就是没事找事干，所以中台是最适合不过的，反正把原来的系统重做一次，又可以占稳地盘又可以写好ppt，非常不错！作者回复: zzz333，你好~
太真实了哈，深挖坑广积粮本身也没错哈，一场仗打完，大家休整休整，稳稳队形，打打基础也是没错的。
不过最后一点，把系统重做一遍，占地盘写好PPT，我就不敢说了…… 可能确实有企业这样吧，不过我看到的情况大家至少出发点还是对的，毕竟那么多钱花出去了，也得看结果见效果，企业的管理层也都不是那么好糊弄的，光靠PPT也撑不了多久，还得有点实际的不是：）
感谢你的留言，欢迎继续把自己的想法分享出来~2019-09-28 3 12
业余草中台绝不是终点！今年写了两篇中台文章，推荐给大家看看：https://mp.weixin.qq.com/s/h3jALEBzIeRb_NlcFOQugg作者回复: 业余草，你好~ 感谢分享哈，关注了……：）
2019-09-25 10- TopCarl很多东西都是逐步进化出来的，所以大自然中总能找到类似的东西。
就像我理解的前台、中台、后台，就好比一颗大树，前台是枝叶，中台是树干，后台是根系。
枝要柔韧、叶要灵活，枝叶能随风摆动、枯荣更迭，也就是前台要随市场变化而灵活更新，有新生和淘汰，并且能够通过光合作用制造有机物(挣钱)；
树干要能支撑树冠，就要足够坚韧，而且要能将水、无机盐、有机物进行输导，也就是中台要能支撑前台、为前台输送资源，同时还能前台的收益反哺后台；
根须要能吸收水分、无机盐等，并且要稳稳抓住土地，也就是后台要源源不断地提供原材料，包括但不限于计算资源、存储资源、网络资源、数据资源、算法资源等等这一切，后台中像数据这些资源都是企业立足之本。
最后单独说说中台，从大树来看，枝叶和根须都是比较分散的，如果分散的业务和分散的资源直接对接，对于两端来说都是复杂度高且效率低，所以树干的还有一个作用就是将枝叶和根须的分散进行了汇聚，降低复杂度，提升对接效率。
只是个人理解，多交流。作者回复: TopCarl，你好～
这个比喻我还是第一次看到，我脑补了一下非常形象哈，包括叶子的灵活与制造有机物；树干的韧性等等，都非常贴切。
而且我也同意你说的，无论是好的产品好的架构都是演进发展来的。所以我才一直强调要演进式的动态的来看待问题，我们的方法也融入了这种演进式的思想。
非常好的隐喻，感谢分享～2019-10-10 1 9 
西红柿牛男老师能把300篇文章分享下吗？作者回复: 西红柿牛男，你好~
刚回复了一个类似的问题哈，感觉大家对于这300篇文章都很感兴趣…… 其实分享没有问题，只是我觉得意义不大，因为专栏本身就可以理解成对于300篇文章的精华的浓缩（当然会受我的视野和能力所限），这也是我认为这个专栏对于大家的价值……至少还能省一些阅读和提炼的 时间。
而对于一些我认为对我有很大启发，干货满满的文章，我也统一放到了总结篇里，作为扩展阅读分享给大家。
当然，如果大家还是对这300多篇文章感兴趣的话，可以继续留言告诉我，我也可以找个地方或是想个法子，把文藏列表整理出来（目前在印象笔记里），都没有问题~
最后感谢你的留言，有问题可以继续留言给我，我们继续探讨~2019-09-27 1 8- 风行2018年底，我也在技术总监的带领下，以产品的角色参与了中台调整，才接触到中台这个概念和实施。
在操作完后，我回过头来总结下总台的理解：
1、从形态上，是将原有的业务和即将发展的新业务抽象成为公用、粒度相对较小（符合公司发展历程）的公共业务/产品模块。
2、从设计理念上，是保持这对行业的优化、资源的整合上，要心怀行业、心怀可能的合作资源整合/合作上，对每一个模块进行开放性和高度抽象化的设计。
3、从公司管理上，是对组织架构的优化，也是对人力成本的调整。
最终，能达到成本降低、快速响应业务变化、内部资源共用的结果.作者回复: 风行，你好～ 感谢分享^_^
2019-10-17 3 
老王的老李头对中台非常的感兴趣，觉得这是继区块链之后又一个技术圈儿的热点(当然这两者没有直接关系)，我所从事的行业是政府服务，总是觉得这么好的思维方式，如果能从政府的角度来进行实践，这要是成功了也算是件利国利民的好事了。所以这个专栏一定要好好学习作者回复: 老王的老李头，你好～
据我所知，中台的理念早就进入到政府行业了，而且还有不少都是国家级的。
这一点从今年的几次政府采购的中标新闻中也能看得出来，也都纷纷提到了中台，甚至是作为亮点写到了中标新闻稿里。
我本身就是做政府行业出身，10多年前就是做相关的项目。对于政府行业来讲，组织的壁垒可能更难打破，但中台或是中台理念的价值也因此而更加的重要和明显。
好在我们看到很多先行者们已经开始探索，当然这也少不了各个参与方的齐心合力，改变正在发生，让我们一起拭目以待吧：）2019-09-30 2
🤪HappyJoo浅显一点来理解，感觉和 python 一样，可以弄出很多模块，要用的人直接使用就好了。。。作者回复: HappyJoo，你好～
没毛病哈，像我说文中也说到的，组件化，拼拼凑凑拖拖拽拽就能快速攒出一个软件来，就跟攒电脑似的，一直是大家这么多年来的梦想。
所以才会有这么多标准、组件库、框架、nocode、lowcode平台产生，而中台只是组件化在企业级的范围下，向业务又迈出的一步而已～
感谢你的分享，其实并不浅显～ 细想想还很深刻～
希望有更多感悟也可以随时留言，分享给大家～2019-09-27 2
日拱一卒我理解中台的出现是必然的，随着公司规模扩大，业务线越来越丰富。一方面要考虑如何把工作中的经验积累下来应用到下一个项目或者业务线，避免“烟囱系统”林立。另一方面，对于市场中出现的机会，怎么能够更快速捕捉。这些动力促使企业改变传统的开发模式，有共同模块，有微服务等等，即使不叫中台，我相信也会有另外一个名词出现，去做中台现在做的事情。作者回复: 日拱一卒，你好，好名字哈哈~
留言说的是，俗话说的好，分久必合合久必分，阿里巴巴的张勇也在很多文章提到过，他最关注的几件事有一件就是企业里哪些部分该合哪些部分该分，去年合的可能今年就分了，去年分的可能今年再合起来，而分分合合的背后就是战略的调整，而战略的调整背后就是愿景与使命……
我现在看到很多中台建设比较早的企业，已经开始“合久必分”了。
所以要动态的看待中台这个问题，合自然是好的，但是也有问题，至少有成本，合完了也总有一天要分的，所以就像我在其他回复里提到的，“我们永远做不对”，只能不断提高自己应变的能力，与变化共舞。
在我看来这分分合合，好像是在找一个平衡点，在最后总结的时候我会提出我的想法，到时候如果还有问题，我们还可以继续深入或是展开~2019-09-26 2
zhaxin老师提到的中台火爆的四个契机：
1. 大哥带头（大厂的样板效应）
2. 武器在手（云+中台战略）
3. 直戳要害（早期信息化建设弊端暴露）
4. 大势突围（经济形势严峻）作者回复: 总结的好形象哈，学到了^_^
2019-10-18 1
Will关注台长在thoughtworks分享的中台资讯很久了，近期公司准备做微服务改造，这次听课程主要想了解下中台能带来哪些便利，希望在此次改造中加以借鉴和应用。作者回复: Will，你好~
感谢关注，中台的建设往往离不开遗留系统的服务化改造，但是反过来不一定，遗留系统的服务化改造不一定是冲着企业级能力共享，也就是中台去的。
这个课程没有太多，聊到微服务改造的部分，不过一般常用的工具也都差不多，目前大家说的最多的也就是用DDD的问题域和限界上下文做服务划分，然后通过重构的手法来做平滑的系统改造。
希望你能从专栏中吸取到养分，帮助解决一些困扰和问题，随时交流~2019-10-11 1 1
纯洁的憎恶我隐约中对中台的理解是，把自己的庞杂能力系统打造成一系列“标准化”的、可迭代的、轻盈灵活的积木，然后能够像拼乐高一样任意组合、快速创新。这是一门很厉害的内功，当然也很难练就，适合在蓄势待发的逆境中锤炼。2019-10-08 1
小伟之前听过一句话：没有中间件解决不了的问题。当时嗤之以鼻，但后来发现，貌似的确是这么回事。中间件可大可小，大到一套解决方案(如Oracle RAC)，小到一个cache(单体Redis)，是解决非功能性问题的利器。
关于中台，也是最近才听说的，看了老师的01课之后，个人感觉中台和中间件有神似之处，原理相通，但解决问题的层次和维度不同。中间件更倾向于解决单一问题，如数据库中间件解决数据持久、一致性和读写性能问题，消息中间件解决系统伸缩性问题。而中台更倾向于解决业务依赖问题，如业务边界划分，业务组件化。
相对于中间件需要解决的问题相对明确，中台要解决的问题，视行业不同，会千差万别。想想就有好多问题和场景，先flag下，等终章时再回看这些问题，希望能有一些感悟。
1. 对于0到1的系统建设，中台如何起步？
2.如何在业务演进过程中预留中台集成的空间？暨新业务来临时，如何顺滑的集成进中台，需要在哪些方面预先考虑？
3.中台组件的粒度如何把控？是否同时提供不同粒度的中台组件？
4.当中台组件不能满足需求时如何演进？如现有业务级中台组件不能满足新业务的构建，而用API级中台组件构建又太笨重(需调用大量API，而只需某些API一部分数据)。
5.中台组件是否需要退出机制？如何能做到最小成本的顺滑退出？场景如旧业务下线。
其他的想到了再留言。2019-10-04 1
Watts领导让做中台，我的理解目前还是微服务。期待下面的文章作者回复: Watts，你好～ 相信后面的内容会解答你的问题，在07的时候我还专门谈了一下我对于业务中台和微服务的看法，希望对你有所启发～ 如果有任何问题和反馈，也欢迎继续留言～
2019-09-29 1
Feeng老师，希望在文章中你能给个栗子，如果从零开始搭建中台，需要满足那些硬性条件，该如何开始，流程怎么走下来，简单的栗子也好。谢谢老师。作者回复: Feeng，你好~
感谢你的建议，确实在设计专栏的时候，考虑到中台的概念比较抽象和大，也是想通过一个例子来展开，把问题和流程都串起来。
所以，你看到后边，会有一个小的极客地产的虚构的例子。不过因为是虚构的，可能案例还比较浅，虽然是虚构的，但是里边很多的情况和问题都是从真正的实践中来的。
没有用真实的案例，是因为需要为客户保密，不能用我们实际参与的客户案例给大家展开，也希望大家能够理解。
你可以先往后看，我觉得极客地产的案例已经能体现出很多中台建设的问题和困难点，如果觉得还不够，或是还有什么疑惑和问题，也可以继续留言，我们继续探讨，或是我找一些例子或是比喻帮你更好的理解：）2019-09-27 1 1
卓不凡现在正在从事集团的中台业务。关于从那个系统对接，怎样落地确实很迷茫。这篇课程太及时了。
今天主要了解了中台的孕育，爆发等历史，也知道了中台出现的原因。互联网企业样板效应，产业互联网转型，烟囱林立，数据孤岛的企业信息整合，经济形势不好情况下的沉淀和快速响应方式作者回复: 卓不凡，你好~
感谢支持与关注，整个课程秉承着全局视角，先发散后收敛的过程。
对于你迷茫的问题，在中台搭建过程中算是个通用问题了，后边我会讲到，如果没有讲清楚，还可以继续留言，我们继续一起探讨，后续如果有任何体会和理解、笔记，也欢迎随时留言，分享给大家。2019-09-26 1
兔2🐰🍃不理解什么是中台，迫切的想了解它的全貌。作者回复: 兔2🐰🍃，你好~ 想要了解全貌，希望01，02两个维度能帮助到你，03会做一些收敛和分析。如果到时候还有疑惑，欢迎继续留言，我们一起探讨~
2019-09-26 1
好孩子我对中台感兴趣的原因是我们目前也处于由竖烟筒向平台化改造的过程。但是我们并不认为自己是在做中台，所以想了解，到底什么是中台作者回复: 好孩子，你好~ 感谢支持，后边我会讲到，中台只是平台化的一个延续和发展而已，希望后边的内容对你有所启发和帮助~
2019-11-25