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

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

我为什么决定做中台？

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

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

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

各产品线的领域范围

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

大型复杂的生态系统

业务形态具备不确定性

存在重复建设

存在数据互联互通的问题

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

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

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

1. 建立共享研发团队

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

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

2. 统一公司技术路线

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

（1）确立Java技术路线为主路线

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

（2）推行微服务开发模式

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

（3）统一前端开发框架

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

中台建设的之一步如何迈出？