中台，可以说是当下IT圈最火的概念。然而，后台、中台、前台等概念总是让人眼花缭乱，业务中台、数字中台不同分类也让人头大。为此，笔者将科普一些中台的基本概念。
 
定义：中台不同于后台、前台
 
在以往的IT企业生产流程中，我们可以将研发团队宏观的划分为前台与后台两部分。
 
用户直接接触到、且有一定认知的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等，称为前台。而后台则是为了支撑前台运作、由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。
 
中台既不同于前台，也不同于后台，那中台到底是什么呢？如果说前台是为了展示，后台是为了效率，那中台就是为了创新。因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。不过，无论是后台、中台还是前台，其初衷都是以用户为中心的持续规模化创新，希望在快速发展的数字经济中占据重要地位。
 
而引发中台旋风的正是阿里巴巴于2015年提出的“⼤中台，⼩前台”战略。说到这里，引用阿里巴巴对中台的定义：“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”
 
所谓中台，其本质是以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系。
 
初衷：前后台之间的“变速齿轮”
 
为何现在企业纷纷建立“中台”，当然是由于现有的后台与前台满足不了企业需求。从企业现状来看，要么前台不好用，或者用不了；要么后台变更速度跟不上前台的节奏。我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。
 
然而，这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
 
此时的前台和后台就像是两个不同转速的⻮轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于⾯对的是相对稳定的后端资源，⽽且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好，转速也自然是越慢越好。
 
所以，随着企业务的不断发展，这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。而中台的诞生正好解决这一问题。中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
 
分类：能力是评判中台的唯一标准
 
IT圈，往往是什么概念火，企业就套用什么概念。平台、微服务等概念甚嚣尘上，往往让人分不清真伪。其实，甄别是不是中台，还要回到中台要解决的问题，即一切以”以用户为中心的持续规模化创新”为目的，将后台各式各样的资源转化为前台易于使用的能力，帮助我们打赢这场以用户为中心的战争的平台，我们都可以称之为中台，例如：
 
业务中台提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大；
 
数据中台提供了数据分析能力，帮助我们从数据中学习改进、调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场；
 
移动及算法中台提供了战场一线火力支援能力，帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；
 
技术中台提供了自建系统部分的技术支撑能力，帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；
 
研发中台提供了自建系统部分的管理和技术实践支撑能力，帮助我们快速搭建项目、管理进度、测试、持续集成、持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队；
 
组织中台为我们的项目提供投资管理、风险管理、资源调度等，是战场的指挥部，战争的大脑，指挥前线，调度后方。
 
所以，评判一个平台是否称得上中台，最终评判标准不是技术，也不是长什么模样，还是得前台说了算，毕竟前台才是战争的关键，是感受得到战场的残酷、看得见用户的那部分人。
 
前台想不想用，爱不爱用，好不好用；帮了前台多大的忙，从中台获得了多大的好处，愿意掏出多少利润来帮助建设中台，这些才是甄别中台建设对错好坏的标准。对于中台来讲，前台就是用户，以用户为中心，在中台同样适用。
 
总结一下，看到这里，你估计对中台有个大概了解。中台是建立在业务之上，为了避免公司发展过程中重新搭建架构，资源浪费问题，从而搭建中台系统完美解决重复造轮子问题。
 
今年，很可能成为"数据中台"的元年。同时，关于数据中台的整体定义，也会随着头部企业落地而逐渐清晰。据知名调研机构Canalys2019年2月的相关数据报告，未来10-15年，“数据中台"或将形成一个万亿级市场，同时中国也将诞生1-2家SAP级别企业

 
 


 
导读：阿里巴巴的中台战略最早从业务中台和数据中台开始，采用业务和数据中台相结合的双中台建设模式。后来又有人提出了各种各样的其他中台，比如技术中台、AI中台等，不一而足。
 
其实不少企业在很多年前就已经有了建设大平台的实践经验。在中台被热议的当下，相信你一定听过很多对中台的质疑声。
 
比如，有人说：“中台就是个怪名词，它不就是已经做了好多年的平台吗？”
 
确实！中台源于平台，但它的战略高度要高于平台。
 
本文希望你能清楚平台与中台的主要差异是什么，中台到底是什么，传统企业的中台建设策略是否应该和阿里一样等内容。
 
作者：欧创新 邓頔
 
来源：大数据DT（ID：hzdashuju）
 

 
01 平台是中台吗
 
在阿里巴巴完美落地中台战略后，很多企业开始与阿里的中台对标。其中有不少企业在十多年前就完成了大一统的集中式系统拆分，实现了从传统大单体应用向大平台的演进，他们也按照业务领域将公共能力和核心能力分开建设，解决了公共功能模块重复投入和重复建设的问题。
 
那这是不是阿里所说的中台呢？在回答这个问题之前，我们不妨先了解一下阿里的中台到底是什么样的。
 
阿里业务中台的前身是共享平台，而原来的共享平台更多是被当作资源团队，承接各业务方的需求，并为业务方在基础服务上做定制开发。
 
阿里业务中台的目标是把核心服务链路（会员、商品、交易、营销、店铺、资金结算等）整体当作一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。这种能力有别于传统的烟囱式的系统建设方式。
 
有些企业的IT人员说：“我们系统很多，功能很强大，所有业务点都有系统支持，但为什么业务人员总抱怨系统做得不够好，业务响应不够快呢？”
 
其实这是一个很多企业都在讨论的、应用“可用”与“好用”的话题。抛开商业模式的原因，问题根源很有可能出在系统的共享、联通和融合能力上。在进行应用建设时，有些人可能会站在部门或个人利益的角度，特别强调和关注应用的局部“可用”，却忽略了企业级业务和流程的整体“好用”。
 
有的企业由于缺乏总体规划，应用建设目标不够明确，加上天然的组织架构、数据和业务边界，很自然地就出现了明显的系统边界和系统重复建设的问题，难以支持企业级业务能力的快速融合，不能快速响应企业级业务和商业模式创新，对前台一线业务支持和融合也不够好，难以在前台形成一致的用户体验，最终影响企业业务发展。
 
这种问题在业务领域分布广泛的大型集团级企业可能会更加突出。而对于大型企业而言，要想解决从“可用”到“好用”的问题，其实还有很长的路要走。
 
下面我们来分析一下传统企业大平台战略和阿里中台战略的主要差异。
 
传统企业的很多平台只是将部分通用的公共能力独立为共享平台。这类平台虽然可以通过API或者以数据服务的形式对外提供共享服务，解决系统重复建设的问题，但它们并没有与企业内的其他平台或应用实现从前端到后端的页面、业务流程和数据的全面融合，没有将企业核心业务服务链路作为企业级解决方案来考虑。各平台仍然是分离且独立的，本质上仍然是烟囱式建设模式。
 
可见，项目级的平台虽然解决了公共能力复用的问题，但与企业级中台的建设目标显然还有一定差距！
 

 
02 中台到底是什么
 
“一千个读者就有一千个哈姆雷特”，用这句话形容技术圈对中台的理解再合适不过了。这也说明了大家对中台的定位和理解还存在很大的争议。
 
