我也不想做中台,但是刀架脖子上了

菜根老谭 2020-05-09 11:25:29

 

一、为什么决定做中台?

 

2019 年,我被老板调去做整个公司的研发总监,负责公司各产品线的研发工作。这对我而言,其实是一个很大的挑战:一是,过去几年,我一直负责某一个具体的产品线,涉及产品、技术、运营到销售,并非纯粹的技术工作或者研发工作;二是,公司研发体系较分散,统一整合难度很大。对于已经离开研发一线的我来说,前景未知。但已被安排在这个位置上,就要履行好自己的职责,全力而为。

 

上任伊始,整个公司不少于五个事业部,每个事业部都不止一条产品线。对我来说,快速将各产品线研发统一,这的确是非常头疼的事。

 

首先,我对各产品线进行初步调研,发现各产品线所涉及的领域都有重复。这也不足为怪,毕竟所有产品线都是围绕医疗、医药领域,虽然应用场景不同,但很多基础服务却是相同的。

 

 

此前的一篇文章中,我已经指出符合以下情形的企业适合实施中台:

 

  • 大型复杂的生态系统

  • 业务形态具备不确定性

  • 存在重复建设

  • 存在数据互联互通的问题

 

从我们产品线的现状看,除第一条目前并不特别匹配外,其他三条都符合,尤其最后两项最突出。2019 年是中台架构最火热的一年,并且许多峰会的主题也基本都以中台为核心。带着老板交待的把研发统一整合的任务,我萌生了基于中台架构来实施的想法。

 

二、做中台前,我做了哪些准备?

 

翻开阿里中台的建设历程,其道路并非一帆风顺,甚至是步履维艰,障碍重重。人们通常认为中台战略是老板工程,没有自上而下的推动想要做成几乎是不可能的。但中台作为一个全新概念,让老板认清中台,让同事接受中台也不是一蹴而就的事情。

 

1、建立共享研发团队
 

 

实施中台架构的一个重要原因是存在大量的重复性建设,一个根本原因是我们过去只重产品线发展而不重视能力线的建设,没有一个团队对公共的部分负责,所以我们要建立共享研发团队来承担对公共基础服务的建设。

 

首先,将产品线的部分人员抽调出来组成共享研发团队,如此,产品开发团队的资源减少,加大各产品团队重复“造轮子”的难度。

 

其次,建立项目评审和技术评审机制,让共享研发团队参与到各产品开发团队的业务中,这样将公共部分从产品开发团队提炼到共享研发团队。最后,通过设置合理的考核体系,强化制度执行。

 

2、统一公司技术路线
 

 

在我们中小规模团队,竟存在 Java、.NET、PHP 三条技术栈。由此可见,我们过去是如何轻视技术管理,任由各团队自我发挥。

 

但是,问题在于太过分散的技术栈导致团队之间无法有效协同,人员间不能很好补位,并且非常不利于团队技术的深度积累。

 

1)确立 Java 技术栈为主路线

 

在上述三个技术栈中,从团队人数、团队质量和技术应用程度来看,Java 最高。并且,在青岛这个城市,Java 人才最好招聘。

 

因此,确立 Java 作为公司内部长期发展的技术路线,而其他技术路线则收缩或向 Java 靠拢。

 

2)推行微服务开发模式

 

由于资源问题,无法很快短时间统一到一条技术路线上,三条技术路线将会持续很长一段时间,所以公共组件的重用无法在代码级别进行,只能采取服务方式提供。微服务的架构非常符合当前现状,三个 Java 主线的技术团队中已经有两个开始实施微服务的开发模式。因此,微服务开发模式和 SpringCloud 的体系也就顺理成章的确立下来。

 

3)统一前端开发框架

 

对于 web 应用开发,前端开发其实占用很大精力,因此为了更好的组件重用和团队间协同,最好统一前端开发框架。这样,就可以让大家在同一个前端技术体系下协同和积累。

 

