一、为什么决定做中台？

 

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日，让我们一起用更多元的视角观察问题本质，寻找中台发展的轨迹和趋势。