编辑导语：上篇文章中作者详细介绍了《什么是中台》，2016年阿里提出的“大中台小前台”战略后，很多企业开始想搭建中台；本文作者详细介绍了中台的定义及在“中台”建设方面的经验和方案，我们一起来看一下。

《中台详解系列》共分上下两篇，本文为下篇，总计约12000字，因为文中涉及知识体系较为广泛，建议预留30-50分钟进行阅读。

目前市场仅对“中台”和“平台”间的继承和发展关系有一定共识，“中台”的定义及建设规范尚未有明确定论。

本系列文章旨在基于“以终为始”的思维模式，及“软件对现实世界建模”的基础条件，梳理传统软件“平台”所面临的问题；并以此为起点，结合经济学中专业化分工协作理论，为“中台”进行职能定义，再通过“中台”的职能定义给出“中台”建设的建议方案。

阿里云在提出“中台”战略后，仅在一定程度上给出了“数据中台”的建设规范，同时市面上关于“中台”的介绍性文章也都避而不谈“中台”的落地方案，想是仍未统一。

本文中，我将主要介绍基于我个人对于“中台”的定义及在“中台”建设方面的经验，总结得出的“中台”总体建设建议方案；不过因为篇幅原因可能不会过于细致，也不会探讨“业务中台”、“数据中台”、“技术中台”在细节上的差别。

相关内容主要包括以下几个章节：

• 如何划分“中台”
• “中台”领域内建模要点
• “中台”数据治理方案
• “中台”模块间建设顺序
• “中台”对外服务要点
• “中台”迭代要点
• “中台”对组织架构及其协作关系的影响

一、如何划分“中台”

要做“中台”，首先自然就是得梳理清楚可以有哪些“中台”。

1. 原理说明

我对于“中台”的划分方法是基于“以终为始”的原则及我个人对“中台”的定义总结的，其细则如下：

“中台”需要通过专业化分工来解决“软件平台间职能边界划分问题”，专业化分工的本质是一种分类规则，要想分类我们就先得梳理自己有哪些业务功能以及要做哪些业务功能。

所有的软件及其背后的理论、原理、概念、技术都是为了解决业务问题而产生的，所以在梳理“自己有哪些业务功能以及要做哪些业务功能”之前，需要先梳理清楚业务目标，这可以帮助我们评估业务功能梳理及其他工作的合理性。

“软件平台”的专业化职能分工所需采用的“能力专业化”的原则，有着“多同一不”的特点（上篇文章有说明），所以建议提炼业务功能中的实体作为后续业务功能“分类”的“锚点”；将业务功能转化为类图等直观可视的静态模型，可以有效降低思维难度。

“中台”的构建需要在企业层面拉通。

2. 方法选择：领域驱动设计

因为“中台”背负着解决“软件平台间职能边界划分问题”的使命，从这个角度出发，我认为最适合应用于“中台”职能边界梳理的方法是“领域驱动设计”；因为从“领域”这俩字就可以看出来，“领域驱动设计”是为定义职能边界而生的。

不过目前“领域驱动设计”的落地实施方案是由技术人员总结的，主要应用于某个既定领域内的建模，如果我们直接用来进行“中台”的“专业化分工”和“数据唯一性建模”可能不太行。

所以针对“中台”的目标特征，我这里借助“领域驱动设计”思想，魔改了一套经验证可行的方案，大家可以简单了解一下。（由于“领域驱动设计”是基于面向对象思想衍生出来的一种建模方法，如果对于面向对象不太熟悉，可能不太看得懂，所以如果实在看不懂建议先跳过本段。）

3. 人员分工：产品经理主导

基于前文的分析，“平台”间的职能边界划分需要遵循专业化分工原则，所以建议增设“业务架构师”岗主导相关工作；除技术“中台”外，包括“业务中台”、“数据中台”的职能边界划分工作均由产品经理担任“业务架构师”。

4. 操作方案

在用本方案进行“中台”划分时，我们大致需要经过两个阶段，共计8个步骤：

第一阶段：

