2.2 下半场对原研发模式的考验

在学习完互联网上下半场的业务特征后，我们已经知道中台并不是互联网企业在一开始就有的，而是基于“前台+后台”的架构演变而来的。

那么在正式开始讨论之前我们要搞清楚一个误区，之所以越来越多的企业都开始布局中台的建设，并不是因为原来的前后台模式在研发架构上无法再支持眼下互联网出现的种种新业务场景，如企业服务、多平台战略等。

事实上前后台模式反而是公司最省时、省力的一种面向新业务场景的解决方案。因为这种业务模式在整个系统建设中不需要我们过多地思考系统的拓展性，我们只需要按照实际业务量的大小将业务交由后台系统做好对应需求的计算逻辑，并在前台完成定制化的信息展示，就做成了一个产品。可以说系统中没有一点“多余部分”的研发，从而为企业节省了大量的研发人力。

比如，现在我们需要为某餐饮企业的100家门店制作一套收银系统，在前后台设计模式中只需要考虑这家企业的偏好，如企业希望在首页展示今日收入总额，那么我们就在设计中将首页内容固定为今日收益内容，不需要再考虑企业想让首页显示别的信息时系统要如何去支持，所以说这种模式反而大大简化了研发一个业务系统的工作量。

既然如此，为什么各大巨头还需要急匆匆地寻找前后台的替代物呢？这背后还真有些内容需要我们仔细揣摩一下。

2.2.1 前后台模式的根本弊病

在第1章，我们其实已经总结出了互联网下半场业务模式的3个特征：

以企业服务为业务核心对象。

渠道中间商的新价值。

千人千面的业务。

这里我们可以先从第一个角度来回答刚提出的问题。原因就是业务的主要矛盾发生变化了，我们的产品由标准化产品变为以用户为单位的定制化产品，此时为了抢夺市场资源，每个定制化产品都需要快速迭代、落地终端。

怎么证明这个变化呢？这里我们要先引入一个概念——功能生命周期，也就是单一功能从研发上线到再次迭代的时间。通过这个概念我们可以衡量一个产品功能对应的特定用户群体的需求变化情况，时间越短说明用户需求变化越快。

例如，我们要为现有的OA系统新开发一个财务报销审批模块，以供企业员工在线上完成外出报销。

虽然说在初期产品经理已经完成了对客户群体的调研并采集了需求，但是当该模块真正上线后还是会出现两种可能情况。

一种情况是这个模块在推广过程中一直没有用户提出意见，说明用户接受度高，本模块能解决目前这些企业内部的报销问题。

而另一种情况在B端市场非常常见。当我们每新增一个企业用户时都会有新的需求被提出，如能否增加附件在线编辑、多人会签、审批流程自动去重。此时我们需要针对本模块进行迭代并增加新的功能，这其实就意味着原来的功能生命周期变短了。

之所以我们要了解这个概念，就是因为在消费互联网与产业互联网中一个功能的生命周期长度发生了巨大的变化。

让我们分别选择C端市场的某电商平台与B端市场的某OA软件作为案例来做个对比，这两个应用的版本迭代记录如图2-2所示。

从这两个App的版本迭代记录中我们能看到，该电商平台中的“特卖商品”功能从上线到历次改版的平均间隔时间为6个月，即该功能生命周期为6个月。

也就是说，虽然我们看到的很多电商平台中特卖专区每天的活动文案与活动商品内容都不一样，但是这些都只是内容的更新，在这背后的功能框架却是不变的。

再来看某OA软件中的“企业云盘”功能，平均每次功能迭代的间隔时间为2.75个月，即该功能生命周期只有2.75个月。

所以不难发现，产业互联网最显著的体现就是任意版本的功能生命周期缩短了，就像这个案例中由6个月缩短为2.75个月。可以想象，除了用户需求的变化越来越多，市场中同一行业的竞争者也越来越多。这些都逼迫着每家互联网企业不断去快速更新产品来更好地满足用户需求。

而就是这样的产品生产节奏恰巧暴露了前后台模式的根本弊病：响应速度太慢。

这是为什么呢？让我们再来看看传统的前后台生产流程，在绝大多数企业的前后台模式中生产流程都采用的是烟囱式架构，如图2-3所示。所谓烟囱式架构，也就是垂直项目体系结构，每当公司内部启动一个项目时，所有的服务都是从底层开始建立的。

例如，一家原来从事国内业务的自营电商公司由于业务的发展涉足海淘业务模块时，以往我们的做法就是成立一个新的项目组去从零开始开发，此时这个项目组需要采购独立的服务器资源，甚至项目负责人在看完之前的自营业务模块后，发现原有流程和模块体系与现有的业务有众多不同，往往会选择从零开始研发一套新的业务系统。

例如，由于国外产品在折扣描述上与国内的习惯是不同的，如“-20%”等于国内的“打八折”，此时想要套用原系统就面临很多业务不兼容的问题。于是便重新开发商品中心、订单中心、会员中心，并成立独立的数据中心。这样导致在公司内不同的项目不共享资源，更不能互相访问调用资源，这样的项目就像烟囱一样树立在公司内，每个项目变为一个个的资源孤岛和信息孤岛。

