业务中台设计方法论

        上篇文章，我们从消费互联网到产业互联网中聊了数字营销，聊到了中台的背景和历史，在互联网中的概念，以及，我们可以将中台分为具体的三个类别，分别是业务中台、技术中台和数据中台，今天，我们接着来聊一下第一个中台–业务中台的设计方法论，关于业务中台的设计原则、中心规划、划分标准成熟度模型评估、落地方法等等以后找机会再写一篇blog来详细描述。


        为什么第一个要讲的中台是业务中台？而不是技术中台或者数据中台？
其实所有的技术和数据都来源于业务，可以说，技术和数据都是因为业务而产生的，业务产生数据，数据支撑业务，所以，我们先从业务中台说起。

一、形与本质

        其实归根到底，业务中台本质上是一个体系或系统，它实现了企业核心的业务运行机制，因而处于企业运行生态的核心位置，所有应用系统都必须和它建立联系。


        有不同的看法认为，中台的存在只是为了抽取可复用的能力，但反过来思考一下，这些能力为什么可以复用呢？


        实践证明，业务能力输出的内容主要是核心业务数据和业务流程，从单一业态的价值链来看，每一个业务环节的产出不仅会影响到下游环节，还会反作用于上游环节，必然要求每个业务环节将其核心业务数据实时共享出来，这是为什么需要能力复用的一个根本原因。从单一业态不同业务场景来看，对同一领域的业务对象的需求基本一致，比如电商和门店都需要查询和修改商品，必然要求业务领域提供类似的能力。


        从不同业态来看，由于商业规律从宏观来看，本质是相同的，因此必然要求每个业务领域提供基于流程的可复用能力。综上所述，众多的可复用能力只是中台的形，核心的业务数据和业务流程才是中台存在的本质。

二、能力与分类

        讲到业务中台，就不得不提业务中台的能力。能力本身也是一种功能，但是它是更加抽象的功能，是多个相似功能的抽象实现。能力的基础是结构和运行机制，功能则是具体的展现方式。


        例如，财务部门基于方便成本核算的考虑，要求定义偏财务的产品类目，这是一种分类功能；业务部门基于方便市场管理的考虑，要求定义偏市场管理的产品类目，这又是另一种分类功能。


        对于中台而言，这两个功能属于同一个能力：中台的类目结构支持按不同维度定义分类，并支持建立不同类目的映射关系。能力是系统内生机制的体现，在不同的业务场景下，表现为不同的功能。类比一下，河流具有流动的能力，那么可以用河流运送木头，也可以载人，运送木头和载人都是流动能力运用到不同场景的功能体现。业务能力的多少决定了业务中台的含金量。

三、建设中台要诀

那么如何着手建设中台呢？建设中台有四句要诀

• 能力支撑是基础
• 中心自治是承载形式
• 三层模型是骨架
• 五步法四指导思想

1.能力支撑是基础

        业务中台居于整个企业数字化平台的中间层，从全局的角度来观察，业务中台是上层应用建设的基础，它提供了应用功能所依赖的业务能力。
应用功能建立在能力的基础上。例如，手机端提供手机号登录的功能，PC端提供邮箱账号登录的功能，这两个不同应用功能都依赖于用户中心多认证方式的业务能力。


        通过对业务能力顺序编排实现业务流程。以电商下单为例，分别需要经过库存校验、优惠计算、订单计算3个节点。这3个节点分别对应库存中心、促销中心、交易中心这3个中心提供的能力。通过对这3个中心能力的编排，就实现了下单流程。


        通过将不同能力的返回结果聚合为一个有针对性的数据集，满足用户需要。例如在用户检索商品时，系统往往需要将商品的库存和商品详情拼成一个数据集合返回给用户。
综上所述，中台能力为应用功能的实现打下了坚实基础。衡量业务中台价值的一个重要标准就是中台业务能力的丰富程度。

