一、中台技术基础知识

什么是IT中台

为什么我们要强调“IT中台”，而不是“中台”呢？因为“中台”这一概念并不是IT互联网所创造，最先出现“中台”这个词据说是在美国部队中出现的。很多资料在介绍中台概念是引用的例子也是军队：

美军的特种部队加航空母舰的策略：10 人以内的一支特种部队在战斗的最前沿侦查，独立决策，一旦发现目标，迅速呼叫强大的中台航母群对其进行毁灭性打击。

所以我们在此介绍的是IT中台。

最先引入中台的公司是阿里巴巴，由马云提出来的“大中台，小前台”战略。据说是参考芬兰的著名游戏公司SuperCell的中台技术而提出。

芬兰著名的游戏公司 SuperCell，开发了部落冲突、皇室战争等现象级的手游。整个公司才 200 多号人，就被腾讯以 86 亿美金收购。在 SuperCell 里，一个游戏开发团队平均是 3-7 个人，但有一个强大的游戏中台在做支撑，可以并行开发 50 款游戏，然后通过“内部赛马”产生出一到两款经典。据说马云在带领阿里众多高官参观了 SuperCell 后，回来就在阿里整个集团层面启动了大中台战略。

所谓的中台就是：通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来，以减少人与人之间的沟通成本，同时还能某种程度地提升协作效率。

有哪些中台技术？

业务中台

一般指在线业务为典型特征的中台。在 OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。但对那些不是以在线业务为主的企业，它需要的业务中台可能就不是在线业务中台了，而是数据中台或别的什么中台。

数据中台

一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。同样，在 OLDI 时代，数据中台越来越重要。狭义的业务中台也就是在线业务中台负责 OLDI 中的 OL（Online），数据中台负责 OLDI 中的 DI（Data-Intensive）。

用户中台

用户中台可以认为是一种特殊的数据中台，一般以用户 ID 统一、全域用户画像建设、全域会员体系建设等为典型特征。用户中台很通用，比更广义的数据中台往往更常见。很多企业没能力建设更全面的数据中台，但建设了会员中心等用户中台。

内容中台

内容中台往往也可以认为是一种特殊的数据中台，一般以内容的采买、内容爬取、内容的加工处理、内容安全保障等为典型特征。

搜索推荐中台

这两个中台比较像，因为搜索和推荐的技术比较相似。这两个中台一般是为推荐和搜索系统提供一套相对标准的工作流程，同时支持流程各环节的可定制能力，从而支持多个前端推荐搜索业务的快速开发。

中台技术的优势

• 服务重用：真正体现 SOA 理念的核心价值，松耦合的服务带来业务的复用。
• 服务进化：随着新业务的不断接入，共享服务也需从仅提供单薄业务功能，不断的自我进化成更健壮更强大的服务，不断适应各种业务线，真正成为企业宝贵的 IT 资产。
• 数据累积：各个业务的数据都沉淀在同一套中台服务，可以不断累积数据，最终发挥大数据威力。
• 快速响应：更快的通过共享服务的组合响应新业务。
• 降低成本：对于新业务，无需再投入新的重复的开发力量，减少人员成本。
• 效能提升：开发人员更专注某一领域，开发更快，更易维护。

中台技术的典型使用场景

• 业务系统研发团队至少大几十人（含外包的），需求多变化快，系统又涉及多个领域（比如做 ERP、电商的），业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚，提高研发效率。
• 做相似行业的外包项目为主，业务规模也做的比较大的（一年有两位数的项目）。这时业务中台可以提升软件复用，降低定制化成本，提高研发效率。如果你做外包，每个项目都完全不一样，那中台也救不了你。
• 对数据中台来说，比较符合的场景主要是数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。如果这些数据产品和运营人员还在多个团队，那基本上数据中台没跑了。如果经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题，那基本上数据中台也没跑了。

总结

对于中台技术还处于初级阶段，还有很多坑需要探索，对于要不要建设中台，作者本人认为要根据公司具体情况而定。对于小公司就完全没有必要了，基本微服务技术在小公司都能处理大部分问题了，中台技术还是对于大公司来说的。

二、中台建设应包含哪些内容？如何发挥作用

中台应该包含哪些内容呢？什么应该包括在中台里，什么不应该放在中台里？中台与企业现有的ERP、CRM是什么关系？如果建设了中台，中台应当如何发挥作用，而不是又让企业陷入建设另一套IT系统的老路？

01 中台的分类

中台是从多个相似的前台业务应用共享的需求产生的，因此最先提出的中台是业务中台。