第1-3步为第一个阶段，是由“领域驱动设计”原落地方案中的“事件风暴”环节演变而来；分别为“企业全量业务目标分解”、“企业全量业务功能风暴”和“企业全量业务功能拓展”。

目标：梳理清楚“中台”所需支持的业务功能边界。

输出物：企业全量业务功能蓝图（ER图或类图）。

具体流程：

第一步：企业全量业务目标分解。

1）在进行业务目标分解时需要优先关心其在商业上的横向拓展。

以下为我个人总结的几个拓展点：

• 上下游业务拓展：比如犀牛制造和菜鸟物流之于淘宝 。
• 资源变现：比如滴滴搞外卖 。
• 数据变现：比如抖音、微信的用户标签等 。
• 流量变现：比如抖音、微信的引流服务等 。

2）具体到某个业务线、或体系下，业务功能都是通过解决一个一个小问题再最终解决小问题背后的大问题的，所以这里业务目标最好是采用金字塔模型来进行梳理。

以营销体系为例：

• 营销的最终目标是“卖更多的东西”，其子目标可以分为“让更多人买东西”、“让人买更多东西”；
• “让更多人买东西”的子目标可以继续分为“拉新”、“给用户洗脑”、“推荐合适的商品”；“让人买更多东西”的子目标可以继续分为“给用户洗脑”、“推荐合适的商品”；
• “给用户洗脑”的子目标又可以继续分为“提升品牌好感度”、“提升产品认知度”、“提升购物积极性”等……

虽然我们在“中台”设计过程中，业务目标划分的越细越好，不过业务子目标的分解也不是无限制的，最终状态的子目标会有着鲜明的场景化特征，大致可以用以下模型表示。

比如：连锁零售商总部营销部门在“女性用户”“非首次”情况下通过“ APP”购买“任意”商品时向其发放“肯德基10代金券”，以提高用户通过APP下单的积极性 。

第二步：企业全量业务功能风暴。

即对照“业务目标金字塔模型”对已有业务功能进行梳理，输出已有全量业务功能版图。

要求精确到实体，在操作本环节时，以下几点需要注意：

前文说明“数据孤岛”问题时提到过关系数据的重要性，所以在进行已有全量业务功能版图梳理时，关系型实体或字段务必要梳理清楚，不能遗漏，比如订单触发积分发放的记录等。

一般来说因为缺乏专业化职能分工设计，业务系统中会出现大量以下类型的临时方案：

• 人机交互型临时方案：比如业务场景没有定义好，在使用某服务时由人工录入服务的使用场景 。
• 在代码中埋数据的临时方案：比如某店铺的银行卡信息直接写死。
• 在进行业务功能风暴时，此类临时方案一定要还原成通用方案。

业务功能版图示例，图片来自网络

第三步：企业全量业务功能拓展。

即对照“业务目标金字塔模型”，基于第二步中输出的已有全量业务功能版图，梳理未来还可能会有哪些业务功能；因为“中台”在应用时处于底层，会被很多上层业务系统集成，如果“中台”没有做好前瞻性设计，后续迭代风险会比较大。

以下为我个人总结的几种拓展点：

业务功能细化拓展：在数据层面表现为字段取值范围的增加，比如客户类型的枚举值从“个人客户”增加到“个人客户、机构客户”，即表示目标客户从个人客户拓展到了机构客户。

另外抛开约束性校验和界面交互，所以软件的底层功能有且仅有对某实体某字段的增删改查，即每个实体天然有“字段数量*增删改查”个功能。

业务功能闭环性拓展：这一项主要是基于面向对象中的组合思想进行的拓展，即解决某一问题时可能需要多个功能组合完成，我们据此判断缺失了哪个功能；比如要达成用户激励，光有积分发放是不行的，还得需要积分消费功能。

业务功能依赖/约束性拓展：在数据层面表现为实体字段的增删改查需要从外部数据源取数或对外部数据源进行校验；比如物流单中商品信息就需要从商品模块获取，用户下单时需要对商品库存数量进行校验 。

业务功能支撑性拓展：即为了让业务更好的开展而进行的业务功能拓展；比如为了提高打开某文章的概率，我们会开发阅读指定文章送积分的功能。

