前文《中台之我不是药神》讲到，阿里和其客户共创了中台。那么中台是在一个什么样的背景下产生的？如何理解中台？企业对中台的需求是什么？中台实现的路径是什么？

本文将结合银行中台实践的案例，带领大家深入理解中台。

01 中台为谁而生？

1. 平台化

通常，最初的决定是正确的；然而，自从项目、工作或关系开始以来，事情已经地改变了，最初的决定不再有意义。

—— EA

企业发展到一定程度，组织架构和层级必然不断膨胀扩张。各大事业部下各大部门，就像一个小型组织一样，各占山头，势必会出现屁股决定脑袋的现象。大企业内部各处都是墙——部门墙、业务墙、数据墙。一个原本可以共用的服务，被不同部门重复建设。

以阿里电商平台为例，淘宝、天猫、一淘各自拥有客户管理、商品管理、门店管理和交易与结算系统，这些系统功能重叠，以至于没有人能搞清楚业务能力到底有哪些、是如何分布的。

部门墙造成的问题是：

1. 重复的建设轮子，资源浪费；
2. 标准不统一、品类不统一、标签体系不统一、评论机制各不相同；
3. 审核问题，但凡做内容必须有审核，不同子公司在审核的投入上都很巨大；
4. 采购问题，不同 BD 采购流程不通。

从企业角度来看，这就形成了烟囱式的建设。烟囱式的建设限制了业务发展速度、推高了业务创新的成本。实际上企业需要的是搭建像乐高一样的组件化体系，通过这个体系，可以将信息、标准、帐户、数据做一系列打通，将业务流、数据流、分发流、商业流这些相近的单元进行平台化。

阿里搭建中台的最初设想就是建设一个业务共享平台：通过建设若干个业务中心将分散到各个系统的独立单元重新构建（合并同类项），对前端提供一个快速响应、抽象共性、边界清晰的平台。

 阿里共享业务平台

2. 从去IOE到微服务

企业软件系统的演进大体经历了三个阶段。以银行系统为例，其业务架构的演进如下：

第一阶段：90年代中后期分布式架构

分布式架构

这个阶段的架构具有以下3个特点：

1. 将总行的集中式系统在各个省分行分别都部署一套，每天晚上再以批量处理的方式将各省数据进行集中。
2. 这种架构的方式能够最快的解决联机性能问题, 但存在跨省转账交易无法实时到账的问题。
3. 基础设备多采用IOE（IBM的小型机、Oracle数据库、EMC存储设备）厂商。

随着互联网新技术的兴起，2009阿里提出了“去IOE”，旨在通过低成本的开源软件替代昂贵的IOE设备。此后，金融、电信、石油行业也闻风而动，一场“去IOE化”运动席卷大江南北。到2019年，Oracle中国区大裁员，几近退出中国市场，传统软件巨头Oracle失去往日光芒。

第二阶段：2000-2010年集中式总线架构

这个阶段引入了ESB总线的理念：

ESB总线架构

ESB总线为渠道、核心和外围系统建立了一座桥梁，提供完全统一的接口标准协议，提升了系统发布的实时性。但同时，ESB成为了最大的单点，要支持大并发高TPS低延时，所以HA和性能要求非常高，变更需要相当谨慎。

ESB解决了异构系统之间互通的问题，却没有真正发挥出SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。

无论从性能还是成本消耗上，ESB总线都会导致瓶颈出现。

第三阶段：2010年之后的互联网金融服务架构

到了2012年以后，随着Facebook、Amazon等开放平台获得的巨大成功，BAT都逐步将自己的接口开放出来，并实施了开放平台生态圈战略，从而推动了SOA服务化的快速发展。

开放平台架构

左边是之前的传统银行集中式总线架构，右边是互联网服务化架构，包含了开放平台、基于微服务技术的服务注册和发现，以及服务化产品系统。

基于微服务架构的平台优点是：

1. 业务系统的扩展没有瓶颈，只需要按照业务发展增加微服务单元和弹性容器；
2. 组织敏捷，开发迭代速度快。

微服务是中台的底层框架技术，它提供了一套代码框架，可以实现对复杂系统的解耦，解耦后各个模块变得相对简单,易于重用,易于分析，易于单元测试和保证。

中台和微服务是有交集的两个领域的概念，中台更偏业务，微服务更偏技术实现。

3. 数字化转型

