• 亚东 置顶
    2019-10-08
    我14年到17年在美资金融公司,就经历过中台实施。当时给我的印象非常深刻,所有的核心计算都在engine层,实现了数据即服务的设计,而前端使用组件式开发。产品经理只要组合一下就是一个全新的产品。一开始也非常痛苦,后面的非常有力地支持了公司的业务发展。在之后公司全面使用AWS云服务,在对客户的服务上非常弹性化。从科技服务金融,变成科技促进金融。

    作者回复: 亚东,你好~

    我看到了你很多的留言,说的都很有道理,最后一条留言来集中回复感谢一下(倒叙看的留言……)

    看得出来你是实际参与和思考过这个概念的,从结果上来看也非常高兴看到确实也突围了一开始非常痛苦和挣扎的时期,看到了最终的效果,其实是非常难得的。

    中台要以用户为中心,用产品化的思维来构建,确实是我近两年的一个感受特别深的点,很高兴在很多方面我们的理解都是一致的,也没什么补充,最后还是感谢一下你的认真回答和分享,有机会我们继续交流~

     2
     23
  • 毛毛
    2019-09-25
    我理解的中台,是把一个业务拆分成多个模块,然后把模块设计成通用的,其他业务可以直接集成使用。这些模块一般有数据收集、AB测试、推荐系统、广告系统等等。

    作者回复: 毛毛,你好~ 这么理解没毛病,但是我觉得还是想小了,这也是我们一开始轻敌了的原因,感觉不就是把共性业务一抽,往平台里一放,前边一接就ok了,结果碰到的问题非常多哈,后边也会讲到一些常见问题和困难,看看我们这边有没有遇到过~ 我看你后边也留言了,我们到时候再展开~

     3
     20
  • TopCarl
    2019-10-10
    很多东西都是逐步进化出来的,所以大自然中总能找到类似的东西。
    就像我理解的前台、中台、后台,就好比一颗大树,前台是枝叶,中台是树干,后台是根系。
    枝要柔韧、叶要灵活,枝叶能随风摆动、枯荣更迭,也就是前台要随市场变化而灵活更新,有新生和淘汰,并且能够通过光合作用制造有机物(挣钱);
    树干要能支撑树冠,就要足够坚韧,而且要能将水、无机盐、有机物进行输导,也就是中台要能支撑前台、为前台输送资源,同时还能前台的收益反哺后台;
    根须要能吸收水分、无机盐等,并且要稳稳抓住土地,也就是后台要源源不断地提供原材料,包括但不限于计算资源、存储资源、网络资源、数据资源、算法资源等等这一切,后台中像数据这些资源都是企业立足之本。
    最后单独说说中台,从大树来看,枝叶和根须都是比较分散的,如果分散的业务和分散的资源直接对接,对于两端来说都是复杂度高且效率低,所以树干的还有一个作用就是将枝叶和根须的分散进行了汇聚,降低复杂度,提升对接效率。
    只是个人理解,多交流。
    展开

    作者回复: TopCarl,你好~

    这个比喻我还是第一次看到,我脑补了一下非常形象哈,包括叶子的灵活与制造有机物;树干的韧性等等,都非常贴切。

    而且我也同意你说的,无论是好的产品好的架构都是演进发展来的。所以我才一直强调要演进式的动态的来看待问题,我们的方法也融入了这种演进式的思想。

    非常好的隐喻,感谢分享~

     2
     17
  • 一步
    2019-09-28
    我理解的中台是把通用的基础的组件或者服务抽离出来,等下次再使用的时候可以快速的集成,但是有个疑问如果只是这样的话,和中间件或者微服务又有什么区别呢?
     2
     14
  • zzz333
    2019-09-28
    最后一点才是最重要的,这两年尽在说互联网寒冬,没有像之前o2o,区块链之类的大规模热点,所以大家的战略都往广积粮方向走。大白话就是没事找事干,所以中台是最适合不过的,反正把原来的系统重做一次,又可以占稳地盘又可以写好ppt,非常不错!

    作者回复: zzz333,你好~

    太真实了哈,深挖坑广积粮本身也没错哈,一场仗打完,大家休整休整,稳稳队形,打打基础也是没错的。

    不过最后一点,把系统重做一遍,占地盘写好PPT,我就不敢说了…… 可能确实有企业这样吧,不过我看到的情况大家至少出发点还是对的,毕竟那么多钱花出去了,也得看结果见效果,企业的管理层也都不是那么好糊弄的,光靠PPT也撑不了多久,还得有点实际的不是:)

    感谢你的留言,欢迎继续把自己的想法分享出来~

     3
     14
  • 业余草
    2019-09-25
    中台绝不是终点!今年写了两篇中台文章,推荐给大家看看:https://mp.weixin.qq.com/s/h3jALEBzIeRb_NlcFOQugg

    作者回复: 业余草,你好~ 感谢分享哈,关注了……:)

    
     10
  • 西红柿牛男
    2019-09-27
    老师能把300篇文章分享下吗?

    作者回复: 西红柿牛男,你好~

    刚回复了一个类似的问题哈,感觉大家对于这300篇文章都很感兴趣…… 其实分享没有问题,只是我觉得意义不大,因为专栏本身就可以理解成对于300篇文章的精华的浓缩(当然会受我的视野和能力所限),这也是我认为这个专栏对于大家的价值……至少还能省一些阅读和提炼的 时间。

    而对于一些我认为对我有很大启发,干货满满的文章,我也统一放到了总结篇里,作为扩展阅读分享给大家。

    当然,如果大家还是对这300多篇文章感兴趣的话,可以继续留言告诉我,我也可以找个地方或是想个法子,把文藏列表整理出来(目前在印象笔记里),都没有问题~

    最后感谢你的留言,有问题可以继续留言给我,我们继续探讨~

     1
     8
  • 风行
    2019-10-17
    2018年底,我也在技术总监的带领下,以产品的角色参与了中台调整,才接触到中台这个概念和实施。
    在操作完后,我回过头来总结下总台的理解:
    1、从形态上,是将原有的业务和即将发展的新业务抽象成为公用、粒度相对较小(符合公司发展历程)的公共业务/产品模块。
    2、从设计理念上,是保持这对行业的优化、资源的整合上,要心怀行业、心怀可能的合作资源整合/合作上,对每一个模块进行开放性和高度抽象化的设计。
    3、从公司管理上,是对组织架构的优化,也是对人力成本的调整。
    最终,能达到成本降低、快速响应业务变化、内部资源共用的结果.
    展开

    作者回复: 风行,你好~ 感谢分享^_^

    
     4
  • 🤪HappyJoo
    2019-09-27
    浅显一点来理解,感觉和 python 一样,可以弄出很多模块,要用的人直接使用就好了。。。

    作者回复: HappyJoo,你好~

    没毛病哈,像我说文中也说到的,组件化,拼拼凑凑拖拖拽拽就能快速攒出一个软件来,就跟攒电脑似的,一直是大家这么多年来的梦想。

    所以才会有这么多标准、组件库、框架、nocode、lowcode平台产生,而中台只是组件化在企业级的范围下,向业务又迈出的一步而已~

    感谢你的分享,其实并不浅显~ 细想想还很深刻~

    希望有更多感悟也可以随时留言,分享给大家~

    
     4
  • zhaxin
    2019-10-18
    老师提到的中台火爆的四个契机:
    1. 大哥带头(大厂的样板效应)
    2. 武器在手(云+中台战略)
    3. 直戳要害(早期信息化建设弊端暴露)
    4. 大势突围(经济形势严峻)

    作者回复: 总结的好形象哈,学到了^_^

    
     3
  • Will
    2019-10-11
    关注台长在thoughtworks分享的中台资讯很久了,近期公司准备做微服务改造,这次听课程主要想了解下中台能带来哪些便利,希望在此次改造中加以借鉴和应用。

    作者回复: Will,你好~

    感谢关注,中台的建设往往离不开遗留系统的服务化改造,但是反过来不一定,遗留系统的服务化改造不一定是冲着企业级能力共享,也就是中台去的。

    这个课程没有太多,聊到微服务改造的部分,不过一般常用的工具也都差不多,目前大家说的最多的也就是用DDD的问题域和限界上下文做服务划分,然后通过重构的手法来做平滑的系统改造。

    希望你能从专栏中吸取到养分,帮助解决一些困扰和问题,随时交流~

     1
     3
  • 老王的老李头
    2019-09-30
    对中台非常的感兴趣,觉得这是继区块链之后又一个技术圈儿的热点(当然这两者没有直接关系),我所从事的行业是政府服务,总是觉得这么好的思维方式,如果能从政府的角度来进行实践,这要是成功了也算是件利国利民的好事了。所以这个专栏一定要好好学习

    作者回复: 老王的老李头,你好~

    据我所知,中台的理念早就进入到政府行业了,而且还有不少都是国家级的。

    这一点从今年的几次政府采购的中标新闻中也能看得出来,也都纷纷提到了中台,甚至是作为亮点写到了中标新闻稿里。

    我本身就是做政府行业出身,10多年前就是做相关的项目。对于政府行业来讲,组织的壁垒可能更难打破,但中台或是中台理念的价值也因此而更加的重要和明显。

    好在我们看到很多先行者们已经开始探索,当然这也少不了各个参与方的齐心合力,改变正在发生,让我们一起拭目以待吧:)

    
     3
  • 日拱一卒
    2019-09-26
    我理解中台的出现是必然的,随着公司规模扩大,业务线越来越丰富。一方面要考虑如何把工作中的经验积累下来应用到下一个项目或者业务线,避免“烟囱系统”林立。另一方面,对于市场中出现的机会,怎么能够更快速捕捉。这些动力促使企业改变传统的开发模式,有共同模块,有微服务等等,即使不叫中台,我相信也会有另外一个名词出现,去做中台现在做的事情。

    作者回复: 日拱一卒,你好,好名字哈哈~

    留言说的是,俗话说的好,分久必合合久必分,阿里巴巴的张勇也在很多文章提到过,他最关注的几件事有一件就是企业里哪些部分该合哪些部分该分,去年合的可能今年就分了,去年分的可能今年再合起来,而分分合合的背后就是战略的调整,而战略的调整背后就是愿景与使命……

    我现在看到很多中台建设比较早的企业,已经开始“合久必分”了。

    所以要动态的看待中台这个问题,合自然是好的,但是也有问题,至少有成本,合完了也总有一天要分的,所以就像我在其他回复里提到的,“我们永远做不对”,只能不断提高自己应变的能力,与变化共舞。

    在我看来这分分合合,好像是在找一个平衡点,在最后总结的时候我会提出我的想法,到时候如果还有问题,我们还可以继续深入或是展开~

    
     3
  • at三月
    2019-12-18
    中台:代替烟囱式架构,即解决大量的重复建设和资源浪费,形成『大中台、小前台』的优势。阿里巴巴提出中台战略是当天猫和淘宝出现重复建设的时候,『阿里共享事业部』应运而生。因此推广到具体公司的业务:当很多业务部门有同样的业务需求而各自都在建设自己的业务平台的时候,就该从公司层面去考虑、规划中台的建设了。
    
     1
  • 纯洁的憎恶
    2019-10-08
    我隐约中对中台的理解是,把自己的庞杂能力系统打造成一系列“标准化”的、可迭代的、轻盈灵活的积木,然后能够像拼乐高一样任意组合、快速创新。这是一门很厉害的内功,当然也很难练就,适合在蓄势待发的逆境中锤炼。
    
     1
  • 小伟
    2019-10-04
    之前听过一句话:没有中间件解决不了的问题。当时嗤之以鼻,但后来发现,貌似的确是这么回事。中间件可大可小,大到一套解决方案(如Oracle RAC),小到一个cache(单体Redis),是解决非功能性问题的利器。
    关于中台,也是最近才听说的,看了老师的01课之后,个人感觉中台和中间件有神似之处,原理相通,但解决问题的层次和维度不同。中间件更倾向于解决单一问题,如数据库中间件解决数据持久、一致性和读写性能问题,消息中间件解决系统伸缩性问题。而中台更倾向于解决业务依赖问题,如业务边界划分,业务组件化。
    相对于中间件需要解决的问题相对明确,中台要解决的问题,视行业不同,会千差万别。想想就有好多问题和场景,先flag下,等终章时再回看这些问题,希望能有一些感悟。
    1. 对于0到1的系统建设,中台如何起步?
    2.如何在业务演进过程中预留中台集成的空间?暨新业务来临时,如何顺滑的集成进中台,需要在哪些方面预先考虑?
    3.中台组件的粒度如何把控?是否同时提供不同粒度的中台组件?
    4.当中台组件不能满足需求时如何演进?如现有业务级中台组件不能满足新业务的构建,而用API级中台组件构建又太笨重(需调用大量API,而只需某些API一部分数据)。
    5.中台组件是否需要退出机制?如何能做到最小成本的顺滑退出?场景如旧业务下线。
    其他的想到了再留言。
    展开
    
     1
  • Watts
    2019-09-29
    领导让做中台,我的理解目前还是微服务。期待下面的文章

    作者回复: Watts,你好~ 相信后面的内容会解答你的问题,在07的时候我还专门谈了一下我对于业务中台和微服务的看法,希望对你有所启发~ 如果有任何问题和反馈,也欢迎继续留言~

    
     1
  • Myself
    2019-09-29
    个人感觉,随着技术的发展,封装和复用这两个特点不仅在技术方面提现的越来越重要,在架构和业务方面也越来越重要。无论是一个项目,还是一个公司,要做大,最终都会做越来越多的分层,各层之间只关心“调用”,不关心“实现”,各司其职,各专其事,需要时做好衔接,做好沟通,就可以很好的运转起来。现在是前中后台,未来可能还会有其它什么“台”😂个人不成熟见解🤝

    作者回复: Myself,你好~

    你说的其实挺对的,很多不同的概念,到底就还是封装、复用、隔离变化点,单一职责,高内聚,低耦合这类基本原则,只不过是作用在不同的层次上而已。

    前一阵听说字节跳动的张一鸣,提出过一个概念叫做Company as a Product,我觉得特别好,这就相当于我们可以用治理软件的原则和方法,来思考对于企业的治理,比如思考能不能把设计模式应用到企业管理上之类的……而这本质上就又回到了康威定律,就不展开了哈

    其实像我说的,叫什么不重要,本质上中台就是两层不够了,加一层来解决问题,以后可能三层不够了,再分个中前台,中后台,也都说不定……

    所以我很认同你的观点,也感谢你的分享,有问题可以继续留言分享自己的观点和反馈~ 感谢

     1
     1
  • MIddlem
    2019-09-27
    你好,现在目前主要从事的是前端开发,但是个人你比较喜欢开发一些架构东西,前期公司已经做了整体的平台,但是公司最近需要快速的发展新业务,发现了很多问题如,用户体系、CRM体系、权限体系等等都不能支撑现在的迭代,现在在了解中台,不知道能不能从之前的平台化跳转到中台,更好的迭代业务

    作者回复: MIddlem,你好~

    从平台化跳转到中台,我认为是可以的,也是中台常见的一种演进路径。

    我在最后10总结篇中推荐的张巍老师的《七问七答,亲历者讲阿里中台落地的实践》中,张老师讲阿里当年基于实际的问题,从交易平台通过对于平台能力的治理,也才是阿里的平台化到中台化的进程。所以张老师才说中台是平台的下一站。

    这个思路我认为跟你现在想做的不谋而合,建议你看一下张老师这篇文章,肯定会对你有所启发。

    希望我的留言对你有些帮助,欢迎继续留言交流~

    
     1
  • 一直
    2019-09-27
    对于中台,我的理解是各企业把自己现有的一些能力(包括前台,后台),拆分成一个个模块化,组件化的东西,集成在一个仓库里面,满足各业务的需求。在这个仓库里面企业也可以清晰看到自己到底有哪些能力,缺少哪些能力。这个集成仓库可以说是企业的能力整合,是一个“多功能宝盒”。

    作者回复: 一直,你好~

    多功能宝盒的比喻好形象哈,你的理解没什么问题,只是后面会讲到建这样一个多功能宝盒可能还是有点困难的……

    还有像你说的在这个仓库里,企业也能清晰看到自己到底有哪些能力,缺少哪些能力。其实要想做到这点,也还是挺难的,真正做到的也不多。

    我看到的很多实际情况是,很多企业做中台建设很久,抽了很多的服务,但是到底有哪些能力在中台里,并不是非常的清晰。后边我会讲到,这也就是我们常说缺少对于能力的治理和产品化包装整合。

    总之,你理解的都挺到点子上的,很多人包括我也是这么理解的,不过就是建设的过程中各种具体才会迎面而来,或是容易驶离了初心,我这个专栏也是想讲讲这些容易碰到的坑和问题,以及如何规避或是提前有个准备。

    希望后边的内容能给你更多的启发,有问题也欢迎再次留言,我们再一起探讨~

    
     1
我们在线,来聊聊吧