业务功能纵向拓展：在数据层面表现为对实体及其属性、方法、实体间关系进行定义；比如设置积分的面值，进行用户操作权限授权等。

业务功能解耦分化型拓展：在数据层面表现为实体的拆分；比如有些车企自建的整车商城，包含汽车交易及汽车物权管理两条业务线，为了保障业务灵活度，最好就是将整车交易单拆分为商品交易单和物权转让单。

经过上面一番猛如虎的操作后，正常来说我们应该可以得到一张比较全面的业务功能蓝图（ER图或类图），接下来我们将进入第二个阶段，开始“中台”的划分工作。

第二阶段：

第4-8步为第二个阶段，是基于“领域驱动设计”原落地方案中的“聚合”概念拓展而来。分别为“关键属性定义”、“实体抽象合并”、“可复用业务定义”、“中台边界划分”和“中台边界修正”。

目标：进行“中台”的专业化职能模块划分，并调优。

输出物：“中台”产品架构图。

具体流程：

第四步：关键属性定义。

每个业务都有很多附加功能，这使得这些业务对应的实体会有很多属性，但实际上每个实体都仅有少量的几个关键属性定义了“它是它”。

实体的属性过多会对实体间的关系整理形成干扰，所以我们需要找出每个实体的关键属性。

关于什么是核心属性，我这里举几个例子：

• 商品的核心属性：价格，关联物品或产品编码 。
• 权益的核心属性：标的物、抵扣规则及面值 。
• 订单的核心属性：买卖双方、交易额、交易商品、成交数量、成交单价 。

第五步：实体抽象合并。

按照“多同一不”（上篇文章有说明）原则，我们需要根据某一个“模型、方法”是否服务于不同的“对象”来进行专业化分工；所以需要把相关实体进行抽象合并，保障各类实体的唯一性；因为我们在第四步“关键属性定义”中找到了各实体的关键属性，这一步就相对容易。

这个环节有一点需要注意：因为缺乏规范，可能明明相同的实体，但关键属性的命名却完全不一样，这可能导致将其分成了两个实体，所以在对实体关键属性定义时需要多检查几遍。

第六步：可复用业务定义。

接下来，我们需要基于“多同一不”（上篇文章有说明）的原则找到那些服务不同对象的“模型、方法”，这是专业化分工的基础。

这里还是举个例子，比如“权益发放”即为服务不同对象的“模型、方法”。

“权益发放”作为服务不同对象的“模型、方法”在业务上表现为：权益发放可以应用于包括用户注册、用户签到、用户下单等多个业务，所以即为服务不同对象的“模型、方法”。

“权益发放”作为服务不同对象的“模型、方法”在数据上表现为：

情况1：实体：用户注册记录（如果有的话）、用户签到记录（如果有的话）、用户订单（如果有的话）都冗余了权益发放数量信息 。

情况2：实体：用户注册记录（如果有的话）、用户签到记录（如果有的话）、用户订单（如果有的话）都冗余了权益发放规则信息，而权益发放规则冗余了积分发放数量信息 。

第七步：“中台”边界划分。

接下来，我们就可以正式进行“中台”边界的划分了。

首先，我们需要将第六步“核心业务定义”环节找到的服务不同对象的“模型、方法”，与其服务对象分开；比如权益发放因为可以同时服务用户注册、用户签到、用户下单等，所以其需要与后三者分开。

然后我们在通过实体关键属性所表现出关联关系进行组合，比如：

• 物流单的核心属性：物品、数量、取货地址、收货地址 。
• 订单的核心属性：买卖双方、交易额及交易商品 。
• 权益账户：所属用户、所属权益、权益余额 。
• 权益发放流水：流水类型（发放）、支出权益账户、收入权益账户、所属权益、流转权益数量 。

我们可以看出，物流单和订单基于核心属性是没有直接联系的，所以我们不会轻易将它们放到一个“中台”业务域中；而积分账户和积分发放流水基于核心属性是有直接联系的，所以我们会将他们放到一个“中台”业务域中。