我们先看一下阿里对中台的定义：
 

  
中台是一个基础的理念和架构，我们要用中台的思想建设、联通所有基础服务，共同支持上端的业务。业务中台更多的是支持在线业务，数据中台则提供基础数据处理能力和很多的数据产品供所有业务方使用。即由业务中台、数据中台、算法中台等一起提供对上层业务的支撑。
 
 
再看一下ThoughtWorks对中台的定义：
 

  
中台是企业级能力复用平台。
 
 
综上，我们可以提炼出几个关于中台的关键词：共享、联通、融合和创新。联通是前台以及中台之间各业务板块的联通，融合是前台企业级业务流程和数据的融合，并以共享的方式支持前台一线业务的发展和创新。
 
我认为，中台首先体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团，大到生态圈的能力共享、业务联通和融合的问题，支持业务和商业模式创新。通过平台联通、业务和数据融合，为前台用户提供一致体验，更敏捷地支撑前台一线业务。
 
中台来源于平台，但与平台相比，中台更多是一种理念的转变，它主要体现在这三个关键能力上。
 
对前台业务的快速响应能力。
企业级的复用能力。
从前台、中台到后台的设计、研发、页面操作、流程、服务和数据的无缝联通、融合能力。
 
其中最关键的是业务快速响应能力和企业级无缝联通及融合能力，尤其是对于跨业经营的超大型企业来说，这种能力至关重要。
 
03 传统企业中台的建设策略
 
与传统企业不同，拥有流量入口的超大型互联企业是互联网生态圈的创造者，而传统企业只是生态圈种群中的个体，除了需要做好原有的传统渠道业务外，还需要融入互联网生态圈，其商业模式、个体能力，以及与其他个体共生的能力决定了它的发展潜力。
 
相对互联网企业而言，传统企业的渠道应用更加多样化，有面向内部人员的门店类应用、面向外部用户的互联网电商以及移动App类应用。这些应用面向的用户和场景可能不同，但其功能与产品同质化严重，基本涵盖了企业的核心业务能力。
 
此外，传统企业也会将部分核心应用的页面或API服务能力开放给生态圈第三方，实现业务的优势互补，相互借力发展。
 
为了适应不同业务和渠道的发展，过去很多企业的做法是开发很多相互独立的应用或App。但由于IT系统建设初期并没有企业级的整体规划，平台之间融合不好，直接影响了用户体验，归根结底是用户并不想安装那么多App。
 
为了提升用户体验，实现统一运营，很多企业开始缩减App的数量，在一个App中集成企业内的所有能力，联通前台所有的核心业务链路。
 
由于传统企业的商业模式和IT系统建设发展的历程与互联网企业不是完全一样的，因此传统企业的中台建设策略与阿里中台战略也会有所差异，中台需要共享的内容也不太一样。但是传统企业的中台建设策略与阿里的中台建设策略基本相同，都需要从业务中台和数据中台这种双中台的模式开始建设，如图1-1所示。
 

 
▲图1-1 “业务+数据”双中台建设模式
 
我们来分析一下企业中台的能力建设过程。企业中台业务能力建设一般会经历“分”和“合”两个过程。通过将企业可复用的能力沉淀，形成多个不同业务领域职责单一的中台领域模型，然后对这些不同类型的中台业务能力进行组合和编排，形成企业级业务能力，从而在企业领域模型的“稳”和商业模式与业务流程的“变”中找到最佳平衡。
 
“分”的主要目标是通过业务领域边界划分和微服务拆分，建立稳定的、单一职能的领域模型，让业务和应用具有更强的扩展和复用能力。但分不是目的，而是手段，是根据单一职责原则实现业务能力的复用和高内聚。
 
分的过程主要发生在业务中台，在完成业务领域和微服务拆分后，降低了应用建设的复杂度，使业务和应用具有更强的扩展能力和稳定性。
 
在完成业务能力拆分后，我们还需要对这些拆分后的、稳定的、可复用的核心领域能力进行组合、编排和融合，形成企业级能力，从而灵活快速地适配外部业务和流程以及商业模式的变化，这是“合”的过程。
 
“合”包括业务融合和数据融合。业务融合主要作用在前台，实现企业不同业务板块能力的联通、组装和整合，实现企业级业务流程的融合，提供一致的前台用户体验。而数据融合则主要作用在数据中台，实现企业不同业务板块数据的汇集、集成、智能分析和商业模式创新等，为企业前台业务提供统一的智能化数据服务。
 
在进行业务领域划分和中台设计时，由于渠道多样化，传统企业不仅要将通用能力中台化，以实现通用能力的沉淀、共享和复用（这里的通用能力对应DDD的通用子域或支撑子域），还需要将核心能力中台化，以满足不同渠道的核心业务能力共享和复用的需求，避免传统核心和移动互联等不同渠道应用之间出现“后端双核心、前端两张皮”的问题（这里的核心能力对应DDD的核心子域）。
 
上述这些都属于业务中台的范畴，需要我们解决核心业务链路的联通和不同渠道服务复用的问题。
 
注意：“后端双核心、前端两张皮”主要是指IT重复建设的问题。
对于相同的核心业务领域，传统核心应用和移动互联应用分别采用不同的技术栈重复建设，出现传统应用和移动互联应用两个核心。而两者在前端技术栈和展现方式又完全不同，无法复用。
 
除此之外，我们还需要解决微服务拆分后的数据孤岛、数据融合和业务创新等问题，这就属于数据中台的范畴了，尤其是当我们采用分布式微服务架构以后，就更应该关注微服务拆分后的数据融合和共享问题了。

 
综上，在中台设计和规划时，我们需要整体考虑企业内前台、中台以及后台应用的协同，实现不同渠道应用的前端页面、流程和服务的共享，还有核心业务链路的联通以及前台流程和数据的融合、共享，以支持前台一线业务和商业模式创新。
 
关于作者：欧创新，某大型保险公司架构师，拥有十多年的软件架构设计经验。热衷于DDD、中台和分布式微服务架构设计。在DDD、中台和分布式微服务架构设计方面有深厚的积累，擅长分布式微服务架构设计。
 
邓頔，某大型保险公司高级工程师，全国青年岗位能手。致力于基于DDD的企业级中台微服务架构改造实践，精通前端开发相关技术栈，拥有丰富的企业级微前端实战经验。
 
本文摘编自《中台架构与实现：基于DDD和微服务》，经出版方授权发布。
 
延伸阅读《中台架构与实现》
 
点击上图了解及购买

 
转载请联系微信：DoctorData
 
推荐语：资深架构师撰写，系统阐述基于DDD的中台和微服务建设方法论，深刻揭示中台从领域建模到微服务落地完整过程。
 

 
划重点????
 
干货直达????
 
重磅盘点：2020年50万大数据DT用户最爱的10本书
中国游戏大数据：市场规模全球第一，直播已进入黄金期
终于有人把标签设计讲明白了
终于有人把业务中台、数据中台、技术中台都讲明白了
 
更多精彩????
 
在公众号对话框输入以下关键词
 
查看更多优质内容！
 
PPT | 读书 | 书单 | 硬核 | 干货 | 讲明白 | 神操作
 
大数据 | 云计算 | 数据库 | Python | 可视化
 
AI | 人工智能 | 机器学习 | 深度学习 | NLP
 