我们最终选择以 VUE.JS 作为团队统一的前端开发框架,共享研发团队提供的组件全部以 VUE 开发的前端为其他团队提供。

 

三、如何迈出中台建设第一步?

 

一切变革都会从组织和人开始,中台战略的实施也不例外,这是它被认为是“老板工程”的原因之一。

 

很多公司想做中台,往往失败或迟迟迈不开第一步,原因在于不敢调整架构,不敢动组织,没有不破不立的胆略。《中台禁区:为什么最关键的组织架构却鲜少人谈?

 

当我有中台建设的想法后,老板支持我创建专门的中台团队。虽然团队规模不大,但让中台建设有了载体。这让我们迈出了最重要的一步。这件事如果能有成绩,首先得益于自上而下的推动。

 

至此,整个共享研发体系已初见成效,这为中台战略的顺利执行奠定了坚实基础。

 

 

四、为什么要从技术中台开始?

 

在阿里的中台体系中,它是业务中台和数据中台双核驱动,这也是大部分企业建设中台的参考模式。

 

但是,对于我们以研发为核心的公司,不存在复杂的生态系统,而且在初创期并没有大量数据,所以业务中台和数据中台在我们这里的驱动力不够。

 

更何况,构建业务中台对我们以研发为主的团队来说,也缺少业务抽象和架构的人员,碰壁的可能性会比较大。

 

任何一个变革要想成功,都要找到最容易的突破口,迅速建立效果,建立自信。而技术中台因为更基础,复用程度更大一些。并且,因为不具备业务特性,所以更加容易被抽象。

 

中台定义是企业级能力复用的平台,所以通过构建技术中台来快速实现复用,从而让中台建设快速取得成效,并使团队建立自信,这是我们深入中台的基础。

 

在这半年时间,我们在技术中台方面快速构建了一些被经常用到的基础组件,比如聚合支付、IM、人脸识别、呼叫中心等等。

 

五、如何选择业务中台的切入点?

 

在技术中台建设过程中,我们让前台尽早体会到和中台协同的益处,这也验证中台的确能为我们各前台应用带来价值——是时候来构建业务中台了。

 

虽然我们重复“造了一些轮子”,但由于业务场景的差异,这些轮子其实是神似形不同,如何做到合适的抽象,这也是业务中台构建的难点。新架构在开始时一旦做不好,往往不能解决前台问题,反而会制造各种障碍。

 

那么,问题来了,为推进更加顺利,如何选择业务中台的切入点?

 

价值考虑

 

  • 寻找复用度高的业务,通过更多的复用降低整体的投入成本

  • 需要持续运营的业务。持续运营意味着长期投入,不适合重复建设

 

可控考虑

 

  • 从新的业务开始

  • 成熟业务沉淀共享

 

 

基于以上考虑的出发点梳理自身业务,从而确立业务中台前期建设内容:

 

  • 随访中台–新的业务,且涉及多个产品线

  • 内容中台–已存在成熟业务,应用范围很广,且需要持续运营

  • 药品中台–应用范围很广,且需要持续运营

     

半年时间,在项目繁多、资源紧张的情况下,我们小心翼翼的推进中台建设。虽然进展缓慢,但中台和前台已经开始紧密协同,逐步打消我刚开始对推进中台的担忧,也让团队越来越有信心,这是一个不错的成果。

 

过去,我们开发一个个单体应用,重复“造各种轮子”,数据也不统一。架构永远都不是一蹴而就的,它在不断演化,这对中台架构更是如此。我们要有清晰的规划,同时要稳步改造,不要冒进。

 

 

六、为何 PaaS 成为我们的重点?

 

中台建设就是把可复用的能力沉淀下来,但这些可复用的能力如何被管理?如何快速复用?很多人形容中台架构模式就像搭积木方式一样构建应用系统,怎么帮助开发人员快速的拼装积木呢?

 

