中台，数字时代企业需要掌握的新技能
ThoughtWorks作为一家有态度的技术公司，我们每年都会进行有态度的前沿技术解析，并以雷达的方式呈现当下技术领域的快照。3月15号我们在深圳举办了最新一期的“技术雷达峰会”，技术雷达委员会也全部聚齐在深圳，Martin.Fowler，Neal Ford这些技术江湖上的前辈在大会上进行了精彩的分享。
在雷达峰会上我也有幸分享了一个话题：中台为什么这么火。主要是基于我们在中台上的实践和研究，从市场竞争，企业管理，IT架构等多个视角来更深入的理解中台，从而明确如何建设中台。这篇文章是把我分享的内容给完整的写出来，希望不论是听过分享的还是没有听过的朋友，都能够通过这篇文章了解我对中台的分析论证和逻辑推演。
整个分享一共有四个部分：
- 中国特色的中台，介绍为什么中台这个概念是中国独有的。
- 企业希望中台解决什么问题，介绍在数字时代企业面临的问题是什么，企业的阵型又会怎样变化。
- 如何实现中台，介绍如何围绕着可重用的数字化服务来实现中台。
- 中台的技术选型，介绍有什么省时省力的好方法帮助我们进行中台技术选型。
1.中国特色的中台
很多人以为中台这个概念是最近这几年才出现的一个新名字，其实在中国的古代唐朝就曾经使用过这个名字。在中国古代的政府组织中大家一定比较熟悉三省六部这个概念，三省是门下省，尚书省，中书省，六部是工部，刑部，兵部，礼部，户部，吏部。其中最重要的是尚书省，这个机构是从汉代皇帝的秘书机关发展而来，然后逐渐发展壮大成为整个政府的中枢。公元662年唐高宗李治下周宣布机构改革，以门下省为西台，中书省为东台，将尚书省改为中台。
虽然唐朝的中台和我们今天所说的中台不是一回事，但根据古代中台的作用，我倒觉得这给了我们一个理解中台的新方向。不再只是因为在技术上我们划分出了前台和后台，所以把前台和后台中间的东西称之为中台，能不能也和唐朝一样成为一个企业组织的中枢？
所以在给雷达委员会介绍中台时，我没有使用直接的英文翻译：Middle-End或者Middle-Platform
，而是直接用拼音作为中台的英文名：Zhong Tai.
让我们从唐朝回到现代，当今的中国，互联网和数字化已经深入的渗透到了每个人的工作和生活当中。现在中国人每天出门之需要一个手机就够了，吃饭的时候点餐可以扫一扫，要付钱的时候可以扫一扫，出行要骑自行车可以扫一扫，进出办公室的大门可以扫一扫，基本上现在一个中国人日常需要完成的大部分事情都可以通过手机完成。而对比西方，不论政府还是社会在接受数字化上都还相对保守，最近刚有一个新闻是费城立法要对无现金商店罚款2000美金。
在这样一个大的数字化市场环境下，我们发现了一个有意思的现象：我们接触到的很多中国企业都会提到一个相同的诉求：想要建设一个中台。而且提出这些诉求的客户来自于各个行业，金融行业，通讯行业，汽车行业，电脑制造行业，家电制造行业，传统零售，甚至有的企业专门准备了20亿预算来建设中台。但是当和这些企业深度讨论的时候，又发现大家对中台的理解又不太一致，有的企业以为中台就是类似于ERP，CRM的的系统，可以开箱即用；有的企业在纠结中台应该有什么，什么可以放到中台里面，什么不能放到中台里面；有的企业不清楚中台应该如何和现有系统集成。
要回答这些问题，我觉得需要研究一下中台的起源，以及这些年发生的和中台有关的事件。2015年12月7日阿里巴巴宣布进行业务升级和调整。阿里巴巴集团CEO张勇宣布正式启动2018年中台战略，打造“大中台、小前台” 的组织机制和业务机制，由树状管理变为网状管理，实现管理模式创新。同时，张勇还提拔了七位80后担任更重要的职位，称“让集团更多优秀的年轻人承担起更大的责任”。
但那时候市场上其他人都不明白中台是什么，更不明白阿里要干什么，所以市场上并没有其他企业跟进。在两年后，阿里在2017出了一本《企业IT架构转型之道》，介绍了这两年阿里在建设中台时积累的经验，同时市场也发现了阿里的变化，很多互联网企业开始宣布要构建中台。滴滴在构建出行总台，鹅厂进行组织架构调整，开始构建企业中台，美团在构建数据中台，京东直接在组织架构中使用中台。
对于这些市场的变化我们有两个疑惑：
- 为什么阿里，腾讯，京东在构建中台的时候都要调整企业组织架构？
- 大家究竟是希望用中台来解决企业的什么问题呢？
2.企业希望中台解决什么问题
通过与很多互联网公司朋友以及我们客户的讨论，他们的感受是数字化的渗透过程诞生了一批各个行业的颠覆者，颠覆者们利用新的数字化技术在很多企业还没有反应过来的时候就快速地占领了市场，然后很快他们又被更新的创新者挑战，这让大部分企业都处在深深的焦虑中，大家都担心自己会被颠覆。而要想不被颠覆，就只能让自己适应数字化浪潮，一方面要让自己掌握新的数字化玩法，能够有效地防御住自己的优势领域；另一方面还要能够非常快速地集结资源进入某个创新领域进行尝试，以前很多大公司会成立实验室来进行这项工作。但在当今的中国，实验室的研发周期对市场来说太慢了。而要满足速度要求，就必须能够重用企业的一些自有能力，还要能够快速地集成一些企业的外部能力。
所以这个时代的企业需要的是数字化敏捷力，数字化敏捷力对企业来说主要是满足两个方面的诉求：
- 老业务全面数字化。让企业目前还处在优势的业务能力数字化，可以让用户通过各种数字化渠道来达到目标，可以整合外部资源构建数字化生态，还要能够做到基于精准的运营数据对业务进行调整。
- 快速地重用成熟业务模式来尝试新业务，新战略。对于新业务，可以重用企业的某些能力，能够基于一部分真实用户快速尝试新业务，还要能够分享在尝试新业务时获得的经验。
基于这两点核心诉求，我们认为中台的定义应该是：企业级能力复用平台。
- 企业级定义了中台的Scope，中台不同于单系统的服务化和微服务。
- 能力定义了中台的主要承载对象，可以是业务能力，技术能力，数据能力，甚至是财务能力，人力资源管理能力。
- 复用定义了中台的核心价值，传统的IT系统对于复用没有太多的关注，而中台要求组织需要通过复用实现数字化敏捷力
- 平台定义了中台的主要形式，区别于传统IT系统的烟囱式构建，通过对能力的更细粒度识别，实现企业能力的柔性复用。
关于这个定义，有一个更精彩的文章 白话中台战略-3：中台的定义
下面让我们用一个实际的例子看看传统的企业IT系统架构有什么问题，以及如何解决这些问题。这个例子是一个整车制造厂商，它原本有两个系统，一个是对C端用户的微信小程序，一个是对B端用户的经销商销售管理，这两个系统都是单独构建的，还采购了独立的服务器存放在企业的数据中心里。现在企业需要启动一个新车电商新业务，按照这种IT架构模式只能当作一个新系统全新构建，然后再通过API集成和数据库集成等方式和现有系统进行集成。这样的烟囱式IT系统架构在每一层都会有一个突出的问题：
- 对于用户触点前台，由于每个应用都是独立搭建硬件和软件，所以发布成本高，实现高可用困难
- 对于支撑前台的API，基本上做不到IT资源的重用，所以很难快速的响应业务的变化需求
- 对于业务流程中产生的数据，必然会产生冗余的数据，这将带来高维护成本，并且难以从数据中获取价值
- 最后是支撑烟囱式应用的数据中心，通常都需要自己维护服务器，机柜，机房，甚至网络，不仅需要高昂的硬件成本，而且很难具有弹性，灵活性也差。
数据中心的问题随着现在云技术的全面普及已经得到了很好的解决，当然使用云的过程中可能会存在一些具体的细节问题，比如如何能够把公有云和私有云组合起来使用，如果需要给AI计算提供支撑如何搭建云基础设施，如何搭建Serverless的云基础设施等等。但企业通过使用IaaS和PaaS已经可以解决数据中心的弹性问题，灵活性问题和运行成本问题。
然后采用DDD方法对每个系统的业务能力进行分析，可以发现这些系统提供的功能和数据其实都代表着企业的某种服务能力。并且如果我们站在企业的全局视角来审视这些服务能力，会很容易地发现不同系统之间存在服务能力重叠，比如新车电商，微信小程序和经销商小时都需要相同的客户服务，新车电商和经销商销售都需要新车库存服务，新车订单服务。如果把这些服务能力变成数字化服务，那么也就不会存在数据冗余，并可以提高IT资源的复用率，前端应用也不再是跟随原来的单体应用架构进行部署，而是可以在应用层进行独立部署，根据业务需要快速组合数字化服务提供的API来响应，还能够通过应用和服务的多实例部署来很容易地实现高可用性。
前面是企业IT架构视角，让我们从业务流程视角来看看会发生什么改变。针对现有的微信小程序业务流程我们分析出3个业务流程节点A1，A2，A3，针对每个业务流程节点进行分析可以知道这个节点需要使用什么能力来支撑，然后我们把这些能力转化成可重用的数字化服务。当企业需要尝试一个新的业务流程时，通过业务分析发现了新业务的流程节点B1，B2，B3，然后用相同的方法对这些流程节点进行分析可以知道这些新节点需要使用什么能力，哪些能力是企业现有的数字化服务，哪些能力是需要新建或者从外部获取的。那么对于这些业务流程，这些数字化服务，企业应该如何进行管理呢？
基于数字化服务的企业阵型就开始转变成了“大中台，小前台”的样子，随着越来越多的企业能力变成了数字化服务，如何管理好这些服务将会是企业面临的新挑战。比如如何评估数字化服务的价值，如何在不影响前台业务的前提下对这些数字化服务进行拆分和合并，设计一个数字化服务需要注意什么，如何提高研发数字化服务的效率，如何组织研发和运营数字化服务的资源，如何计算这些数字化服务的成本和收益等等各种问题。
所以我想需要研究一下管理思想体系，以及这些管理学派的创建背景，来看看有没有什么管理理论可以帮助我们管理这些数字化服务的。根据郭咸纲老师的《西方管理思想史》一书，到目前为止管理思想主要有三个重要阶段：
- 第一阶段称为古典管理理论，发起自1911年前后，那时候的世界在各种科学技术的推动下，工业有了非常迅猛的发展，但是这个发展过程并非顺畅的，这期间遭受了5次世界性经济危机的打击。工人和资本家的矛盾越来越尖锐；垄断型大企业开始出现，如何管理这些大型组织；如何快速地把农民转换成高效率的工人。这三个主要问题随着资本主义发展越来越突出，社会迫切需要一种管理理论来推动和维护社会发展。在这样的大背景下，泰勒提出了科学管理理论来改善工人的操作；法约尔从企业活动出发，提出了组织管理理论，把企业活动分成了6大类：技术活动，商业活动，财务活动，安全活动，会计活动，管理活动；马克思韦伯从集权组织视角出发，针对大型垄断组织提出了行政集权组织理论。这些管理理论构筑起了古典管理理论。
- 第二阶段称为现代管理理论，从二战到八十年代，这段时间由于二战和之后的冷战世界的科技发展更迅猛，美国的国势与经济水平都得到了大幅度的发展，企业所处的环境，生产经营方式以及社会资源的配置方式都发生了重大变化，企业面临很多新情况和新问题，这些变化都需要新的管理理论。在这样的大背景下，巴纳德创立了社会系统学派，把企业当成一个社会系统研究人们的协作关系；西蒙发展出了决策理论学派，研究如何更好的进行企业决策；还有我们非常熟悉的彼得德鲁克是经验主义学派的掌门人，主张管理学就是研究管理的经验，学习管理中的成功和失败，就能解决管理中的问题；还有从企业经理的职务和工作来分析的经理角色学派。还有很多这个阶段产生的管理理论无法一一列举，但是可以看出随着经济飞速发展，企业管理的主要课题开始从如何提高组织内部效率转向到组织如何适应环境，但是由于那个时代信息沟通的限制，大家的研究视角不同产生了很多看法和思路，从而形成了多种管理学派。
- 第三阶段称为当代管理理论，从八十年代开始，八十年代以后世界经济发生了结构性变化，美国的管理界认为美国经济正在衰落，原材料经济和工业经济脱钩，原材料开始过剩，全球一体化让国家需要根据世界经济制定自己的经济政策，市场竞争越来越激励。在这样的大背景下，波特从竞争战略角度提出了竞争战略学说；彼得圣吉从提升企业整体素质角度提出了学习型组织，企业要进行的五项修炼；戴明博士从质量管理角度提出了有名的戴明环；杰克韦尔奇利用六西格玛理论缔造了伟大的通用电气。总的来说，当代管理理论呈现了五大趋势，从过程管理向战略管理转变，从产品的市场管理向价值管理转变，从行为管理向文化管理转变，人本管理思想更加深入，以不断地创新追求经营绩效的持续改善。
从上面的管理思想史可以发现，每一次当时代的浪潮来临时，都会产生很多新的管理理论。在时代的浪潮中，有些人因为发明了新东西称为了浪潮的受益者，有些人则是把新东西很好的利用到了某些领域也成为了浪潮的受益者。说到蒸汽机，我相信很多人都知道瓦特，甚至有人还知道博尔顿，但估计很少人知道这位韦奇伍德。他利用蒸汽机技术，使得人类历史上第一次出现某种产品供大于求的情况，这个产品就是中国引以为傲的瓷器。现在Wedgwood这个品牌依然是瓷器界的奢侈品。
从八十年代到现在，时代的车轮不但没有放缓，反而越来越快，尤其是从2007年乔布斯发布iphone以后的世界又发生了巨大的变化，智能手机，人工智能，AR/VR，区块链新技术层出不穷，从研发到产业化的转化越来越快，个人的行为方式，企业的协作方式也已经发生了很多变化。同时整个世界的势力格局也在发生变换，中国作为世界工厂上可以承接欧美的高科技设计，利用已经形成的供应链生态优势生产出产品买回欧美；下可以利用中国的发展经验，基础设施建设经验，把产品和能力输出给更多的发展中国家。
所以根据前面分析的管理思想史，我认为我们又站在了一个时代大变革的浪潮上，企业面临的问题随着时代又发生了变化，需要一些新的管理思想和指导实践的管理方法，甚至新的管理技术。如果再只是把中台看做是简单的企业IT平台架构，或者只是一个企业技术部门应该关注的东西，那么就还没有深刻认识到中台对于企业的意义，中台应该是是数字时代企业管理需要掌握的新技术。
可能有些人会觉得我这个观点把中台放的太高了，企业管理是一个非常复杂庞大的体系，有人觉得现有的管理思想，管理方法，以及一些管理技术对于管理一个企业来说已经够用了，但能够用一套逻辑一套思想解释现在和未来所有一切事物的只有自大的宗教。也许未来有人给出了数字时代的新企业管理技术不一定叫中台，但是对目前数字时代的大部分企业来说，需要一个把数字化技术融入到思想的管理方法。Gary Hamel在他的《The Future of Management》一书中提出：现在你们公司拥有嵌入21世纪互联网技术的业务流程，使用20世纪中叶的管理流程，但这些都建立在19世纪的管理原则上。
3.如何实现中台
前面用了不少篇幅来逻辑推演中台的核心意义。下面来点干货，看看如果要构建一个中台管理好这些数字化服务，那么已经改怎么做？
最终有一堆的数字化服务在线上运营是我们的最终目标，所以要做到很好的运营需要有一套数字化服务运营规范来指导运营。
在运营数字化服务的时候，所有前台应用都是通过数字请求的方式来获取的服务的，所以对于企业来说需要具备强大的数字接入能力，根据ThoughtWorks之前的项目经验，当说到数字接入能力的时候主要要考虑三个层次的问题：请求管理层，安全防护层，API治理层。另外对于这么多的数字化服务，还需要具备服务治理能力。这两块的能力后面会有详细的介绍。
然后往前推导，是如何把企业的某种能力转变成数字化服务的呢？需要有一个数字化服务设计规范来指导我们把组织能力设计成服务，然后还需要一个数字化服务研发规范来指导我们把设计最终开发出来。数字化服务的研发和普通的软件研发有些不同，单服务开发的依赖问题，各个环境部署的集成问题，已经研发中的项目管理问题都需要一个服务研发平台来提供高效的研发支持。
最后这些数字化服务，数字接入能力，服务治理能力，服务研发平台都需要建立在一套弹性的数字化基础设施上。
既然中台需要这么多东西，那么应该怎么做才能一步步把中台落地呢？
- 第一步是搭建数字化基础设施，这是整个中台的地基
- 然后需要导入数字化服务设计规范，基于DDD，Design Thinking这些方法论，通过一起协同的工作坊方式，让团队能够设计出合理的数字化服务。
- 然后导入数字化服务研发规范，团队根据研发规范知道如何开发出标准的数字化服务
- 在第三步的同时开始建设服务研发平台，比如CI/CD流水线，服务设计管理，服务自动化测试等
- 当有的数字化服务研发接近完成的时候就可以开始建设数字接入能力了
- 同时也可以同步建设服务治理能力
- 最后随着一个服务逐渐研发完成并上线运营，需要导入数字化服务运营规范，指导运营人员进行服务扩展，服务合并，并处理各种线上问题。
下面是ThoughtWorks独家的服务服务化设计流程，一共分成四个阶段：
- 首先是业务方案设计阶段，这时候主要是进行高阶的业务方案设计，使用商业模式画布，精益画布，价值主张画布等方法分析并识别业务痛点，并给出业务方案和业务架构。
- 然后是产品/服务设计阶段，这个阶段要分成两部分进行，一部分是从用户视角出发进行用户产品设计，一部分是从系统视角出发，进行服务发现。用户产品设计会采用Design Thinking方法论，使用Inceptiong工作坊，根据业务方案进行针对性的用户访谈，根据访谈结果建立用户画像，然后梳理用户旅程地图，根据用户旅程进行产品功能设计，并对功能特性进行分类，最后产出产品ROADMAP。服务发现会采用DDD方法论，使用EventStorming工作坊，根据业务流程进行事件风暴，命令风暴，然后寻找领域聚合，探索限界上下文。
- 接下来是交付设计阶段，所谓交付设计，就是为交付做准备的设计。会从需求角度进行用户故事拆分，设定用户故事验收标准，并进行RAIDs分析优先级。从架构设计角度，根据前面划分的服务进行系统架构设计，外部系统集成设计，根据聚合的命令进行API设计。
- 由于有了交付设计的产出，所以最终进行服务迭代开发也很容易落地。在迭代开发阶段采用敏捷和精益开发方法论，需要CI/CD，Devops，自动化测试等工具和实践的支撑。
下面是在研发数字化服务时团队需要遵循的规范，其中包含业务梳理规范，服务设计规范，可用性规范，系统集成规范，数据集成规范，应用管理规范。它们为团队提供工作方法与完成标准，包括微服务拆分、API接口设计、数据采集与管理、API调用与集成、云化与容器化部署、性能、系统安全性。这些规范可基于企业已有的规范为基础，针对中台的场景做一些适配。
数字化服务研发平台需要分成两部分考虑，一部分是基础的软件研发工具，比如代码仓库，项目构建工具，持续交付流水线，Devops管理平台，以及用来管理项目计划，任务，缺陷的敏捷项目管理平台。另一部分是专门针对数字化服务的研发工具，比如服务需求管理平台，服务设计管理平台，服务契约管理平台，服务测试平台，服务架构守护平台等等。
我们重点介绍一下数字化服务接入能力和服务治理能力，这两个能力是服务上线运营的关键能力。
对于数字接入能力，前面说过主要要考虑三个层次：
- 请求管理层
- 请求预处理，某些业务场景需要针对请求进行一些预处理，比如根据请求的用户ID来补充用户基本信息
- 静态路由，请求管理中最基础的路由能力
- 灰度访问，在发布新功能时一个非常有用的能力
- 多租户管理，主要是根据不同的租户进行进行不同的请求处理能力
- 负载均衡，负载均衡其实是一种动态路由，也是请求管理层的重要能力
- 安全防护层
- 请求认证鉴权，确认请求的合法身份
- 权限控制，校验请求能否访问所需的资源
- 会话管理，管理请求的会话上下文
- 统一入口，给请求提供统一的入口
- 请求限流，当发生非正常情况时能够对请求进行限流处理
- API治理层
- API定义，以标准化的格式定义API，让使用者方便地查找API
- API测试，帮助API使用者在开发接阶段进行调试
- API发布，如何无破坏地发布或更新API的能力
- API可视/性能，记录并统计API的性能，监控API的状态
- API链路监控，能够跟踪每一次请求的API链路
对于服务治理能力，可以参见我的一个文章《当我们在说微服务治理的时候究竟在说什么》，在那篇文章中我对市面上常见的服务治理相关工具进行了一次系统分析，通过类比城市交通治理我发现，虽然有很多服务治理的框架和工具可供选择，但是这些工具核心处理的问题一共就4类：网关就是整个整体的守门人日志采集，这一块的能力由请求接入能力负责。追踪工具，服务注册发现都是用来采集信息的，然后需要监控平台来展现这些采集的信息，并进行监控和分析。最后根据分析的结果采取治理策略，有的服务快撑不住了要限流，有的服务坏了要熔断，并且还能够及时的调整这些服务的配置。
对于中台架构中的每一块内容，由于演讲的时间限制，所以不可能完全展开了进行深度讲解。否则每一块的具体落地细节都足够讲上一天的。这里主要想给出一个实现中台的整体框架，框架中的每一个组成部分都不是随便拍出来的，而是采用逻辑推演的方式得出。相信随着大家在中台领域进行不断深入的实践，一定会发现一些新的能力和平台需要补充的这个框架中来。也欢迎大家随时和交流建设中台的经验和心得，让我们一起来完善这个数字时代的企业管理新技术。
4.Last but not least：中台的技术选型
在实现中台的框架中，不论是各种规范，还是需要的数字能力和数字化服务研发平台，在具体落地时都会面临技术选型问题。在进行中台的技术选型时，参考技术雷达对相关技术条目的成熟度评估，能够规避一定的风险、进而节省成本。下面是一些例子：
- 19期的Event Storming，就是数字化服务设计规范中可以选用的成熟技术。
- 19期的Four Key Metrics，指的是软件交付性能的四个关键指标(FOUR KEY METRICS):前置时间，部署频率，平均恢复时间(MTTR)和 变更失败百分比。可以用在数字化服务研发规范中。
- 19期的ARCHUNIT，这是一个通过源代码来分析架构，并采用单元测试方式校验架构是否满足期望的工具。可以它来构建服务研发平台中的架构守护平台
- 19期的LocalStack，使用云服务时面对的一个挑战是如何在本地进行开发和 测试。LOCALSTACK 为 AWS 解决了这个问题。可以是服务研发平台的一个有用工具。
- 18期的Jupyter，除了将JUPYTER作为一个分析工具，开发者们还在尝试一些创新的用法，比如将Jupyter用于自动化测试。新用法可以用在服务研发平台的服务测试平台上。
- 18期的Kong, 这是一个成熟的商业框架，它可以满足大部分的数字接入能力。
- 18期的GraphQL，很多个微服务对于前台应用来说是痛苦的，因为它需要请求多个API才能获取到完整的数据，通过使用GraphQL构建一个轻量的BFF层，就可以容易的解决这个问题，前台只需要通过一次API调用就能够获取它需要的所有数据。
以上就是我在雷达峰会上分享的全部内容，如果你对上面的内容有任何问题，欢迎留下你的评论。