中台，都被你们说糊涂了，文内才是正宗解释，别摸石头过河了，石头早就有了

作者：吕建伟  

来源：阿朱说（微信号: azhushuo）

（1）我们先说说技术架构分层

我们按技术架构通常是这样的：

1、UI交互层：Windows UI、PC Web UI、移动App UI、微信小程序UI、摄像头视觉识别人机界面、语音交互人机界面

2、逻辑层：面向对象技术/组件技术/SOA服务中间件/微服务中间件技术、人工智能NLP/机器学习

3、数据层：SQL数据库/NOSQL数据库、大数据计算平台/数据仓库数据湖/可视化

4、基础设施层：云计算IaaS（服务器、存储、网络、文件系统）

但我们今天要说的中台，根本不是在这个分层视角维度体系来看事的。

不过话说回来，中台应用要具体代码实现，还得依赖这些具体的技术。这就是他们俩之间的关系。

（2）我们再说说中台的由来

中台这个词最初来源于阿里。阿里为啥要中台。没办法啊。

京东提出过一个概念叫：无界零售。也就是说，消费者流量在哪里，哪里就有京东的商品购买插入。所以京东有个平台叫：京东商品开放平台，你可以调用Open API在你任何地方都可以插入京东的商品。

过去在Web时代流量挺集中，流量能被倒来倒去。但是在移动app时代，流量都被冰封在一个个App里面了，这样就形成了流量碎片化。要做到无界零售，你就需要对接很多很多流量口。

对接的多了、烦了，你就要把不稳定的场景应用和稳定的共性功能分离开来。稳定的共性功能就形成了中台。

也就是说：中台是应用，中台不是技术，但中台又不是最终用户能直接使用的，它必须被集成到各个业务场景中。所以中台应用是必然Open API的。平台是让别人集成到你身上，而中台是你要连接别人，让别人集成你。

我刚才拿阿里、京东举例子，他们只不过都是零售端。其实吧，以后的应用趋势是：产业互联网，零售环节只是产供销研端到端一体化的产业互联网的一个环节而已。

完整的环节应该是：

1、商业互联网：会员营销-O2O零售门店-线上批发分销平台-厂家订货

2、工业互联网：区域集群协同生产-智能设备监控调度-B2B原材料采购-全球研发设计协同平台

商业互联网和工业互联网，产供销研一体化，构成了完整的产业互联网。

以后，产业还需要和社会（政府）连接在一起，如连接：银行、工商、税务、海关、公检法、社保、民政、住建、国土资源、交通/车管...，这就构成了社会化商业。

也就是说，未来的业务应用是产业互联网，是社会化商业，连接无处不在。你光你企业内部那点ERP应用，算个啥啊。

（3）我们说说未来的软件应该是什么样子的

各位朋友啊，阿里云都成立十周年了。你们还当云是个前沿技术啊。

我知道很多朋友都还活在地底下呢：PC WebUI、本地安装部署、单实例关系数据库、ETL/数据仓库。

其实，就连云计算都上半场都过去了，你们还迷离马镫的。

云技术上半场是：

1、UI层：移动App、微信小程序

2、逻辑层：分布式微服务、分布式消息中间件

3、数据层：分布式关系数据库、分布式NOSQL数据库

4、数据层：实时大数据计算平台

5、基础设施层：虚拟化、容器

同志们，这都过去了。你用了分布式微服务了没，你用了NOSQL了没，你用了容器了没？你的应用是不是还活在10年以前啊。

云技术下半场应该是：

1、UI层：IoT智能硬件传感器、麦克风语音交互、摄像头视觉识别

2、逻辑层：人工智能关联推荐&最佳资源调度

3、数据层：跨链区块链

4、基础设施层：量子计算

未来输入数据可不是在PC Web上或移动App上不断的人工录入啊录入，而是很多种手段采集数据：

智能硬件传感器收集

摄像头视觉识别收集

麦克风语音交互收集

互联网爬虫收集

互联网OpenAPI来收集

未来也不是在逻辑技术层写死业务规则逻辑代码，而是设计好模型、触发消息，通过人工智能最佳调度算法自动调整模型、自动设置阈值来触发逻辑规则条件发生。所以，中台应用逻辑是活的，是大数据训练的人工智能智能执行的。

