今年 9 月份,我参加云栖大会,了解了中台发展的现状和趋势,并和业界同行进行了深入交流。为此,我写了自己第一篇关于中台的文章《向左还是向右?聊聊中台建设中的那些纠结事》。该文章首发于 InfoQ,并得到多家媒体的转载,反响热烈。如果说这篇文章是关于中台的思考和选择,那本篇文章我想介绍一下我们的中台实践和这个过程中的思考逻辑。
一、为什么决定做中台?
2019 年,我被老板调去做整个公司的研发总监,负责公司各产品线的研发工作。这对我而言,其实是一个很大的挑战:一是,过去几年,我一直负责某一个具体的产品线,涉及产品、技术、运营到销售,并非纯粹的技术工作或者研发工作;二是,公司研发体系较分散,统一整合难度很大。对于已经离开研发一线的我来说,前景未知。但已被安排在这个位置上,就要履行好自己的职责,全力而为。
上任伊始,整个公司不少于五个事业部,每个事业部都不止一条产品线。对我来说,快速将各产品线研发统一,这的确是非常头疼的事。
首先,我对各产品线进行初步调研,发现各产品线所涉及的领域都有重复。这也不足为怪,毕竟所有产品线都是围绕医疗、医药领域,虽然应用场景不同,但很多基础服务却是相同的。
此前的一篇文章中,我已经指出符合以下情形的企业适合实施中台:
1.大型复杂的生态系统
2.业务形态具备不确定性
3.存在重复建设
4.存在数据互联互通的问题
从我们产品线的现状看,除第一条目前并不特别匹配外,其他三条都符合,尤其最后两项最突出。2019 年是中台架构最火热的一年,并且云栖大会的主题也基本都以中台为核心。带着老板交待的把研发统一整合的任务,我萌生了基于中台架构来实施的想法。
二、做中台前,我做了哪些准备?
翻开阿里中台的建设历程,其道路并非一帆风顺,甚至是步履维艰,障碍重重。人们通常认为中台战略是老板工程,没有自上而下的推动想要做成几乎是不可能的。但中台作为一个全新概念,让老板认清中台,让同事接受中台也不是一蹴而就的事情。
1.建立共享研发团队
实施中台架构的一个重要原因是存在大量的重复性建设,一个根本原因是我们过去只重产品线发展而不重视能力线的建设,没有一个团队对公共的部分负责,所以我们要建立共享研发团队来承担对公共基础服务的建设。
首先,将产品线的部分人员抽调出来组成共享研发团队,如此,产品开发团队的资源减少,加大各产品团队重复“造轮子”的难度。
其次,建立项目评审和技术评审机制,让共享研发团队参与到各产品开发团队的业务中,这样将公共部分从产品开发团队提炼到共享研发团队。最后,通过设置合理的考核体系,强化制度执行。
2.统一公司技术路线
在我们中小规模团队,竟存在 Java、.NET、PHP 三条技术栈。由此可见,我们过去是如何轻视技术管理,任由各团队自我发挥。
但是,问题在于太过分散的技术栈导致团队之间无法有效协同,人员间不能很好补位,并且非常不利于团队技术的深度积累。
2.1 确立 Java 技术栈为主路线
在上述三个技术栈中,从团队人数、团队质量和技术应用程度来看,Java 最高。并且,在青岛这个城市,Java 人才最好招聘。
因此,确立 Java 作为公司内部长期发展的技术路线,而其他技术路线则收缩或向 Java 靠拢。
2.2 推行微服务开发模式
由于资源问题,无法很快短时间统一到一条技术路线上,三条技术路线将会持续很长一段时间,所以公共组件的重用无法在代码级别进行,只能采取服务方式提供。微服务的架构非常符合当前现状,三个 Java 主线的技术团队中已经有两个开始实施微服务的开发模式。因此,微服务开发模式和 SpringCloud 的体系也就顺理成章的确立下来。
2.3 统一前端开发框架
对于 web 应用开发,前端开发其实占用很大精力,因此为了更好的组件重用和团队间协同,最好统一前端开发框架。这样,就可以让大家在同一个前端技术体系下协同和积累。
我们最终选择以 VUE.JS 作为团队统一的前端开发框架,共享研发团队提供的组件全部以 VUE 开发的前端为其他团队提供。
三、如何迈出中台建设第一步?
一切变革都会从组织和人开始,中台战略的实施也不例外,这是它被认为是“老板工程”的原因之一。
很多公司想做中台,往往失败或迟迟迈不开第一步,原因在于不敢调整架构,不敢动组织,没有不破不立的胆略。《中台禁区:为什么最关键的组织架构却鲜少人谈?》
当我有中台建设的想法后,老板支持我创建专门的中台团队。虽然团队规模不大,但让中台建设有了载体。这让我们迈出了最重要的一步。这件事如果能有成绩,首先得益于自上而下的推动。
至此,整个共享研发体系已初见成效,这为中台战略的顺利执行奠定了坚实基础。
四、为什么要从技术中台开始?
在阿里的中台体系中,它是业务中台和数据中台双核驱动,这也是大部分企业建设中台的参考模式。
但是,对于我们以研发为核心的公司,不存在复杂的生态系统,而且在初创期并没有大量数据,所以业务中台和数据中台在我们这里的驱动力不够。
更何况,构建业务中台对我们以研发为主的团队来说,也缺少业务抽象和架构的人员,碰壁的可能性会比较大。
任何一个变革要想成功,都要找到最容易的突破口,迅速建立效果,建立自信。而技术中台因为更基础,复用程度更大一些。并且,因为不具备业务特性,所以更加容易被抽象。
中台定义是企业级能力复用的平台,所以通过构建技术中台来快速实现复用,从而让中台建设快速取得成效,并使团队建立自信,这是我们深入中台的基础。
在这半年时间,我们在技术中台方面快速构建了一些被经常用到的基础组件,比如聚合支付、IM、人脸识别、呼叫中心等等。
五、如何选择业务中台的切入点?
在技术中台建设过程中,我们让前台尽早体会到和中台协同的益处,这也验证中台的确能为我们各前台应用带来价值——是时候来构建业务中台了。
虽然我们重复“造了一些轮子”,但由于业务场景的差异,这些轮子其实是神似形不同,如何做到合适的抽象,这也是业务中台构建的难点。新架构在开始时一旦做不好,往往不能解决前台问题,反而会制造各种障碍。
那么,问题来了,为推进更加顺利,如何选择业务中台的切入点?
1.价值考虑
寻找复用度高的业务,通过更多的复用降低整体的投入成本
需要持续运营的业务。持续运营意味着长期投入,不适合重复建设
2.可控考虑
从新的业务开始
成熟业务沉淀共享
基于以上考虑的出发点梳理自身业务,从而确立业务中台前期建设内容:
随访中台–新的业务,且涉及多个产品线
内容中台–已存在成熟业务,应用范围很广,且需要持续运营
药品中台–应用范围很广,且需要持续运营
半年时间,在项目繁多、资源紧张的情况下,我们小心翼翼的推进中台建设。虽然进展缓慢,但中台和前台已经开始紧密协同,逐步打消我刚开始对推进中台的担忧,也让团队越来越有信心,这是一个不错的成果。
过去,我们开发一个个单体应用,重复“造各种轮子”,数据也不统一。架构永远都不是一蹴而就的,它在不断演化,这对中台架构更是如此。我们要有清晰的规划,同时要稳步改造,不要冒进。
六、为何 PaaS 成为我们的重点?
中台建设就是把可复用的能力沉淀下来,但这些可复用的能力如何被管理?如何快速复用?很多人形容中台架构模式就像搭积木方式一样构建应用系统,怎么帮助开发人员快速的拼装积木呢?
这需要构建在中台之上的 PaaS 平台来完成。
其实,急于建设 PaaS 层,更源于我们业务的变化和现存的问题。去年下半年,公司业务再调整,产品线在聚焦、收缩,我们的定位也转成以面向 TO B 应用的产品研发为主,医疗行业的产品以本地化部署居多,互联网业务在减少,中台服务的迫切性已经不那么高了。
而作为我们前台的各个产品都存在标准化不足,扩展性不够的问题,这就造成项目交付需要大量定制化开发,极大影响了交付成本和速度。因此,通过构建低代码开发的 PaaS 平台来解决这些问题成为当前重中之重。
在代号为 OECP 的 PaaS 平台 1.0 beta 版推出后,快速应用在几个项目上,这让项目开发效率提升数倍以上。而去年顶着项目压力研发的这个平台初见成效,我内心的焦虑也得到适当缓解。
从长远看,中台+OECP 的建设不仅解决了我们自身研发的成本和效率问题,而且在这个体系指导下,我们还可以扩大到整个集团范围,帮助集团数字化转型。并且,我们构建的医疗服务中台,也将成为我们的产品优势和亮点,助力客户数字化转型,搭建新型智慧医院的服务体系。
七、为什么很多中台项目都失败了?
前段时间,一篇《中台,我信了你的邪》的文章给风风火火的中台泼了一盆腊月的冰水,这也引起行业大讨论。
茅台的中台项目到底如何,因为其实施方云徙科技的辟谣而更扑朔迷离。前段时间,我看到另外一家医药企业的中台项目招标书,也是深吸一口凉气,估计结局也可能和茅台一样。
为什么会失败?为什么推行不下去?我感觉有以下原因:
中台之风太热,导致企业对于中台的期望过高!中台不是“包治百病的万能神药”,它只是企业架构演化的一个阶段或一种方式,它只能解决企业数字化转型的部分问题而不是全部。
太注重形式,一切向大厂看齐!阿里的中台是一蹴而就的吗?阿里的中台适合所有的企业吗?每家企业的发展过程不一样,每家企业的问题也有所不同,盲目照搬不仅问题没解决,还消耗大量资源。
中台是企业级能力复用的平台,我们要把握中台之神韵:以复用为核心,以企业级为视角、以各种能力为复用范围。千万不要被互联网大厂的各种中台之形而掣肘,因为中台对数字化转型的传统企业,对像我们这样的研发型企业,都有不同的应用动机和场景。
所以,落地中台,贵在其神,活用其形!
关于作者:
谭明智 ,经历技术、产品、运营等多个领域,现在负责百洋智能科技产品研发。喜欢并擅长做 IT 架构和产品架构,微信公众号:菜根乱谭(ID:CGLT_TAN),欢迎关注,聊产品,聊技术。
评论 8 条评论