2.中心自治是承载形式

        中心是一个独立的体系，它能够独立运营，支撑多个业务场景。同时，它也是中台能力的物理载体，既提供了中台能力的编码实现，又在运行时生成一个物理进程承载多个中台能力。


        这里的中心需要区别于微服务，从业务上来讲，中心实现的业务范围比微服务更大，中心是多个或多类型业务实体的聚合，而微服务一般指一个业务实体或一类业务实体的聚合。例如商品中心既提供类目也提供商品属性，而类目微服务只提供类目服务。


        从技术角度看，中心具有复杂的内部组件结构和数据流关系，微服务追求的是简单和轻量，一个中心可以由多个微服务组成。


        中心自治在业务上要求中心能够独立运营，比如商品中心可以提供多个维度的类目定义供前端用户查询，而不需要横向依赖其他中心提供的能力。（独立是相对概念，在现实世界中任何一个业务都可能与其他业务发生直接或间接的关系。这里的独立是指进程的独立、物理代码的独立。）


        在技术上，中心具有独立的生命周期，包括中心启动、运行、停止三种状态。我们可以通过运维的技术手段观察和控制某个中心的生命周期，而不会影响到其他中心的生命周期。

3.三层模型是骨架

        既然业务中台是一套体系，那么从系统论的观点来分析，它一定具有层次结构和相互联系。联系自不必说，业务中心间的关联关系错综复杂。那么层次结构呢？根据DDD的分析，我们可以看到领域模型分为核心域、支撑域、通用域，但是我们认为这远远不能揭示复杂的业务世界，原因如下：

        第一，这三个分类边界模糊，核心域的内容难道不可以是通用的吗？


        第二，这三类领域的比较都是以功能角度去考虑，难道功能就应该是划分领域的标准吗？


        第三，我们划分领域的标准是不一致的，能否通用是一个维度，是否为核心则是另外一个维度。




        我们认为，既然业务中台分析的是业务规律，那么我们对业务领域的划分也应该回归业务的角度。业务世界有什么信息在暗示我们吗？


        业务活动的目标。所有的业务功能都是为了达到目标而存在，我们将目标相同的功能归为一类，那么这些功能自然是紧密耦合、协同不可分的。


        业务功能按照目标的不同分为两大类：为了管理好企业资源而存在的业务功能，以及为了管理好经营活动而存在的功能。系统论明确指出，层次在系统中是客观存在的。因此我们再深入一层剖析，将经营活动按是否必要划分为核心类业务活动和支撑类业务活动。

        所以业务中台从下向上可拆分为业务实体层、业务协作层和业务活动层，如下图。该分层结构不仅定义了业务中台的结构，也定义了数据流向、服务依赖关系、单次事务的调用次数等。我们可以基于此定义中台的开发规范。

        1）业务实体层（Business Entity Layer，BEL）：由对静态业务实体进行管理的中心所构成，也就是我们分析的企业静态资源管理。静态资源包括通用业务对象，比如省地市、元数据，还包括商品、会员、用户等。

        2）业务协作层（Business Collaboration Layer，BCL）：由以完成或管理支撑类业务活动为目标的中心所构成，比如促销中心、评价中心等。本层的中心并不一定是业务活动不可或缺的部分（或者说主流程的一部分），但是没有这些支撑类的业务中心，我们的服务和业务水平就不能更上一层楼。

        3）业务活动层（Business Activity Layer，BAL）：由以完成或管理核心类业务活动为目标的中心所构成，比如交易中心、供应中心、物流中心等。本层的中心都是企业业务活动必不可少的部分，它们为业务活动提供了核心运行机制。

        中台的内部层级关系确定下来后，接下来就需要确定层级间的依赖关系了。层级间的依赖，其实就是不同类型中心的调用关系和异步数据流动关系。

        静态资源是一个企业经营的基础，上层业务活动需要实时获取企业资源以完成业务活动，这是商业的本质规律。因此业务实体层向第一层和第二层提供了能力以被调用。第二层是业务协作层，本层的目标是支撑核心层的业务活动，因此从逻辑上看，本层只有提供能力随时准备给核心层调用，才能实现支撑的目的。

        业务活动和业务协作反作用于资源层，是希望资源层做出相应的调整。我们往往不需要也没有必要对这样的希望进行实时反应，因此上层的反作用以事件异步流动的方式向下传递。支撑层也是同样道理，活动层对协作层的反作用往往不需要实时，因此异步流动是最好的选择。

        如果我们将同层内各中心按业务流程的先后顺序，从左向右排列，那么中心领域事件会从左向右驱动业务流程的运行。反过来，下游业务中心往往需要根据上游业务的最新状态来选择业务动作，此时，就需要进行反向实时调用。