需要注意的是，因为“中台”强调专业化职能分工，就像企业员工在实施某项目时，协作的各工种之间有很多衔接环节一样，在实际开展业务过程中，“中台”功能间也需要很多衔接性功能才能够真正支持业务。

一般来说，为了避免影响业务职能的完整性，不建议将这些衔接性功能强行划分到某个“中台”业务域中；实在不行，建议单独抽象一个“业务流程编排/管理中台”来统一行使功能衔接的职能。

第八步：“中台”边界修正。

第一，我们不排除有“基于关键属性是没有直接联系的两个实体”需要划分到同一个“中台”业务域中的可能，比如，有企业因为商品和订单在业务上紧密的关系而将两者划归为交易中台；

第二，也不排除有“基于关键属性是有直接联系的两个实体”需要划分到不同“中台”业务域中的可能。比如，很多软件供应商会因为部署需要，把权益中心在拆分为会员卡中心、积分中心、卡券中心等；

第三，会有一些业务特征不明显的功能是跨领域的，这种功能实际上可以抽象提取出来作为一个独立的“中台”板块，比如基于用户行为发卡券、积分、短信的功能可抽象为事件营销中台。

所以在“中台”边界划分完成后，我们还需根据实际情况进行微调。

经过验证，只要按照以上步骤执行，就可以梳理出相对理想的“中台”结构。不过“中台”划分原则的细节还有很多可聊，这些内容我后面也都会单独写专题文章介绍。这里就不赘述了。

二、“中台”领域内建模要点

鉴于“中台”背负着解决“软件平台的职能边界问题”的使命，其领域内建模即包括业务建模和技术建模两个方面：

1. 业务建模

这一块的工作可以进一步细分为“功能拓展”和“业务字段定义”两块工作，同样建议由产品经理作为“业务架构师”承担。

1）功能拓展

主体步骤跟“中台划分原则”中“第一步”阶段的差不多，主要还是基于业务目标和“领域驱动设计”思想对已有实体和功能进行各种形式的拓展，这里也就不重复说明了。

仅强调以下要点：

在“中台”的业务建模过程中，如果发现某个“中台”业务域对某些外部数据有依赖，而相关数据源还没有构建完成；这时万万不可私自在当前“中台”业务域中定义相关数据，这会严重破坏业务完整性，所谓“中台”的职能边界划分就无从谈起了（此种情况的解决方案在下文“3.3.中台数据治理”章节会给出）。

2）业务字段定义

由于“中台”还承担着解决“数据孤岛”的使命，所以在进行“中台”的业务建模时需要进行实体业务字段的定义。

这一部分我们重点聊一下：

除了核心属性字段外，我们需要基于以下要点进行字段冗余：基于实体间的依赖关系进行字段冗余，比如“卡券仅可用于指定商品功能”，就要求“卡券”实体冗余可用“商品ID”字段 。

“中台”是底层应用，不会直接对用户提供服务，都是上层业务系统按照一定逻辑顺序调用“中台”的接口来实现业务串联的；而上层业务系统在调用中台服务时是基于明确的业务场景的，为了满足后续数据分析、生产问题定位等目标，上层业务系统调用“中台”服务时需要入参相关服务调用的具体应用场景，而“中台”建模时也需要考虑相关数据的存储。

比如某APP后台调用积分中心、卡券中心进行积分或卡券的发放时都需要入参渠道ID、业务终端ID、操作人ID、业务ID（如订单这一业务的ID）、业务流水号（如具体某一笔订单的ID）、后台发放还是用户行为触发等，后续就可以用这些信息进行营销成本分析了。

为了便于拓展，实体业务字段的定义尽可能做到全解耦，即字段名称不要有任何定语；字段耦合的重灾区是各种“类型”，比如“流水类型”，有很多人会设计为“系统发放”、“人工发放”、“系统核销”、“人工核销”，就建议拆分成“流水类型”和“操作方式”两个字段。

因为业务字段直接决定了“中台”间的专业化职能分工关系，所以定义字段时，还要定义字段数据来源及枚举 。

3）特别提醒

