《中台战略》- Chapter 5 - 5.3 业务中台设计方法论

推荐购买《中台战略-中台建设与数字商业》正版纸质书籍阅读

  业务中台本质上是一个体系或系统，它实现了企业核心的业务运行机制，因而处于企业运行生态的核心位置，所有应用系统都必须与之建立联系。
  众多的可复用能力只是中台的形，核心的业务数据和业务流程才是中台存在的本质。

中台建设4句要诀

5.3.1 能力支撑是基础

  业务中台居于整个企业数字化平台的中间层，从全局的角度来观察，业务中台是上层应用建设的基础，它提供了应用功能所依赖的业务能力。
  1）应用功能建立在能力的基础上；
  2）通过对业务能力顺序编排实现业务流程；
  3）通过将不同能力的返回结果聚合为一个有针对性的数据集，满足用户需要。
  综上所述，中台能力为应用功能的实现打下了坚实基础。衡量业务中台价值的一个重要标准就是中台业务能力的丰富程度。

5.3.2 中心自治是承载形式

  中心是一个独立的体系，它能够独立运营，支撑多个业务场景。同时，它也是中台能力的物理载体，既提供了中台能力的编码实现，又在运行时生成一个物理进程承载多个中台能力。
  这里的中心需要区别于微服务：
  从业务上来讲，中心实现的业务范围比微服务更大，中心是多个或多类型业务实体的聚合，而微服务一般指一个业务实体或一类业务实体的聚合。例如商品中心既提供类目也提供商品属性，而类目微服务只提供类目服务。
  从技术角度看，中心具有复杂的内部组件结构和数据流关系，微服务追求的是简单和轻量，一个中心可以由多个微服务组成。

  中心自治在业务上要求中心能够独立运营，而不需要横向依赖其他中心提供的能力。在技术上，中心具有独立的生命周期，包括中心启动、运行、停止三种状态。我们可以通过运维的技术手段观察和控制某个中心的生命周期，而不会影响到其他中心的生命周期。

5.3.3 3层模型是骨架

  根据DDD的分析，我们可以看到领域模型分为核心域、支撑域、通用域，但是我们认为这远远不能揭示复杂的业务世界，原因如下：
  第一，这三个分类边界模糊，难道核心域的内容不可以是通用的吗？
  第二，这三类领域的比较都是以功能角度去考虑，难道功能就应该是划分领域的标准吗？
  第三，我们划分领域的标准是不一致的，能否通用是一个维度，是否为核心则是另外一个维度。

  业务功能按照目标的不同分为两大类：为了管理好企业资源而存在的业务功能，以及为了管理好经营活动而存在的功能。
  业务中台从下向上可拆分为业务实体层、业务协作层和业务活动层。该分层结构不仅定义了业务中台的结构，也定义了数据流向、服务依赖关系、单次事务的调用次数等。我们可以基于此定义中台的开发规范。

业务中台的3层架构模型

  1）业务实体层（Business Entity Layer，BEL）：由对静态业务实体进行管理的中心所构成，也就是我们分析的企业静态资源管理。静态资源包括通用业务对象，比如省地市、元数据，还包括商品、会员、用户等。
  2）业务协作层（Business Collaboration Layer，BCL）：由以完成或管理支撑类业务活动为目标的中心所构成，比如促销中心、评价中心等。
  3）业务活动层（Business Activity Layer，BAL）：由以完成或管理核心类业务活动为目标的中心所构成，比如交易中心、供应中心、物流中心等。

  静态资源是一个企业经营的基础，上层业务活动需要实时获取企业资源以完成业务活动，这是商业的本质规律。因此业务实体层向第一层和第二层提供了能力以被调用。第二层是业务协作层，本层的目标是支撑核心层的业务活动，因此从逻辑上看，本层只有提供能力随时准备给核心层调用，才能实现支撑的目的。
  业务活动和业务协作反作用于资源层，是希望资源层做出相应的调整。我们往往不需要也没有必要对这样的希望进行实时反应，因此上层的反作用以事件异步流动的方式向下传递。支撑层也是同样道理，活动层对协作层的反作用往往不需要实时，因此异步流动是最好的选择。

5.3.4 5步法是指导思想

中台建设5步法

  1）业务抽象：在业务抽象阶段，通过业务调研和业务分析，设计业务蓝图和抽象业务元素，为下一阶段的中心建模阶段准备顶层思想和业务素材。
  a）业务调研：通过座谈会、调研表、实地考察等多种方式获取业务素材，深入理解企业业务和感受企业面临的竞争。这里的调研分析不同于传统的系统调研。我们更加强调的是，以面向中心的思想来探讨业务，认为业务流程只是形式，核心是各领域中心的结构和运行机制。各中心的设计需要满足业务流程的需要，但是这不是核心目的。我们主张在业务调研过程中进行领域模型的探讨，反复思考逐步清晰业务领域的边界。
  b）顶层业务分析：在业务调研结束后，结合行业趋势、类似项目的比较以及自身的经验，输出企业的商业模式和核心业务场景。业务场景包括企业级业务场景、部门级业务场景和操作级业务场景。并在业务场景梳理过程中，找出企业痛点。最终设计出企业TO-BE的业务蓝图和应用蓝图。
  c）业务抽象：通过顶层业务分析，明确了总体方向后，我们便可以展开对具体业务场景的梳理和抽象，并输出功能需求清单。在此过程中，还需要定义出功能操作的业务对象或业务实体。基于业务实体，结合对应的功能需求，定义出需要系统提供的能力。根据能力的主题和实体间的密切关系，我们便能对实体进行归类，定义出主题域。具体方法将在第6章详细阐述。

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

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

