2015年底,当大部分企业忙着进行年度总结和下一年的规划的时候,阿里巴巴集团对外宣布全面启动阿里巴巴集团2018年中台战略,构建符合DT时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制,即作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场、而中台将集合整个集团的运营数据能力、产品技术能力,对各个前台业务形成强力支撑。
与任何一个公司一样,阿里巴巴组织架构的战略调整肯定会对公司现有组织架构、部门之间的协作等各个方面都将带来深远影响。战略执行到位、3年之内达到战略调整目标,对业务的创新和支持将带来巨大的影响,假若没有很好的控制战略执行过程中的风险,对组织架构的动荡太大,都会和现有的业务带来巨大的冲击,甚至为拉垮整个业务产品。
那么阿里巴巴为什么要做出这么大的决定去做中台呢?这个主要还是马老板在拜访了芬兰的一家游戏公司之后,发现他们企业用一个200人不到的研发团队,支撑起一家年税前利润超过15亿美元的公司,效率太高了,并发现他们采用的就是中台战略,因此阿里巴巴就将这个先进的企业架构理念引入到国内,并想做第一个吃螃蟹的人。
好吧,当这种架构模式在阿里这么巨大的业务体上跑通之后,各大中小企业也就开始要效仿阿里巴巴去做中台了。
我们先来看企业为什么要建中台?想要回答这个问题,咱得先解决另一个问题,那就是企业为什么需要平台化?企业为什么需要平台化呢?先给我的答案:因为在当今这样一个互联网时代,用户才是商业战场的中心,为了快速响应用户的需求,借助平台化的力量可以事半功倍。这背后的逻辑很简单,不断地快速响应、探索、挖掘、引领用户的需求,才是企业得以生存和持续发展的关键因素。那些真正尊重用户,甚至不惜调整自己、颠覆自己来响应用户的企业,将在这场以用户为中心的商业战争中得以生存和发展。反之,那些在过去的成就上故步自封,存在侥幸心理希望用户会像之前一样继续追随自己的企业,则会被用户淘汰。很残酷,但这就是这个时代最基本的的企业生存法则。
而平台化之所以重要,就是因为在这场以用户为中心的现代商业战争中,它赋予或加强了企业最核心的能力:用户响应力。平台化思想(Platform Thinking)恰好鼓励企业不断抽象沉淀自己核心的底层能力,通过平台化包装,得以更好地赋能前台业务,用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。从结果来看,在不确定性当道的当今商业战场,真正的弄潮儿也大多是那些具备平台化思维并很早就开始发力平台建设的企业,这也在一定层面上佐证了平台化对于一家企业的重要性。
好,现在我们想明白了第一个问题,企业为什么需要平台化。但是平台化并不是一个新概念,很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起?对于企业来讲,传统的“前台 + 后台(或是平台)”的平台化架构为什么不能满足企业的要求呢?这就引出了我们的核心问题:企业为什么要建中台?同样,先给我的答案:中台化是平台化的下一站,是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能,真正为前台而生。
为了能够更清楚地讲解我的观点,这里需要先定义一下,在今天我们讨论的上下文中,前台和后台分别指什么:
前台:由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点,大多是企业最终用户直接使用的系统,是企业与最终用户的交点。例如用户直接使用的网站、手机 App、微信公众号、小程序等都属于前台范畴;
后台:由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源(数据 + 计算),例如财务系统、产品系统、客户管理系统、仓库物流管理系统等,这类系统构成了企业的后台。(在和很多互联网的朋友聊过之后,在互联网企业很多并没有后台的概念,更多直接使用平台的概念,例如分为前台层和平台层,但位置和作用与传统企业里的后台相似,我这里直接统一使用后台这个概念来代表。)
我参考了很多资料之后,给中台下一个定义,那就是企业级能力复用平台,这 9 个字看起来简单,重要的是其背后对“中台”价值的阐释,下面就让我为你一一拆解来看。
(1)企业级;
企业级定义了中台的范围。不是说一个企业只能有一个中台,也不代表一个中台就是只能包含一家企业,企业级更多代表的是中台处理的问题在企业级别,即至少包含多条业务线或服务多个前台产品(团队),如果一个中台只为了支持一条业务线或产品线,那就不是中台,即使它用了服务化或是大数据等技术。企业级这一点非常非常重要。它让我想清楚了,中台建设的事情并不是一个技术问题,而是一个要上升到企业架构的问题。做中台建设的时候,一定是跳出单条业务线、站在企业整体视角来审视业务全景。想清楚了这一点,我对中台的理解就有了一次质的变化,也终于知道为什么一开始用做系统服务化的方式做中台会面临那么多的问题,比如最常见的组织和干系方以及利益再分配的问题。从中台的兴起与爆发我们也能看到一个趋势,就是越来越多的企业,无论是想提升自身的运营效率,还是出于业务创新发展的需求,都已经把企业全局视角、跨业务线的能力沉淀,提到了前所未有的战略高度。
(2)能力;
提到中台,最常听到的一个词就是“能力”。可能是因为能力这个词足够简单,又有着足够的包容度与宽度。能力定义了中台主要承载的对象。能力的抽象解释了为什么会有那么多种类中台的存在,也能解释为什么每家企业的中台都不一样,因为不同的企业之所以能够同时存在,就是因为其核心能力不同,可以满足用户不同层面的需求,也就是我们常说的差异化竞争力。
(3)复用
复用定义了中台的核心价值,也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注,更多关注的是如何消除掉重复的能力建设,既所谓的“去重”。
(4)平台
平台定义了中台的主要形式。区别于传统应用系统拼凑的方式,中台通过对于更细粒度能力的识别与平台化沉淀,实现企业能力的柔性复用,更好地支撑前台业务,来满足对于业务的快速响应和复用的需求。
“企业级能力复用平台”这个定义虽然看起来简单,但经过这么长时间对于中台的实践与思考,我觉得这个定义背后所代表的意义是目前对中台价值的最贴切的阐释:
“企业级”定义了中台的范围,区分开了单系统的服务化与微服务;
“能力”定义了中台的主要承载对象,能力的抽象解释了各种各样中台的存在;
“复用”定义了中台的核心价值,传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注,中台的提出和兴起,让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上;
“平台”定义了中台的主要形式,区别于传统的应用系统拼凑的方式,通过对于更细粒度能力的识别与平台化沉淀,实现企业能力的柔性复用,更好地支撑前台业务。
如果一个企业完全去照搬阿里巴巴的中台模式,去构建业务中台、数据中台和技术中台,那么基本可以断定是要失败的,为什么这样说呢。
第一点,绝大部分企业都没有像阿里巴巴那样大的业务量;
第二点,绝大部分企业都没有像阿里巴巴那样大的技术储备;
第三点,绝大部分企业都没有像阿里巴巴那样,去落地中台的决心。
所以,如果照搬,那么项目大概率是要夭折的,我们中小型企业只能采用最短路径的方式去落地中台。
一般我建议大家按照如下路径去做。
第一步,如果企业内部的技术还没有统一,则需要优先去建设技术,搭建一套既能满足现状,又能有一定的超前的技术体系,我推荐大家采用Spring Cloud Aalibaba作为基础框架,去标准化微服务技术体系,这个是最基础的。也就是说在Spring Cloud Alibaba的基础之上去构建一套最小技术中台;
第二步,在完成技术的标准化之后,就可以去落地业务中台,然而在落地业务中台的过程中,又要按照三步走的套路:
(1)高屋建瓴,构建一个业务中台蓝图,从而让所有的人都知道中台的架构以及开发人员需要去做什么?
(2)挑选最基础的服务去落地,比如加解密服务、用户服务等。为什么要这么说呢,主要是这些服务不会去触碰最上层的产品业务,也就是公司最核心的业务,从而会有更加充裕的时间去试错。
(3)从下往上逐层去落地业务中台,最终到完成一个最小产品矩阵的业务中台,比如某一个业务领域的业务中台,但是这个中台并不是涵盖整个公司所有的业务场景。如果说公司想要去重新包装一个新的产品的话,可以利用这个最小业务中台去重新孵化,并且在孵化的过程中,也会给中台输出更多的业务需求,从而达到产品层次的互惠互利的局面,只有这样咱们的业务中台才会落地。
总之,我们企业不能去做东施效颦,而是要做一个真正的西施,不仅要学到轮廓,也要去学到消化之后的精华,这样才能真正的将中台的效能最大化,而不是公司某一位领导的政治业绩。
https://item.jd.com/14337086.html?编辑https://item.jd.com/14337086.html
“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后,又一本历时超过1年半的巨无霸技术实战类型的书籍。
为了提高读者阅读本书的体验性,本书总共设计了十个特色,下面我一一的给技术小伙伴阐述一下。?
本书将RocketMQ的技术原理和最佳实践体系化,按照由浅到深的顺序呈现给读者,使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后,读者不仅能熟悉RocketMQ的核心原理,还能充分理解RocketMQ的“根”。
本书不仅包括RocketMQ4.x(4.9.2版本)的核心原理分析和最佳实践,还包括RocketMQ5.x(5.1. 0版本)的新特性分析和最佳实践。
本书精心研究了程序类、架构类知识的认知规律,全书共分为6篇:①基础;②进阶;③高级;④高并发、高可用和高性能;⑤应用;⑥新特性,是一条相对科学的主线,让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。
一图胜于文,书中在涉及原理、架构、流程的地方配有插图,以便读者更加直观地理解。
本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理,并从架构的视角展开分析,这些也是程序员进阶为技术专家或架构师必备的技能。
以下为从架构师和技术专家的视角分析RocketMQ典型案例,读者阅读完本书之后,也能够达到这样的水准。
本书介绍了大量的实战案例,能让读者“动起来”,在实践中体会功能,而不只是一种概念上的理解。
在讲解每一个知识模块时,我在思考:在这个知识模块中,哪些是读者必须实现的“标准动作”(实例);哪些“标准动作”是可以先完成的,以求读者能快速有一个感知;哪些“标准动作”具有一定难度, 需要放到后面完成。读者在实践完书中的案例之后,就能更容易理解那些抽象的概念和原理了。
本书的目标之一是,让读者在动手中学习,而不是“看书时好像全明白了,一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力,这样本书的价值就会被最大化。?
本书相信“知行合一”的理念,而不是“只知,而不行”,避免开发人员出现眼高手低的现象。尤其是在技术面试过程中,面试官更加看重的是既懂原理,又能够主动是实践技术的技术人。
?本书以系统思维的方式,从业务功能视角剖析?RocketMQ?底层的技术原理,使读者具备快速阅读?RocketMQ?框架源码的能力。读者只有具备了这种能力,才能举一反三,实现更复杂的功能,应对更复杂的应用场景。
?本书向读者展示了如何修改?RocketMQ?源码,并快速验证案例分析。这样,读者可以从中学到参与开源的技能,并为后续自己能够参与开源做准备。
为了提高读者阅读本书的体验,在有上下两册的前提下(巨无霸,超过800页),出版社不吝啬印刷成本,依然采用双色印刷。
?为了提高读者学习RocketMQ的效率,我这边结合我自身从RocketMQ小白到RocketMQ专家的经历,为读者汇总了一条最佳学习路径。
RocketMQ是我深度参与研究的一款开源消息中间件,无论是从源码,还是架构场景,我都提炼了很多最佳实践。
在开源领域,技术小伙伴可以使用的开源消息中间件非常的多,比如Kafka、Pulsar等,我之所以选择研究RocketMQ,除了工作内容和角色需要之外,更多的还是自己感兴趣,因此我建议技术小伙伴一定要先培养自己的兴趣,兴趣才是提升技术硬实力的第1要素。
当然我并不止研究了RocketMQ,还研究了Pulsar和Kafka等(包括开源消息中间件生态中的主流框架),只是本书作为一本关于RocketMQ实战派的书籍,我必须要以RocketMQ为主。
假如技术小伙伴想成为Java领域的架构师或者技术专家,我强烈建议你去研究RocketMQ,它会给你带来很多意想不到的技术和架构方法论的收获,这个也是我写本书的主要目的之一。
建议技术小伙伴按照本书设计的学习路线,逐章的去阅读和实战,这样学习效果会更好。
如果技术小伙伴有技术交流的,可以通过博文视点官方的读者群找到我的联系方式,并与我沟通,我会实时的解答读者的疑问。
本文公众号“架构随笔录”
本人视频号“架构随笔录”
2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”,它是我涉足知识输出领域以来的第一本书,同时它也是我自己积累的技术池中部分技术的产出。
为了写好那本书,我几乎花费了所有的休息时间,并主动的承担了书的售后技术辅导和咨询的职责(几乎是有问必答,坚持了整整两年)。
所谓有付出总会有回报,Alibaba这本书的销量还不错,我也因此获得了博文视点颁发的2021年度优秀作者。
我很清楚,这个是博文视点为了鼓励我继续去用心写书,因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。
所谓一分耕耘一份收获,我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人,希望真的对大家有帮助。
2022年,我开始涉足技术直播和技术讲师领域,并和博文视点合作几次技术直播,直播效果还不错,再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术,并且这些技术都是有助于“技术人”快速成长的,因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项,这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术,因此只要我有时间,我就会孜孜不倦的去讲和聊技术。
2022年,我开始涉足企业培训和相关技术直播,并和“四维口袋”合作了几次技术直播,并荣获了2022 KVP最具价值技术专家的技术奖项。
?