上篇文章在介绍“数据孤岛”问题时提到过关系数据的重要性，所以在进行“中台”“领域内”的业务建模时，需要基于全量业务功能蓝图，充分考虑到关系型实体或字段的定义需求。

2. 技术建模

“领域驱动设计”有很明确的技术建模落地方案，在此我仅强调一下充血模型在“中台”技术建模过程中的重要性，它可以有效保障系统的可拓展性。

举个例子：

支付清结算业务中涉及多方分账，多方分账包括“指令分账”和“自动分账”两种情况。

如果我们将“支付”、“分账”分别作为一个事务进行封装，等我们需要修改“指令分账”功能时整个流程就阻塞了。

如果我们将“支付——指令分账”、“支付——自动分账”分别作为一个事务进行封装，等我们需要修改“指令分账”功能时“支付——自动分账”这条流程将不会收到影响。

三、“中台”数据治理方案

1. 数据依赖性治理

“中台”的划分遵循“多同一不”的原则，而各个“中台”业务域中的实体本身也可能作为业务对象存在的，所以在“中台”的业务建模过程中，可能出现某些“中台”业务域之间有数据依赖关系的情况。

为了保障各个中台业务域的独立性，建议采用“主数据”管理平台对中台间的数据依赖关系进行解耦处理。

具体方案为：构建主数据管理平台，提供主数据写入接口；梳理领域间的数据依赖关系，并在主数据管理平台进行需要在多领域共享的数据实体定义 。

可通过“中台”基础信息维护的前端直接调用主数据写入接口进行相关主数据的写入，或通过主数据独立写入前端进行相关主数据的写入 。

因为各有数据依赖需求的“中台”业务域对于主数据的数据依赖规则有所区别，所以在应用时还需要根据实际数据依赖情况进行数据依赖需求注册，从原始主数据中圈选依赖的数据；比如在主数据中“活动”和“商品”是两个实体，卡券的可用对象需要包含“活动”和“商品”，就可以通过这种方式把“活动”和“活动”打包应用。

此处是采用面向对象表示业务结构，不代表技术方案

这样做有两点好处：

• 在进行“中台”研发时各个模块之间不需要点对点进行对接联调，都只需要对接主数据，大大降低研发难度 。
• 因为有主数据的存在，即便被依赖的数据源暂未构建完成，我们也可以通过数据库预设、导入等方式维护相关主数据 。

2. 数据唯一性治理

我们在进行了“中台”专业化职能分工后，相似业务的相似数据在职能上的唯一性已经有所保障；但因为“中台”的本质是模块组件，模块组件多数情况下是必须与其他模块组件进行业务化串联，甚至还要进行增量的个性化定制包装，才能够真正解决业务问题。

这时可能出现“中台”业务域间、“中台”和定制内容间对于不同业务的数据字段命名一样的情况，这虽然不会影响数据分析，但容易误导研发，造成事故；所以建议采用“元数据”管理来规避这种风险。

具体方案为：

• 构建“元数据”管理平台模块，提供“元数据”查询接口及监察插件 。
• 各“中台”业务域及对接“中台”服务的业务系统在进行模型构建时，可以根据业务依赖关系查询元数据，并选择绑定。
• 如果需要新增“元数据”则元数据管理平台会通过插件进行“元数据”唯一性校验；校验不通过则预警，校验通过且正式使用相关“元数据”后，元数据管理平台即自动进行相关“元数据”的注册。

此处是采用面向对象表示业务结构，不代表技术方案

3. 数据一致性治理

由于种种原因，某“中台”业务可能会依赖甚至冗余外源数据，如果外源数据发生变动，就会出现双方数据不一致的情况；比如为了检索更方便可能会在“积分中心”——“积分流水”中冗余用户手机号信息，但用户手机号是支持换绑的。

对于此类情况我们一般有4种处理方案：

• 仅冗余主键字段：比如积分账户中仅冗余用户ID，前端展示时使用主键属性前往数据源进行指定字段查询；检索时则使用指定字段前往数据源查询主键属性，再用主键属性去查询当前模块数据。因为主键字段不会改变，所以自然就不会出现上述问题。
• 冗余数据不做增量修改：比如积分发放流水冗余了用户手机号，我们可以理解积分发放流水为积分发放那一刻的凭证，后续就算用户手机号变了，而积分发放那一刻的手机号是没变的。
• 冗余数据在数据源变动后实时同步，这个难度比较大。
• 冗余数据在数据源变动后采用定时任务同步。

