前段时间写过一篇数据中台:《阿里数据架构师告诉你,如何建立实时数据中台》,引起了读者很大的兴趣,现在我想更加详细的讲一讲数据中台,结合上面的这篇文章,就构成了一套完整的不同于市面上的方法论!
中台战略是企业数字化转型过程中的一个热门话题。说到中台转型,企业大多对标阿里巴巴。
2015年阿里巴巴提出了“大中台,小前台”的中台战略,提出之初阿里有近 4 亿用户,为超过 1000万各类企业提供服务,业务种类繁多,业务之间相互网状依赖。同时,阿里部门也越来越多,分工越来越细,沟通过多,相互依赖,创新成本非常高,对业务响应也越来越慢。阿里需要找到能够对外界变化快速反应,整合阿里各种基础能力,高效支撑业务创新的机制。
相信很多公司或多或少都遇到过类似的问题,或者随着企业规模越来越大,也正面临着同样的问题。
很多IT人员在谈论中台时说:“我们在系统建设之初就已将产品、用户、权限、客户等公共模块独立成了共享的平台了,这不是中台吗?”也有很多人对中台提出质疑:“中台是个怪名词,它不就是平台吗?”
我们先了解一下阿里业务中台的发展历程。
阿里中台从业务中台和数据中台开始,后来发展出移动中台、技术中台、研发中台等。
“阿里业务中台的前身是共享平台,原来的共享平台更多的被当作资源团队,承接各个业务方的需求,为业务方在基础服务上做定制开发。”
看到这里是不是似曾相识呢。有的企业十多年前就已经完成了大一统的集中式系统拆分,将公共能力和核心能力分开建设,解决了公共模块重复投入和重复建设的问题。有的企业共享平台建设时间甚至比阿里还要早,但并没有发展成为像阿里一样的中台。
同样的起点,为什么结果会不一样?
阿里这十年经历了光速发展,同时业务领域快速扩张也增加了业务的复杂性,这种业务发展也只有像阿里这样的互联网企业才会遇到。可以说:业务的发展和复杂性推动了阿里中台的诞生。
我们再进一步来了解阿里业务中台的目标。
“业务中台是把核心服务链路 (会员、商品、交易、营销、店铺、资金结算等) 整体当作一个平台产品来做,为前端业务提供的是业务解决方案,而不是彼此独立的系统。”
这也是我们为什么可以在闲鱼上能直接登录淘宝、支付宝,在刷微博时也能流畅的跳转到淘宝和天猫店铺的原因。您是否感受到了这种跨平台融合能力的强大呢?
平台化只是将部分公共模块独立为共享平台。虽然平台通过API接口或者数据共享对外提供公共服务,解决了重复建设的问题,但由于这类平台并没有与企业内其他平台或应用实现页面、业务流程和数据从前端到后端企业级的全面融合,没有将核心业务服务链路作为一个整体方案考虑,各平台仍然是独立和分离的,本质上仍然为竖井式建设模式。
共享平台虽然解决了公共能力复用的问题,但离中台的目标还有一段距离!
中台到底是什么?“一千个读者就有一千个哈姆雷特”,业内提法很多。
听听阿里业务平台负责人玄难老师说说中台是什么?
“中台是一个基础的理念和架构,我们要把所有的基础服务用中台的思路建设,进行联通,共同支持上端的业务。业务中台更多的是支持在线业务,数据中台提供了基础数据处理能力和很多的数据产品给所有业务方去用。业务中台、数据中台、算法中台等等一起提供对上层业务的支撑。”
我们提炼几个中台的关键词:“共享、联通、融合和创新”。联通是前台以及中台之间的联通,融合是前台流程和数据的融合,以共享的方式支持前端一线业务发展和创新。
中台首先体现的是一种企业级的能力,它提供的是一套企业级的整体解决方案,解决小到企业、集团、大到生态圈的能力共享、联通和融合的问题,支持业务和商业模式创新。通过平台联通和数据融合为用户提供一致的体验,更敏捷的支撑前台一线业务。
中台源于平台,但中台与平台比,它更多的体现在一种理念的转变,它更主要体现在三个关键能力上:
其中最关键的是第3点:企业级的无缝联通和融合能力,尤其对于集团化的超大企业而言,这一点至关重要。
传统企业有别于互联网企业,阿里、腾讯等公司是互联网生态圈的创造者和流量入口,传统企业作为生态圈种群中的个体,除了需要做好原有的传统渠道业务外,还需要融入互联网生态圈,其商业模式、个体能力、与其他个体共生的能力决定了它的发展潜力。
为了适应不同业务和渠道的发展,过去很多企业的做法是开发很多独立的应用或App。但由于IT系统建设初期没有企业级的整体规划,平台之间融合不好,导致用户体验不好,关键的是用户也并不想装那么多APP!
为了提高用户体验,实现统一运营,很多企业开始缩减APP数量,通过一个APP集成企业内所有能力,联通前台所有核心业务链路。
由于传统企业的商业模式和IT系统建设发展的历程与互联网企业不完全一样,因此传统企业的中台建设策略与阿里中台战略也应该有所差异。
由于渠道多样化,传统企业不仅要将通用能力中台化(对应领域驱动设计的通用域或支撑域),以实现通用能力的沉淀、共享和复用。还需要将核心能力中台化(对应领域驱动设计的核心域),以满足不同渠道的核心业务能力复用的需求,避免传统核心和互联网不同渠道应用出现“后端双核心、前端两张皮”的问题。这属于业务中台的范畴,需解决核心业务链路的联通和不同渠道服务共享的问题。
除了核心业务链路的联通和服务共享,还需要解决系统微服务分拆后的数据孤岛、数据融合和业务创新的问题。这属于数据中台的范畴。采用分布式架构后更应关注微服务拆分后的数据融合。
在中台设计和规划时,需要整体考虑企业内前台、中台以及后台应用的协同,实现不同渠道应用的前端页面、流程和服务的共享,实现核心业务链路的联通以及前台流程和数据的融合,支持业务和商业模式的创新。
中台转型要做到:前台流程融合、中台服务共享、数据融合创新。
分布式和云原生等开源技术的逐步成熟,阿里、腾讯等互联网企业也从互联网业务主战场转型为面向企业的2B技术能力输出。这些成熟的云计算技术将为传统企业中台战略转型赋能,也为传统企业中台建设的技术路线选择提供了多种可能。
1. 先谈谈前台
传统企业早期系统有不少是基于业务领域或组织架构来建设的,每个系统都有自己的前端,相互独立,用户操作是竖井式,需要登录多个系统才能完成完整的业务流程。
中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案,实现各不同中台前端操作、流程和界面的联通和融合。不管后端有多少个中台,前端用户感受只有一个前台!
前台设计中可以借鉴微前端的设计思想,在企业内不仅实现前端解耦和复用,还可以根据核心链路和业务流程,通过对微前端页面的动态组合和流程编排,实现前台业务的融合。
2. 再说说中台
这里只讨论业务中台和数据中台。
传统企业核心业务大多基于集中式架构开发,单体系统存在扩展性和弹性伸缩能力差的问题,无法适应忽高忽低的互联网业务场景。而数据类应用也多数通过ETL工具抽取数据实现数据建模、统计和报表分析功能,但由于数据时效和融合能力不够,再加上传统数据类应用本来不是为前端而生,难以快速响应前端一线业务。
业务中台的建设可采用领域驱动设计方法,通过领域建模,将可复用的公共能力从各单体剥离,沉淀并组合,采用微服务架构模式,建设成为可共享的通用能力中台。同样的将核心能力采用微服务架构模式,建设成为可面向不同渠道和场景的可复用的核心能力中台。 业务中台面向前台、第三方和其它中台提供API服务,实现通用能力和核心能力的复用。
需要记住一点:在将传统集中式单体按业务职责和能力细分为微服务,建设中台的过程中,会产生越来越多独立部署的微服务。虽然提升了应用弹性和高可用能力,但由于微服务的物理隔离,原来一些系统内的调用会变成跨微服务调用,再加上前后端分离,微服务拆分会导致数据进一步分离,增加企业级应用集成的难度。
如果没有合适的设计和指导思想,处理不好前台、中台和后台的关系,将会进一步加剧前台流程和数据的孤岛化和碎片化。
数据中台的建设可分为三步走。第一步实现各中台业务数据的汇集,解决数据孤岛和初级数据共享问题。第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。第三步萃取数据价值,支持业务创新,加速从数据转换为业务价值的过程。
数据中台不仅限于分析型场景,也适用于交易型场景。它可以建立在数据仓库或数据平台之上,将数据服务化之后提供给业务系统。基于数据库日志捕获的技术,使数据的时效性大大提升,可为交易型场景提供很好的支撑。
数据中台主要完成数据的融合和加工,萃取数据业务价值,支持业务创新,对外提供数据共享服务。
为什么要单独来说前台的融合呢?因为前台的融合对企业级的业务融合非常重要!
中台通过微服务实现了后端应用的解耦,提高了应用的弹性伸缩能力。但中台化的过程中也会将单体应用拆分出许多的微服务,前台团队将会面对多个微服务团队。如何实现不同中台的前台融合?前台应用如何正确的连接和拼装这些服务?不是一件很容易的事情。
为解决前台与中台的集成以及前台页面和流程的融合,我们借鉴微前端设计思想。在前端设计时,对齐微服务功能和职责,按照领域模型和微服务边界,构建与微服务前端功能相对应的可以独立部署、完全自治、松耦合的页面聚合,每个聚合只负责特定的 UI 元素和特定的功能。一个完成特定微服务前端功能的页面聚合就是一个微前端。
微前端与微服务集成后可形成从前端到中台可独立开发、测试、部署和运维的并且功能自包含的微前端业务组件。微前端除了可以实现前端页面的解耦外,还可实现前端页面的复用,这也与中台服务复用理念是一脉相承。
在微前端之上还有一个企业级的前台应用,它可以是一个企业级的移动APP,也可以是PC端应用,按照正确的业务逻辑和流程能够编排和动态加载企业内所有微前端页面,完成企业内核心业务链路的融合,给用户提供一致体验。
通用能力微前端大多作为共享的页面和功能,其功能入口一般常驻前台APP中,如购物车、商品、会员以及支付等功能。核心能力微前端主要完成核心业务前端功能,一般会根据业务类型动态加载对应业务的微前端页面。
比如:可以根据商品类型,加载核心业务微前端录单页面。在完成所有保单录入后,加载订单共享微前端页面,完成订单生成。订单生成后,加载支付共享微前端页面完成支付等等。共享微前端可在不同渠道前台实现复用。
用技术语言总结就是:“前台聚合,中台解耦,数据融合,业务创新”。先有共享、后有联通、再有创新。