5G | 中台 | 用户画像 | 1024 | 数学 | 算法 | 数字孪生
 
据统计，99%的大咖都完成了这个神操作
 
????
 

 
 

有一个事情已经困扰我很久了——大中台、小前台作为战略已经提出很久了，在业界也掀起了不小的波澜，可是反观阿里的业务中台，为什么总觉得旁边有朵小乌云，感觉哪里不对劲。
 
业务中台小乌云
 
建一所房子，你要挖坑打地基，铺钢筋，然后一块砖头一块砖头的往上磊。没办法，原子世界就是这么物质，一块砖头都少不了。软件是比特世界，软件开发很少是从买服务器开始，特别是在这个Cloud Native的时代，很多基建的事情云厂商都已经帮我们做好了。IaaS是对算力、网络、存储、操作系统等基础设施的复用；PaaS是对中间件的复用；
 
 
 
基于这样的演进路径，有没有可能做一个Business-PaaS（业务中台）， 提炼出业务共性的东西，让前台业务少做点事情，提升研发效率呢？
 
单看上面的图示，这个逻辑似乎是通的。于是乎，在“大中台、小前台”的大旗帜下，星环诞生了。可是不管是从一线研发同学的反馈，还是高层的质疑声，都在表明星环似乎并没有解决问题，反而是制造了更多的阻碍、困难，这是为什么呢？
 
业务中台的困境
 
中台战略没有错，大中台也没有错，什么技术中台、数据中台都没问题，为什么到业务中台就有问题了呢？我想问题就出在这个“业务”身上。
 
IaaS也好，PaaS也罢，之所以能提效是因为其业务无关性，它们和业务的边界很清晰，彼此正交，互不干扰。IaaS、PaaS解决的是技术问题，业务解决的是业务问题。（偶尔PaaS也会侵入业务应用，为了与应用隔离解耦，于是有了PandoraBoot、Service Mesh等技术）
 
业务中台却没有这样的好命，它解决的是复杂、多变的业务问题，如果你拉近距离看业务和业务中台的关系，就会发现，他们并不像上图描绘的那样，中间有一道清晰的边界线，而是犬牙交错的耦合在一起：
 
 
 
前台业务要借助业务中台一起去完成业务逻辑，所以是有一部分埋在业务中台里的，至于埋得有多深，取决于使用中台能力的多少，用的多就埋的深，用的少就埋的浅。
 
因此，业务中台低效的根因，用一句话来说，就是因为前台业务和业务中台的“深度单体耦合”。这种耦合性，至少在三个方面严重影响了整体的研发效率：
 
协作成本
 
研发≠写代码，实际上我们大部分时间不是在写代码，而是在沟通协调上。而且跟人打交道要比跟机器打交道要麻烦的多。这也是为什么《人月神话》中会说加人只会让项目更糟糕的原因，因为你额外增加了更多的协作成本。
 
因为中台的深度介入业务，导致组织协作成本倍增，详细分析可以参看 复杂组织下协作成本倍增的起因、影响及可能的解
 
除了组织协作成本倍增之外，因为耦合带来的工程协作成本也很高，试想一下如果几百个研发人员在同一个代码库上修改代码、部署，会是怎样的体验。
 
以下是一个同学的真实反馈：
 
 
 
“星环在外面宣传的是业务方7*24想发就发，实际远远做不到，很多限制，效率很低，体验过才知道多恶心。”
 
 
认知成本
 
整个星环体系不可谓不复杂，里面有一堆的新概念——业务身份、活动（Activity）、领域服务（Domain Service)、领域能力（Ability）、扩展点（ExtensionPoint），扩展实现（Extension）、奥创、Lattice、业务容器...
 
通过下面新人的日报片段，可以感受下其高昂的认知成本。
 
 
 
KISS是一种美德，正如尼古拉斯所说：
 
 
 
“在现代生活中，简单的做法一直难以实现，因为它有违某些努力寻求复杂化以证明其工作合理性的人所秉持的精神。”
 
 
稳定性成本
 
《反脆弱》里说：越是精巧的东西越脆弱。
 
现在的业务中台很精巧，同时也很脆弱。跟所有的“Big design up front”犯了同一个错误，即忽视了unknow unkowns。业务的灵活性、差异性，导致我们很难提前抽象，因为抽象是归纳之后的抽象，可是新的业务需求还没出现，你让我怎么归纳，怎么抽象？
 
理想的情况是我能预见所有的业务变化，提前做抽象，把所有的业务扩展点都预留好，这样不同的业务只需要在扩展点中定制就好了。但没人能预见未来，难免会动到平台代码，加一个扩展点啥的，因为平台代码是被所有业务共享的，这就给稳定性带来了极大隐患。会出现A业务改了平台代码，B业务啥事也没做，就出了故障。
 
这就是为什么对稳定性要求比较高的业务场景，比如APOS，宁愿冗余代码，也不愿被动出故障。实际上，代码冗余（Repeat）也是一种代码复用（Reuse），在很多情景下，Repeat是解耦更彻底，更简单高效的做法。比如在写测试代码的时候，用copy-paste的方式去准备测试数据就是很好的解耦方式，通过代码的Repeat，可以更好的隔离不同test case之间的相互影响。
 
总之，在精巧的、不稳定的复用和简单、高效的重复之间，后者会是一个不错的选择。软件架构无其他，只是权衡（trade-off）。DRY（Dont Repeat Yourself）和Decoupling（解耦）都是对的，选择哪种方案，应该是仔细权衡后的选择，而不应该是“拍脑袋”或基于”屁股“的选择。
 
可能的解决方案
 
针对上面的问题，如果让我来重新设计业务中台的话，我会尝试做以下事情：
 
把业务能力做薄。做薄是为了解耦，业务自己最懂自己的业务，不要尝试去control他们，放过他们，也放过自己。中台可以更多的关注在“业务无关”的能力建设上，比如稳定性、性能、监控、运维工具等非功能属性。
把中台能力做强。除了非功能属性，中台还可以通过建设丰富的业务解决方案库、业务组件库等工具，赋能业务快速发展，用enable代替control。
把系统结构做简单。复杂是万恶之源，星环太精巧了。
解耦
 
协作成本、稳定性问题皆是因为前台业务和业务中台的深度耦合造成的。因此，星环的这种集中式的代码管控和部署的“大单体”模式亟需得到解决。
 
其实解决方案大家都知道，解决“大”的问题就是分而治之，解决“单体”的问题就是服务化。
 
也就是说，前台业务和业务中台的关系，必须从代码和部署的耦合状态，变成分布式的服务关系，就像BPass这个名字所隐喻的一样，让业务中台真正变成服务（Business Platform as a Service）。
 
 
 
解耦不难，关键是这一刀要从哪里切？我个人认为这一刀可以切在“业务无关”这个切面上。
 
所谓的“业务无关”就是想办法在业务中台中找到和具体业务无关的内核（kernel）。这样可以最大程度的复用中台能力，又可以保持业务的灵活性。比如所有的业务都需要对数据进行CRUD操作，这个就是业务无关的，而业务的各种校验逻辑就是业务相关的。
 
当然，这个边界具体放在哪，还是要具体情况具体对待，但是肯定会比现在的业务中台要薄。
 