另外，为了便于后续进行数据核对，还建议所有的数据维护所有数据的修改记录及历史版本。

在实际操作中，我们需要对“中台”业务域内的业务细节进行全面排查，具体情况具体分析，分别选取上述不同的解决方案。

四、“中台”模块间的建设顺序

“中台”的建设是有顺序的，这个顺序主要基于依赖性原则，即被依赖的实体、功能先做；在“中台”划分时，我们几乎不可能把所有具备依赖关系的实体、功能划分到同一个“中台”业务域中。

鉴于除了关系型实体有着明确的依赖对象外，依赖关系并没有什么特别的规律，所以我建议是在进行“中台”划分时就需要把各“中台”间的依赖关系理清楚。

以我目前的实践经验来看，包含以下实体的“中台”业务域需要优先搭建：

• 业务基础实体：组织机构信息、客户、账户、商品等；绝大部分企业的最核心业务都是交易，交易最核心依赖的就是这些数据 。
• 数据分析关键实体：业务场景、渠道、终端、页面、点位等；业务分析最核心的就是找出最有效的上述信息。

五、“中台”对外服务要点

1. 对外接口字段标准化

1）通用标准字段定义：

上文有提到，“中台”是底层应用，不会直接对用户提供服务，“中台”的对外服务需要记录应用场景信息。

这一情况在“中台”各业务域中都是普遍存在的，所以所有“中台”对外暴露的接口中都应该冗余这些通用字段；当然，我们也可以根据具体企业的业务需要定义其他通用字段。

2）业务标准字段定义：

这里的业务标准字段主要是根据“充血模型”的建模需求定义的，比如积分发放接口，基于贫血模型定义的接口可能如下：

• 通过积分发放账户关联B端用户ID来找到积分发放账户，再进行积分发放。
• 使用积分发放账户进行积分发放。

过多的校验环节可能带来较大的错误风险，所以建议改成“积分账户查询”及“积分发放”等两个接口，示例如下：

2. 服务组合

前文提到“中台”之间可能存在数据依赖，这使得很多时候上层业务系统在调用某“中台”接口时，需要先去被依赖的数据源取数，再回过头来调用原先的接口。

这种情况无疑会大大增加“中台”服务的理解难度，以及上层业务系统对接“中台”服务的联调工作量与出错概率；针对这种情况，建议是拓展一个“中台”服务组合层，通过这个组合层进行各“中台”相互依赖的接口间的组合。

这样做的好处有以下几点：

• 可以保障领域层服务的独立性，保障充血模型的有效性。
• “中台”服务还可集成中台应用服务网关的职能。

3. 对外服务应用架构

前文有多次强调过，“中台”的本质是模块组件，模块组件多数情况下是必须与其他模块组件进行业务化串联，甚至还要进行增量的个性化定制包装，才能够真正解决业务问题。

这里的“业务化串联”及“个性化定制包装”工作就需要单独拓展一个“业务应用层”来完成。

注意这个“业务应用层”与“第二点”中的“中台服务组合层”并不是一回事，服务组合层主要是基于接口间的依赖关系构建的，而“业务应用层”中需要串联的业务之间不只存在依赖关系；比如前文“3.1.如何划分中台”中提到的业务之间的“支撑关系”。

这里举个例子：抽奖活动的创建和卡券的创建之间并不存在必然的依赖关系，而在实际操作过程中，我们常常会在活动创建的过程中创建新的卡券，这就需要研发人员在“业务应用层”进行逻辑编码。

这里有2点需要说明：

1）“业务应用层”的设计建议采用前文提到的经济学原理——专业化分工原则中的“对象专业化”原则，这里就当开了个新坑，以后再专门写一篇相关的文章，在本文中就暂不细聊了。