“银行业正处在一个‘技术主导一切，并且无处不在’的世界中，不被淘汰的唯一办法就是为那些数字化的消费者打造新的体验模式，重复网点的模式终将失败”。

——《银行 4.0》作者布莱特·金

面对席卷而来的互联网浪潮和内外竞争加剧的新环境， 数字化转型是很多企业的迫切需要。

以银行业为例，新兴金融科技公司崛起，快速向支付结算、消费信贷和财富管理等银行业务领域渗透，来势汹汹。对此，银行则利用互联网思维适时调整经营理念和方式，将大数据、云计算、移动互联和人工智能等引入自身变革转型中，以此来拓宽获客渠道、重构业务流程。在获客方式创新方面，主要的做法有三种：

（一）服务移动化

通过布局直销银行以及手机银行APP等客户端产品，缩短了与用户的距离。

通过银行的APP，客户不仅仅可以办理金融业务，还可以缴水电费、订影票、在线购物。

（二）全业务渠道

通过与互联网企业进行多元化的合作，将获客的渠道与入口尽量分散。利用互联网企业庞大的用户基数来触达更多的潜在客户。

截止目前，工、农、中、建为代表的四大国有银行均与BATJ（百度、阿里、腾讯、京东）展开“一对一”的战略合作，曾经势不两立的金融阵营如今也不得不握手言和，谋求最大公约数。

（三）私域流量

通过轻型化门店改造，在去高柜的同时嫁接生活场景和社交产品，利用高频的生活场景、社交场景赋能传统物理网点转型升级，有效引流获取客户。

以某商业银行数字化转型实践为例，企业以敏捷组织转型作为切入点，带动精益项目管理和IT创新，通过传统ESB架构和微服务中台的双速IT架构建设，解决了传统架构“快前台慢后台”的问题，实现了中后台敏捷，产品迭代周期由过去的1个月降至1周，实现了产品创新能力、迭代速度的全面转变。

某商业银行数字化转型战略

02 如何理解中台？

1. 中台画像

笔者整理一下对中台的描述，用词云的方式给中台做了个画像。

2. 问题域

中台属于企业架构的范畴。纵向看包括从业务、信息和技术三个维度。横向看为“施动者”+“动词”+“操作对象”逻辑，施动者是触发者和需求提出方，操作对象是被动者和需求供给方。

按照这样的划分，中台实际上包含下面几个领域：

• 产品域：以商品形式对客户提供服务的有形或无形东西。如淘宝和天猫。
• 信息域：以处理业务流为目的的软硬件系统，包括用户界面、数据。如订单系统、商品系统。
• 流程域：采购、仓储、物流、配送等提供服务的企业内部流程。
• 组织领域：企业组织单元，如财务部、销售部等。
• 数据域：订单数据、商品数据、订单记录、操作日志等。
• 应用域：产品的附属软件和硬件单元，提供一组相关的用户交互能力，如淘宝客户端。
• 技术基础设施域：服务器、存储系统、网络等设备。

3. 视角

中台的复杂来于它本事就是解决复杂问题提出的，不同的人站的角度不同，理解也不相同。

在建设中台之前，利益相关者需要就项目目标、范围、度量等关键问题进行充分的沟通并达成共识。为此需要构建一个沟通的上下文和观察视角。

业务-技术视角：产品、流程、信息、应用、数据、平台。

业务-组织视角：战略、目标、原则、价值、度量、项目、项目组合。

组织-技术视角：快中台、敏捷中台、慢后台。

4. 中台的价值

03 中台正确打开姿势？

1. 中台的需求

先来看看某银行对中台的需求：

可以看出企业对中台的期望很高，需求是方方面面的。

2. 中台建设原则

中台涉及的问题比较复杂，客户对中台的期望也比较高。中台项目的挑战是不言而喻的。中台实践要遵循一些基本方法、原则。

1. 从设计层面看：主要是遵循面向对象的分析和设计方法。
2. 从运营层面看：服务中心的分割，要有数据运营和业务整合的价值。比如淘宝的商品中心，绝不是简单的提供商品增删改查服务接口。而是建立一个全球最大的商品库，同时提供该商品库的管理运营方法和配套工具服务。
3. 从工程层面看：共享服务的架构是基于分布式架构、分布式事务和分布式数据库。

基本原则：

1. 高内聚低耦合
2. 数据完整性
3. 业务可运营
4. 渐进性建设

3. 实现路径