4.五步法四指导思想

        数字中台建设的整体策略，核心思想是从业务抽象到领域建模，再到架构设计。因此业务中台的架构思路和整体策略保持一致，并进行必要的补充，下图所示为业务中台建设的五步法。

1.业务抽象

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

（1）业务调研

        通过座谈会、调研表、实地考察等多种方式获取业务素材，深入理解企业业务和感受企业面临的竞争。调研前，需要做好调研的计划、调研道具等；调研中，积极有序引导，良好互动，详细记录，保证调研的质量；调研后，及时汇总整理调研内容，初步梳理加工后形成调研纪要。如何做好调研不是本节的重点，在相关专业书籍中有详细介绍。这里需要强调几个和传统IT咨询调研不同的地方。

        业务调研参与人就是中台交付人，因为只有这样才能保证对业务的准确理解可以完整地传导到设计、实施过程中。调研参与人不仅有产品经理、业务架构师，还应当包括技术架构师。这里的技术架构师既包括业务中台的技术架构师，也包括数据中台的技术架构师。为什么技术架构师要参与业务调研呢？因为我们的核心目的是设计业务中台和数据中台，只有正确理解了业务，技术架构师才有可能遵从业务规律，进行业务模型的抽象和设计。

        我们主张数据中台和业务中台的设计，应该交由同一个架构师团队来统一设计（极端一点，也可以是以一个人为主，由他全程负责）。业务中台和数据中台的架构师在一个团队中，后期在领域模型设计阶段才能相互融入，我们称之为无缝对接。因为业务中台的领域模型，是大数据架构师设计数据分析模型的基础，只有深入理解了业务中台的领域模型，才能设计好数据中台的数据分析模型。另外，当业务中台的领域模型发生变更后，设计团队能快速评估影响，设计出数据中台的调整方案；相对地，数据分析模型变更，比如增加或减少了变化因子，设计团队能快速评估影响，设计出业务中台支持或调整的方案。

        这里的调研分析不同于传统的系统调研。我们更加强调的是，以面向中心的思想来探讨业务，认为业务流程只是形式，核心是各领域中心的结构和运行机制。各中心的设计需要满足业务流程的需要，但是这不是核心目的。我们主张在业务调研过程中进行领域模型的探讨，反复思考逐步清晰业务领域的边界。

（2）顶层业务分析

        在业务调研结束后，结合行业趋势、类似项目的比较以及自身的经验，输出企业的商业模式和核心业务场景。业务场景包括企业级业务场景、部门级业务场景和操作级业务场景。并在业务场景梳理过程中，找出企业痛点。最终设计出企业TO-BE的业务蓝图和应用蓝图。

（3）业务抽象

        通过顶层业务分析，明确了总体方向后，我们便可以展开对具体业务场景的梳理和抽象，并输出功能需求清单。在此过程中，还需要定义出功能操作的业务对象或业务实体。基于业务实体，结合对应的功能需求，定义出需要系统提供的能力。根据能力的主题和实体间的密切关系，我们便能对实体进行归类，定义出主题域(这个以后找机会写一篇blog来展开描述)。

2.高阶设计

（1）中心规划

        经过业务的调研和分析，技术架构师理解并熟悉了业务。基于上阶段输出的主题域，技术架构师按照中心的多个划分标准，进行中心的规划(这个以后找机会写一篇blog来展开描述)。

（2）0级架构设计

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

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

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


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