• 对象专业化：按照业务对象来划分生产单位的原则，即按不同的业务对象，建立不同的生产单位。
• 特点：“多不一同”。多不——不同模型 、不同方法、相同服务等；一同——相同的业务对象。

2）我们常说的B端或者运营后台一般就对应着这个业务应用层。所以从这个角度上来说，“中台”相对所有业务系统来说都是更底层的，不存在文章一开始所说的“业务支撑后台”概念。

六、“中台”迭代要点

1. 常规版本迭代

通过前文“3.1.如何划分中台”，我们大致可以了解到“中台”以下两个特点：

• 前瞻性：这使得很多“中台”功能可能暂时用不到；
• 规模大：这使得“中台”很难一两个版本直接搞定；

所以“中台”的迭代是很正常。在“中台”的常规版本迭代过程中，我们可以结合企业的业务发展路径来进行各“中台”业务域的PI计划制定。

2. 重构性迭代

虽然我们是基于专业化分工原则来划分“中台”职能，但以下两点原因可能会造成中台的重构：

• “中台”在进行职能划分时需要使用“能力专业化”原则，其有“多同一不”的特点，而实际“多同”是可以有不知一种解读的，比如原先我们将“权益账户”划归了“权益中心”，后续可能我们又会将其滑轨到“账号账户中心”，其实这都有道理，关键是看与相关企业的业务匹配度。
• 因为一些特殊原因需要将中台进行细化；比如我司会因为部署需要，把权益中心在拆分为会员卡中心、积分中心、卡券中心等。

理论上来说，以上两种原因造成的“中台”重构都只是涉及到原有某一个或某几个“中台”，如果发现各“中台”业务域都需要调整，那估计是一开始的“全量业务风暴”和“全量业务拓展”没做好，这就建议从头再来一遍了。

七、“中台”对企业组织架构及其协作关系的影响

很多与“中台”相关的文章和出版图书中都提到了“中台”对企业组织架构的影响，其中不乏观点认为“中台”的本质就是企业组织架构的升级，这可以说是错把结果当原因了。

实际上“中台”与企业组织架构间的关系是这样的：

就像“中台”概念是用来协调“平台”间职能分工、协作关系的一样，组织机构是用来协调“组织成员”间职能分工、协作关系的；而恰好“中台”的应用特性使得其需要专门的团队维护，而新团队的出现则带来了新的“组织成员”间协作关系的构建需求。

因为“中台”继承了“平台”解决“重复造轮问题”，并拓展出了解决“数据孤岛”问题的使命，所以中台对于组织架构的影响必然是企业级的。

不过一方面运营人员直接面对的是“业务应用层”，另一方面各类数据也可以通过数据权限进行隔离，所以“中台”的构建不会对运营工作产生任何影响，这也很符合“中台”的定义和使命；“中台”的构建主要影响的还是IT团队。

1. 增设新的部门

“中台”的构建和运维工作有以下特点：

• 首先，“中台”的研发工作将持续一个长周期，这期间工作密度较大；但如果一切正常，在这个阶段后，相关研发工作就会急剧减少，除非需要进行某些“中台”业务域的重构；
• 其次，“中台”构建完成后，构建各业务系统的IT团队在对接“中台”时，需要进行高强度的业务咨询及技术咨询；
• 最后，因为“中台”虽然进行了“专业化分工”和“数据唯一性建模”，所以在实际生产环境中，“中台”承担的并发量是各业务线相似业务的并发量之和，这使得“中台”对于业务运维、应用运维人员、技术运维及DBA的能力及响应速度要求都高出一般的业务系统很多。

基于上述特点，我们建议需要围绕“中台”增设一个部门，这个部门及其人员配备应具备以下特点：

• 为了保障中台的独立性，不会轻易被业务系统的需求所碾压，该部门最好与业务系统的研发部门平行存在；
• 因为“中台”构建的工作量前重后轻，所以相关研发团队建议是从原有业务系统研发部门抽调，待“中台”研发工作取得阶段性成果后，可以逐步释放回原来的部门；这样做的好处还有：因为相关研发团队对原有业务系统比较熟悉，更能够做好业务组合、关系实体构建以及其他前瞻性设计；
• 因为“中台”对于运维工作要求高，所以相关团队建议单独建立，可以招聘，可以抽调，但要稳定；
• 相关业务架构师、技术架构师需要保持稳定，以保持业务和技术理解的连续性。