大家可以回忆下自己所待过的公司在新项目上马时是不是这样的情况。

我们从图中可以看到，在这样的架构下，每个项目的底层支撑部分都是独立建设的，但是实际上对于一个产品来说，用户真正能接触到的部分只是前台业务，如App、小程序、网站等。这就造成了当我们要研发一个新产品时，大量底层支撑部分的建设工作与等待时间对用户来说是“无效工作”，因为真正应该快速迭代的功能核心只在于前台部分，只有这样用户才能感知到，用户是不可能为你的系统底层架构建设而买单的。

举例来说，前后台模式中，我们的一个电商网站由于用户前台需要组织各种新的销售方式（如拼团、一元购等），所以在每次活动页面开发的时候不仅需要前端重新设计页面，而且后台的服务接口与数据表都要重新设计。

这种架构让公司内部每次开发一个新业务都需要从底层的工作开始，这样导致很多底层服务的重复建设，并大大增加了开发时间。这无疑拉长了我们的需求响应时间，造成的局面就是在某些时候活动模块还没开发完成，我们的热点风口就已经过去了。

因此对于现在的模式来说，各大公司需要的是一个最少改动底层或只开发上层就能应对绝大部分需求的新的解决方案。

2.2.2 前后台模式下的发展瓶颈

接下来我们来谈论第二个原因，实际上是因为公司业务发展到某一阶段时，在推进多条业务线并行发展时遇到了瓶颈，此时为了解决如何继续朝前走的实际问题而不得不去探索前后台如何更便捷配合的新解决方案。

那么，这里的发展瓶颈又要如何理解呢？具体来说可以分为这3点。

（1）公司内外发展冲突

还拿前文的收银系统案例来说，在业务初期这个系统可能只面向餐饮行业，所以我们的收银系统都是依照餐饮业务场景进行设计的。但是随着企业市场的扩张，我们的这套系统需要面向零售行业进行推广。此时，我们要如何针对零售流程去改造收银系统？是一切都从零开始建设一遍，还是将原餐饮行业的收银系统剔除面向餐饮行业的特殊化功能后将剩余部分迁移过来进行二次开发？

大家可以看到，对这两种方案，我们都或多或少需要对原有业务系统进行改造，这里还只涉及公司原有业务进入一个新的细分市场，而当我们需要同时投放多个市场时又要如何高效地进行呢？这种公司外部需要快速迭代而内部每次迭代都需要“伤筋动骨”的冲突是我们存在发展瓶颈的根本原因。

（2）“前台+后台”的齿轮速率匹配失衡

在前台业务不断变化的过程中，为了能予以支撑，后台必须提供对应的接口与进行数据持久化。而在这个大背景下由此带来的矛盾就是：以往为了支撑前台越来越多的业务，后台在建设中不断通过模块化设计来追求服务稳定性，这种设计模式反而会导致系统越来越庞大，同时这样的后台变得越来越没法去快速响应前台业务调整所带来的改变。此外，原来的这种前后台直接关联模式，也决定了后台响应不及时便会导致前台业务无法上线的现象出现。所以，两者的冲突也就不可避免了。

（3）公司内部的二次统一

众多管理学书籍都曾提到这样的一个概念：一个有战斗力的公司一定是二次统一的公司。

其中，第一次统一是组织架构上的统一，这个统一在每一位新员工加入公司时就已经自动完成了，也就是大家都归属同一家公司。

第二次统一是指思考角度上的统一，大家能否不计较个人利益得失，从公司大局方向去思考，以集体的需求为统一出发点。

而第二次统一在企业刚组建完成时其实是自动具有的。常见的例子就是在很多创业公司初期只有十来个人时，这些初创的非核心员工由于受到创始人的热情感染，往往能做出很多令常人瞠目的事情，比如我见过的某创业公司里一位普通员工在出差时为了给公司省钱甚至自发到网吧度过一个夜晚。

但是当企业发展到一定阶段后，随着业务规模的扩大，其内部的组织规模也出现了极速的膨胀。最终会出现一个公司包含多条独立业务线的情况，每条业务线就像一个独立群落一样在公司内“圈地为王”。而当企业膨胀到这种组织体系后初始的第二次统一就消失了，开始普遍出现组织行为学里非常经典的“屁股决定脑袋”的现象，也就是每个部门在决策时只会从本部门利益出发。换言之，如果出现一个能对公司有好处但对部门的关键绩效指标（KPI）没好处的事情，部门的负责人是绝对不会去做的。

所以各个部门的这种狭隘思想就很容易让企业内部的团队形成一个个隔离地带，让每个团队的人员、业务、数据这三要素只停留至该团队内部。这使得一些功能模块被不同事业部反复建设，当使用时还需要跨越多个部门去多次对接。结果就是，不仅无法快速完成产品迭代，还要耗费极大的开发成本。

所以从这个角度来说，中台的出现也可以说是互联网企业在管理学方面的集体提升。