白话中台战略 -1 开篇：中台是个什么鬼（三）

来，先定义一下前台与后台

因为平台这个词过于宽泛了，为了能让大家理解我在说什么，我先定义一下本篇文章上下文下我所说的前台和后台各指什么：

• 前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机 App，微信公众号等都属于前台范畴。

• 后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

后台并不为前台而生

定义了前台和后台，对于第二个问题（企业为什么要建中台），同样先给出我的答案：

因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题

大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。

我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。

总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。

有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个 2.0 问题不就解决了。

但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，以⽀持前台快速的创新需求。

此时的前台和后台就像是两个不同转速的⻮轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于⾯对的是相对稳定的后端资源，⽽且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好， 转速也自然是越慢越好。

所以，随着企业务的不断发展，这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。

随着企业业务的发展壮大，因为后台修改的成本和⻛险较⾼，所以驱使我们会尽量选择保持后台系统的稳定性，但还要响应用户持续不断的需求，自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”，用户满意度降低，企业竞争力也随之不断下降。

对于这样的问题，Gatner 在 2016 年提出的一份《Pace-Layered Application Strategy》报告中，给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。

而 Pace-Layered Application Strategy 也为“中台”产生的必然性，提供了理论上的支撑。

Pace-Layered Application Strategy

在这份报告中 Gatner 提出，企业构建的系统从 Pace-Layered 的⾓度来看可以划分为三类: SOR(Systems of record )，SOD(Systems of differentiation)和 SOI(Systems of innovation)。

处于不同 Pace-Layered 的系统因为⽬的不同，关注点不同，要求不同，变化的“速率”自然也不同，匹配的也需要采⽤不同的技术架构，管理流程，治理架构甚至投资策略。

⽽前面章节我们提到的后台系统，例如 CRM、ERP、财务系统等，它们⼤多都处于 SOR 的 Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核⼼可追溯单据(例如财务单据，订单单据)为主要⽬的。它们的变更周期往往比较⻓，⽽且由于法律律审计等其他限制，导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求，这就导致了它们往往变化频率低，变化成本高，变化⻛险高，变化周期⻓。⽆法满⾜由⽤户驱动的快速变化的前台系统要求。

我们又要尽力保持后台(SOR)系统的稳定可靠，⼜要前台系统(SOI)能够⼩而美，快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题，感觉鱼与熊掌不可兼得。

正当陷入僵局的时候，天空中飘来一声 IT 谚语：

软件开发中遇到的所有问题，都可以通过增加⼀层抽象⽽得以解决!

⾄此，⼀声惊雷滚过，“中台”脚踏七彩祥云，承载着 SOD(Systems of differentiation)

的前世寄托，横空出世。

我们先试着给中台下个定义：

中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。

中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。

中台很像 Pace-Layered 中的 SOD，提供了比前台（SOI）更强的稳定性，以及⽐后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。

有了“中台”这⼀新的 Pace-Layered 断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”⽀援。

所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台）。

总结

思考并回答了文初提出的两个关于中台价值的核心问题，解决了我对于中台产生的一些困惑，不知道对你有没有启发，让我最后再来总结一下：

1. 以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力，是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段，并不是⽬标本身。

2. 中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境， 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾，提供⼀个中间层来适配前台与后台的配速问题，沉淀能⼒，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应⼒。

3. 所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化，只是恰巧走在了了这条正确的⼤道上。

本文转载自健荐公众号。

原文链接：https://mp.weixin.qq.com/s/vBh76rQfGpnbm7eu0YbMNA