经典数字化转型案例，一文通解架构设计流程及方法（上）

一套成熟的中台服务中心建设，该如何着手操作？本篇文章从思路出发，该思路包含了从业务调研到中台设计开发的标准流程和方法论，结合实际业务场景中落地的经验，供企事业在进行中台建设时参考。

我们把业务中台的落地方法总结为一个流程图，如图4-1所示。从业务的调研与规划开始，到产出中台设计，大致步骤包括：1）调研与规划。2）需求分析。3）中台设计。4）开发实现。

（1）调研与规划

业务的调研与规划目标是，从发展角度去看企业当下的业务运营情况和未来的业务规划。这一步非常重要，业务规划的长远度决定了业务中台的高度。所以这里要求业务方综合考虑企业自身的特性、新技术应用、新业务发展趋势等方面。这里列举一个零售行业某企业的例子，如图4-2所示。

从这个业务规划中，能明确看到企业中台建设的总体规划，在不同阶段对于会员、库存、营销以及供应链方面的业务诉求。有了规划，接下来的中台分析设计就更加有的放矢，不会出现目标混淆和不可持续发展的问题。

（2）需求分析

业务规划之后就是需求分析，单纯从中台设计的角度来说，需求分析更关注粗粒度核心业务流程，并不关心业务层面具体的用户交互和功能细节需求。一般业务系统和中台架构设计的需求调研都是同步进行的，所以这里也不用分得太清晰。

需求分析的目标是，从业务规划的各种业务场景出发，梳理核心业务流程。业务流程的粒度需要包含这几类：业务角色、业务实体、业务规则、已经存在的业务系统的接口、外部系统或者平台的服务和接口。这个过程是边梳理业务流程边识别业务实体，两者相辅相成。

（3）中台设计

从需求分析到中台设计有两条路径，如前面图4-1所示。路径A是从业务域分析开始的完整过程，经过流程分析、时序图分析和聚合分析，最后得出中台设计方案；路径B针对业务比较明确和相对简单的场景，或者行业已经有类似的业务沉淀（行业模型库），可以基于这些模型库进行迭代，直接基于已有的方案开始迭代推演。下面我们演示路径A的方法和过程。

这时就会遇到企业客户经常提出的问题—我们的公司到底需要几个中心？这些中心怎么出来的？这些中心是什么样子？

中台设计一般分两个阶段：业务中心分析和业务中心设计。业务中心分析是从业务流程纷繁复杂的业务场景出发分解出目标业务中心，业务中心设计需要完成中心的概要设计和详细设计。

阶段1：业务中心分析

这一步需要架构师具有深度的行业业务理解能力和软件分析设计能力，中台既是前台业务的基石，也是衔接前后台业务的中枢，所以中台设计一定要从企业核心业务场景和流程出发。

第一步，识别整个体系中最核心的业务流程，如图4-3所示。从这些流程出发，分析流程中参与进来的关键业务和数据实体，一一列举。从核心到边缘，从前台到后台、从后台到前台，正向流程、逆向流程，正常流程、异常流程，完整分析之后，你会得到一个企业业务实体的全景图，这个图包括用户、会员、企业组织架构、商品、交易（批发、零售），等等。

这个过程做得越细越好。在这个过程中，不要给自己设定用户中心、商品中心的概念，这时候你的眼里应该没有中心和业务系统的边界，只关注流程和实体本身。流程梳理完全是从具体业务场景出发，忠实于用户期望的业务需求，不要被现在实际的流程和系统所束缚。

图4-4展示了O2O场景下一个线上下单、线下物流送货的处理流程中，把所有跨系统流程全部梳理后得到的流程全景图。

第二步，把第一步分析的业务流程全景图聚合分析，从不同业务领域来归纳分析产生的业务和数据实体。这时你会发现，整个大图中最关键的那些业务实体与绝大多数的流程都有关系，而且和绝大多数的业务场景都有交互。通常，这时你所要找的适合纳入中台的业务领域就呼之欲出了，比如会员域、商品域、交易域、库存域，等等。这时就可以初步确定中台的基本轮廓。

图4-5是从上面梳理的业务流程全景图出发，分析流程中的主要业务对象，归类整理形成核心业务域，这些业务域将成为下一步服务中心设计的基础。

第三步，对这些初步确定的业务域进行进一步分析，分析业务域相互之间的依赖关系、复杂度、实体之间的亲密度等。不同业务场景得到的结果可能大不一样，例如，有的企业积分营销活动还不是很规范，也不成熟，在第一、二步的分析中可能会把积分账户放在会员域，因为用户注册时会赠送初始积分，这是很自然的事情。

而有的企业营销活动非常成熟，会员消费行为会导致积分账户变化，同时积分营销活动又会消费积分，所以会把积分账户放在交易域。

这一步需要基于一些服务化设计原则（参见后面的“服务化设计原则”部分）把这种初筛后的业务域的边界清晰化，有些需要把某些实体从A业务域放进B业务域；有时需要去伪存真，把一些噪音型的对象剔除，让它们回归本来的前台或者后台；还有一些需要火眼金睛，把本该进入但是却由于业务场景覆盖度不够暂时没有进入业务域的业务实体有预判性地拉进来。这一步需要架构师有丰富的分布式架构、服务化设计、中台设计的经验。

基于上一步的产出再用时序图的形式分析应用与业务域之间的关系，如图4-6所示，如果做得细致一点，这个过程可以进一步细化出调用过程之中参与的业务实体。注意，这里的时序图是基于业务域得出的，不是旧有系统依赖关系的时序图。

分析业务规划中的业务场景和用例会产出完整的基于中台业务域架构的调用关系，再把这些时序图按业务域进行分类归集。时序图中和业务域的每一次交互算一次“触点”，按业务域把所有触点进行聚合，如图4-7所示，通过触点数我们可以直观地看出来这些“业务域”的活跃度以及与业务场景的依赖程度。这时可以结合上节介绍的判断标准、团队的资源以及业务规划，定义出第一批可以升级到“中心”的业务域。

通过业务域与实体对象之间的依赖关系、业务域复杂度、业务实体之间的亲密度对业务域做进一步的聚类，这样就可以将每一个业务实体归类到合适的业务域。

通过这三个步骤，基本可以确定在当前规划的业务场景下，我们的中台到底应该有几个中心，分别是哪些中心。

从业务调研得出中台服务中心的设计，这一步现在很多企业做得非常随意，一般都参考一些互联网公司的实际经验或者基于自己对中台的理解，看到相关的流程就照搬过来，结果很可能会“水土不服”。在这里，我们推荐的方法是从企业的实际情况和具体需求出发，进行科学分析，从客观分析中总结得来。

文章部分素材源自：《数字化转型的道与术：以平台思维为核心支撑企业战略可持续发展》，作者：钟华