功能层级的0级架构示意图

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

• IaaS层：完成硬件资源的虚拟化管理，为用户提供对资源的使用服务。
• PaaS层：为应用软件提供部署平台和运行环境。
• 基础组件层：介于业务服务和技术中间件之间，提供通用的业务功能和技术功能，并解耦业务应用和技术中间件。
• 数字中台层：分为业务中台和数据中台，实现企业业务活动的核心机制，并通过数据中台对业务运营提供指导。
• 业务应用层：通过调用和组合中台能力，实现应用逻辑。

技术层级的0级架构示意图

  技术架构总体上分为展现层、服务层、接口系统、运营管理和运维支撑。
  展现层与服务层相分离，展现层采用当下主流的前端框架，分别对移动端、PC端进行支撑。
  服务层的架构采用分布式的微服务架构，微服务架构去中心化加强终端的特点，让服务免去雪崩效应等容灾上的风险。同时，整体技术架构具备易于扩展、组合、部署，可支持动态伸缩、精准监控，并且可以提供灰度发布等优点。服务层包含应用服务、中台服务、技术服务。应用服务与中台服务都以微服务架构实现。技术服务又分为PaaS层和IaaS层：PaaS层通过各项基础中间件的能力向上层输送搜索引擎、分布式文件存储、分布式数据库、分布式缓存等能力；IaaS层向用户提供基础资源服务。
  运营管理通过埋点技术、A/B测试技术、大数据技术来进行数据采集分析和业务试错，并通过计算结果来指导业务工作。
  运维支撑将从底层对所有服务做支撑。

  c）中心核心数据流规划

基于中台的业务数据流

  3）组件建模
  a）产品设计：产品设计是在业务顶层设计的指导下，逐层往下抽象的过程，主要是将业务调研的成果转化为产品原型和需求规格说明书（主要由业务场景、业务流程构成）。

• 中台产品的详细设计需要以面向中心为指导思想。
• 建设中台的核心目的不是为了共享，共享只是中台的特性。

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

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

某企业功能层级的交易中心1级架构

  d）关键交互图设计：我们可以通过实现业务场景的动态交互图，来反向论证设计的合理性。如何判断动态交互图是否合理呢？根据业务逻辑是否清晰、流程是否简洁、客户交互是否高效来判断。如果设计出的交互图不合理，那就说明0级或1级架构存在设计不合理的问题。另外，通过交互图还可以较好地将设计思想传递给开发团队。

  4）开发交付：我们主张采用敏捷的方法进行开发交付，将最终目标拆解为多个小目标，逐个完成。同时又将每个小目标拆为多个子项目，每个小团队各自负责一个子项目，所有团队并行开发，协同向前推进。
  a）迭代规划：将项目的最终目标拆分为几个阶段性小目标，每个小目标都能上线交付。这里强调一下，每个小目标都是一个闭环，是一个端到端可验证的交付物。在这个阶段，需要定义好可交付的标准，而不是开发人员常说的开发完成，我们主张是集成部署验证后，才能算作达到可交付的标准。
  b）需求反讲开发：任务确认后，要求开发人员反讲需求，并给出对应的技术解决方案。团队讨论通过后，进行开发。开发阶段，每日召开站立会，同步开发进度和存在的问题，并在看板中加以体现。
  c）持续集成交付：敏捷方法强调开发完成的代码能够立即提交，自动构建测试，强调立刻处理代码冲突并验证。验证的过程强调自动化测试，对可能出现的问题进行预警反馈。集成测试通过后，能够自动将代码部署到类生产环境中，交由用户和质量保障人员验证。这里要强调的是，保障代码的每一次改动都能在任何时候部署到环境中。
  d）回顾总结调整：在每一次迭代完成后，团队及时组织召开总结会议。回顾本次迭代在技术、组织、沟通方面表现优秀的成员，学习先进的技术和方法。总结错误和阻塞的问题，针对性提出改正的措施，并在下一次迭代开始前，做好对应的调整和准备。

  5）持续运营：项目上线后，只是产出业务价值的开始。数字中台需要在持续不断的运营中，不断沉淀和发展。能力会逐步增强和扩展，模型会逐步调整和完善。
  a）业务运营：通过数字中台的能力，我们可以调优传统的业务流程或者尝试新的业务场景，并且反哺数字中台。比如对于电商平台而言，我们需要结合新的互联网玩法，定义新的营销活动。针对不同的行业，业务运营的内容不同。
  b）内容运营：内容运营主要是指通过企业自营渠道、第三方流媒体等电子渠道来建立与客户的连接。连接内容包括向客户推送企业新品介绍、促销活动宣传、企业动态等。数字中台完成内容管理、推送逻辑管理。
  c）技术运营：为了更好地发挥数字中台的作用，需要支持灵活的业务运营和内容运营。因此，数字中台需要不断运用技术栈或反复调整技术参数来适配，常见的有A/B测试技术的使用和策略调整，以及弹性伸缩技术、限流降级技术的使用等。这些内容都属于技术运营的范畴。
  d）数据运营：在线业务需要数据中台的反馈和指导，因此数据中台需要对业务数据进行分析和挖掘。而分析的维度和挖掘的算法需要不断地补充调整以及优化，数据运营则完成这些调整和优化任务。