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

2020 年 3 月 07 日

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


今年 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 年 3 月 07 日 14:566626

评论 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
回复
没有更多评论了
发现更多内容

架构师训练营第三周学习总结

lwy

Zookeeper通信协议详解

tunsuy

zookeeper TCP/IP 通信协议

组合设计模式编码&手写单例模式

吴建中

极客大学架构师训练营

第三周-设计模式-学习总结

吴建中

极客大学架构师训练营

WPF中的Data Binding调试指南

大白技术控

.net 微软 WPF

区块链系列教程之:比特币中的挖矿

程序那些事

比特币 区块链 挖矿

2020年6月26日 查询性能优化

瑞克与莫迪

HelloWorld.go

吐核hú

go 学习笔记 TraceLog

架构师第4周

上山砍柴

极客大学架构师训练营

近两年流行面试题:Spring循环依赖问题

Java小咖秀

spring 面试题 ioc

Oracle SQL调优系列之看懂执行计划explain

Nicky.Ma

sql

极客大学架构师训练营 系统架构 第7课 听课总结

John(易筋)

极客时间 系统架构 高并发 极客大学 极客大学架构师训练营

Docker基础修炼2--Docker镜像原理及常用命令

黑马腾云

Docker Linux 容器 运维 镜像

​外包公司干了不到3个月,我离职了...(防坑指南)

程序员生活志

程序员 外包 程序员人生 工作经历

创业一定要学投资

Neco.W

创业 投资

Zookeeper的数据剖析

tunsuy

zookeeper 日志分析 事务 快照 数据恢复

抖音、腾讯、阿里、美团春招服务端开发岗位硬核面试(完结)

aoho

面试 后端 阿里

基于阿里云服务网格(ASM)的GRPC服务部署实践

韩陆

Kubernetes gRPC Service Mesh

Why Spring ???

猴哥一一 cium

spring 源码 Spring Boot Java、 框架设计

架构训练营第四周 - 作业

无心水

极客大学架构师训练营

架构师训练营第四周

Melo

架构师训练营第三周命题作业

lwy

极客大学架构师训练营

架构师训练营第四周-总结

无心水

极客大学架构师训练营

新手村:Redis基础补充知识

多选参数

数据库 redis 数据库设计 redis6.0.0

区块链的应用为什么这么难?出路在哪?

CECBC区块链专委会

比特币 区块链技术 Token 联盟共识

第三周手写单例模式(饿汉模式)

吴建中

极客大学架构师训练营

Zookeeper集群模式启动

tunsuy

zookeeper 源码分析 socket 分布式集群

【非原创】微服务设计

Arthur

太赞了!一份适合程序员的精选面试题清单。

JackTian

GitHub 编程 程序员 面试题 开源项目

极客大学架构师训练营 框架开发 模式与重构 JUnit、Spring、Hive核心源码解析 第6课

John(易筋)

spring 极客时间 极客大学 极客大学架构师训练营 JUnit

架构师是怎样炼成的-3-2-设计模式

闷骚程序员

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