内容简介:2019 年,我被老板调去做整个公司的研发总监,负责公司各产品线的研发工作。这对我而言,其实是一个很大的挑战:一是,过去几年,我一直负责某一个具体的产品线,涉及产品、技术、运营到销售,并非纯粹的技术工作或者研发工作;二是,公司研发体系较分散,统一整合难度很大。对于已经离开研发一线的我来说,前景未知。但已被安排在这个位置上,就要履行好自己的职责,全力而为。上任伊始,整个公司不少于五个事业部,每个事业部都不止一条产品线。对我来说,快速将各产品线研发统一,这的确是非常头疼的事。首先,我对各产品线进行初步调研,发现
一、为什么决定做中台?
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日 ,让我们一起用更多元的视角观察问题本质,寻找中台发展的轨迹和趋势。
以上所述就是小编给大家介绍的《我也不想做中台,但是刀架脖子上了》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 中国人工智能正在被“卡脖子”
- 核心算法缺位,人工智能发展面临“卡脖子”窘境
- 芯片技术被「卡脖子」?这是中国对抗封锁最有效的「武器」
- 面试时遇到 “看门狗” 脖子上挂着 “时间轮”,我就问你怕不怕?
- 倪光南:利用我国大数据的长板补齐被外国卡脖子的短板
- 改了配置,不想重启,怎么整?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
计算机程序设计艺术
Donald E.Knuth / 苏运霖 / 机械工业出版社 / 2006-4 / 45.00元
《计算机程序设计艺术》(经典计算机科学著作最新版)(第1卷第1册双语版)更新了《计算机程序设计艺术,第1卷,基本算法》(第3版),并且最终将成为该书第4版的一部分。具体地说,它向程序员提供了盼望已久的MMIX,代替原来的MIX的一个以RISC为基础的计算机,并且描述了MMIX汇编语言。一起来看看 《计算机程序设计艺术》 这本书的介绍吧!