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

从新的业务开始
成熟业务沉淀共享

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，落地中台，贵在其神，活用其形！

关于作者：

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

创作场景

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