3 业务中台建设
业务中台是以业务领域划分边界,形成高内聚、低耦合的面向业务领域的能力中心,打造持续演进的企业级业务能力共享服务平台。直观呈现就是各能力中心。
业务中台的建设对象包括业务对象,业务能力,业务规则,业务流程,业务配置,业务隔离。
3.2 业务中台的核心架构
纵向划分
中台将企业的业务内容,按照不同领域,以及是否能独立运营为标准,进行纵向切割。
对切割后的大小各异、算不上严谨的多个业务领域,中台从技术上再进行一系列的分析、抽象、归类、推演,形成在业务上能独立运营、技术上包含多个微服务的系统。
切分后的系统,我们一般称为能力中心,比如用户中心、消息中心、营销中心、调度中心、流程中心等。
横向划分
在纵向划分的基础上,从下而上拆分为业务实体层、业务协作层、业务活动层。
3.3 业务中台构建策略
领域驱动设计战略阶段
业务中台建设的战略阶段的核心目的是划分问题域,确定核心领域,整理限界上下文。
领域按照类型可划分为核心领域、支撑子域和通用子域。
实现业务愿景和价值的主要系统功能既是核心域,支撑核心域的子域为支持子域,而相对通用的子域称为通用子域。
限界上下文为领域提供上下文语境,确保领域内的术语在其特定的边界范围内没有二义性。
领域驱动的业务中台在构建过程中,先从业务维度出发,开发者与领域专家梳理出业务关键的核心域和支撑子域,过程中,会浮现出通用系统需求及出于技术维度考虑的场景,从而形成通用子域。
在领域划分的基础上,将业务领域划分为通用能力域及商业能力域。
前者比如用户管理、登录认证、消息发送、数据字典、调度中心、流程中心、基础数据中心等通用功能。
而针对客户互动相关的场景,涉及商品中心、交易中心、库存中心、会员中心、营销中心等促进商业行为的领域,形成商业能力域。
战术阶段
更关注领域内部,一般用领域模型来表达领域知识。常见领域模型包括聚合根、实体、值对象、领域服务、领域事件和聚合等。
每个实体都会涉及状态的改变,而状态改变的动作可以触发一个领域事件,一般是名词+动词过去式。
某一个动作可能涉及其他上下文的领域对象,可以通过领域服务进行协调,从而保证不同上下文的一致性。
基于事件风暴Event Storming的DDD
戏称糊墙。核心是协同共创,要求领域专家、业务架构师和技术人员以协同的方式迭代探索,构建出领域模型。
事件风暴的基础来自领域事件,即角色在业务上的操作导致系统的响应。
首先,事件风暴的展开是基于业务场景。领域专家识别出业务场景。
然后,展开每个业务场景,从左到右识别出该场景下的领域事件,以及触发该事件的命令和角色。
这些事件流是后续建模工作的输入,基于这些事件可以逐步推演出领域模型。
如何基于事件风暴构建业务中台领域模型
1) 业务架构师和领域专家主导,带领团队按照业务场景识别领域事件、命令和角色,并按照时间排序。
2) 业务架构师和领域专家带领团队,基于战术层的业务场景和事件流提炼子域。对于中台而言,可以认为子域是能力中心。但是此时,能力中心还处于问题域空间,没有任何解决方案。
3) 技术人员带领团队基于事件流提取业务元素,识别实体、值对象和聚合。
4) 技术人员带领团队,跨越到战略层,识别出限界上下文及其映射与集成的关系,并验证是否有足够能力解决能力中心的问题。此时,能力中心的问题有限界上下文解决,业务中台架构终于从问题过渡到解决方案。
3.4 业务中台构建五步法
3.4.1 高阶规划
包括宏观业务规划和宏观技术规划,是提纲挈领的过程。
宏观业务规划就是分析企业的核心业务场景,解剖企业整体及局部存在的问题和痛点,从宏观上规划出业务蓝图及业务解决方案,是一个顶层设计的过程,无须深入每一个具体的业务场景。
宏观技术规划,就是通过对核心业务场景、宏观业务蓝图的理解和分析,推导出宏观的业务领域与业务中心,然后以此为基础,设计出宏观的0级架构的过程。
0级架构要解决的是如何拆解系统才能承接和支撑业务蓝图的问题,包括能力中心、应用以及需要集成的三方系统及其相互关系。另外还需体现分层的职责。
3.4.2 领域分析
包括3个部分:
业务场景梳理
根据高阶规划划分的业务领域,梳理各领域的业务场景。结合场景存在的痛点,规划未来的系统功能,进一步设计出对应的系统原型。
领域模型推导
根据场景清单,采用事件风暴梳理总结出领域事件清单。再根据领域事件,抽象归纳出领域模型,包括领域活动、领域事件、领域对象、领域规则等。
再以领域模型为基础,按照模型之间的关系,推导出业务子领域。
最后分析各子领域的职责与整体目标的相互关系,我们就能推导出能力中心。
高阶规划调整
推导出能力中心后,需对高阶规划阶段预设的能力中心进行比较,根据需要对内容和0级架构进行调整。
3.4.3 中心设计
组件规划
明确根据领域模型规划出的能力中心由哪些业务组件组成。
I级架构设计
I级架构聚焦具体业务场景下,各中心、各应用如何各司其职、承载所属的数据和业务逻辑,即通过具体业务场景,将各中心的能力和领域事件串联起来。
中心概要设计
是从系统设计到开发交付的过渡阶段。包括设计数据库概要模型、功能包结构、核心时序图、接口设计等,为中心的详细设计和开发奠定基础。
3.4.4 开发交付
中心详细设计、测试用例设计、代码开发、持续交付等。
中心详细设计包括数据库物理模型设计、具体能力的时序图、类图等。
3.4.5 持续运营
业务运营
利用业务中台的管控能力,结合数据中台的各类分析视图、趋势预测,调整原有的业务运营措施或者增加新的业务试错方案,驱动业务发展。
内容运营
技术运营
通过中台控制平面,快速调整业务配置,灵活调用编排能力,聚合不同内容,以满足业务运营的需要。
对于不能动态调整的场景,需要扩展已有能力或增加新的能力。
中台控制平面与执行平面的交易引擎、营销引擎、链路监控等一系列技术结合,组成管控和执行体系,助力技术运营。
数据运营
业务需要数据的反馈和指导,同样,中台能力建设也需要数据的指引。因此,数据运营不仅会帮助企业进行业务的调整和优化,还可以指导中台能力的迭代。
3.5 业务中台与其他系统的集成
企业应用与中台存在哪些关系
一是在中台上新建应用,替换原有应用。
二是部分改造原有应用,将其与中台对接。
三是企业应用目前是稳态应用,中台需要借助这些应用已有的功能或者数据,集成这些应用。
集成策略
需考虑3个原则:
耦合性:设计松耦合的架构,来确保业务中台的独立性和完整性。
侵入性:中台与其他系统集成时,需抽象出一套标准接口,统一实现外部系统的对接,以减少对业务中台的功能代码的改动。
可靠性:需要保证无论是中台还是其他系统出现故障时,都有完善的容错和重试机制,确保系统恢复正常后业务能够继续开展。
综上,为保证中台的业务独立性、降低对外部系统的依赖、提高集成的效率和系统的容错性,需要设计一个中台连接器,来统一实现和管控与第三方系统的对接。起到DDD中防腐层的作用。
中台连接器可以解决的几个问题:
第一中台连接器能够隔离中台与外部系统,避免外部系统的复杂影响业务中台本身的纯粹性。
第二有中台连接器进行数据统一适配转换,解决各系统数据不一致的问题,降低数据维护成本。
第三当数据有错漏时,中台连接器进行数据重试。提供重试机制,并且可以手动批量调整数据状态进行重放。
第四,当中台与各系统对接数据场景不一致时,中台连接器备有预留扩展。对于不满足的场景,增加开发新的适配器即可。
常用的集成方式
接口调用:Restful或RPC
消息队列
文件传输
共享数据库:一般避免直接暴露中台的生产数据库,因为可能导致性能问题。可以主备方式,实时同步一个只读库。
4 数据中台建设
想要了解战场情况、指挥炮火打向哪里,就需要数据中台。
数据中台是将企业数据变成资产,持续使用数据、产生智能、为业务服务,从而实现数据价值变现的系统和机制。
数据仓库 vs 数据中台
统计分析,预测分析
被动分析,主动分析
非实时分析,实时分析
结构化数据,结构化、半结构化和非结构化数据
数据中台包括大数据处理技术(比如HBase保存数据,Spark批量分析数据,Flink实时接入和处理数据),人工智能技术。
大数据丰富的数据计算和存储技术为数据中台提供了强大的数据处理能力。
数据仓库对数据的分域建模是数据中台的主要部分,实现将企业数据治理得井井有条的能力。
基于强大的数据能力,结合业务场景提供实时、智能的服务和应用是数据中台的核心价值体现。
4.2.1数据中台功能架构
工具平台层
数据开发平台,包括数据采集、存储和处理。
数据资产管理
首要任务是管理好进入数据中台的元数据。
标签工厂
数据标签是数据中台走向数据业务化的关键步骤。
标签工厂一般分为底层的标签计算引擎和上层的标签配置与管理门户。计算引擎有MapReduce、Spark、Flink等大数据计算框架,标签存储可采用ES或HBASE。
ID-Mapping
又称ID打通工具。一般利用强大的图计算功能,通过两两关系实现互通,自动高效地将关联的身份映射为同一身份即唯一ID的数据工具。
机器学习平台
流程包括模型训练的代码开发,数据准备,清洗,标注,特征提取,超参数的选择及优化,训练任务的监控,模型的发布与集成,日志的回收等。
机器学习平台支持训练数据的高质量采集与高效标注,内置预训练模型,封装机器学习算法,通过可视化拖曳实现模型训练,支持从数据处理、模型训练、模型部署为在线预测服务,通过RESTful API与业务集成。
统一数据服务
门户,作为唯一的数据服务入口,实现数据的统一市场化管理,在有效降低数据开放门槛的同时,保障数据安全。
数据资产层
主题域模型区
将业务过程或维度进行抽象的集合。
标签模型区
按计算模式分为客观标签和主观标签,前者可以量化,后者不可。
按照实现方式又可以分为事实标签、模型标签、算法标签等等。
根据业务场景可以分为基础信息标签、偏好标签、价值标签等等。
算法模型区
模型搭建过程包括定场景、数据源准备、特征工程、模型设计、模型训练、正式上线、参数调整7个环节。
数据应用层
分析与决策应用
为企业提供可视化分析。快速获取企业现状和问题,同时可对数据进行钻取、联动分析等,深度分析企业问题及其原因,辅助企业进行管理和决策,实现数字化管理和智能决策。
标签应用
旨在挖掘实体对象的特征,将数据转化为真正对业务有价值的产物并对外提供标签数据服务,多用于客户圈选、精准营销和个性化推荐等,从而实现资产变现,不断扩大资产价值。
智能应用
实现千人千面的个性化推荐。
进行高精度的用户触达,推动首购转化、二购促进、流失挽留等。
4.2.2数据中台技术架构
技术平台建设
技术平台是支撑业务中台和数据中台发展的基石。
不同于技术中台。技术中台主要是提供常见的互联网技术中间件服务,包括消息队列、分布式缓存等。
11.2 中台的进化路径
中台是逐步建设成长起来的。
11.2.1 第一阶段:领域微服务化
根据选定的应用场景,将应用按能力领域拆分。可以看做是企业开始建设中台的切入点,比如先做会员相关的领域,或者选择电商相关的领域。
不过,这样的中台形成不了从营销、交易到服务的闭环,无法形成完整闭环,只是中台的雏形,中台0.5。
这一阶段的重点在于共享能力的沉淀。沉淀的过程也是中台自我演进的过程。
在深度上,中台团队在支撑上层业务的过程中,随着不同业务场景的持续输入,不断沉淀新的业务能力,使得各能力中心的能力越来越丰富。
广度是指中台涉及的领域会越来越广,可能出现与现有能力中心相对独立的新领域,则将其建设成为新的能力中心,这同时也是在建设和加强中台。
11.2.2 第二阶段:业务中台或数据中台
随着领域在深度和广度上的完善,不断扩大中台场景对企业业务的覆盖度,最终会形成面向选择切入点领域的闭环,此时成为中台1.0.
同时1.0阶段也会出现数据中台。整合不同数据源以及不一致、不规整的数据,工作量也较大。在建设数据中台的过程,虽然可能梳理出一些现有业务系统建设不合理的地方,
倒逼着业务系统进行改造,一定程度上推动业务系统的发展,但是单建数据中台无法将数据能力与业务形成闭环,会大大限制数据中台价值的发挥。
11.2.3 第三阶段:业务中台+数据中台
中台1.0属于单条腿走路。
业务数据化,数据业务化,以业务和数据双中台驱动前端业务,是中台2.0最重要的特征。
它不仅关注单形态中台的内部串联打通,还在建设双中台的同时,进一步打通双中台的能力,两者相互协作,相互支撑。
业务和数据双中台建设聚焦于业务,围绕创新开展业务和数据一系列能力的建设,从而快速满足业务场景闭环及业务创新尝试。
以营销活动为例,没有数据中台,无法圈选到合适的人;没有业务中台,设计不出合适的促销活动,无法带动交易;没有活动和交易数据,找不到合适的人群。
11.3 中台的未来:软件定义中台
在中台2.0之上,企业需要找到更好的中台建设方式和途径。软件定义中台明确提出建设由技术平台支撑业务中台和数据中台的闭环,解耦运营平面、控制平面和执行平面,
实现中台的统一运营、集中管控和柔性执行。
1.平台化
领域微服务化是量变,而平台化是质变。
领域微服务化沉淀的不少业务能力,通过平台化,不断进行业务抽象建模,支持多场景的业务流程编排,使得通用的业务能力配合具体的业务规则、流程的灵活编排,能够满足更多、更复杂的业务场景。
在领域微服务化过程中,每增加一个能力都是从0到1的过程,而通过平台化,新增一个场景或能力,则可在原有能力和场景的基础上不断延伸,提高中台迭代的速度。
2.协同化
关注的是一种多方协同共建中台的机制。所有业务方都可成为中台的参与者,参与中台的能力建设和能力使用的过程。
3.智能化
一是数据中台的建设将更智能,包括数据采、存、通、治的加工链条将大幅缩短。数据中台将自学习,及时诊断数据加工链路的故障并主动修复。
二是数据智能应用将无处不在,并赋能营销、渠道、供应链、服务等领域。
4.行业化
一个大型企业可能会涉及多个行业的业务。
首先,不同行业会注重不同领域发展。其次,对于同一个能力中心,不同行业会有不同的业务需求。
中台为了支撑整个企业的业务,不能让不同行业的特性纠缠一起,需要以行业化的角度对各行业特性进行统一隔离管理。
5.生态化
中台的核心在于共享。从一开始企业内部各业务的共享,演进为行业生态的共享,进而形成能力生态。
在生态化阶段,企业立足于生态赋能,帮助其他企业快速创新,并反哺自身。一般而言,生态化可以通过能力地图、应用市场、开放平台等机制来体现。开放的平台有利于拓展企业的业务边界。
数字中台是基于云计算、大数据、人工智能等新一代技术打造的持续演进的企业级业务能力和数据共享服务平台。数字中台将大大推进企业的数智化转型。
随着中台的发展,数字中台将逐渐从前台、中台、后台的中台演变为企业中枢的中台。




