作者回复: 秋水,你好~
首先,我也比较同意汪总的说法哈,如果给中台找一个关键词,我可能就会选“业务”。如果能找两个,我可能再加上一个“赋能”。
不过对于技术中台很难有业务属性,所以不能算是中台,我也有一些自己的思考和意见。
我认为,中台的关键字是“业务”,从狭义上来讲就像上边说的必须包含业务属性,从这个角度上来看,技术中台很难有业务属性,所以不能算“中台”。
但如果把外延扩一些,只要是从业务的视角出发,只要为了为业务更好赋能的,帮助业务更好的创新和响应用户的改进,也算是中台化的过程的话。
那像对于技术平台的产品化包装,打造自助服务平台,关注业务的用户使用体验,让业务可以更快速更方便体验更好的使用企业内部的技术能力。
如果这个过程也能被中台这个概念和趋势推动,让更多人意识到要从业务的视角、以产品化的思路,关注用户(业务前台)体验,去建设技术平台,并以此称之为技术平台的中台化改造,我认为也是有重要价值的。
所以还是那句话,具体什么是中台什么不是中台并不重要,这个概念能帮我们推动什么,解决什么问题才重要。
作者回复: laugherxiao,你好~
不好意思,回复的有些晚了…
关于概念炒作,我文中也提到过,我一开始的时候也是这么认为的,觉得现在这个时代太浮躁了,大家整天都在炒概念……
而对于业务中台和数据中台到底是不是概念炒作,我现在也不知道,有可能。
但是我自己始终提醒自己,对于一个新的概念,要先报着开放和学习探索的心态,去了解,去思考这个“概念”背后到底是什么,有那么多概念,为什么只有这个这么受人关注,有“炒作”的空间?
新概念本身是没错的,因为新概念往往代表着新的边界,新的约束,而新的边界和约束也往往就是新价值的来源(例如SOA和微服务,虚拟化和云)。
炒作本身也是没错的,一个新的东西,无论是新的层次还是新的边界产生,如果其本身能创造新的价值,让更多人知道这个价值,帮助更多人解决遇到的问题,也是挺好的事情。
所以我的观点是,永远保持好奇,先接纳,再判断。不要轻易把门关上,可能会错失掉一些新的东西,就算是进去转了一圈,最后发现并没有什么新的价值,其实也没有多大的损失不是。
技术的发展,在我看来,也正是在不断的新概念产生发展,也就是新的边界和新的抽象层次的发现与包装沉淀下,在抽象层次不断向业务方向的推进过程中(操作系统->编程语言->库&框架->业务组件服务(中台)……)滚滚向前的。
当然,我们也要知道何时停止,不要在价值不大的新概念上浪费太多的的精力,及时踩下刹车。
这一点推荐一个工具,也就是Gartner每年都会推的新兴技术成熟曲线,对于一个新概念,我们也可以用这样一个曲线,从一个技术的全生命周期视角来思考,到底正处于哪个阶段,是该踩下油门还是该踩下刹车了(XX Envy)。
希望对你有所帮助和启发,有什么新的想法,欢迎继续留言探讨~ 感谢支持和评论^^
作者回复: Darren,你好~
首先感谢你的留言,首先我理解你这里谈到中台指的是业务中台(像文中提到的中台的种类有点多,讨论还是需要划个上下文)~
我能理解你提到的观点,我也非常认同。
不过这里有一个小建议,就是我们在谈中台的时候,往往在业务、应用和技术中跳来跳去,一会儿谈的是技术架构层面例如微服务、切面、TMF、Spring,一会又跳到应用架构层面,例如各类业务系统,一会又跳到业务架构,比如支付之类的。这样的感觉就是在不同的抽象层次跳来跳去,让人比较容易懵。
所以建议,在谈中台的时候,需要先给一个上下文,比如从业务中台的技术架构层面谈微服务,spring,TMF;或是从业务中台的应用架构层面谈前中后台的业务系统;或是从业务中台的业务架构上谈用户、支付、订单、仓储物流,这样就比较清晰,也容易在一个相同的上下文内更好的交流与沟通~
而我上边说的那几个架构,都是在企业架构(EA)范畴之内,我们在07部分会做一定程度展开,以及最终的总结篇里还有一些参考资料,希望能帮助你理解~
作者回复: 远大理想,你好~
又见面了哈(可能我是倒叙回复留言的……),你的概念性思考(Conceptual Thinking)能力确实比较强哈(不才,我也是,哈哈)。
有这种能力的人,会习惯讲不同领域的知识和概念思想平移、关联和打通,并追求其背后的本质问题,再以此来解决和解释更多的未知问题。从而将知识点连线,线连面,面成体,构建自己的思维框架和体系。
所以学习新知识的过程知识在原有的知识体系中与旧的知识体系连接和定位的过程,也会比别人快的多~
希望你在后续的学习过程中,可以充分的发挥这种能力,给我们带来更多有意思的类比、发散和启发,期待~
作者回复: zscome,你好~
感谢留言发表自己的观点~ 首先,我同意你的理解,我觉得没什么问题,非常准确,你也谈到了核心领域是不变的,这点也是我们在构建中台的核心:从不确定性中找确定性,将其分离,再通过确定性帮助我们更好的应对不确定性……
但是,多说两句,这个理解也有一些局限,看起来更匹配业务中台,如果用这个解释去解释数据中台、技术中台、组织中台就会感觉有些局限。
为什么现在大家谈中台的时候,谈的都不一样,在我看来就是都是从自己的企业和场景出发(也没错),所以当有些人谈中台时,说的是数据中台;有些人说中台的时候,默认说的是技术中台等等。
我经常比喻,这就像是云早期的时候,大家都在谈云,但是谈的又都不是一个东西,都觉得自己的才是真的云……
但是从第三者看说的都不是一类东西,后来才知道,原来你说的是IaaS,我说的是PaaS,他说的是SaaS……
所以我写02,就是希望给大家一个全局视角,跳出自己对于中台的理解,我们从整体上看一下到底都有哪些不同种类的中台,先发散再收敛,再看看,中台到底是什么,到底分几类,就跟云一样,把概念清晰,避免大家在谈中台的时候都是在不同的“限界上下文”下,感觉说的是一个词,但是其实是不同的概念。
你理解的没错,我只是做了一些扩展,希望大家能理解为什么每个人看中台都不一样……最后还是要感谢一下留言分享自己的心得,有问题可以继续留言,我们继续深入探讨~
作者回复: 苏忆,你好~
刚回答了一个类似的问题哈,只不过还在后边章节:)
其实这个问题我在下一讲03的时候,就会简单展开介绍一下,还没到哈。
这里可以先回答一下,其实这个问题,之前也一直困扰着我,我曾经翻遍了阿里那本讲中台的书,都没有找到这个问题的答案。后来和一些前阿里的朋友聊的时候,才知道当时阿里内的后台,更多代表的就是一些企业内部的运营系统,例如人力,财务之类的,与中台没什么关系。
与中台对应的是平台,比如阿里的业务中台就是由阿里早先的交易平台演进而来,所以我才说中台化是平台化的下一步。
但是回到很多传统企业,由于IT发展历史悠久,就有了与中台对应的后台概念,例如核心ERP之类的。这时候中台就像我03中提到的变成了后台与前台之前的变速齿轮和桥梁。
所以我后来才想明白,为什么中台和后台这么乱,是因为不同的行业,不同的企业,对于这些词的定义都是不同的,这块熟悉DDD的朋友肯定能知道,在不同上下文下的同一个词可能不是一个概念,不同上下文下的不同的词反而又可能是一个概念……
这块再推荐一下文中推荐的《阿里的中台战略其实是个伪命题》和《七问七答,亲历者讲阿里中台落地的实践》两篇文章,希望能给你一些启发,有问题可以继续留言交流~
作者回复: 业余草,你好~ 组织架构确实是难点,因为涉及到组织边界的责任与利益再分配的问题,感谢分享~ 最后也有一些组织层面的书和资料推荐,有兴趣也可以看一下哈~
作者回复: 风在身后,你好~
首先你的问题,中台与平台的区别,我在03的时候会给出我的理解和认识。不知道你是否已经看到了,能不能解答你心中的疑惑呢?
关于“炒概念”,我在上边回复“ laugherxiao”的时候也已经展开说了说我的看法,总之,我还是觉得炒概念也没什么不好,要保持开放的心态来看待新概念的产生,技术就是在不断地“微创新”推动下前进的,但是也确实需要有自己独立思考的能力,知道什么时候停止,那个回复里讲了,这里就不展开了。
最后,如果你看完了后边的内容,仍然有什么疑问和问题的化,欢迎再次留言,我们继续深入探讨~
作者回复: 一步,你好~
感谢你的留言分享,也很高兴能给你一些启发。
可能平台这种东西在企业内部更多的还是技术部门去推进,所以也多是技术视角。
而技术和业务,就像研发和产品一样,因为立场不同,也一直是个对立面。所以让平台去具备业务视角,从业务出发,这看似是理所当然的,但实际上是非常非常难的。
我希望中台这个概念能让大家认识到这一点,可能其使命也就完成了~
感谢你的留言分享,有好想法或是理解也欢迎继续分享给大家~ 感谢
作者回复: 你说的对,尤其是最后的“如何在现有技术约束条件下以最小成本落地实施,并且获得最大收益,这样的最佳实践,才最有意义”,这就是“业务”这两个字最原始的意义,也是我认为中台的目的,所以我常说“中台是什么并没那么重要,中台对于企业解决了什么问题才重要”~ 感谢你的留言,受教了~
作者回复: 莲台野夜行,你好~ 问的问题都是大家关注的点,业务中台与微服务拆分;数据中台与大数据平台的差别;这两个问题我在后续都有针对性的展开介绍,看过之后,如果有不同意见或是反馈可以再留言交流哈~ 感谢支持:)
作者回复: vkingnew,你好~
对呀,所以为什么大家往往都是从数据中台开始做,就是我说的以及你总结的这些点,而且数据的打通痛点也比较明显,数据中台对于业务的价值也比较容易说清楚。
但数据中台真建起来也不容易,很多企业都是拿着数据和技术找场景,我们则认为应该场景优先,再补技术和数据。这点还是推荐凯哥的公众号和文章哈,代表了我们对于数据中台的理解和方法~~
作者回复: 毛毛,你好~
是哈,本身数据和业务就是一体的,数据业务化,业务数据化,原来还能用OLTP和OLAP来区分,现在大数据技术,流式计算,实时计算已经逐渐在抹平这种差别。再加上很多企业的主数据管理系统(MDM),这三者就更扯不清了。
所以到现在,我也不是非常纠结边界的问题,回到问题本身,本着“如无必要,勿增实体”的奥卡姆剃刀定律,本着中台的建设愿景,以演进的视角来驱动架构变化,这样反而能实质性的推进和见到效果。
具体内容后边会讲到,感谢关注,持续交流~