数据是从业务系统产生的，而业务系统也需要数据分析的结果，那么是否可以把业务系统的数据存储和计算能力抽离，由单独的数据处理平台提供存储和计算能力，不仅可以简化业务系统的复杂性，而且可以让各个系统采用更合适的技术，专注做本身擅长的事？这个专用的数据处理平台即数据中台。

02 业务中台定义及建设内容

业务中台是阿里巴巴首先提出的作为企业IT架构的转型之道。站在阿里巴巴集团全局的角度，业务中台是从整体战略、业务支撑、连接消费者和业务创新等方面进行统筹规划。因此业务中台深深内含了阿里巴巴做为电商交易的主营业务。业务中台关注的更多的是如何支撑在线业务。

阿里巴巴一开始通过淘宝作为平台方连接商家和消费者，进行电商交易活动。随之发展出淘宝商城即后来的天猫。天猫本质上还是电商交易平台。既然都是电商交易平台，就都涉及售前、售中和售后的业务流程。

业务中台围绕以交易为核心所关联的领域组成。交易的对象是商品，商品通过店铺售卖给会员，交易的凭证是订单，在线交易需要支付，成单后需要货品出库和物流派送等，售前需要营销促销活动吸引流量加强转化，售后用户会对店铺、商品进行评价等。由此，典型的业务中台表现为由多个业务服务中心组成，如图3-3所示。

▲图3-3 一个典型的由服务中心组成的业务中台

会员中心服务于用户的消费全生命周期，为用户提供特定的权益和服务，企业可以通过会员中心进与用户进行互动，培养用户忠诚度。主要能力包括：

• 会员运营管理：会员注册、个人信息维护、会员注销、会员卡办理等相关能力。
• 会员体系管理：会员体系的创建、积分规则、长大值规则、等级、权益等相关能力。
• 客户服务管理：包括客户的新增、导入、查询等相关能力。
• 积分交易管理：包括积分获取、核销、清零、冻结、兑换等相关能力。

商品中心提供管理商品核心数据的能力。围绕商品构建商品关联数据，诸如商品版本信息、商品品牌、商品属性、商品类目等。主要能力有：

• 品牌、类目、属性管理：包括对商品品牌的维护、查询，前后端类目的维护，属性及属性组管理等相关能力。
• 产品数据管理：包括对产品模板的创建、编辑、查询、禁用等相关能力。
• 商品数据管理：包括创建商品、修改商品、查询商品等相关能力。
• 商品发布管理：包括商品发布、上下架（即时+定时）等相关能力。

交易中心负责企业业务交易订单的整体生命周期管理，包括加入购物车车→订单生成→合并分拆→流转→支付→发货→退换货→完成。所有电商业务的核心系统都是围绕交易订单进行构建的。主要能力包括：

• 购物车管理：包括购物车商品添加、编辑、查询、校验等相关能力。
• 正向交易管理：包括交易订单生成、发起支付交易订单、商品发货管理、上门自提及核销等相关能力。
• 逆向交易管理：包括商品换货、退货、退款等相关能力。
• 订单数据管理：包括交易订单数据、支付记录、发货记录、换货记录、退款记录等数据管理能力。
• 交易流程编排：支持交易流程节点的配置化，便于根据业务场景的不同设置与之匹配的流程。

评价中心提供对评价主体对象、评价规则/等级、评价内容、评价操作的管理能力，从而满足了不同角色的评价用户对评价内容的发布、追加、平台审核、平台申诉等需求。主要能力包括：

• 评价内容管理：包括评价的主体对象管理、评价规则配置、评价等级、评价标签配置管理等相关能力。
• 评价操作能力：包括评价的发布、修改、追加、回复、申诉等相关能力。
• 评价监管能力：包括评价发布审核、申诉审核、评价屏蔽等监管相关能力。

店铺中心提供企业店铺主体管理、店铺管理、类型管理、经营对象管理等能力以支持企业为其商户用户提供线上门店，同时也支持商户管理、店铺会员、店铺会员等级管理、店铺装修等。主要能力包括：

• 商户管理：包括商户单个、批量开通，商户审核，商户基本信息维护等相关能力。
• 店铺管理：包括店铺开通、店铺基本信息维护、店铺审核、店铺会员等相关能力。

支付中心给下游商户输出标准的支付服务，提供代付代收、财务对账等服务。通过对接多个主流渠道，稳定输出微信、支付宝、银联等支付能力。主要能力包括：

• 支付能力：包括创建支付订单、接收渠道通知、渠道订单查询等基本支付能力。
• 支付路由：包括支付渠道管理、支付方式管理、支付商户和应用开通管理等相关能力。
• 资金账户：包括资金账户管理、充值维护、提现等相关能力。

