首页 > 互联网 > “水深火热”的中台

“水深火热”的中台


01 “水深火热”的中台

“中台”概念的缘起大家都清楚,来自马云先生对一家欧洲游戏公司考察后的感悟,一个比喻。实践层面,钟华老师写的《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》是第一本比较完整地阐述阿里巴巴中台实践过程的著作,可以说是中台布道的开始吧,钟华老师如今仍在实践其理念。

2019年中台可谓火的一塌糊涂,既有从原产地阿里巴巴出来的创业团队,也有将其原有实践简单包装冠以中台名号的“贴牌”者。

去年在的一次交流中,笔者曾经用Gartner曲线的形式,串起了与中台相关的书和文章,与参会者开了一个小小的玩笑,如图11所示:

▲图11 中台曲线

彼时还没有那篇炸了圈儿的文章,笔者也无意将其补进去,毕竟这张图也只是个玩笑。任何技术形态都会经历这个历程,架构理念也不例外。有价值的自然会重新走回上升态势,哪怕是10年以后,或者像AI一样几起几落;没价值的也就寿终正寝了。

Richardson 也说过:“人们往往容易被情绪因素所驱动,这也是为什么会有这么多关于技术的两极分化和过度粉饰的争论”。

中台就其设计理念而言,仍是为了有效降低系统设计复杂度、提升复用能力的企业架构方法。

去年南京中台大会的闭门讨论中,主持人曾要求每位演讲嘉宾用一句话概括自己对中台的认知,笔者当时说的也是“跟我实践过的EBA相似,也只是一种架构方式”,确实,就目的而言,二者殊途同归,都是在考虑识别、沉淀企业的业务能力,将其模块化、服务化之后,更好地支持业务变化。

笔者在《企业级业务架构设计:方法论与实践》一书中对EBA的定义:“以实现企业战略为目标,对企业能力进行整体规划并将其传导到IT实现端的结构化分析方法”。

EBA与中台的差别,在实操层面也许主要是EBA并未考虑要将沉淀的业务能力剥离为中台层,因为EBA主张企业级复用,从这个角度讲,也不需要单独进行一个特殊的表达。EBA形成的业务组件之间按照调用的频率也可以适当进行分层,但这种分层结果并非现在中台的含义。除此之外,中台目前对企业战略如何分解落地也没有很详细的解释方法。

EBA的一般设计过程如图6所示:

▲图6 EBA设计的一般过程

EBA的整体逻辑如图7所示:

▲图7 EBA的整体逻辑

如图8所示,EBA强调的是“知行合一”,强调企业自己对方法论的驾驭和对架构师的培养,未来的企业管理必然包含架构管理,企业管理追求的“韧性”很可能将来自于架构的“弹性”和演化能力。


▲图8 业务架构的知行合一

EBA方法也是一个业务架构设计与IT实现之间不断迭代的过程,如图9所示:

▲图9 业务架构设计与IT实现的持续迭代过程

阿里巴巴也是业务架构理念的实践者,业务架构根据其设计范围可以区分为领域级和企业级,阿里巴巴对业务架构的应用,从其自身披露信息来看比较侧重于领域级,业务架构师按领域配置和开展工作。当然,设计发展到一定程度,总是会自然关注到企业级。

对中台的探索,笔者认为仍然值得开展下去,无论它以后还叫不叫中台,这是对架构设计理念的探索。从阿里巴巴的角度看,也是他们在技术底层实践越来越成熟之后,对上层设计的必然追求。

笔者也不太赞同按照企业规模去给中台划个准入门槛,毕竟企业无分大小,只要系统建到一定规模或者数量,时间累积到一定程度,总有“技术债务”要还,总有重构的十足理由,那么作为一种架构设计理念去应用中台方法,未尝不可。

如果说到成本,规模小的企业当然不必仿照阿里巴巴的方式构建昂贵的基础设施,设备成本是由系统的非功能性需求决定的,与企业的规模、财务能力也是匹配的,所谓中台烧钱,可能主要是想照搬阿里的技术方案造成的吧。抛开这个,它与一般的重构相比,是否真的会大幅度提高重构成本,笔者还是怀疑的。

至于进行业务梳理的成本,只要企业想改革,这个成本无论用任何方法都是要付出的。

玄难和毗卢离职前,阿里的中台计划取名为“星环”,据说名称创意来自于刘慈欣老师的《三体》,是那艘超光速飞船的名字,对于快的追求不言而喻。但是从笔者的角度来看,倒是更喜欢美剧《无垠太空》中的“星环”,每个“星环”都是通向一个世界入口。

企业自建中台需要自身的沉淀,中台产品提供商则需要行业沉淀,现实中,还需要对行业中处于不同位置或者细分领域的客户进行不同分类的沉淀,如此看,中台就像“星环”一样,是通向不同世界的入口。如果愿意再揶揄一下,走进入口,遇见的可能是“天堂”,也可能是“地狱”。

EBA也可以成为“星环”,道理是一样的。通过EBA也可以不断积累对行业或者细分领域的模型,这些模型不仅对架构设计者有所帮助,而且可能是未来走向自动化设计、AI设计的必经之路,因为AI也需要架构数据的供给才能产生设计能力,而目前架构领域连案例都经常是语焉不详、光怪陆离,更不说积累数据了。