举两个例子，比较合理的方式可能会像这样：
 
商品业务：同样是电商业务，但是淘宝的商品、盒马的商品、零售通的商品之间可能存在巨大的差异。他们的扩展属性不一样，业务校验规则也不一样。这种情况就适合把中台做得很薄，让其退化成EJB中的Entity Bean。这也是业务中台的底线，即业务中台要做统一的数据收口，防止数据孤岛。
然而，即使是这样的薄中台也是极其有价值的，因为它帮助我解决商品的存储、存储扩展、性能、稳定性、工具（商品360、forest类目管控）、搜索构建等一些列和业务无关的非功能属性问题。说实话，这就足够了。
 
支付业务：支付业务的细节我不是特别清楚，但感觉在这里业务中台可以做得厚一点，因为像对接不同的支付渠道，建设统一的支付网关，很多业务都是存在这样的共性需求的。
简单
 
通过上面的解耦工作之后，星环这一套基本就可以deprecate掉了，因为业务中台只会保留“业务无关”的通用原子服务，自然也就不需要那套扩展机制了。
 
于此同时，因为前台业务和业务中台从之前的星环耦合关系，变成简单的服务调用关系、组件组合关系，系统的复杂度和认知成本也会极大的改善。这样前台和中台的同学就都解放了。
 
我相信，如果能按照这种“业务的归业务，中台的归中台”简单设计，边界清晰，职责清晰。不同BU的业务的演变、部署都在自己的掌控中，彼此正交、互不干扰，便可以极大的提升业务团队和中台团队的研发效能。
 
Platform as Code
 
简单不等于简陋，帮助业务快速奔跑的职责不能丢。
 
假如有这样一个场景，一个全新的业务需要启动，因为中台做薄了，之前在业务中台沉淀的业务能力很多都释放给业务自己了，中台要怎么帮助新业务快速搭建呢？
 
这里可以考虑借鉴DevOps里的IaC（Infrastructure as Code）的概念，我暂时给它起个名字叫PaC（Platform as Code）。
 
如下图所示，可以由中台的PD、研发同学设计一个针对不同业务场景的业务解决方案库。
 
 
 
具体的实现方式可以是Maven的Archetype，并用版本的方式进行迭代，这样针对一个全新的业务，业务方可以快速的通过Archetype，生成一个functional的业务应用。再由前端业务部署到自己的服务器集群，按需修改完成自己的业务诉求上线即可。之后需求变更时，业务方便可以按照自己的意愿，在自己的“一方乐土”上自由奔跑了。
 
实际上这也是一种Reuse（重用），只不过是用代码Repeat（重复）的方式在重用。这样做，可能会导致不同的业务代码之间出现一些代码冗余（实际上，有些业务为了快速发展、稳定性的考虑，已经在采用copy代码的方式，比如陶特、APOS）。但是请相信我，这点代码冗余，在稳定性、可理解性、可维护性、工程效率的综合权衡之下，会显得微不足道。
 
正如《Fundamentals of Software Architecture》一书中所说：“There is no best architecture, but the least worst architecture"。
 
Platform as Code + 组件库
 
在PaC的基础之上，再进一步，可以考虑组件化，即把一些共用的逻辑封装成组件，打造一个“中台组件库”，业务可以按需组合这些组件去实现业务，同时，业务也可以把自己沉淀的组件反哺给“组件库”，形成一个良性循环的“大集市”：好的组件会被大量使用、迭代和演化。不好的组件会被冷落，躺平。
 
 
 
然而，还是那句话，业务是VUCA（Volatility Uncertainty Complexity Ambiguity）的，很难标准化，如何设计组件，如何让组件和业务之间松耦合——即不要让组件绑架业务，困住业务的手脚，将会是一个蛮大的挑战，需要一些智慧。这也是为什么我一开始提出PaC的时候，没有提组件化的原因。
 
总之，不管是PaC也好，还是PaC+组件化也好。大的方向都是把“中台大单体”给拆了，让业务回归业务本身，让业务和中台解耦，让中台更纯粹，让业务更灵动，让同学更幸福！
 
 
 
作者：技术匠人
 
 
链接：https://www.toutiao.com/a6979126309251400228/?log_from=0925039662685_1627026131482
 

前言
 
 
 
中台建设，是近两年非常火热的一个话题，从产品中台，到技术中台，再到组织中台，各种概念、理念，以及方法论被深度的研究、探讨。
 
 
 
对于互联网产品领域来讲，中台更多的是2B产品建设中涉及的课题，因为软件系统的抽象复用，更多的是做复杂B端系统建设中面临的问题。因此，中台产品设计，是所有B端产品经理应该深度关注的课题。
 
 
 
针对B端产品设计领域，中台产品到底该如何设计？有何特点？设计的本质是什么？有何挑战？本文将从全新的视角，重新审视中台产品建设，让您更加深刻地理解中台产品设计精要。 
 
 
 
一、经典视角下的中台建设
 
 
 
首先，我们有必要回顾下经典的中台建设视角。一般来讲，行业内往往从组织中台、产品中台、数据中台、技术中台这四个主题切入并探讨中台建设。
 
 
 
组织中台：组织中台研究的是企业内部的组织结构设计，如何通过合理的权责划分，以及管理架构搭建，提高业务部门的经营能力，迅速响应市场变化，并且能够让企业提升整体跨部门跨业务线协作效率，降低运营成本，实现标准化管理。所谓组织中台的设计思路，实际上已经存在了很多年了，在集团企业中，往往采取事业部制的组织形态，再配合各种共享服务中心的建设，实现前后端业务分离，前端业务保持机动性，后端业务提供火力支援。类似于财务共享服务中心FSSC（Financial Shared Service Center），人力资源共享服务中心HRSSC（Human Rersources Shared Service Center），其实就是典型的中台管理思路下的组织形态和职能部门建设的方法，如下图。
 
 
 
 
一个常见的事业部制的组织机构图
 
 
 
产品中台：产品中台研究的是企业内部的软件系统如何进行抽象和设计，从而让企业的软件系统就像搭建积木一样灵活，可以重复高效利用现成的软件组件，快速组装开发出新的软件系统，从而节约软件开发成本，并能够快速支持新业务开展。很多文章也把这类中台产品称作业务中台，或业务中台产品。
 
 
 
目前被广泛讨论的产品中台包括电商交易中台、账号中心中台等，其中电商交易线又被更加广泛的探讨，包括了订单中台、支付中台、商品中台、促销中台等。
 
 
 
产品中台还有另一层含义，即能够给全公司全企业提供一致服务的管理软件产品，也可以纳入产品中台的范畴，例如呼叫中心、项目管理软件。从某种程度上来讲，这些标准化软件产品也是中台产品。
 
 
 
数据中台：数据中台研究的是企业内部的数据管理、治理问题，以及数据产品体系和数据底层结构的搭建问题。数据中台研究的范畴，包括企业统一的数据安全、数据规范、元数据管理、数据编码管理，以及数据仓库、数据集市的拓扑架构，也包括大数据底层和运算能力建设和复用。要注意的是，数据中台更多的关心从业务和产品层面对数据的治理、管理、应用，而非技术层面问题。
 
 
 