营销中心提供商家的活动计划、申报、审批、执行、核销的全链路管理，也提供了基本的促销能力，如优惠券活动、满减买赠等。主要能力包括：

• 活动模板管理：包括营销活动的策略模板、规则配置、条件、动作模板等相关能力。
• 活动管理：包括具体活动的基本信息配置、人群圈选、商品管理、触发条件等相关能力。
• 优惠券管理：包括优惠券的发放、领取、查询、使用核销等相关能力。
• 赠品管理：对于满赠、买赠活动，提供赠品维护、查询、启用、禁用等相关能力。

库存中心提供仓库、库存、货品、单据（入库单/出库单/盘点单/盘点盈亏单）、审核（调拨/盘点），包裹、货品运费、物流运输、接入第三方物流公司的服务能力。主要能力包括：

• 仓库管理：包括服务区、仓库、仓位及其关联管理等相关能力。
• 货品管理：包括货品进货入库、销售出库、调拨入库、调拨出库、调拨审核等相关能力。
• 货品盘点：包括盘点单生成、审核、查询等相关能力。
• 履约管理：包括库存检查、发货单创建及查询、包裹物流查询、运费管理、物流状态跟踪等相关能力。

建设了一套中台系统，则可同时运用在多个电商平台的开发设计和服务中。因此，中台可以为同时建设运营多套电商平台的互联网企业节省系统建设和运营成本。因为既可以避免功能重复建设，又可以通过全渠道打通会员、增加流量、互相促进，还可以减少运营成本和人员。有了中台，再发展电商相关应用就会变得更加容易。比如，阿里巴巴发展出的聚划算。

如果使用传统的系统思维来设计业务中台，很有可能只是将原先隔离的各业务系统通过微服务的方式，强行集成在一起，如图3-4所示。这种方式构建的微服务不是纯粹的领域建设，而是一个系统的粒度层次。比如PMS会涉及用户和订单，OMS也需要关注会员和订单，CRM同样涉及会员。

因此，按此方式建设的所谓中台，它的各组成部分还是互相交叉重叠的，并不能体现中台是能力共享平台的核心理念。所以，只将企业业务系统做了一个大一统的集成，并不是中台。

▲图3-4 传统思维下所建设的“业务中台”

03 数据中台定义及建设内容

• 数据中台是什么？
• 数据中台与数据仓库有什么区别？
• 数据中台到底怎么与业务中台融合？

一直以来，这是被问到的最多的三个问题。本节将试着对这三大问题进行一一解读。

在回答数据中台是什么这个问题之前，先了解一下大家比较熟悉的数据仓库是什么。在以BAT为首的互联网公司蓬勃发展起来之前，国内三大运营商对于数据仓库的建设走在其他行业的前面。

早在2011年的时候，中国移动集团公司就组织编写了指导各省公司建设数据仓库的纲领性文件《中国移动NG2-BASS3.0建设规范》。在文件中明确将中国移动的业务分成了7大业务板块，按照功能将数据资产划分为三层：数据层、功能层、应用层。这是很典型的数据仓库建设的分层模式，如今的数据中台数据分层建设模式也延续了数据仓库的分层建设规范，后面会详细讲到。

图3-5是应用层规划的内容，详细规划了每个应用领域的数据应用。但是仔细研究可以发现，这些数据应用几乎全是“分析”，也就是解决了事后“看数据”的问题。

▲图3-5 中国移动数据仓库分层模型

再来看看图3-6中阿里巴巴的数据中台支撑的数据应用层，除了通用的数据分析以外，还包含了“个性化推荐”、“风险评估”、“预警监控”等与业务紧密结合的数据赋能业务的应用。而这些丰富的赋能业务的数据应用必须依赖数据中台提供的强大的数据服务支撑。

▲图3-6 阿里巴巴数据中台总体架构

通过上面的对比不难看出，数据中台与数据仓库最大的区别就是数据中台更加贴近业务，不只提供分析功能，更重要的是为业务提供服务，与业务中台或者业务系统（老旧系统）链接更加紧密了。

就拿大家比较熟悉的“千人千面”案例（如图3-7所示）来说，除了要整合业务系统产生的用户基础属性、订单、评价、加入购物车等行为数据，还要通过埋点的方式实时获取用户偏好浏览、搜索、分享商品等行为数据，经过数据中台一系列的数据加工处理后，最终以微服务的形式提供。

在业务系统每个需要呈现商品给目标用户的数据服务处，已不是简单的、一成不变地去商品库查询数据，而是调用数据中台提供的商品推荐接口，以此来根据不同的人群偏好、浏览历史、商品相似度等数据来为每个人推荐他最感兴趣的商品。试问这种业务、数据紧密联动的场景在数据仓库时代又如何能做到呢？

