1.业务抽象

在业务抽象阶段，通过业务调研和业务分析，设计业务蓝图和抽象业务元素，为下一阶段的中心建模阶段准备顶层思想和业务素材。这一阶段，根据企业不同的实际情况，可轻可重。比如企业已经做过咨询调研和流程梳理工作了，那就可以在以往工作成果基础上进行短期的业务理解和业务设计工作了。如果企业对以往的咨询工作并不满意或者上一次咨询时间久远，竞争环境发生了巨大的变化，这就需要做仔细完整的业务咨询了。

2.高阶设计

（1）中心规划

经过业务的调研和分析，技术架构师理解并熟悉了业务。基于上阶段输出的主题域，技术架构师按照中心的多个划分标准，进行中心的规划。

（2）0级架构设计

业务中台的0级架构本质上是应用架构，它以中心为最小单位进行设计，因此也称为整体架构设计。0级架构包括了功能层级的架构和技术层级的架构。

功能层级的架构需要描述业务中台在整个数字平台中所处的位置，业务中台由哪些中心组成，以及中心与应用、中心与后台的交互关系。功能层级的0级架构承接了企业的应用蓝图规划，指导企业各IT系统的职责划分和定位。

下图所示为一个企业功能层级的0级架构示意图。

从上图中我们可以看到，企业整体功能架构从下往上分为IaaS层、PaaS层、基础组件层、数字中台层（包括业务中台和数据中台）和业务应用层。每一层的具体功能如下：

• IaaS层：完成硬件资源的虚拟化管理，为用户提供对资源的使用服务。

• PaaS层：为应用软件提供部署平台和运行环境。

• 基础组件层：介于业务服务和技术中间件之间，提供通用的业务功能和技术功能，并解耦业务应用和技术中间件。

• 数字中台层：分为业务中台和数据中台，实现企业业务活动的核心机制，并通过数据中台对业务运营提供指导。

• 业务应用层：通过调用和组合中台能力，实现应用逻辑。

技术层级的0级架构需要说明各系统、各中心分别使用什么技术来实现，以及整个体系的技术分层，如下图所示。

技术架构总体上分为展现层、服务层、接口系统、运营管理和运维支撑。

展现层与服务层相分离，展现层采用当下主流的前端框架，分别对移动端、PC端进行支撑。通过合理的技术搭配人性化的设计满足用户感官体验需要。

服务层的架构采用分布式的微服务架构，微服务架构去中心化加强终端的特点，让服务免去雪崩效应等容灾上的风险。同时，整体技术架构具备易于扩展、组合、部署，可支持动态伸缩、精准监控，并且可以提供灰度发布等优点。服务层包含应用服务、中台服务、技术服务。应用服务与中台服务都以微服务架构实现。技术服务又分为PaaS层和IaaS层：PaaS层通过各项基础中间件的能力向上层输送搜索引擎、分布式文件存储、分布式数据库、分布式缓存等能力；IaaS层向用户提供基础资源服务。

运营管理通过埋点技术、A/B测试技术、大数据技术来进行数据采集分析和业务试错，并通过计算结果来指导业务工作。

运维支撑将从底层对所有服务做支撑。运维体系通过对基础设施的监控、服务升降级等措施来确保系统的容灾能力与稳定性。

（3）中台核心数据流规划

为了简化业务流程，根据前期的业务分析，结合0级架构的设计，我们可规划出企业的业务数据流（以房屋租赁行业为例，多业态），如下图所示。

客户中心承接前台应用租房、买房客户的注册信息；对于集团多业态的业务特点而言，经纪人、物管人员、企业员工都是企业客户，都应该进行精细化管理。客户中心为统一认证提供账号、密码的验证，为各应用提供客户的全局唯一标识。

产品中心接收来自ERP的工程域楼盘信息、员工录入或经纪人提供的可租楼盘营销信息，形成每一间房的完整且统一的档案。为前台各应用提供全方位的楼盘信息，包括工程信息、营销文案信息和房间信息。

交易中心接收来自WMS的库存信息，完成购房订单的生成、在线租房的交易等业务活动。订单生成后，根据订单中的商品向WMS发起发货指令。

3.组件建模

（1）产品设计

产品设计是在业务顶层设计的指导下，逐层往下抽象的过程，主要是将业务调研的成果转化为产品原型和需求规格说明书（主要由业务场景、业务流程构成）。如何做应用的原型和画出业务场景不是本节的重点，详细内容可参看相关专业书籍，这里需要强调两点：

• 中台产品的详细设计需要以面向中心为指导思想。不仅需要设计出应用需要实现的功能，更重要的是要将需要中心支撑的功能明确标识出来，归到中心的待实现列表里。这样技术工程师在领域建模阶段才有具体和明确的输入。

• 建设中台的核心目的不是为了共享，共享只是中台的特性。中台是为了完成业务的核心运行机制，为前台提供业务能力基础的系统。确立了这个原则后，产品经理才能放开手脚，自主推动中心的建设。

（2）组件模型设计

组件模型设计承接0级架构设计，是对中心内容的展开。通过对中心功能的分析和对中心业务实体的抽象，将具有较强依赖关系的业务实体聚合为一个组件，或者将具有相同主题的业务功能聚合为一个业务组件。最后以结构化的形式聚合这些组件，构成中心。

如何判断组件模型是否合理呢？是否很好地支持业务流程、业务场景、复杂的业务规则是衡量组件模型优劣的标准。我们可以通过穷举边界业务场景的方法，来反证组件模型设计是否合理。

最后需要强调一点，组件是可以独立为微服务的，只要符合微服务的条件，就可以独立。但是在实践过程中，我们发现如果微服务承载的业务规模不大，独立带来的业务价值不高，反而会增加运维成本。

（3）1级架构设计

组件模型设计完成后，需要将模型转化为应用架构。这里的应用架构是指中心内部的应用架构，我们称为1级架构。1级架构是以组件为最小单位设计的功能层级的架构。1级的功能架构是必不可少的，它指导着我们的设计和开发；技术层级的1级架构可视情况而定，如果技术内容比较复杂则需要输出。下图所示为某企业功能层级的交易中心1级架构。

（4）关键交互图设计

前面已经完成了0级和1级的架构设计，有什么方法能证明设计是否可以满足实际业务场景的需要吗？我们可以通过实现业务场景的动态交互图，来反向论证设计的合理性。如何判断动态交互图是否合理呢？根据业务逻辑是否清晰、流程是否简洁、客户交互是否高效来判断。

如果设计出的交互图不合理，那就说明0级或1级架构存在设计不合理的问题。另外，通过交互图还可以较好地将设计思想传递给开发团队。

4.开发交付

我们主张采用敏捷的方法进行开发交付，将最终目标拆解为多个小目标，逐个完成。同时又将每个小目标拆为多个子项目，每个小团队各自负责一个子项目，所有团队并行开发，协同向前推进。一般流程包括迭代规划、需求反讲开发、持续集成交付和回顾总结调整。

5.持续运营

项目上线后，只是产出业务价值的开始。数字中台需要在持续不断的运营中，包括业务运营、内容运营、技术运营和数据运营，不断沉淀和发展。能力会逐步增强和扩展，模型会逐步调整和完善。