企业是一个复杂系统，对待复杂问题应该用庖丁解牛的思路，从大处着眼，从小处入手。中台本身要解决的是系统解耦的问题，但尴尬的是解决这个问题要成立独立的项目组甚至独立的事业部，由于技术债和康恩定律，中台项目组和事业部本身会带来新的耦合问题。

没有阿里这样壮士断腕的决心，这样的组织单元一开始就会阻力重重，负重前行。

中台要先从组织敏捷开始，也就是构建一个独立的快反团队，通过KPI切割、资产确权划清和原有部门的界限，轻装上阵。具体的路径如下：

1）从一个敏捷项目开始

最好是企业范围的，但可以从任何地方开始。把敏捷中台看作是终身学习。

2）组建跨部门的团队

使用敏捷来执行和管理扩部门团队。沟通至关重要。

3）资产确权

从IT和业务管理层获得参与和承诺：包括组织、设备、数据等资产。所有权也必须澄清——谁对某个特定的架构工件是否足够代表企业的特定部分拥有最终发言权？

4）制定考核指标

考核指标为项目提供了价值度量依据，也是项目组前进的方向。

5）架构设计

从业务、信息、技术、运营四个方面进行需求分解和架构设计。

6）制定演进路线

制定一个持续交付的产品路线图，围客户成功进行产品生命周期管理。

中台建设是和组织相关的，没有组织的解耦就没有技术的解耦。

04 中台之路：矩阵革命

“生存下来的不是最强壮的物种，也不是最聪明的物种，而是对变化最敏感的物种。”

——查尔斯·达尔文

《黑客帝国》很多人都看过，影片讲述了这样一个故事：

人类在与人工智能机器人的战争中失败，于是遮蔽了天空隔绝太阳能试图以此切断机器人唯一的能源供应。但机器人没有就此灭亡，机器人中最强大的存在“架构师”创造了“Matrix”，也就是“矩阵”。但矩阵V1.0不久就崩溃了，架构师认为是人类的大脑思维不适应新环境，于是用人类历史的某个鼎盛时期为背景又开发出矩阵V2.0版本，但却再次崩溃了。架构师明白了矩阵与人类不兼容的症结所在，进而设计了一个专门用来研究人类心智的程序——“先知”。

在先知的帮助下，架构师不再构建完美的世界，让矩阵中的人类拥有选择的权利，终于99%的人类接受了这个新版本的矩阵V6.0。但是每个程序都存在漏洞也就是bug，随着矩阵的更新迭代，有一些旧程序需要被删除，但现实却没想象的那么容易，这些旧程序在矩阵里隐藏了起来成为非法程序，以“法国人”梅文为首的非法程序集合成了一个团体，并且这个团体的某些成员还能够超出矩阵的一些规则束缚拥有特异功能，他们的存在对矩阵也构成了威胁。

架构师针对这两个可能会导致矩阵崩溃的bug想出了解决方案：唤醒无法适应矩阵的人类并让他们离开被机器占领的世界去地底深处建立了人类最后一个城市“锡安”进行反抗，但是这种反抗仍是在架构师控制范围内的，甚至是架构师更新矩阵计划中的一环。与此同时架构师集合了所有非法程序的原始代码组成一个新程序植入到一个人类的大脑里，让这个人成为“程序+人类”的存在，并赋予了这个人“救世主”的角色。

——来自简书《《黑客帝国》三部曲剧情解析》 作者Switchhh

中台就是构建企业的虚拟世界（Matrix），这个虚拟世界并不完美，充满了技术债（旧程序），还有一些超出代码范围的问题（史密斯）,在多个版本后崩溃后，中台设计师（架构师）认为纯粹的代码映射解决不了问题，于是开始研究心智程序：精益+敏捷（先知）。在精益+敏捷（先知）的帮助下，中台设计师不在构建完美的世界。终于，99%的用户接受了这个新版的中台x.0（矩阵V6.0），但中台X.0仍然存在bug，解决最终的问题需要“技术+感性+颠覆式创新”的合体（尼奥）。

理解了上面这段话，你就理解了中台的必由之路：

1. 理解并背负技术债
2. 持续交付
3. 选择不完美
4.  赋予心智模型并理解变化：精益、敏捷、设计思维
5.  颠覆式创新（重启矩阵）

作者：涛哥，微信公众号：涛哥笔谈。前华为高级产品经理，PPV课数据科学社区发起人，15年以上IT和通信领域，5年B端产品总监，数字化转型实践者，Togaf粉

本文由 @涛哥 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议