▲图3-7 数据中台与外部系统交互

在介绍完数据中台与数据仓库的区别之后，我们再回过头谈谈数据中台到底是什么。首先说说数据中台不是什么。

第一，数据中台不等于大数据。近些年来，“大数据”这个名词可能是被提及最多的词汇之一，大数据甚至成为国家战略。同时，“数据中台”也正是在大数据概念兴起之后应运而生的。因此，不可避免的，相当一部分人把数据中台和大数据划等号，一提到数据中台，天然的就想起Hadoop、Spark等大数据处理技术，这样的想法是不对的，这些大数据处理技术只是数据中台的基础设施提供者。大数据技术的大行其道，加速了数据中台战略成熟。

第二，数据中台也不是一个研发工具。最近一段时间，在市面上流行着一种说法，说某某公司有一个数据中台产品，可以直接卖给某某客户。这种说法是在忽悠客户。实际提供给客户的仅仅是一个可视化的研发工具而已。数据中台一定是整合了企业自身的数据并经过加工、治理后形成的企业自身的数据资产平台。试问，根本还没了解客户到底有什么数据的情况下，如何能说自己有一个数据中台产品呢？

那么如何定义数据中台呢？我们也曾尝试在网上找到一个标准答案，找过首倡“数据中台”概念的阿里大咖们寻求标准答案。最近网络媒体上各种数据中台分享、解读、峰会纷纷扰扰，各种解读真是乱花渐欲迷人眼，但都没有得到一个很精炼、标准的数据中台定义。但越是没有标准，越是被人问得多，这就是为什么开篇提到的第一个问题就是“什么是数据中台”。

经过这些年来对数据中台的一腔热血，也曾经为此翻阅大量资料，力求言简意赅，力求精准定义，我们认为：数据中台是一个用技术链接计算存储能力，用业务链接数据应用场景的能力平台。

“链接能力”是数据中台的精髓。作为一个处在中间层的能力平台，“链接”是其根本的任务。

• 在业务层面需要尽可能链接各种数据源作为其生产资料；
• 同时，由于生产数据的场景越来越多，覆盖了线上、线下等多渠道，各数据生产资料之间也需要进行链接，才能形成全域的数据；
• 数据在数据中台这个平台上按照标准的模型进行规范的加工处理后需要服务于多种场景，同样需要我们提供标准的数据服务接口将数据与应用场景链接起来。

因此，链接是数据中台的根本能力，也是数据中台的价值所在。

04 业务中台和数据中台的关系

无论是业务中台还是数据中台，都是在企业IT系统架构演进过程中形成的，并从企业自身IT系统规划、建设、运营、运维等多年的经验中提炼出来的共性能力。

业务中台和数据中台作为两个轮子并肩构建了数字中台，支撑前台对会员的从营销推广、转化交易到智能服务业务的闭环，促进企业业务的提升和发展（如图3-8所示）。数字中台对内连接企业的后台系统，诸如ERP、人力资源、协同办公、财务管理等。

▲图3-8 业务中台与数据中台双轮驱动的数字中台支撑前台业务

业务中台抽象、包装和整合后台资源，转化为便于前台使用的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化，为前台应用提供了强大的“炮火支援”能力，随叫随到。业务中台的共享服务中心提供了统一、标准的数据，减少了系统间的交互和团队间的协作成本。

数据中台接入业务中台、后台和其它第三方数据，完成海量数据的存储、清洗、计算、汇总等，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。可以认为数据中台为前台战场提供了强大的“雷达监测”能力，实时掌控战场情况，料敌先机。

不过数据中台所提供的数据处理能力和之上建设的数据分析产品，也不局限于服务业务中台。数据中台的能力可以开放给所有业务方使用。

从前台应用的角度，业务中台所提供的“炮火支援”能力和数据中台所提供的“雷达监测”能力是一体的，并不是截然独立的。业务中台与数据中台相辅相成，互相支撑。对于业务方来说，自己产生数据，并同时消费自己的数据，在消费自己的数据时又在继续产生数据，从而形成数据闭环。

打个比方，业务沉淀数据是产矿，将数据导入到数据中台是探矿和挖矿，数据中台对数据进行建模等加工处理是对矿物的加工提纯，通过数据服务指导业务的开展则是矿产再生的过程。业务中台和数据中台只是技术实现方式不同，但它们一起组成了支撑业务创新的两只轮子，缺一不可。

本文摘编自即将出版的新书《中台战略：中台建设与数字商业》，经出版方授权发布。

三、5步搭建你的业务中台

只需5步搭建你的业务中台

2019-09-23 07:56·CIO之家

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.持续运营

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