<nobr id="95ffx"><thead id="95ffx"></thead></nobr>

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

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

今年9月份我参加了云栖大会,亲临现场体会了中台发展的现状和趋势,和业界同行进行了深入的交流,为此写了我第一篇关于中台的文章《向左还是向右?聊聊中台建设中的那些纠结事》。这篇文章发表到infoq上,也得到了多家媒体的转载,反响还是很不错的。

如果说第一篇中台的文章是一种思考,一种选择,那么今天的这篇文章,我想介绍一下我们的中台实践,以及过程中的思考逻辑和实施内容。

我为什么决定做中台?

2019年,我被老板调去做整个公司的研发总监,负责公司各产品线的研发工作。这对我其实是一个很大的挑战,其一过去几年我一直负责其中一条产品线,从产品,技术到运营、销售,什么都要做,并非纯粹的技术工作或者研发工作;其二是公司的研发体系比较分散,想统一整合难度很大,对于已经离开研发一线的我,的确前景未知。

但既然被安排在这个位置上,就要履行自己的职责,尽力把工作做好。

上任伊始,整个公司不少于五个事业部,每个事业部都不止一条产品线,一下子把各产品线研发统一,对我初来乍到的人来说,的确是非常头疼的事情。我对各产品线进行了初步的调研,发现各个产品线所涉及的领域都非常的重复,其实这也不足为怪,毕竟所有产品线都是围绕医疗、医药领域,虽然应用场景各有不同,但是很多基础的服务却是一样的。

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

各产品线的领域范围

在之前的中台文章中我也分析了,符合以下情形的企业是适合实施中台的:

  1. 大型复杂的生态系统
  2. 业务形态具备不确定性
  3. 存在重复建设
  4. 存在数据互联互通的问题

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

做中台之前我做了哪些准备?

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

1. 建立共享研发团队

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

将产品线上的部分人员抽调出来组成共享研发团队成员,这样产品开发团队的资源减少了,从而加大了各产品团队重复制造轮子的难度;其次,建立了项目评审和技术评审的机制,让共享研发团队参与到各产品开发团队的业务之中,从而将公共部分从产品开发团队提炼到共享研发团队;最后,通过考核体系,加强制度的执行。

2. 统一公司技术路线

对于我们中小规模的团队,居然存在Java,.NET,PHP三条技术栈,可见过去我们对于技术管理是如何的轻视,任由各个团队自我发挥。太过分散的技术栈导致团队之间无法有效的协同,人员之间不能很好的补位,也非常不利于团队技术的深度积累。

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

在这三个技术栈之中,Java的团队人数,团队质量,以及技术应用程度都是最高的,并且在青岛这个城市,Java的人才也是最好招到的,所以确立以Java作为公司内长期发展的技术路线,其他技术路线收缩或者向Java靠拢。

(2)推行微服务开发模式

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

(3)统一前端开发框架

对于web应用开发,其实前端开发占用了很大的精力,为了更好的组件重用和团队间协同,最好要统一前端开发的框架,让大家在同一个前端技术体系下协同和积累,根据各团队使用的普及度,最终选择以VUE.JS作为团队统一的前端开发框架,共享研发团队提供的组件全部以VUE开发的前端对其他团队提供。

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

一切变革都会从组织和人开始,实施中台战略也不例外,这也是它之所以被认为是“老板工程”的原因之一。很多公司想做中台,但都以失败告终或者就迟迟迈不开第一步的原因就是不敢调整架构,不敢动组织,没有不破不立的胆略。

《中台禁区:为什么最关键的组织架构却鲜少人谈?》 在我有了中台建设的想法后,老板支持我创建了专门的中台的团队,团队虽然不大,但让中台的建设有了载体。不管我和老板在中台的定义和目标的理解是否完全一致,但我们迈出了最重要的一步,感谢老板的支持,这件事如果能够有成绩,首先得益于自上而下的推动。

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

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

共享研发体系

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

在阿里的中台体系中,是业务中台和数据中台双核驱动,这也是大部分企业建设中台的参考模式。但对于我们以研发为核心的公司,不存在复杂的生态系统,而且在初创期并没有大量的数据。所以业务中台和数据中台在我们这里驱动力不够,更何况构建业务中台对于我们以研发为主的团队来说,也缺少业务抽象和架构的人员,一上来碰壁的可能性会比较大。

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

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

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

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

在技术中台的建设过程中,我们让前台尽早的体会到和中台协同的益处,也验证了中台的确能为我们各前台应用带来价值,是时候来构建业务中台了。我们虽然重复制造了一些轮子,但是由于业务场景的差异,这些轮子其实也是神似形不同,如何做到合适的抽象,这也是业务中台构建的难点。

新的架构在开始一旦做不好,往往不能解决前台问题,反而会制造各种障碍,为了推进更加顺利,如何选择业务中台的切入点呢?

1. 价值考虑

  1. 寻找复用度高的业务,通过更多的复用降低整体的投入成本;
  2. 需要持续运营的业务,持续的运营意味着长期的投入,不适合重复建设。

2. 可控考虑

  1. 从新的业务开始;
  2. 成熟业务沉淀共享。

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

确立业务中台的切入点

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

  1. 随访中台–新的业务,且多个产品线涉及;
  2. 内容中台–已存在成熟业务,应用范围很广,且需要持续运营;
  3. 药品中台–应用范围很广,且需要持续运营。

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

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

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

中台架构演进

为什么PaaS成为我们的重点?

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

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

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

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

OECP的主要方向

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

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

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