技术中台：技术中台研究的是软件产品的技术实现过程中，哪些技术上的处理能力和架构可以进行抽象复用，例如消息中间件MQ，分布式计算框架Hadoop，分布式服务框架HSF，各种Open API等等。技术中台是纯粹从技术实现底层来思考基础服务和基础模块的复用能力，其设计思路和产品中台一脉相承，是技术人员需要深度思考的问题。
 
 
 
以上四个主题，涵盖了互联网模式下对于企业中台建设的所有课题范围，其中，对于产品经理来讲，工作相关性最强，最需要关注的是产品中台和数据中台。
 
 
 
实际上，上述四个主题，也正是传统企业信息化建设中非常核心的企业架构EA（Enterprise Architecture）理论，对企业业务管理的IT视角下的切分。其中组织中台对应EA中研究的企业业务架构EBA（Enterprise Business Architecture）中的组织架构治理部分，产品中台对应EA中研究企业应用架构的EAA（Enterprise Application Architecture），数据中台对应EA中研究企业数据架构的EDA（Enterprise Data Architecture），技术中台对应EA中研究企业技术架构的ETA（Enterprise Technology Artchitecture）。
 
 
 
关于EA的论述，可能让很多纯互联网背景的同学读起来很困惑，但实际上，互联网企业所谓的中台建设思路，逃不出经过几十年沉淀的信息技术理论框架，以及管理理论框架。而传统信息技术理论，在互联网企业的B端产品建设中具有极强的参考、借鉴价值。
 
 
 
然而，我们今天讨论的主题，还不是研究企业架构EA对中台建设的指导，而是尝试从更加深层次的角度，去探索产品中台、数据中台的设计本质，尤其是对于B端产品经理来讲非常核心的产品中台的设计精要。
 
 
 
对于产品中台，目前公认的关键要点包括如下关键词：企业级、抽象、下沉、复用，这些关键词代表了产品中台建设的特点，同时也是在企业应用架构设计中需要深层次思考的问题。（所谓企业应用架构，是指企业内部的各个软件系统，应该以什么样的形式建设、组合，从而高效的支持企业的经营运作）
 
 
 
因此，如果要深层次的思考软件产品的企业级抽象、下沉、复用问题，可以从以下三个角度进行全新的审视，分别是：基于抽象复用的视角，基于架构合理性的视角，基于业务统一管理的视角。
 
 
 
我们通过从这三个视角切入，可以全面的解构中台产品设计的要义，并且可以更加全面的穷举中台建设的方法论、要点和难点。
 
 
 
二、基于抽象复用的视角建设中台
 
 
 
1、建设的目的
 
 
 
 
 
所谓抽象复用，是指对软件中重复的功能和模块进行抽象并下沉一层。
 
 
 
什么叫抽象？什么叫下沉？我们举例说明。
 
 
 
如下图，有两个系统I和II，其中系统I中具有模块M，系统II中具有模块N，经过分析发现，模块M和N的功能高度类似重复，完全可以抽象合并，避免重复建设。
 
 
 
 
识别共性模块
 
 
 
现决定将模块M和N分别从系统I和II中剥离出来，如下图。
 
 
 
 
抽离共性模块
 
 
 
将M和N剥离出来后，我们对其功能进行抽象合并，如下图。M和N合并后，得到模块A + B + C，其中A是M和N中共有的功能，B和C分别是针对系统I和II提供的一些定制化功能。虽然有少量功能无法做到完全合并和复用，但新模块中绝大多数功能集合A已经被高度抽象，可以被系统I和II复用。而被剥离合并后的全新模块A+B+C，将会下沉一层，作为基础服务，为系统I和II提供支持。如下图。
 
 
 
 
合并共性模块
 
 
 
以上案例，演示了系统功能如何被合并、抽象、下沉，这种设计思路，节约了软件研发成本，是一种非常经典的中台设计思路。
 
 
 
接下来，我们通过一个实践案例，进一步演示这种设计思路。
 
 
 
2、案例：统一客户视图建设
 
 
 
 
 
1）案例背景
 
 
 
某流量型互联网公司，变现模式主要为针对中小企业的广告售卖，业务团队包括电话销售团队（IS，Inbound Sales），外勤线下销售团队你（OS，Outbound Sales），以及客服团队。三个业务团队有着各自独立的业务系统支持其运转，每个业务系统中既有个性化功能，例如针对IS的外呼管理、针对OS的拜访管理、针对客服的关怀回访；也有功能高度类似的重复功能，例如客户管理列表，客户详情页。系统架构图如下图所示。
 
 
 
 
重复的客户详情页建设
 
 
 
2）遇到的问题
 
 
 
三套业务系统各自有产品研发团队维护，系统早期为了快速支持业务从而分别建设，快速响应业务诉求，为业务发展立下了汗马功劳。但随着系统的逐步成熟，其中一些问题也逐渐凸显，首要问题就是功能重复开发建设问题。虽然三个业务部门对客户关注的侧重点不同，但基本诉求是一致的，希望能看到客户所有的重要信息。因此，三个系统的客户详情页功能已经高度类似，而每次针对客户资料的调整变化，需要三个研发团队分别重复开发三遍，非常浪费人力资源。
 
 
 
3）解决方案
 
 
 
为了解决三套业务系统中高度类似的客户详情页的重复开发问题，也为了给业务人员提供一致的、准确的客户视图，公司决定将客户详情页模块从三个业务系统中剥离，将功能合并后，建设“统一客户视图（ECIF）”模块，该模块拥有一致的客户数据底层，并提供完整的客户信息查询服务化接口，以及可以嵌入业务系统直接使用的客户详情页面组件。“统一客户视图”将作为中台产品，为各个业务系统提供企业客户数据查询的服务以及视图。如下图。
 
 
 
 
将客户详情页抽象下沉建设统一客户视图中台
 
 
 
任何业务系统，既可以调用该模块的成熟接口查询客户数据并自己设计前端页面，也可以直接嵌入“统一客户视图”提供的现成的客户详情页组件，并且该页面组件还可以进行灵活的权限配置，定义针对不同的业务系统、不同用户角色的数据查看、编辑范围。
 
 
 
由此，我们完成了对客户详情页的抽象下沉，三套曾经重复开发的页面被合并成了一套，以后研发团队只需要维护这一套页面，研发人力得到了释放。
 
 
 
这就是典型的基于抽象复用的视角设计的中台产品。这种模式有一个显著特点，即软件的抽象和复用是成本问题，不影响业务。案例中，虽然有三套客户详情页被重复建设，但只是个资源浪费问题，并不会影响到业务的开展。
 
 
 
3、面临的挑战
 
 
 
 
 
对软件功能模块进行抽象复用，是具有很强挑战性的工作。如果分析不当或经验不足，有可能做出错误的抽象方案。
 
 
 
我们总是希望能够对软件和功能进行正确的抽象决策，让抽象出的系统和模块具有高度重叠的特性，例如下图这样。
 
 
 
 
期望的抽象结果
 
 
 
然而受限于经验不足，或掌握的信息不足，很可能做出错误的判断和设计，做出了错误的抽象决策，最后被抽象的系统模块，并不能被充分复用，只是制造了一个畸形的别扭的模块，生硬的把一堆毫无关联的功能强行捏在一起，给研发工作反而带来的更大的麻烦，如下图。
 
 
 
 
错误的抽象结果
 
 
 
