前段时间参加了IAS2019(互联网架构峰会)，本次峰会以中台为主题，所以又称中台战略大会，据说是全国首届关于中台战略的会议，会议上有许多优秀的企业架构师带来了他们各自在实践中台过程中的心得。本文就笔者对自己参与的会场的情况做一些分享，同时也写写自己参会以及查阅相关资料后关于中台这一概念的理解和体会。
什么是中台？
中台不是一个新名词。然而你如果想找到它的源头，可能真不太好找。有人说来自银行的”前台-中台-后台“的组织结构，有人说来自阿里提出的“大中台，小前台”概念。
而”中台“这个词真正火起来，还是在2017-2018年，这个时间段里，阿里出版的《企业IT架构转型之道：阿里巴巴中台战略思想和架构实战》详细阐述了他们认为的中台是什么，而随后，滴滴、京东等一大批互联网企业开始分享自己在中台探索的成果。
那么你可能要问，究竟中台是什么？王健老师在《当我们谈中台时，我们在谈些什么| 白话中台战略》一文中提到：
在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。
可见目前对中台其实大家仍然处于一种都有感觉，但是仍然看不清的状态。甚至会让人觉得每种理解都说的通，但是一旦拿来和自己面对的情况相比，又总是缺了些什么。
其实这也正常，看不清才是中台真正的模样，就像我们看到一个抽象类，它的定义是模糊的，虽然我们能看到这个类很多的实现，但是如果我们自己要用的时候，可能还是要重新做一套适合我们的实现，因此我比较偏向关于中台的另一种定义，就是”中台是一种思维方式“。无论是阿里说的前台-中台-后台，还是技术平台，或共享组织，都是面对复杂问题时采用的策略，而其本质思想用两句话可以概括：“多维拆解⾼复杂系统，全局设计可复⽤架构”，这里的系统和架构都可以跳出软件的范畴来理解。
什么时候需要中台？
我们讨论了如何定义中台，现在来看看怎么就需要中台了。首先，让我们设想一个二维矩阵，每一行表示一个分布式项目，每个分布式项目由前台和后台两部分组成：
[ 前台，后台, 前台，后台, 前台，后台, ... ]
我们先给出前台和后台的定义：
- 前台 由各类前台系统组成的前端平台。例如用户直接使用的网站，手机App，等。
- 后台 由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
从纵向的维度来说，如果系统之间有重复建设的部分，无论是前台还是后台，将重复的部分提炼出来单独构建，然后在各系统之间共享就是一种中台思维的运用。比如阿里的淘宝、天猫还有1688等，最初都是烟囱式架构，彼此独立，但是后来发现这样重复建设的内容挺多的，成本太高了，所以就将重复的部分，比如用户、订单、物流等提炼出来单独考虑，如此这般阿里的业务中台也就慢慢建立起来了；
从横向的维度来说，无论是什么系统，前台都更贴近用户，更可能产生变化，更需要快速响应变化的能力，而后台更多的是偏向信息化管理方面，无论是技术还是业务需求都更加固化，需求的是稳定，但问题是不能满足前台日趋多变的需求，此时的前台和后台就好比两个不同转速的齿轮，强行配合终将导致两者都难以维护，而在前台和后台之间加入一个变速齿轮(那些比前台稳定，比后台灵活的机制)，使得二者的速率能合理的匹配也是一种中台思维的运用。比如如果你要在某个城市搭建一个公共服务项目，为市民提供水电气、社保、公积金、共享单车等公共服务，你设计的直接面向市民用户的前端一定是需求多变的，而水电气、社保、公积金这些单位的系统都是长期以往稳定运行的，要想解决二者之间的矛盾，比起每次前台有变化都深入这些系统内部进行分别改造，更好的方式当然是建立一套中间系统去进行适配，这样中台也就会慢慢建立起来了。
中台的实践案例
《医院后勤生态模式下的企业级中台建设》
- 讲师是南京天溯的侯逸文 天溯是一家聚焦于医院智慧后勤运维服务领域，采用“生态平台+应用中心+管家团队”的平台运营模式，为医院提供智慧后勤线上与线下相结合的全线、全产业链运维服务的企业。
- 侯老师从中台的解决方案、技术方案、应用和案例三个方面介绍了他们在医院后勤运维领域的实践心得。
- 医院后勤管理范畴涵盖的内容很多，包括30多个种类和100多个服务，比如房间空间管理，总务服务，膳食服务，安全保卫等。医院本身基于这些服务构建了一批庞杂的系统，这些系统各自为政，数据不共享，标准不统一，变更非常困难，为此迫切需要一种方式能够解决这些问题。中台自然当仁不让。
- 然而，侯老师认为，如果仅把中台看成是一套IT系统就有些局限了，侯老师认为，toB类的企业级中台，需要关注3个方面： 【技术赋能】 中台除了提供通用的IT基础硬能力，更要能提供合规的业务规范、标准的运行流程和统一的考核体系这些软能力。 【管理赋能】 中台不仅是线上系统的事情，更要能打通线上线下，有一个精干的线下团队来有效使用中台，落地执行中台包含的规范、流程和标准。 【生态赋能】 中台不仅是本企业的事情，更要能以开放的精神服务整个行业中的所有合作伙伴，实现互惠共赢，构建行业命运共同体。
- 我们来看一下侯老师提供的他们为医院做的功能架构：
架构分为三层：基础服务层、业务接入层、应用生态层、交互展示层，可以看到中台分布在业务接入层和基础服务层，包括：数据分析中台、基础能力中台、IoT中台。 - 再来看下部署方式：
上图中的生态平台涵盖了3个大中台：数据分析中台、基础能力中台、IoT中台。可以看到有两种不同的部署方式，基于云端的和基于本地的。 - 在应用案例中，侯老师介绍了能力中台、数据中台、IoT中台带来的实际价值。 【利用能力中台中的工作流引擎服务，他们更快的的上线了新的业务】
【利用数据中台对数据的聚合和分析能力，他们有效的发现了医院相关设备在空间上的能耗问题】
【利用IoT中台对数据的采集、监测、告警的能力，配合BIM，具备了从空间上监测设备并能够快速定位故障点的能力】
- 最后侯老师做了一下总结： 在医院后勤运维业务场景中，中台的职责是为人和应用生态赋能统一的技术和规约，这三者之间的关系如下：
- 小结： 侯老师的汇报很干货，结合医院后勤这个实际的应用场景阐述了中台在项目功能架构中的位置，如何发挥作用，以及带来的具体好处，很有借鉴意义。
《阿里巴巴业务中台实践与思考》
- 讲师是阿里巴巴智能资深技术专家谢纯良 谢老师从阿里20年技术演进的关键节点入手，介绍阿里巴巴的中台是如何成型的。
- 2003年，1688和淘宝出世，后者是阿里巴巴花了2000美金从一个美国人那里买了一个网站系统，然后改造出来的，所以和1688系统在技术上相互隔离，无法复用1688的技术。也就是说创立之初，阿里研发的系统，也是烟囱式建设的。
- 2008年，在王坚博士的带领下，阿里开始核心系统去IOE的工作，并开始建立淘宝技术体系，做为集团统一标准，淘宝、天猫、1688实现了技术统一。
- 2013年，阿里技术上持续统一，并成立共享事业部，业务上确定淘宝、天猫、一淘并驾齐驱，业务中台初见雏形。
- 2016年，阿里巴巴旗下的业务越来越多，包括聚划算、天猫、河马、1688，饿了么等，所有归于阿里的系统，其技术栈会被统一成阿里的技术栈，基于技术上的统一，阿里成立了稳定的中台，稳定的中台帮助阿里加快了创新，更好的拓展了线下的业务。
在演进的过程中，阿里以用户体系做为切入点，统一了各独立系统的用户数据，并通过不断的总结提炼，得出了一套中台构建方法论，沉淀出了很多成熟的技术产品，积累了丰富多样的业务能力，也正是凭借这三点，阿里的中台得以成功演进。
小结：
阿里的强大中台也是一步一步演化出来的，凭借其强大的抽象和提炼能力，中台的构建方法论，沉淀的相关技术，打造的业务生态，还可以助力其他企业快速构建自己的中台和前台，只能叹服了。
《孩子王新零售中台架构演进之路》
- 讲师是孩子王中台研发负责人王海龙，负责孩子王新零售中台从0到1的搭建，以及后续各阶段的完善。
- 孩子王起初是没有线上渠道的，只有pos和内部的ERP系统，每个门店的ERP和总部的ERP对接。
- 随着移动时代的到来，孩子王意识到要增加线上渠道，于是建设了app、微商城等线上渠道，至此孩子王线上、线下全渠道覆盖完成。
- 然而，各系统先后上线，彼此独立，导致多套用户，多种标准的出现，不仅未能发挥线上优势，反而带来了用户线上线下，甚至线上不同渠道会有不同履约、用户信息不一致等问题。
- 为了解决如上问题，王海龙老师从统一线上用户入手，然后到统一全渠道的会员数据，最后实现会员体系的统一。
- 一旦统一了全渠道的会员体系，可以做的事情就多了，比如收费会员、积分兑换、全渠道券等等运营策略都可以玩了，可以说是进入了一个完全不同的万物生长的阶段。
- 随后，商品、订单、库存、促销等业务开始从线下的ERP系统转移至线上，与统一会员体系相互协同起来
- 至此，孩子王的中台已见雏形。
- 有了中台的雏形，就有了替换线下ERP系统的可能，ERP系统本身存在很多痛点，比如商品促销策略、新商品上线等都无法准实时的推出，但是很多时候，如果无法及时更新营效策略，将失去市场先机，所以王海龙他们其实早就想替换这个老旧的ERP系统，但是由于诸多业务都在上面运行，为了保险平滑的过度，他们选择由中台构建入手，逐步架空ERP系统，直至替换，最后孩子王的中台演进成了下面的架构：
更详细的架构如下：
小结：
孩子王和阿里一样，在面对日趋增加，复杂多变的业务，传统的烟囱建设模型捉襟见肘时，从统一用户体系入手，开始构建自己的中台，通过不断提炼通用的业务或技术上的能力，让中台逐渐成长，各业务系统逐渐瘦身，随着中台地位的上升，便可以顺势建立统一的标准，之后的新系统便只需专注于自身的业务，其建设效率自然不言而喻了。
中台的启发
这次参加中台战略大会，让我回想起自己2年前在做工作流业务解决方案的时候做的一次设计理念汇报，汇报的大致内容是说如今工作流引擎更多的是嵌入到业务系统中，而未来工作流引擎将做为一种服务，在业务系统中共享，并且除了工作流引擎是这样，其他的很多业务或技术都会这样。
当时其实只是基于可复用和组件化的理念在构思，现在看来这也是中台思维的一种运用，无论是阿里还是孩子王这样的互联网公司，还是天溯这样的传统软件公司在构建中台的道路上，都是从统一用户体系入手，《OAuth2.0概念以及实现思路简介》这篇文章中我们介绍了oauth2，以及用它打造单点登录体系的思路，未来还可以考虑基于统一用户中心打造一个分布式平台，提供统一的技术栈，技术标准供业务系统使用，逐渐形成我们各业务领域的中台架构，当然这条路不容易走，因为会涉及业务、技术甚至是组织架构上的变化。
总结
我们一开始对中台做了一个定义，认为中台是一种思维方式，接着从2个不同的维度讨论了什么情况下需要中台，然后通过一系列应用案例展示了中台的构建过程，并谈了我个人的一些启发，希望这些内容能够对你理解中台有所帮助，并能建立起自己的中台思维。
最后，让我们再回顾一下中台思维的本质——
“多维拆解⾼复杂系统，全局设计可复⽤架构。”
ok，本次分享就到这里了，88~
参考资料
IAS2019中台战略大会：
《什么样的企业需要数字化中台》——ThoughtWorks 和坚
《医院后勤生态模式下的企业级中台建设》—— 侯逸文
《阿里巴巴业务中台实践与思考》—— 谢纯良
《孩子王新零售中台架构演进之路》—— 王海龙
ok,本篇就这么多内容啦~，感谢阅读O(∩_∩)O。
