业务线扩充

软件架构从单体架构，到分布式 SOA，到微服务，到中台架构，这都是业务复杂化的结果，架构好比生产关系，业务是生产力，架构一定要随着业务发展而演化。

0 到 1 阶段，只有一条业务线，比如出租车业务，直接根据需求实现即可。从 1 到 n 阶段，业务线逐渐增加，比如快车 / 顺风车。

这时系统有两种做法，第一种是新业务线还是单独实现，多个业务线之家是相互独立的，系统结构整体上是”川”字型，如下图所示。但如果业务线类似，它们的核心逻辑（地图 / 调度 / 订单支付）也是类似的，子系统之间有大量的代码复制和多地维护，这是非常低效的。

第二种做法是把核心逻辑单独抽取出来，做好通用化，共同服务于所有业务线的需求，此时对于各个业务线系统而言，包括自身的应用层和通用层两部分，定制的东西在应用层解决，共享的东西由通用层提供，再通过编排共享逻辑完成业务流程。系统结构整体上是”山”字型，这个通用层就是山字最底下一横，把各个业务线有机粘合在一起，共享业务逻辑和统一业务规则，实现最大程度的复用。

当然搭建山字形是有难度的，什么时候转型为“山”字形？一方面和 n 值有关，比如 n>=3 时，应该要考虑转到山字形，另一个因素和各个业务线的相似度有关，相似度高更适合”山”字形，比如电商的 C2C 和 B2C 业务；差异比较大，适合”川”字形，比如电商业务和互联网金融业务，没必要强行扭在一起。

从业务角度看，中台代表通用的基础业务，一个企业基础的业务能力和业务规则是相对稳固和清晰的，各个业务线可以认为具体业务场景，如小程序下单 / 三方外卖等相对复杂和多变，但可以通过组装各个基础业务，快速满足业务场景需求。对于新的业务来说，基础的东西已经差不多有了，只需要少量针对场景的定制开发。总的来说，中台收敛了业务场景，统一了业务规则，比如各个渠道的订单都归到中台的订单服务，遵循类似的订单状态流转和履单过程。

基础业务是有限的，业务场景是无限的，特别是在移动互联网和全面数字化转型的大背景下，传统企业需要开拓大量新渠道，搭建中台，可以很好地通过有限的基础业务满足无限的业务场景。

从系统角度看，中台相当于商业操作系统，提供标准接口给上层应用，对于传统企业来说，中台之下还有明确的后台，中台很好地把前端应用 (面向互联网) 和企业遗留系统 (面向内部管理) 衔接起来，屏蔽底层系统的复杂性和各种适配工作。

从数据角度看，中台收敛业务场景的同时，也收敛了数据 比如自有小程序的订单和外卖订单统一到一个订单库，使用同一套数据模型（具体用到的字段可能略有差异），这为后续的数据中台搭建打下良好基础。

烟囱式平台

平台化解决了技术平台的问题，但是每个单元业务的执行都要跨多个领域来完成，复杂度会随之升级。比如说淘宝的宝贝，商品发布规则、交易规则、营销规则散落在各个系统中，进行一个动作时，无法做到靠一个人就能说清楚全局。结果就是一个需求要评估一个月，开发需要几天，测试又需要几天，这已经不是一个流程能够解决的，是一个比较复杂的生态协作问题。

“大中台”的概念就是从较为复杂的协作生态上来纵向地从服务链路来做资源整合，技术中台注重能力沉淀与整合，业务中台注重链路、效率、成本、流程优化。业务中台在我的眼里变成了规则引擎执行者与定制化服务输出方，规则的输出通过对数据的控制来进行。

大企业的很多业务在最初都会经历疯狂的扩张过程，在这个过程中由于各个 BU 自我闭环，导致大厂内部存在着很多重复造轮子的工作。比如同样在内容领域，独立 BU A 做了一款 App，独立 BU B 做了一款 App，都有很多详细功能。但是这些功能在内部的必要性又没有那么强，继续做存在着人力成本的浪费。这个时候我们会通过一个抽象出来的公共业务模块去单独处理。

虽然这个集团是某体系当中的巨无霸，但是在内容生态这块其实还是较为薄弱的，需要一个业务中台来支撑内容生态。当时的情况是：好几个事业群都有类似的生态业务在运作。比如南方某事业群有自己的图文内容生态，北方某事业群有自己的视频内容生态，各自的生态又分别为各自客户端业务提供内容生产审核，帐户体系、内容评定标准、奖励机制各不相同。具体到数据体系上，其中两个子集团或成为事业群的业务方都有各自的数据体系，造成的问题是：

• 账号没有打通，账号评估与分级体系不统一；
• 内容评定标准不统一、品类不统一、标签体系不统一、奖励机制各不相同；
• 审核问题，但凡做内容必须有审核，不同子公司在审核的投入上都很巨大；
• 采购问题，跟 BD 采购流程不同，或签约多个主体；
• 内容生态所涉及到的帐户数据、图文、视频、粉丝互动、内容库、消费数据、内容审核等较容易整合并服务化。

从集团角度来看，这就形成了烟囱式的建设。每一个烟囱的能力直接决定了业务的发展速度与业务创新的成本，但实际上业务的快速更新与创新更需要像乐高一样的体系去快速搭建。结合内容生态这个业务来看，根基与出发点是偏业务型的中台建设。实际上我们可以通过一点接入、多点分发的方式来支撑各端业务，做好内容生态供给。在建设过程中对信息、标准、帐户、数据做一系列打通，将业务流、内容流、分发流、数据流、商业流这些相近的单元进行业务中台化。