我们将通过实际案例，给大家演示这种设计错误。
 
 
 
4、案例：订单中心的建设
 
 
 
 
 
1）案例背景
 
 
 
某互联网公司同时开展了电商业务和电影票业务。每条业务线都有独立的C端系统、后台交易系统（包括商品管理、订单管理、促销管理）来支持业务。为了追逐潮流，公司决定将两条业务线的订单中心合并，实现订单中台，如下图。
 
 
 
 
并不一定正确的订单中台
 
 
 
2）错误的决策
 
 
 
实际上，公司经营的B2C电商业务和影票业务，在交易形态上有较大区别，尤其体现在订单模块的设计上，订单的状态机、数据模型和财务账务处理模式完全不同，强行将两者合并后，并没有太多的共性模块和功能，最终只是表面上看起来实现了订单中台，但是里边的功能模块各自独立，各自运转，完全没有抽象和复用。
 
 
 
3）扩展难题
 
 
 
现在，公司管理者以为拥有了强大的“订单中台”，可以为任何新业务的快速开展提供支持。很快，公司决定开展机票售卖业务，针对机票业务，有独立的C端，商品管理，促销管理。但是当产品经理和工程师开始期待订单中台的强大能力时，遗憾的发现订单中台无法给机票业务提供任何现成的功能复用能力，机票的订单模型和电商以及影票都不相同。
 
 
 
机票业务线的设计人员面临一个尴尬的局面，要么“政治正确”的将机票订单中心纳入订单中台统一建设，但实际上这会严重降低开发效率，因为中台研发团队肯定不会像机票业务自己的研发团队那样重视新业务的开展；要么就抛弃订单中台，自己独立开发订单模块，但这样做又会显得订单中台没有产生该有的价值。如果你是机票业务的负责人，该怎么权衡取舍呢？此时的系统架构如下图。
 
 
 
 
订单中台并不能很好的支持机票业务
 
 
 
可见，订单中心，在不同业务模式下，并不一定适用于中台化建设，设计人员要有足够的思辨能力，判断产品形态上是否值得抽象下沉，是否能够提供复用能力。然而这也是软件工程设计中非常难的部分。
 
 
 
任何软件系统的设计，都是基于归纳法，而非演绎法，即软件设计人员总是通过对现有世界和业务的总结提炼，完成软件设计，而无法通过推测演绎，完成软件设计。设计人员无法对业务的未来做出预测，只能基于有限的经验，尽量的保证设计的灵活性和正确性。理解这一点非常重要，这会让你在软件设计、产品设计时心存敬畏之心，不会一味地追求短期无法论证的结论而产生的严重的过度设计。
 
 
 
5、实践中的建议
 
 
 
 
 
以下是基于抽象复用的视角建设中台的几条建议。
 
 
 
 
明显具备共性的模块尽早抽象
 
 
 
B端产品的体系化设计中，很多形态的产品是具备明显共性的，可以尽早的进行抽象设计，这样在系统架构建设的早期，就能做出正确的设计方案，而且并不会增加多少研发工作量，但会让未来的系统扩展更加轻松。例如，业务系统的统一权限管理系统、单点登录系统、组织架构系统、公告系统、短信系统，这些系统都应该尽早抽象建设。
 
 
 
 
不确定共性的模块事后抽象
 
 
 
例如统一客户视图、订单中心、商品系统，这些软件模块，很难判断在多业务线场景下能够完全复用，如果对于是否抽象拿不准主意，完全可以先不做抽象，等业务渐渐明确后，有足够的信息作出充分的分析和判断，再决定是否合并抽象。
 
 
 
 
避免人力外包中台
 
 
 
中台的建设一定要有合理的原因，如果只是为了中台而中台，会让系统的架构混乱，工作效率反而降低。而且很容易产生“人力外包中台”现象，即下游业务团队把中台团队当做乙方来合作，“反正你们要帮我们打理好这些模块，不管是否合理，需求提交给你就必须得高优支持，否则就是不支持业务一线”，这样会让中台产品和中台团队失去该有的气质，形成团队间的敌意和隔阂。
 
 
 
三、基于架构合理性的视角建设中台
 
 
 
1、建设的目的
 
 
 
 
 
软件的应用架构设计，不是随意任性的系统、模块组合，而是有着深刻的设计方法论与合理性诉求。为了满足应用架构合理性的要求，很多时候需要将软件抽象并下沉一层。
 
 
 
所谓应用架构合理性，是为了避免因为应用架构设计的不合理，而造成业务问题。企业中软件系统的建设，很容易出现两个常见问题，一个叫做烟囱应用，一个叫做数据孤岛。
 
 
 
企业内部的软件系统，很多都是为了某个独立的业务部门而设计研发，例如CRM，WMS，OA。这些系统设计初衷是支持业务部门的独立运作，而企业内部跨部门的业务流程和数据传递是无处不在的。如果业务系统没有做很好的架构设计或服务化处理，那么系统之间就无法通信交流，业务流程就会被割裂，每一个应用系统就像一根根烟囱一样，互无联系，这就是“烟囱应用”。烟囱应用会造成部门墙，让企业的业务无法顺畅流转运作。
 
 
 
 
烟囱应用
 
 
 
因为烟囱应用的存在，每个应用系统生产的数据会更加孤立，系统之间数据没有关联，没有打通，系统之间的数据就像一座座孤岛，彼此独立，数据的价值被严重弱化，数据孤岛会造成严重的业务问题，接下来的案例，会演示数据孤岛问题，以及如何通过中台化的架构设计思路解决该问题。
 
 
 
 
数据孤岛
 
 
 
2、案例：客户主数据的建设
 
 
 
 
 
1）案例背景
 
 
 
某公司开展了线下零售店和线上商城两条业务线，由于这两条业务线开展之初是独立经营建设管理，因此系统建设也是由两个产研团队分别负责，这就造成了线上和线下业务分别有一套客户数据库。现在公司设立了独立的客服一级部门同时服务于线上线下业务，而客服人员使用的客服业务系统，是不能同时访问两套客户数据库的，因此只能将两套客户数据库冗余成一套针对客服业务系统使用的客户数据库。此时，公司内部一共有三套客户数据库，各自像孤岛一样存在。如下图所示。
 
 
 
 
客户数据存在孤岛
 
 
 
2）遇到的问题
 
 
 
显然，上述应用架构存在严重的数据孤岛问题，并且会产生严重的业务问题。具体如下：
 
 
 
 
线上客户如果想体验线下服务需要重新注册会员，客户体验极差；
 
 
线下客户如果想体验线上业务需要重新注册账号，客户体验极差；
 
 
线上线下客户数据重复，无法识别唯一性；
 
 
呈现给客服人员的客户数据是同步后的具有滞后性；
 
 
客服无法准确识别客户信息并帮助客户修改资料；
 
 
企业无法做线上线下客户消费的关联性分析，无法做交叉销售。
 
 
 
3）解决方案
 
 
 