未来的输出也不是PC Web UI、移动App UI，也不是什么查询报表、统计可视化这些现在的东西，而是没有异常的时候业务流程和机器设备自己黑灯跑，有了异常的时候会自动推送消息给你，和你进行语音交互，你下了人工干涉命令后它就会按照你的指示再次自动调节规则自动黑灯运行。

你以为这是科幻？嘿嘿嘿，你连已经成熟了十年的云上半场技术都还没有应用，还在讨论概念，你怎能不觉得是科幻呢？夏虫不可语冰。夏虫是不可能想象出冰是什么样子的。

（4）我们说说应用分层

我们讲了未来的应用是：产业互联网、社会化商业，到处连接；我们讲了未来的技术是：人工智能最佳算法调度，而非写死的业务逻辑规则代码。

我们现在再来讲讲应用分层。估计很多人都没听过应用也要分层。

是的，在这个未来应用和未来技术体系内，应用也要分层。你不在这个体系内看事，你肯定理解不了中台应用。因为中台应用就属于应用分层中的一层。

过去我们面对的是集中在一个IT系统里的功能，现在我们有了前台应用，即碎片化的应用场景，它无处不在，分布在各个特定业务场景中。

有一些稳定的共性应用就放在了中台，对前台应用形成被集成的Open API调用。

但是还有一种应用它就更后台，它就给企业内部使用，它属于内敛内控的，它趋向于越来越内敛内控，超稳定。我们把它叫做后台应用，如各种工作流权限审批。

有人说，会计记账以后会成为后台应用。我个人不这么看。我个人认为未来的应用是这样的一条龙全程自动化：

电子商务-电子支付-电子发票-电子合同-自动记账-自动结账-自动报表-自动报税-自动银行对账-自动审计

所以说，会计模块也会对外提供Open API，各种应用（如费用报销SaaS、人力资源薪酬管理SaaS），都可以直接调用Open API，直接记账。所以，就连会计记账模块，以后也会分成中台应用和后台应用。

以后会不会没有后台应用呢？也许长期会存在。在未来5年甚至更长的时间，我们的应用格局会呈现下列样子：

1、庞大的、碎片化的前台应用

2、中度规模、相对共性稳定的、对上提供Open API集成的中台应用

3、以后会越来越小但在相当长时间内还会比较中度规模的，非常稳定的后台应用

有人说，中台应用因为与无数个场景进行连接，所以是海量连接、海量并发、海量数据，而后台应用是内敛内控的，是超稳定应用，少量人应用少量数据。我是不同意这个观点的。一般持这种观点的人，是因为用的ERP还是20年前的技术，根本没把ERP改造成云技术上半场的技术：多端适配的UI、分布式微服务、分布式关系数据库/分布式NOSQL数据库、实时大数据技术平台、云IaaS。

（5）中台与平台的区别

中台、平台，都带一个“台”字，都傻傻分不清了。尤其两者都还对外提供Open API。

但，嘿嘿，中台是业务应用啊，平台是不带有业务特征性啊。刚才我就提到了零售中台、财务中台。

中台是被别人集成的，要爬在无数个别人的身上。而平台的作用一般是要集成别人的，让无数个别人爬到自己身上。

中台是动态变化的，是数据驱动不断训练调整人工智能业务算法和业务模型的。平台是静态的，一旦版本发布，不管你是今年调用这个功能，还是明年调用这个功能，出来的效果是一样的。

（6）完整的体系应该是什么样子

第一层：无数碎片化的、场景化的前台业务应用，如零售、采购、招聘、报销...

第二层：业务中台，如零售中台、人力中台、财务中台....

第三层：数据中台：主数据（画像标签/关系图谱）、数据模型、人工智能业务算法

第四层：后台应用：如被分解后剩下的单一企业内部超稳定的收敛的应用

第五层：应用平台：协同平台（工作流引擎/消息引擎等）、应用组件（聚合支付/电子发票/电子合同/自动报税等等）、集成开发平台/定制开发平台/实施平台/运维平台

第六层：技术平台：微服务中间件、SQL/NOSQL数据库、大数据技术平台（如hadoop和Spark）、AI技术引擎、云IaaS平台

