今年9月份我参加了云栖大会，亲临现场体会了中台发展的现状和趋势，和业界同行进行了深入的交流，为此写了我第一篇关于中台的文章《向左还是向右？聊聊中台建设中的那些纠结事》。这篇文章发表到infoq上，也得到了多家媒体的转载，反响还是很不错的。如果说第一篇中台的文章是一种思考，一种选择，那么今天的这篇文章，我想介绍一下我们的中台实践，以及过程中的思考逻辑和实施内容。
我为什么决定做中台？
2019年，我被老板调去做整个公司的研发总监，负责公司各产品线的研发工作。这对我其实是一个很大的挑战，其一过去几年我一直负责其中一条产品线，从产品，技术到运营、销售，什么都要做，并非纯粹的技术工作或者研发工作；其二是公司的研发体系比较分散，想统一整合难度很大，对于已经离开研发一线的我，的确前景未知。但既然被安排在这个位置上，就要履行自己的职责，尽力把工作做好。
上任伊始，整个公司不少于五个事业部，每个事业部都不止一条产品线，一下子把各产品线研发统一，对我初来乍到的人来说，的确是非常头疼的事情。我对各产品线进行了初步的调研，发现各个产品线所涉及的领域都非常的重复，其实这也不足为怪，毕竟所有产品线都是围绕医疗、医药领域，虽然应用场景各有不同，但是很多基础的服务却是一样的。
在之前的中台文章中我也分析了，符合以下情形的企业是适合实施中台的：
- 大型复杂的生态系统
- 业务形态具备不确定性
- 存在重复建设
- 存在数据互联互通的问题
从我们的产品线现状看，除了第一条目前并不特别匹配外，其他三项都符合当前团队的状况，而最后两项尤其突出。2019年是中台架构最为火热的一年，云栖大会的主题也基本都以中台为核心，带着老板交给的进行研发统一整合的任务，萌生了基于中台架构来实施的想法。
做中台之前我做了哪些准备？
翻开阿里中台建设的历程，其道路并不是一帆风顺的，甚至是步履维艰，障碍重重。人们通常认为中台战略是老板工程，没有自上而下的推动要想做成几乎是不可能的。但是中台作为一个全新的概念，让老板认清中台，让同事接受中台也不是一蹴而就的事情。
建立共享研发团队
实施中台架构的一个重要原因是存在大量的重复性的建设，其根本原因之一就是过去我们只重视产品线发展而不重视能力线的建设，没有一个团队对公共的部分进行负责，所以首先我们要建立共享研发的团队来承担对公共基础服务的建设。
将产品线上的部分人员抽调出来组成共享研发团队成员，这样产品开发团队的资源减少了，从而加大了各产品团队重复制造轮子的难度；其次，建立了项目评审和技术评审的机制，让共享研发团队参与到各产品开发团队的业务之中，从而将公共部分从产品开发团队提炼到共享研发团队；最后，通过考核体系，加强制度的执行。
统一公司技术路线
对于我们中小规模的团队，居然存在Java，.NET，PHP三条技术栈，可见过去我们对于技术管理是如何的轻视，任由各个团队自我发挥。太过分散的技术栈导致团队之间无法有效的协同，人员之间不能很好的补位，也非常不利于团队技术的深度积累。
确立Java技术路线为主路线
在这三个技术栈之中，Java的团队人数，团队质量，以及技术应用程度都是最高的，并且在青岛这个城市，Java的人才也是最好招到的，所以确立以Java作为公司内长期发展的技术路线，其他技术路线收缩或者向Java靠拢。
推行微服务开发模式
因为资源问题，不可能一下子统一到一条技术路线上来，三条技术路线将会持续很长一段时间，所以公共组件的重用无法在代码级别进行，而只能采取服务的方式提供，而微服务的架构非常符合当前的现状，而三个Java主线的技术团队有两个已经开始实施微服务的开发模式，微服务的开发模式以及SpringCloud的体系也就顺理成章的被确立下来。
统一前端开发框架
对于web应用开发，其实前端开发占用了很大的精力，为了更好的组件重用和团队间协同，最好要统一前端开发的框架，让大家在同一个前端技术体系下协同和积累，根据各团队使用的普及度，最终选择以VUE.JS作为团队统一的前端开发框架，共享研发团队提供的组件全部以VUE开发的前端对其他团队提供。
中台建设的第一步如何迈出？
一切变革都会从组织和人开始，实施中台战略也不例外，这也是它之所以被认为是“老板工程”的原因之一。很多公司想做中台，但都以失败告终或者就迟迟迈不开第一步的原因就是不敢调整架构，不敢动组织，没有不破不立的胆略。《中台禁区：为什么最关键的组织架构却鲜少人谈？》
在我有了中台建设的想法后，老板支持我创建了专门的中台的团队，团队虽然不大，但让中台的建设有了载体。不管我和老板在中台的定义和目标的理解是否完全一致，但我们迈出了最重要的一步，感谢老板的支持，这件事如果能够有成绩，首先得益于自上而下的推动。
至此，整个共享研发的体系已经初见成效，为中台战略的顺利执行奠定了坚实的基础。
为什么要从技术中台开始？
在阿里的中台体系中，是业务中台和数据中台双核驱动，这也是大部分企业建设中台的参考模式。但对于我们以研发为核心的公司，不存在复杂的生态系统，而且在初创期并没有大量的数据，所以业务中台和数据中台在我们这里驱动力不够，更何况构建业务中台对于我们以研发为主的团队来说，也缺少业务抽象和架构的人员，一上来碰壁的可能性会比较大。
任何一个变革要想成功，都要找到最容易的突破口，迅速建立效果，建立自信。而技术中台因为更加基础，复用程度会更大一些；而且因为不具备业务特性，所以更加的容易被抽象。中台的定义就是企业级能力复用的平台，所以通过构建技术中台从而快速实现复用，从而让中台建设快速取得效果，让团队建立自信，是我们深入中台的基础。
这半年的时间，我们在技术中台方面快速的构建了我们产品和项目经常被用到的一些基础组件，比如聚合支付、IM、人脸识别、呼叫中心等等。
如何选择业务中台的切入点？
在技术中台的建设过程中，我们让前台尽早的体会到和中台协同的益处，也验证了中台的确能为我们各前台应用带来价值，是时候来构建业务中台了。我们虽然重复制造了一些轮子，但是由于业务场景的差异，这些轮子其实也是神似形不同，如何做到合适的抽象，这也是业务中台构建的难点。新的架构在开始一旦做不好，往往不能解决前台问题，反而会制造各种障碍，为了推进更加顺利，如何选择业务中台的切入点呢？
价值考虑
- 寻找复用度高的业务，通过更多的复用降低整体的投入成本
- 需要持续运营的业务，持续的运营意味着长期的投入，不适合重复建设
可控考虑
- 从新的业务开始
- 成熟业务沉淀共享
基于以上考虑的出发点梳理自身业务，从而确立了业务中台前期建设内容：
- 随访中台--新的业务，且多个产品线涉及
- 内容中台--已存在成熟业务，应用范围很广，且需要持续运营
- 药品中台--应用范围很广，且需要持续运营
半年的时间，在项目繁多、资源紧张的情况下，我们小心翼翼的推进中台的发展，虽然进展缓慢，但中台和前台已经开始紧密协同，逐步打消我刚开始推进中台的担忧，也让团队越来越有信心，依然是一个不错的成果。
过去我们开发了一个个的单体应用，重复制造了各种轮子，数据也不统一，但架构永远都不是一蹴而就的，都是在不断演化的，对于中台架构更是如此，我们要有清晰的规划，同时要稳步的改造，不要冒进。
为什么PaaS成为我们的重点？
中台建设就是把可复用的能力沉淀下来，但这些可复用的能力如何被管理？如何快速的复用？很多人形容中台的架构模式就像搭积木的方式一样构建应用系统，怎么帮助开发人员快速的拼装积木呢？需要在构建在中台之上的PaaS平台来完成。
其实着急建设PaaS层，更源于我们业务的变化和现存的问题。去年下半年公司的业务再调整，产品线在聚焦收缩，我们定位也在转成以面向TO B应用的产品研发为主，医疗行业的产品以本地化部署居多，互联网业务在减少，中台服务的迫切性已经不那么高了。而作为我们前台的各个产品都存在标准化不足，扩展性不够的问题，造成了项目的交付需要大量的定制化的开发，极大影响了交付的成本和速度，通过构建低代码开发的PaaS平台来解决这些问题成为当前更重点的事情。
代号OECP的PaaS平台1.0beta版推出后，快速的应用在几个项目上，让项目的开发效率提升了数倍以上，去年顶着项目压力研发的这个平台初见成效，内心的焦虑也适当的得到了缓解。
从长远看，中台+OECP的建设不仅解决我们自身研发的成本和效率问题，在这个体系指导下我们还可以扩大到整个集团范围，帮助集团数字化转型，而我们构建的医疗服务中台，也将成为我们产品的优势和亮点，帮助客户做数字化转型，搭建新型的智慧医院的服务体系。
为什么很多中台项目都失败了？
前段时间，一篇《中台，我信了你的邪》的文章，给风风火火的中台泼了一盆腊月的冰水，也引起了行业的大讨论。茅台的中台项目到底如何，因为其实施方云徙科技的辟谣而更扑朔迷离。前段时间，我看到了另外一家医药企业的中台项目的招标书，也是深吸一口凉气，估计结局也可能和茅台一样。为什么会失败，为什么推行不下去，我感觉有以下原因：
- 中台之风太热，导致企业对于中台的期望过高！中台不是包治百病的万能神药，它只是企业架构演化的一个阶段或一种方式，它只能解决企业数字化转型的部分问题而不是全部。
- 太注重形式，一切向大厂看齐！阿里的中台是一蹴而就的吗？阿里的中台适合所有的企业吗？每家企业的发展过程不一样，每家企业的问题也有所不同，盲目的照搬不仅问题没解决，还消耗了大量资源。
中台是企业级能力复用的平台，我们要把握中台之神韵：以复用为核心，以企业级为视角、以各种能力为复用范围。而不要被互联网大厂的各种中台之形而掣肘，因为中台对数字化转型的传统企业，对于像我们这样的研发型的企业，都有不同的应用动机和场景。
所以，落地中台，贵在其神，活用其形！