前段时间,一篇《中台,我信了你的邪》的文章,给风风火火的中台泼了一盆腊月的冰水,也引起了行业的大讨论。茅台的中台项目到底如何,因为其实施方云徙科技的辟谣而更扑朔迷离。前段时间,我看到了另外一家医药企业的中台项目的招标书,也是深吸一口凉气,估计结局也可能和茅台一样。

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

  • 中台之风太热,导致企业对于中台的期望过高!中台不是包治百病的万能神药,它只是企业架构演化的一个阶段或一种方式,它只能解决企业数字化转型的部分问题而不是全部。
  • 太注重形式,一切向大厂看齐!阿里的中台是一蹴而就的吗?阿里的中台适合所有的企业吗?每家企业的发展过程不一样,每家企业的问题也有所不同,盲目的照搬不仅问题没解决,还消耗了大量资源。

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

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

#专栏作家#

菜根乱谭,微信公众号:CGLT_TAN,人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。关注医疗,早教领域,擅长企业IT架构及互联网产品架构。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 受教了,感谢

    回复
  2. 以作者这个策略,从原有团队里抽人或者再招聘增加些人手,组建团队建中台,再用中台去开发原有产品。5条产品线,要么折腾死你最后失败告终,折腾不死就说明你公司本来人员就冗余。

    回复
  3. 如果作者写的这件事是真的,那这老板支持你做这件事无非3个原因:
    1. 他真的对公司有长远规划,这个长远是指超过10年以上。
    2. 他打算把你建好的中台拿来卖或者其它形式产生收入
    3. 他脑子发热

    1的可能性不大,能做10年的企业很少。2的可能性也不大,能拿出来卖的中台,得做得比较通用,这里的成本很高,一般人都不具备这么高的研发水平。所以,更大可能是3
    我们要有一个大概的成本估算,做一个给你的企业内部用的能支撑得起现有所有业务的中台,其开发成本是你现有所有产品开发成本总和起码一半以上,所以花这么多成本做一件事,必须要赚得回来。
    所以,我觉得一个务实的做法:
    1. 把现有的产品,能做服务的做成服务,供其它系统使用。所以,无需立即统一技术,用PHP的继续用PHP。
    做服务比较简单,无非定义好对外的接口,少量开发即可。
    2. 有新业务或者旧业务系统很差劲要重做,就用新成立的中台技术团队去开发。没有,就无需立即建中台。
    3. 等中台做得差不多了,就把原来产品一个一个用中台开发,界面是不会重新开发的,因为这会影响用户使用。无非替换掉原有的服务。
    期间成本承受不住可以随时暂停。

    复用是为了减少成本,你重新做个中台无形中增加了成本,意义何在?!

    回复
    1. 感谢您回复了这么多内容,说明您对中台有深刻的思考。但是正如本文标题所阐述的,中台没有标准,每个人对中台之形的理解都是不一样的,您怎么就断定我们中台的建设成本巨大呢?我统一主流的技术路线也没说干掉其他的技术路线啊,我想干掉也不现实啊!我们中台的确是在逐步的管理php,.net发布的共享服务啊。我们对于中台的定义是做到服务层即可,但是一些需要复杂交互的中台提供基于vue的界面,但是前台可以使用,也可以不使用,至少有服务提供的。成本的评价要放在整个公司来考虑,对中台团队肯定是增加了成本,但是相应的整体的成本因为共享就降下来了呀。
      作为对客户交付的产品,很多项目的招标书中提到了需要中台的能力,做一些中台服务,套一些中台概念,的确是提升产品竞争力的方式的。
      当然,如果这些团队一开始就是我组建的,我的确无需搞中台,我只需要统一技术路线,采用微服务架构就足够了,其实我们现在对于共享服务也是这么做的。
      还是你那句话:落地中台,贵在其神,活用其行。中台只是一种叫法而已!

      回复
  4. 什么中台,不就是复用吗,马云天天炒概念,新零售也是。有句话说的好,“说人话”

    回复
    1. 是的,所以理解中台精神,即使不谈中台,也能取得自己想要的结果。对于炒概念,也没什么不对啊,商业上需要包装才能更好推广,这一点不得不佩服马云。现在看看很多项目的招标要求,很多把中台写了进去,不管它用途到底多大,至少套用概念,才更接近机会。所以,落地中台,还是要领会精神为自己所用,达到自己目的就可以了。

      回复
    2. 忽悠的最高境界就是内行人都是信,外行傻子能不跟风

      回复
    3. 复用不一定需要中台,中台也不单纯是复用

      回复
    4. 复用只是我简单的一种说法,懂的人都懂

      回复
  5. 中台无形胜有形,10年前在阿里做的平台化和这个没有本质区别,天天炒概念,研发成本不少反多;中台的意义是解决合适效能,减少研发人员和成本,而非形式过场

    回复
    1. 非常认同,所以用中台的思想解决企业内部的问题,而不要纠结于具体形式。既然中台概念很火,用之更容易让人理解,让领导认同,让客户认可。现在很多客户的信息化项目都要求中台化,如果我们解决方案里不靠拢中台的概念,也不利于项目的开展。

      回复
  6. 国内需要做中台的公司产品没几家吧?数据没有上亿级别的玩中台就是拿**打小鸟

    回复
    1. 那是太在意中台之形了,太参考大厂的中台的样子。中台没有严格标准,用中台精神解决自身问题,岂不是更合理的做法呢?

      回复
    2. 还是比较同意作者的观点,我们集团化的企业就是用中台来解决的后台数据不互通,业务不互联的,功能重复开发的问题,中间遇到过很多困难,也走过弯路,但是目前来看效果还是比较不错的

      回复
赚钱小项目 469| 207| 441| 991| 516| 289| 997| 733| 88| 377| 179| 179| 573| 152| 797| 377| 496| 957| 538| 619| 963| 453| 232| 207| 723| 56| 203| 667| 816| 124| 116| 910| 876| 14| 216| 366| 622| 339| 779| 484| 479| 380|