（7）中台的核心本质

一句话：中台的核心本质就是：业务为本、网络连接、数据智能。

不理解我这个话的，你们再看一遍我的这篇文章。

姜文说的好：看不懂？那就再看一遍去。

——————————————————————

白话中台战略：中台的定义

作者：王健  

来源：健荐（微信号: gh_3b7794be56e0）

写白话这个系列主要是想通过写文章来驱动自己思考，并希望可以和更多人一起交流和探讨中台这个话题。

幸运的是，确实有很多朋友在公众号后台给我留言来表达自己的想法，我摘出来一个具有代表性的：

“互联网的企业就是爱炒概念。本来很明白的东西，被他们一包装，就变得高深莫测了。我理解中台，就是敏捷响应机制…是一种思维或者理念…企业根据自己的实际情况落实就行。”

对于这位同学的观点我很赞同，中台本身就是一个比较抽象的概念，很多时候我们被那个“中”字困住了，整天在前与中，中与后的具体差别和评判标准上纠结不已。

但是，就像「看板」不是“我们看到的那个板子”一样，「中台」也不一定就是代表“处于中间平台”，这两个字作为一个整体，代表了一种新的思维和理念。在最新一期的ThoughtWorks技术雷达讨论阶段，中国区的同学就把“ZhongTai”作为一个独立的技术点提交，并没有做意译，就像“Kanban”一样。

那这种新的思维和理念到底是什么呢？“中台”的背后到底意味着什么？有没有价值？价值何在？这也我一直在不断询问自己的问题。

要想搞清楚这些问题，我认为一个关键点就是看我们是否能够给「中台」这个相对抽象的概念找到一个清晰的定义，因为只有通过定义才能让抽象的概念清晰化，从而明确边界、体现价值。

废话不多说，回到「中台」，如果让我给出一个定义，目前我认为最贴切的应该是：

中台就是「企业级能力复用平台」

很简单，有点失望是不是？但是为了找到一个靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，只有这个定义我觉得最贴切、最简单、也最准确，它能解释几乎所有我碰到的关于中台的问题，例如：

• 为什么会有那么多中台，像上文提到业务中台，数据中台，搜索中台，移动中台，哪些才是中台，哪些是蹭热点的？
• 中台与前台的划分原则是什么？
• 中台化与平台化的区别是什么？
• 中台化和服务化的区别是什么？
• 中台该怎么建设？
• 等等……
  
  
  

这9个字看起来简单，重要的是其背后对「中台」价值的阐释，下面就让我为大家一一拆解来看。

---

企业级

首先，中台一定是企业级的，这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围，甚至可以是跨企业，例如现在同样火爆的生态的概念。按照徐昊（ThoughtWorks中国区CTO）的说法，更贴切的叫法应该是「多前台产品团队」，这里为了简单我还是用企业级来代表。

当做中台建设的时候，一定是跳出单条业务线站在企业整体视角来审视业务全景，寻找可复用的能力进行沉淀，从而希望通过能力的复用一方面消除数据孤岛业务孤岛，一方面支撑企业级规模化创新，助力企业变革，滋生生态。

所以虽然中台的建设过程虽然可以自下而上，以点及面。但驱动力一定是自上而下的，全局视角的，并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门，例如CIO级别领导或是企业的战略规划部门，因为只有这些横跨多条业务线的角色和组织，才会去经常反思与推动企业级的能力复用问题。

这一点也引出了中台建设的一个关键难点，就是组织架构的调整和演进以及利益的重新分配，这是技术所不能解决的，也是中台建设的最强阻力，这个我打算在后续的文章里详细阐述。

同时企业级也是区分企业中台化与应用系统服务化的关键点，简而言之中台化是企业级、是全局视角，服务化更多是系统级、是局部视角。

所以从中台的兴起与爆发可以看到一种趋势，就是越来越多的企业无论是由于企业运营效率的原因还是由于创新发展的需要，对于企业全局视角跨业务线的能力沉淀都提高到了前所未有的战略高度。

---

能力

提到中台，最常听到的一个词就是「能力」。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。