因为应用架构设计的不合理，导致业务受到严重影响，客户体验差。如何解决多个业务系统中存在的数据孤岛问题呢？实际上解决办法也很简单，就是将客户数据库合并后只保留唯一的一份客户数据资料，所有下游业务系统都访问这个唯一的客户数据库，进行客户数据的增删改查操作。此时，系统之间的拓扑结构发生了改变，新的应用架构图如下图。
 
 
 
 
通过主数据设计思路解决孤岛问题
 
 
 
这种针对企业的核心的、相对稳定不容易变化的、被充分共享的数据，叫做主数据MDM（Master Data Management），通过主数据的设计思路，可以很好地解决烟囱应用和数据孤岛问题，尤其是数据孤岛问题。主数据作为一种基础服务，正是一种中台化的治理理念。企业内常见的主数据包括客户主数据、供应商主数据、组织机构主数据、商品主数据等等。你可能之前没有听到过主数据的概念，但仔细想想，实际上主数据在B端产品的架构设计中时刻存在。
 
 
 
基于应用架构合理性的视角来构建中台，这种模式的特点，是软件的抽象和架构设计会影响业务，这和基于抽象复用的视角构建中台有着显著地区别，前者如果不做抽象和下沉，会造成很多业务问题，例如案例中提到的客户管理问题；后者如果不做抽象和下沉，只是成本问题，不影响业务，例如之前统一客户视图的案例，虽然开发资源浪费，但系统的问题并不会影响业务开展。
 
 
 
3、面临的挑战
 
 
 
 
 
有时候，对于企业来讲，正确的架构并不一定是合理的选择，反而错误的架构可能更有益于业务发展。理想化的架构设计，可能反而会拖慢业务节奏。这是架构设计中经常面临的问题，我们通过一个案例来进行阐述。
 
 
 
4、 案例：账号中心的建设
 
 
 
 
 
1）背景
 
 
 
某互联网公司起家于短视频业务，业务发展良好，市场占有率高，短视频产品功能形态丰富。公司基于各方面考虑，决定同时开展理财业务，希望在火爆的P2P市场中狂欢一场。
 
 
 
公司的短视频业务的账号中心，建设初期就采用了服务化的思路，因此很好的和短视频前台业务的C端APP实现了解耦合，实际上已经实现了中台化的建设部署。面对新开展的理财业务，产研负责人决定复用一套账号中心（Passport），从而发挥中台产品优势，为新业务赋能。理财业务的产品技术体系是独立的，虽然想完全独立研发所有的前后端系统，但是迫于压力，不敢违背公司搞大中台、小前台的指导思想，决定复用基于短视频业务构建的账号中心中台来开展业务。整个架构图如下图。
 
 
 
 
理财业务复用了短视频业务的账号中心中台
 
 
 
2）遇到的问题
 
 
 
账号中心作为中台产品，除了为短视频业务提供服务，还能快速赋能新业务，支持理财业务开展业务。理财业务只需要建设对应的APP C端和简单的管理后台，对于比较复杂的账号中心，完全不用浪费人力从头开发。看起来，完美的架构发挥了优势，支持了业务。产研负责人很开心，中台理念得到了落地，在老板面前有面子。然而事实真的如此么？
 
 
 
理财业务开展过程之中，需要针对账号中心做较多的个性化功能定制，例如需要实线账号的信用认证管理，地址管理，银行卡管理等等，相对于短视频业务的账号中心，理财业务对账号中心的功能要求、安全性要求、风控要求更高。理财团队给账号中心提交了一堆需求，但是账号中心的响应速度非常缓慢，因为两个团队不是一个产研体系，也没有管理关系，账号中台团队总是将理财业务的需求优先级调到最低。
 
 
 
因为账号中台的响应速度慢，理财业务负责人多次找老板沟通协调，但公司对待理财业务的态度又变的有些暧昧，并没有保持最强有力的支持，这下就比较尴尬了，理财业务虽然有自己的研发团队，但是账号中心用的却是中台的，而中台团队又不是很支持理财业务（按照中台团队的说法，理财业务提交的需求个性化太强，工作量巨大，对短视频业务一点价值都没有，投入产出比低，优先级低），导致业务进展缓慢，不能很好地支持客户需求和业务发展诉求，浪费了宝贵的竞争时间，只能眼睁睁的看着对手攻城略地，越走越远。
 
 
 
可见，设计了正确的中台产品，以及保证了架构的合理性，在某些情况下，反而会影响到业务的快速发展。
 
 
 
5、 实践中的建议
 
5. 实践中的建议
 
 
 
架构设计的核心目标是支持业务发展，某些时候可以允许不合理的架构存在。
 
 
 
在Passport的案例中，理财业务实际上是按照独立公司、独立品牌运作的，包括产品研发团队都是独立的。作为一个不确定性高、市场变化迅速的创新业务，极有可能运作半年后项目就中止了，这时候业务上更希望保持快速的响应和落地能力，而不是考虑软件架构是否合理，即便理财业务独立开发了Passport，即便理财业务发展成功、最后又需要将两套Passport合并，即便两套Passport合并非常麻烦，成本高，但是，至少业务通过快速响应，迅速切入市场，取得了成功。
 
 
 
而且，有些时候，所谓的中台化改造，架构合理性设计，会严重影响到原有系统和业务的稳定性。例如，假设新开展的B2B业务，要复用B2C业务的订单中心，将B2C业务的订单中心实现中台化改造，那么问题来了，B2C业务作为公司的核心主营业务，承担了每日十几万的订单交易量，营收占公司整体营收的95%。而B2B业务作为创新实验项目，预计每个月只能带来几十万的GMV，并且，如果要将B2C的订单中心中台化，兼容B2B业务，要承担非常高的系统改造风险。那么问题来了，有必要为了架构合理的中台化建设，而承担高风险（甚至有可能把主营业务的核心B2C订单系统干趴下），去支持小体量的创新业务么？
 
 
 
产品设计人员、架构师、产研负责人，在面临这些问题时，必须谨慎思考，基于对业务、市场、系统、代码、架构、人员、团队，各方面进行综合判断后，做出决策，即便有时候做出的决策在系统架构上看起来是错误的，但对于公司和业务的长远利益来讲上是正确的。
 
 
 
四、基于业务统一管理的视角建设中台
 
 
 
1、建设的目的
 
5. 实践中的建议
 
 
 
企业发展到一定阶段后，往往会出现集中化管理的诉求，对之前各自独立的子公司、事业部，在某些方面实现集中化的管理控制，一方面为了加强集团管控能力，另一方面也是因为业务协同经营需要。
 
 
 
如果想实现这类业务诉求，就必须通过对软件的下沉和抽象，来实现业务的集中化管控。下边，我们来通过案例进行说明。
 
 
 
2、案例：集团多业务线统一客户销售管控
 
5. 实践中的建议
 
 
 
1）案例背景
 
 
 
某保险集团经过多年发展，实现了寿险、财险、理财稳定的业务三角。三条业务线分别由独立的全资控股子公司经营，三家公司的所有业务系统，从C端到B端，也全部独立建设，互无交集。简化版的系统架构如下图。
 
 
 
 
某集团三条业务线下的系统架构
 
 
 
2）业务诉求
 
 
 