构建各业务系统的IT团队在对接中台时，在进行业务咨询和技术咨询时需要有专门的顾问解答，具体工作内容在下方“研发及运维流程调整”章节有详细描述。

2. 研发及运维流程调整

鉴于“中台”的企业级使命，所以在新的部门成立后，以下工作要点需要注意：

• 是否需要接入“中台”服务，不能由业务系统研发团队自己说了算，需要由业务系统研发团队派出“产品经理”、“技术经理”与“中台”团队的“业务咨询顾问”及“技术咨询顾问”共同商讨决定；
• 无论某个业务系统最终是否接入了“中台”服务，其模型及元数据必须上报“中台”-“元数据管理平台”，也必须遵循企业层面元数据唯一性原则；
• 因为“中台”与业务系统间是“1对多”的关系，正常情况下如果“中台”出了问题所有业务系统都会受到影响，所以在某个业务系统与“中台”的衔接环节出现了问题后，需要先由业务系统相关运维团队进行问题定位。

基于上述要点，我们建议业务系统研发流程大致如下：

业务系统研发流程：

• 业务系统研发团队“产品经理”、“技术经理”深度学习“中台”服务；
• 业务系统研发团队“产品经理”、“技术经理”对自身业务及模型进行梳理，初步确定与“中台”间的交互关系；
• 业务系统研发团队“产品经理”、“技术经理”提交工单申请“中台”服务咨询，并与“中台”团队的“业务咨询顾问”及“技术咨询顾问”交流确认业务系统与“中台”间的交互关系；
• 业务系统研发团队“产品经理”、“技术经理”在得到“中台”团队的“业务咨询顾问”及“技术咨询顾问”确认后，申请接入“中台”服务，并在通过后获得相关接口文档及其他必要材料/工具/网关授权等；
• 业务系统研发团队在系统构建过程中全程受“中台”元数据管理平台及业务编排监控插件的监控，以免出现数据“张冠李戴”等错误；

业务系统研发流程异常处理：

• 业务系统如涉及到“中台”还在研发中的需求，可以在经过高层审批后，酌情让业务系统自身定制，但相关问题需要由负责的“业务咨询顾问”及“技术咨询顾问”记录，并在后续“中台”相关服务上线后立即进行服务切换及数据迁移；
• 一旦发现“元数据重复定义”及其他明令禁止的，会影响“中台”职能定义及“数据归一”的问题，即使相关模块已上线，也需要立刻进行修正。

运维流程大致如下：

“中台”内部运维流程：

• 由“中台”测试团队每日汇总内部问题，并根据问题严重性进行排期，严重问题需要当日解决；
• 各“中台”业务域按照测试的排期计划进行相关修复工作。

缺陷型业务应用生产问题运维流程：

• 问题发生后由业务系统运维团队优先定位问题，在排除业务系统问题后，向“中台”运维团队业务运维岗提交工单；
• 由“中台”运维团队的业务运维岗每日汇总缺陷型业务应用生产问题，所有问题必须当日定位，当日解决；

需求性业务应用生产问题运维流程：

• 由业务系统运维团队提交需求性业务应用生产问题工单至“中台”运维团队的应用运维岗；
• “中台”运维团队的应用运维岗对业务需求进行核实和确认，制定服务器内存扩容等解决方案，并提交相关主管审核；
• 相关主管审核通过后即可以启用相关解决方案；

在实际操作中，细节可能要比上述描述更加复杂，因为篇幅有限，暂且略过了。

八、写在最后

至此，《中台详解系列》文章完结了，文中所载均是我个人一些微薄、浅显的见识，“中台”作为软件建设的一个里程碑式概念（至少基于个人对“中台”的定义我是这么认为的）有着太多内容可以探讨。

所以如有不同观点，欢迎联系作者进行交流，彼此促进，共同成长。

本文由 @阿魏 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议