企业的能力可能包含多个维度，常见的例如计算能力，技术能力，业务能力，数据能力，AI能力，运营能力，研发能力……其中大部分的能力还可以继续细化和二次展开，从而形成一张多维度的企业能力网。

可以说，中台就是企业所有可以被「多前台产品团队」复用能力的载体。

这里有一个经常碰到的问题，就是对于某一家企业来讲，你说了有这么多种不同类型的能力，到底哪些能力才是我们企业需要的？哪些是值得中台化的？优先级又怎么划分？

这个问题比较大，也很难有一个统一的答案。我们ThoughtWorks现在的做法是通过一系列Workshop，从业务、数据、技术三个方面切入，通过一系列方法，结合企业愿景，市场定位和数字化现状，跨越多条业务线，试图将企业需要的能力和可复用的能力识别出来，并为落地做好规划和准备。

这些会在后续写到中台如何落地的文章时再详细展开。

---

复用

讲到这儿，相信大家一定有一个疑惑，无论是说企业级，多前台产品团队，还是讲能力沉淀，都不是什么新话题。很多企业组件化，服务化，平台化搞了好多年，那「中台」到底有哪些新的启发？

我的答案就是对于「复用」的关注被提高到了一个前所未有的高度。

虽然我们一直讲「去重复用」讲了很多年，但仔细想想，大多平台化建设会将重点放在「去重」（消除重复）上，而对于「复用」则没有足够的关注。

很多企业都号称已经建成了各种各样成熟的平台，但是我们问心自问一下，有多少平台是业务驱动的？有多少前台产品团队又是自愿将自己的产品接入到平台上的？有多少平台建设者是在真正关注前台产品团队的平台用户体验？

「去重」讲的更多是向后看，是技术驱动的；「复用」讲的更多是向前看，是业务驱动和用户驱动的。

所以「去重」与「复用」虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同，做到「去重」已然非常困难，关注「复用」的就更是寥寥无几，所以：

• 「复用」是中台更加关注的目标；
• 「可复用性」和「易复用性」是衡量中台建设好坏的重要指标；
• 「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。
  
  
  

而实现更好的复用，常常改进的方向有两个方面：

• 一方面将更高抽象（例如业务模式级别）的通用业务逻辑通过抽象后下沉到中台，这样前台就会更轻，学习成本和开发维护成本更低，越能更快的适应业务变化；缺点是，抽象级别越高，越难被复用，需要架构师对于各业务有深入的理解和非常强的抽象能力。
• 另一方面就是通过对于中台能力的SaaS化包装，减少前台团队发现中台能力和使用中台能力的阻力，甚至通过自助式（Self-Service）的方式就快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。
  
  
  

---

平台

这里的平台主要是区别于大单体的应用或是系统。

传统的企业数字化规划更多的是围绕业务架构，应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划，例如要采购或是自建哪些具体的系统，例如ERP、CRM等。

当然这个过程并没有什么问题，可以理解此时这些独立的系统就承载了企业的各种能力，由于企业各业务线统一使用一个应用或系统，也自然实现了能力的复用。

但问题常常出现在两个方面：

• 一个是大单体系统的业务响应力有限，缺少「柔性」，当业务发展到一定阶段后，必然产生大量定制化需求，随着内部定制化模块的比例逐渐上升，响应力成指数下降，成为业务的瓶颈点。
• 另一个则是系统间的打通通常比较困难，容易形成业务孤岛和数据孤岛；
  
  
  

所以越来越多的企业开始像互联网学习，以平台化的方式重塑企业IT架构，从而对于业务提供足够的「柔性」，来满足对于业务的快速响应和复用的需求。

---

总结

「企业级能力复用平台」这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得如上文所述的这个定义背后所代表的意义是目前对中台价值的最贴切的阐释：

* 「企业级」定义了中台的范围，区分开了单系统的服务化与微服务；

* 「能力」定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；

* 「复用」定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；

* 「平台」定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细力度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。

有了定义后，如何建中台的思路也就豁然开朗：如果说中台是「企业级能力复用平台」的话，那中台化就是「利用平台化手段发现、沉淀与复用企业级能力的过程」，再回头看看这两年做的事情，确实也都在围绕着这些展开。

这就是我对中台的定义，如果你有不同观点或是意见，欢迎留言一起探讨。