这需要构建在中台之上的 PaaS 平台来完成。

 

其实,急于建设 PaaS 层,更源于我们业务的变化和现存的问题。去年下半年,公司业务再调整,产品线在聚焦、收缩,我们的定位也转成以面向 TO B 应用的产品研发为主,医疗行业的产品以本地化部署居多,互联网业务在减少,中台服务的迫切性已经不那么高了。

 

而作为我们前台的各个产品都存在标准化不足,扩展性不够的问题,这就造成项目交付需要大量定制化开发,极大影响了交付成本和速度。因此,通过构建低代码开发的 PaaS 平台来解决这些问题成为当前重中之重。

 

 

在代号为 OECP 的 PaaS 平台 1.0 beta 版推出后,快速应用在几个项目上,这让项目开发效率提升数倍以上。而去年顶着项目压力研发的这个平台初见成效,我内心的焦虑也得到适当缓解。

 

从长远看,中台 +OECP 的建设不仅解决了我们自身研发的成本和效率问题,而且在这个体系指导下,我们还可以扩大到整个集团范围,帮助集团数字化转型。并且,我们构建的医疗服务中台,也将成为我们的产品优势和亮点,助力客户数字化转型,搭建新型智慧医院的服务体系。

 

七、为什么很多中台项目都失败了?

 

前段时间,一篇《中台,我信了你的邪》的文章给风风火火的中台泼了一盆腊月的冰水,这也引起行业大讨论。

 

茅台的中台项目到底如何,因为其实施方云徙科技的辟谣而更扑朔迷离。前段时间,我看到另外一家医药企业的中台项目招标书,也是深吸一口凉气,估计结局也可能和茅台一样。

 

为什么会失败?为什么推行不下去?我感觉有以下原因:

 

  • 中台之风太热,导致企业对于中台的期望过高!中台不是“包治百病的万能神药”,它只是企业架构演化的一个阶段或一种方式,它只能解决企业数字化转型的部分问题而不是全部

  • 太注重形式,一切向大厂看齐!阿里的中台是一蹴而就的吗?阿里的中台适合所有的企业吗?每家企业的发展过程不一样,每家企业的问题也有所不同,盲目照搬不仅问题没解决,还消耗大量资源

     

中台是企业级能力复用的平台,我们要把握中台之神韵:以复用为核心,以企业级为视角、以各种能力为复用范围。千万不要被互联网大厂的各种中台之形而掣肘,因为中台对数字化转型的传统企业,对像我们这样的研发型企业,都有不同的应用动机和场景。

 

所以,落地中台,贵在其神,活用其形!

 

作者丨菜根老谭,经历程序员、技术Leader、研发Leader等多种岗位;关注医疗,早教领域,擅长企业IT架构及互联网产品架构。
来源丨菜根老谭(ID:CGLT_TAN)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
 

 
中台不是银弹,而且盲目搭建还可能会造成不堪设想的后果。Gdevops全球敏捷运维峰会北京站精选了业内优秀的中台建设案例,不妨来看看吧:
 
  • 《建设敏捷型消费金融中台及云原生下的DevOps实践》中邮消费金融 总经理助理 李远鑫

  • 《平安银行“传统+互联网”混合CMDB及运营中台实践》平安银行 运营开发负责人 徐大蔚

  • 《中国农业银行信贷中台及数据中台建设实践》中国农业银行  研发中心资深架构专家 张亮

  • 《技术体系建设:架构、质量、中台、后端的战略落地与矛盾破解》58到家集团/快狗打车 技术VP/CTO 沈剑

  • 《揭露现象看本质:到家、货运O2O业务试金石基础-中台建设》58到家集团/快狗打车 业务服务部负责人/中台技术部负责人 李洪英

 

9月11日,让我们一起用更多元的视角观察问题本质,寻找中台发展的轨迹和趋势。

活动预告