三家公司独立经营，保持了充分的灵活性，能够快速响应市场变化，取得了成功。但是，随着经营的深入，有一些问题也逐步暴露，并且变得越来越严重，总部高度关注，需要尽快解决，典型问题如下：
 
 
 
 
三家公司经常出现重复采购流量的现象，浪费集团营销成本；
 
 
三家公司往往对同一个客户重复营销，造成客户投诉；
 
 
客户价值不能充分挖掘，跨业务线的交叉销售和向上销售做的不好。
 
 
 
现在，集团下定决心解决这些问题，而解决这些问题，必须通过软件产品的中台化建设来实现。
 
 
 
3）解决方案
 
 
 
针对集团面临的三点问题，解决方案如下：
 
 
 
 
建立集团的统一客户标识数据库（作为集团统一客户管理中心的核心模块来建设），从集团层面识别客户唯一性，确保各个业务线采买流量时能够正确过滤已有客户，节约成本；
 
 
 
 
具备客户唯一性识别的能力后，可以实现集团层面的统一客户营销管理、客户旅程管理、以及防骚扰控制。通过统一客户管理中心实现客户旅程模块、防骚扰控制模块，将控制策略插入到各个子公司的销售系统中，确保各个子公司的销售触达任务开始之前首先要经过集团层面的控制中心的校验和管理，从而确保同一客户不会同时被几条业务线的销售重复骚扰；
 
 
 
 
统一客户管理中心还可以实现交叉销售模块，针对某些业务场景下的客户数据，进行跨业务线的销售任务分发，例如识别某寿险客户经济实力较好，则将客户推送到理财业务的销售系统，尝试二次销售转化。
 
 
 
整个系统架构如下图。
 
 
 
 
通过集团统一客户管理中心实现跨业务线的客户销售管控
 
 
 
综上可见，集团层面，如果想对各个子公司的客户资料、客户营销、客户触达进行统一管理，就必须建立统一客户管理中心，首先实现客户唯一性标识，其次基于客户唯一性标识落地各种统一客户管理策略。集团统一客户管理中心，正是中台设计思路的实践应用。而集中化的业务管理诉求，则必须通过软件的抽象和架构设计来实现，这也是这种中台建设模式的特点。
 
 
 
3、面临的挑战
 
5. 实践中的建议
 
 
 
业务集中管控的策略，总是滞后的，这是因为业务开展很长的一段时间中，各个业务线独立运作，相安无事，即便有一些小问题，也是可以容忍的，或无关紧要的。但是当企业规模增长到一定阶段，业务线之间的管理问题会越来越突出，之间的协同问题也会越来越明显，此时就有必要进行集中化的管理和控制。
 
 
 
滞后的业务管理决策，会对系统建设带来较大的挑战，因为各个业务线、事业部、子公司的系统已经发展的非常成熟，针对成熟的系统，去调整架构，改变系统和业务的逻辑，置入新的外部逻辑，是一件很有挑战的事情。
 
 
 
针对未来可能的集中管控诉求，是否能够在系统架构上提前布局，做好结构性的设计，以便未来的某一天，业务需求发生时，能够顺畅、轻松的进行支持么？实际上这也是不现实的，因为业务上的需求是一个未知数，没必要对未知的需求做架构上的过度设计。
 
 
 
总之，集中化的业务管理诉求总是滞后的，这会给系统、中台的设计和实现带来挑战。设计人员要对这个问题有清晰地认知。
 
 
 
4、 实践中的建议
 
5. 实践中的建议
 
 
 
针对业务集中管控诉求下的中台建设，有以下建议。
 
 
 
 
不要过多考虑未来不一定发生的事情
 
 
 
集中管控是不一定发生的需求，产品设计初期和中期，没有必要为未来不确定的事情提前做过多的布局，因为很有可能未来根本用不到，却会产生过度设计，造成开发资源的浪费，甚至也会让系统架构看起来非常奇怪。例如，案例中的集团客户管理中心，在寿险、财险发展初期和中期，有必要在系统上做出这样复杂的架构设计么？在各自独立经营的子公司推进这种架构的落地，如果没有明确的收益和价值，难度和成本巨大。
 
 
 
 
通过业务价值和业务诉求驱动系统迭代抽象
 
 
 
没有明确的收益和价值，却采用了这种集中控制调度的软件架构设计，这会让各个事业部的核心销售系统被割裂，被控制，被牵制，恐怕各个事业部是不会愿意配合这种项目的。即便这种架构很合理，在可预期的未来一定是必须的，但是在当前阶段下却没有任何价值，还会影响各个事业部各自的工作。没有业务价值和业务诉求的系统迭代抽象工作，是很难推动落地的。
 
 
 
 
项目必须有高管介入确保推进
 
 
 
即便业务上已经有明确的诉求，公司决定了执行架构调整，实现集中管控，项目的推进，依然会阻力重重，因为这种调整首先会打破原有的利益格局，也会造成工作习惯的巨大改变。这类集中管控的项目，如果想成功落地，必须有集团层面的，超越了各个下游业务线的非常高级别的管理人员牵头挂帅，管理团队必须有统一的认识，通过强有力的项目管理手段，才能保证在项目执行过程中化解任何困难，成功落地。
 
 
 
五、三种视角下中台建设模式的总结
 
 
 
我们已经分别介绍了基于抽象复用的视角、基于架构合理性的视角、基于业务统一管理的视角，这三种视角下的中台建设模式，以及每种模式的建设目的、建设特点、面临的挑战。汇总后得到下表。
 
 
 
 
 
 
这三种视角（或叫三种模式），从左到右，业务属性从弱到强。即最左侧的抽象复用的视角，纯粹是成本问题，和业务关系不大；中间的架构合理性的视角，具备了一定的业务含义和业务价值；最右侧的业务统一管理的视角，则完全是个业务问题了。
 
 
 
任何系统的中台化建设，都可以从这三个视角中找到影子，要么是基于其中的某个视角建设，要么是基于其中的某两个视角来建设。
 
 
 
例如，统一客户视图、报表引擎，这类产品纯粹是成本问题，遵循着抽象复用视角下的中台建设特点。主数据、账号中心、数据集市，这类产品兼具了架构问题和业务问题，遵循着后两种视角下的中台建设特点；而防骚扰、大积分体系（即集团多套积分体系的打通和汇兑中心），则纯粹是基于业务出发而建设的产品中台，遵循着业务统一管理视角下的中台建设特点。
 
 
 
在很多情况下，中台产品兼具了多种属性，例如，订单中心、账号中心、组织机构管理、权限管理，这些中台产品，既是研发成本问题，也是架构问题，同时还会影响业务。再例如，支付、清结算、促销重心、商品中心等中台产品，则既是为了解决业务问题，也是为了解决架构问题，同时也可能还解决了成本问题。
 
 
 
总之，上述三种中台建设的视角，在一定程度上穷举了产品中台（即产品经理关注的软件产品的中台化，也就是媒体上常说的业务中台）建设中的所有出发点和可能性。你可以思考下，目前你所接触的中台，是否处于上述三种视角下的某一种或某几种，通过我们的论述，你是否对相关中台产品设计的特点和要点有了更深刻的认识和理解呢？
 
 
 
 
 
 
 
https://mp.weixin.qq.com/s/J-U53-e0LN6cCBxUfHeGqg