HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

我的半年中台实践思考:落地中台,贵在其神,活用其形

  • 2020-03-07
  • 本文字数:3866 字

    阅读完需:约 13 分钟

我的半年中台实践思考:落地中台,贵在其神,活用其形


今年 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.可控考虑

  • 从新的业务开始

  • 成熟业务沉淀共享



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


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

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

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


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


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


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

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


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


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


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



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


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

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

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


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


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


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

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


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


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


关于作者:


谭明智 ,经历技术、产品、运营等多个领域,现在负责百洋智能科技产品研发。喜欢并擅长做 IT 架构和产品架构,微信公众号:菜根乱谭(ID:CGLT_TAN),欢迎关注,聊产品,聊技术。


2020-03-07 14:567669

评论 8 条评论

发布
用户头像
中台是方法论+技术能力的沉淀;这需要甲方也沉淀相应的技术能力和实施能力;而甲方的能力沉淀是中台落地以及项目可以交付的保证。
2020-03-15 22:14
回复
完全赞同
2020-03-21 14:29
回复
用户头像
很佩服老谭的文笔,他的文章能站在制高点上全面深入的分析问题;文中很多观点都有过交流我也很认同;这次这篇中的的“Paas平台”和“为什么很多中台项目失败了”对我有很大触发。落地中台,贵在其神,活用其形!正因为“贵在其神,活用其形”,所以,难点和重点都在“落”上。希望以后多加交流,互通有无。
2020-03-09 20:26
回复
用户头像
请教一个问题,中台和产品线服务的边界怎么来定?比如已例子中的药品中台为例,药品服务下沉到中台后,产品线上的药品模块是一个什么形态?是全部基于药品中台的接口来开发吗?产品线还会存储药品的数据吗?对于各个产品线药品模块非常个性化的需求以及不断新增的需求,这块是是药品中台全部来实现还是业务线来实现?
2020-03-08 23:44
回复
很好的问题,中台定位的是抽象公共的服务,目的是实现多产品线的复用能力,中台服务不能完全替代产品的功能,也不能完全存储产品上的数据,否则就把中台做成了前台。药品的数据需要维护,需要运营,这个会持续的产生成本,不能让各产品线重复的去做,需要抽取到中台,中台提供服务,前台使用即可。至于如何使用需要结合产品的场景,如果中台提供的服务可以满足需求,就直接使用,如果不满足,可以和中台一起探讨是否公共的可复用的需求,如果是中台抽象服务支持,如果不是那就在产品线上处理。对于数据这部分,公共部分在中台,但是产品线上结合自己的场景可能会扩展这些数据,从自由度和灵活度上来考虑,部分数据冗余在前台产品,会让产品更加灵活,不制肘于中台,但有些数据只是在单向使用,并不和业务太多关联,也可以不保留在前台,直接使用中台服务调用即可。比如药品主数据和业务关联性很大,前台冗余,但是药品的说明书,合理用药规则和业务关联性小,就直接调用中台服务就OK。
展开
2020-03-09 22:21
回复
用户头像
把技术栈、组织结构、流程规范统一是非常重要的一步,后面才能做更高阶的企业级别的复用
2020-03-08 15:00
回复
用户头像
关于在中台只是构建 PaaS 平台能更具体一些吗?最近也在推进公司的中台建设,希望能跟大家多交流学习一下。
2020-03-08 10:14
回复
您想了解哪方面的具体问题呢?可以关注我公众号加我微信沟通
2020-03-08 10:46
回复
没有更多了
发现更多内容
我的半年中台实践思考:落地中台,贵在其神,活用其形_架构_菜根老谭_InfoQ精选文章