作者回复: 亚东,你好~
我看到了你很多的留言,说的都很有道理,最后一条留言来集中回复感谢一下(倒叙看的留言……)
看得出来你是实际参与和思考过这个概念的,从结果上来看也非常高兴看到确实也突围了一开始非常痛苦和挣扎的时期,看到了最终的效果,其实是非常难得的。
中台要以用户为中心,用产品化的思维来构建,确实是我近两年的一个感受特别深的点,很高兴在很多方面我们的理解都是一致的,也没什么补充,最后还是感谢一下你的认真回答和分享,有机会我们继续交流~
作者回复: 毛毛,你好~ 这么理解没毛病,但是我觉得还是想小了,这也是我们一开始轻敌了的原因,感觉不就是把共性业务一抽,往平台里一放,前边一接就ok了,结果碰到的问题非常多哈,后边也会讲到一些常见问题和困难,看看我们这边有没有遇到过~ 我看你后边也留言了,我们到时候再展开~
作者回复: TopCarl,你好~
这个比喻我还是第一次看到,我脑补了一下非常形象哈,包括叶子的灵活与制造有机物;树干的韧性等等,都非常贴切。
而且我也同意你说的,无论是好的产品好的架构都是演进发展来的。所以我才一直强调要演进式的动态的来看待问题,我们的方法也融入了这种演进式的思想。
非常好的隐喻,感谢分享~
作者回复: zzz333,你好~
太真实了哈,深挖坑广积粮本身也没错哈,一场仗打完,大家休整休整,稳稳队形,打打基础也是没错的。
不过最后一点,把系统重做一遍,占地盘写好PPT,我就不敢说了…… 可能确实有企业这样吧,不过我看到的情况大家至少出发点还是对的,毕竟那么多钱花出去了,也得看结果见效果,企业的管理层也都不是那么好糊弄的,光靠PPT也撑不了多久,还得有点实际的不是:)
感谢你的留言,欢迎继续把自己的想法分享出来~
作者回复: 业余草,你好~ 感谢分享哈,关注了……:)
作者回复: 西红柿牛男,你好~
刚回复了一个类似的问题哈,感觉大家对于这300篇文章都很感兴趣…… 其实分享没有问题,只是我觉得意义不大,因为专栏本身就可以理解成对于300篇文章的精华的浓缩(当然会受我的视野和能力所限),这也是我认为这个专栏对于大家的价值……至少还能省一些阅读和提炼的 时间。
而对于一些我认为对我有很大启发,干货满满的文章,我也统一放到了总结篇里,作为扩展阅读分享给大家。
当然,如果大家还是对这300多篇文章感兴趣的话,可以继续留言告诉我,我也可以找个地方或是想个法子,把文藏列表整理出来(目前在印象笔记里),都没有问题~
最后感谢你的留言,有问题可以继续留言给我,我们继续探讨~
作者回复: 风行,你好~ 感谢分享^_^
作者回复: HappyJoo,你好~
没毛病哈,像我说文中也说到的,组件化,拼拼凑凑拖拖拽拽就能快速攒出一个软件来,就跟攒电脑似的,一直是大家这么多年来的梦想。
所以才会有这么多标准、组件库、框架、nocode、lowcode平台产生,而中台只是组件化在企业级的范围下,向业务又迈出的一步而已~
感谢你的分享,其实并不浅显~ 细想想还很深刻~
希望有更多感悟也可以随时留言,分享给大家~
作者回复: 总结的好形象哈,学到了^_^
作者回复: Will,你好~
感谢关注,中台的建设往往离不开遗留系统的服务化改造,但是反过来不一定,遗留系统的服务化改造不一定是冲着企业级能力共享,也就是中台去的。
这个课程没有太多,聊到微服务改造的部分,不过一般常用的工具也都差不多,目前大家说的最多的也就是用DDD的问题域和限界上下文做服务划分,然后通过重构的手法来做平滑的系统改造。
希望你能从专栏中吸取到养分,帮助解决一些困扰和问题,随时交流~
作者回复: 老王的老李头,你好~
据我所知,中台的理念早就进入到政府行业了,而且还有不少都是国家级的。
这一点从今年的几次政府采购的中标新闻中也能看得出来,也都纷纷提到了中台,甚至是作为亮点写到了中标新闻稿里。
我本身就是做政府行业出身,10多年前就是做相关的项目。对于政府行业来讲,组织的壁垒可能更难打破,但中台或是中台理念的价值也因此而更加的重要和明显。
好在我们看到很多先行者们已经开始探索,当然这也少不了各个参与方的齐心合力,改变正在发生,让我们一起拭目以待吧:)
作者回复: 日拱一卒,你好,好名字哈哈~
留言说的是,俗话说的好,分久必合合久必分,阿里巴巴的张勇也在很多文章提到过,他最关注的几件事有一件就是企业里哪些部分该合哪些部分该分,去年合的可能今年就分了,去年分的可能今年再合起来,而分分合合的背后就是战略的调整,而战略的调整背后就是愿景与使命……
我现在看到很多中台建设比较早的企业,已经开始“合久必分”了。
所以要动态的看待中台这个问题,合自然是好的,但是也有问题,至少有成本,合完了也总有一天要分的,所以就像我在其他回复里提到的,“我们永远做不对”,只能不断提高自己应变的能力,与变化共舞。
在我看来这分分合合,好像是在找一个平衡点,在最后总结的时候我会提出我的想法,到时候如果还有问题,我们还可以继续深入或是展开~
作者回复: Watts,你好~ 相信后面的内容会解答你的问题,在07的时候我还专门谈了一下我对于业务中台和微服务的看法,希望对你有所启发~ 如果有任何问题和反馈,也欢迎继续留言~
作者回复: Myself,你好~
你说的其实挺对的,很多不同的概念,到底就还是封装、复用、隔离变化点,单一职责,高内聚,低耦合这类基本原则,只不过是作用在不同的层次上而已。
前一阵听说字节跳动的张一鸣,提出过一个概念叫做Company as a Product,我觉得特别好,这就相当于我们可以用治理软件的原则和方法,来思考对于企业的治理,比如思考能不能把设计模式应用到企业管理上之类的……而这本质上就又回到了康威定律,就不展开了哈
其实像我说的,叫什么不重要,本质上中台就是两层不够了,加一层来解决问题,以后可能三层不够了,再分个中前台,中后台,也都说不定……
所以我很认同你的观点,也感谢你的分享,有问题可以继续留言分享自己的观点和反馈~ 感谢
作者回复: MIddlem,你好~
从平台化跳转到中台,我认为是可以的,也是中台常见的一种演进路径。
我在最后10总结篇中推荐的张巍老师的《七问七答,亲历者讲阿里中台落地的实践》中,张老师讲阿里当年基于实际的问题,从交易平台通过对于平台能力的治理,也才是阿里的平台化到中台化的进程。所以张老师才说中台是平台的下一站。
这个思路我认为跟你现在想做的不谋而合,建议你看一下张老师这篇文章,肯定会对你有所启发。
希望我的留言对你有些帮助,欢迎继续留言交流~
作者回复: 一直,你好~
多功能宝盒的比喻好形象哈,你的理解没什么问题,只是后面会讲到建这样一个多功能宝盒可能还是有点困难的……
还有像你说的在这个仓库里,企业也能清晰看到自己到底有哪些能力,缺少哪些能力。其实要想做到这点,也还是挺难的,真正做到的也不多。
我看到的很多实际情况是,很多企业做中台建设很久,抽了很多的服务,但是到底有哪些能力在中台里,并不是非常的清晰。后边我会讲到,这也就是我们常说缺少对于能力的治理和产品化包装整合。
总之,你理解的都挺到点子上的,很多人包括我也是这么理解的,不过就是建设的过程中各种具体才会迎面而来,或是容易驶离了初心,我这个专栏也是想讲讲这些容易碰到的坑和问题,以及如何规避或是提前有个准备。
希望后边的内容能给你更多的启发,有问题也欢迎再次留言,我们再一起探讨~