• IaaS层：完成硬件资源的虚拟化管理，为用户提供对资源的使用服务。
• PaaS层：为应用软件提供部署平台和运行环境。
• 基础组件层：介于业务服务和技术中间件之间，提供通用的业务功能和技术功能，并解耦业务应用和技术中间件。
• 数字中台层：分为业务中台和数据中台，实现企业业务活动的核心机制，并通过数据中台对业务运营提供指导。
• 业务应用层：通过调用和组合中台能力，实现应用逻辑。
  技术层级的0级架构需要说明各系统、各中心分别使用什么技术来实现，以及整个体系的技术分层,参考下方的图片。

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

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

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

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

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

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

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

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

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

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

3.组件建模

（1）产品设计

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

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

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

（2）组件模型设计

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

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

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

（3）1级架构设计

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

（4）关键交互图设计

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

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

4.开发交付

        我们主张采用敏捷的方法进行开发交付，将最终目标拆解为多个小目标，逐个完成。同时又将每个小目标拆为多个子项目，每个小团队各自负责一个子项目，所有团队并行开发，协同向前推进。本节只对敏捷开发方法做概要说明，如有需要可参考相关专业书籍。

（1）迭代规划

        将项目的最终目标拆分为几个阶段性小目标，每个小目标都能上线交付。这里强调一下，每个小目标都是一个闭环，是一个端到端可验证的交付物。在这个阶段，需要定义好可交付的标准，而不是开发人员常说的开发完成，我们主张是集成部署验证后，才能算作达到可交付的标准。

（2）需求反讲开发

        任务确认后，要求开发人员反讲需求，并给出对应的技术解决方案。团队讨论通过后，进行开发。开发阶段，每日召开站立会，同步开发进度和存在的问题，并在看板中加以体现。

（3）持续集成交付

        敏捷方法强调开发完成的代码能够立即提交，自动构建测试，强调立刻处理代码冲突并验证。验证的过程强调自动化测试，对可能出现的问题进行预警反馈。集成测试通过后，能够自动将代码部署到类生产环境中，交由用户和质量保障人员验证。这里要强调的是，保障代码的每一次改动都能在任何时候部署到环境中。

（4）回顾总结调整

        在每一次迭代完成后，团队及时组织召开总结会议。回顾本次迭代在技术、组织、沟通方面表现优秀的成员，学习先进的技术和方法。总结错误和阻塞的问题，针对性提出改正的措施，并在下一次迭代开始前，做好对应的调整和准备。

5.持续运营

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

（1）业务运营

        通过数字中台的能力，我们可以调优传统的业务流程或者尝试新的业务场景，并且反哺数字中台。比如对于电商平台而言，我们需要结合新的互联网玩法，定义新的营销活动。针对不同的行业，业务运营的内容不同。

（2）内容运营

        内容运营主要是指通过企业自营渠道、第三方流媒体等电子渠道来建立与客户的连接。连接内容包括向客户推送企业新品介绍、促销活动宣传、企业动态等。数字中台完成内容管理、推送逻辑管理。

（3）技术运营

        为了更好地发挥数字中台的作用，需要支持灵活的业务运营和内容运营。因此，数字中台需要不断运用技术栈或反复调整技术参数来适配，常见的有A/B测试技术的使用和策略调整，以及弹性伸缩技术、限流降级技术的使用等。这些内容都属于技术运营的范畴。

（4）数据运营

        在线业务需要数据中台的反馈和指导，因此数据中台需要对业务数据进行分析和挖掘。而分析的维度和挖掘的算法需要不断地补充调整以及优化，数据运营则完成这些调整和优化任务。

总结: 业务中台设计的方法论其实最核心的就是五步法四指导思想,业务中台是业务运行的核心机制提供者，也是企业业务运行指导方针的一个支撑，五步法四指导思想的设计一样也是不能一步到位的，它也会随着业务顶层架构的变化不断的快速推进，同样的，这也是中台需要具备的一个特点。

ok，数据中台设计方法，下篇见。

my blog

笔记已同步至我的博客园，欢迎访问哈

我的博客园 https://www.cnblogs.com/huangyingsheng/p/12974564.html