02 中台与“组合拳”

其实中台与“组合拳”的关系,阿里巴巴的人自己出来多讲讲会更好。

从笔者的了解来看,阿里巴巴的中台实践中,“组合拳”的应用是不少的,他们的特点是一般不会强制团队使用某种方法。微服务显然是广泛使用的,敏捷开发、DDD在不同的团队中也都有应用,但是,应该不是每个团队在每次开发中都采用这些方法。

阿里巴巴的中台,据说在大规模构建之前面对的问题之一就是企业已经有上万个微服务,每次承接新需求都可能有数百个微服务受到波及,而服务数量如此之多,以至于没有人能搞清楚业务能力到底有哪些、是如何分布的,所以,搞起了业务架构,分离业务领域,理清不同领域的业务模式,再沉淀业务能力,形成中台。

微服务是中台在技术层面落地的方式之一,但是中台设计要有效地为微服务的划分提供指导,并从架构层面提供业务能力的可视化,进而支持业务能力的持续优化,通过架构演进指导微服务的设计与变化。微服务则在技术落地上提升对业务能力的运维支持,提供良好的升级维护和可扩展性。

在分离业务领域方面,DDD方法也有一定范围的使用,毕竟这种方法与微服务的结合被广泛传说,而且DDD的思维方式就是侧重对限界上下文的分离,以达到在同一个限界上下文内对同一业务概念理解上的一致。每年Thoughtworks的大会上,也都有阿里人来分享应用DDD的经验。至于敏捷开发,更是常被当作互联网企业的标配。

中台跟“组合拳”的关系,其实也应该类似于EBA跟“组合拳”的关系,只是现有的信息中,中台并没有像EBA那样给出一个明确的设计过程和方法,所以,分析也很难做的更深入,这并不是对着几张漂亮的架构图就可以做的比较。

03 特化与泛化

笔者从各种交流,包括对笔者文章的留言中,也能感受到,中台面临的一个问题就是领域的积累达到一定程度之后,必须从企业层面去思考问题。

所谓的做中台以支持业务的灵活变化,那到底业务是什么?到底是支持需求还是支持业务?技术人员到底理不理解业务?需要理解到什么程度?需求到底是来自业务人员的还是来自真实客户的?

说到底,就是技术到底怎么支持业务,其实这样说还是有些“见外”,应该说,技术到底怎么跟业务融合。

这波对中台的争论,也反映了对阿里中台的一个认知问题,它到底是个特化的方法还是泛化的方法。

从阿里自身看,这首先是一个特化的方法,理由不难理解,他们要梳理自身过于复杂的微服务实现状况,要支持业务端给数千万商户提供的千变万化的营销、管理手段,要面对复杂的商业生态和大量的不确定性,应对每年“双十一”独步全球的高并发环境,应对互联网领域“唯快不破”的残酷竞争,还要应对大量的技术“无人区”,这样可谓“极端”生存环境下产生的方法,一定是个“特化”的方法。

其实每个方法诞生之初都是“特化”的,面对的环境越极端,方法的特化性相应也越强,阿里的中台也理应属于这种情况。

但是大家需要的是一个泛化的方法,这就需要首先解释清楚方法的特化之处,考虑清楚对特化的处理,才能实现泛化的目标。

作为一个局外人来看,笔者建议,把阿里中台方法中的各种武器首先拆分清楚来看,先不要抱着“要要要”“买买买”的想法,而是搞清楚武器之间的关系和成本,应用的前提条件和最适宜解决的问题,再对号入座,实现“客户化”过程。

比如,业务能力梳理方法、组织结构是不是直接对标阿里(阿里可是经常变的)、微服务要不要搞、阿里技术栈选用哪些、需要全链路压测吗等等之类的问题。

一个泛化的方法在应用过程中还是会再经历一次本地的特化,尤其是中台、EBA之类的企业级方法,这也代表需要足够的时间和成本。“九尺之台,起于垒土”,中台的构建,也少不了“搬砖”的过程。

对于做中台产品的服务提供商而言,应当把中台认真当成一个软件工程方法看待,把其中的组成要素、软件过程、可选方案都研究明白,“工欲善其事必先利其器”,这是对工匠的基本要求。

对于这些厂商而言,帮助客户搞清楚自己要的到底是特化的阿里中台还是泛化的中台,是很重要的。

泛化的中台意味着要根据客户的实际情况决定中台的实施目标,而非靠“对标”的方式预先诱导实施目标,后者销售的意味太过强烈。当然,这种情况不只中台有,但凡商业化的东西,都有这个问题,说“酒香不怕巷子深”的越来越少了。

中台说到底也是一个技术怎样与业务融合的问题,看到了一个有成功实践做背书的技术理念,但是套用到自家业务实践上,却发现“知行合一”远非易事。

作者:付晓岩,《企业级业务架构设计:方法论与实践》图书作者,原国有大行资深业务架构师,负责业务架构设计、项目管理,热衷新技术探索与实践,具有丰富的银行业务经验和企业级项目业务架构设计经验,曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计,现就职于建信金融科技有限责任公司。

本文来自投稿,不代表本人立场,如若转载,请注明出处:http://www.souzhinan.com/hlw/379324.html