经典数字化转型案例,一文通解架构设计流程及方法(下)

上篇阶段1分析出了有几个中心以及中心边界,这一阶段要完成中心的详细设计工作。在这个阶段中,不是简单地根据业务需求划分模块后把这些模块落到中台层就是中台了,这样设计出来的中台只是具体的业务模块下沉,缺乏抽象建模的过程,让中台的能力和扩展能力都非常有限,这不能成为称职的中台。业务中台一定要经历从具体到抽象的建模过程,中台设计的核心是对业务抽象建模。

经典数字化转型案例,一文通解架构设计流程及方法(下)

服务中心是业务中台最核心的架构元素,看起来和原来的应用系统的模块名称差不多,但是在本质上提升了维度。中心是拉通所有前后端系统的相关功能模块,进行统一抽象设计,用一个统一的模型去支持前后台不同业务场景的需求,如图4-8所示。

经典数字化转型案例,一文通解架构设计流程及方法(下)

我们从三个维度来描述一个完整的业务中心设计:业务模型、数据模型、服务能力,一个服务中心通过业务模型描述业务承载逻辑,通过数据模型描述数据的底层规范,通过服务能力描述服务接口契约。通过这三个维度明确一个服务中心的设计,每个服务中心设计说明书要产出这三个核心概念。图4-9是一个会员中心的设计示例。

经典数字化转型案例,一文通解架构设计流程及方法(下)

维度一:业务模型

业务模型是一个比较难直接定义的概念,我们拿一个实际的例子来说明。一家多业态经营的房地产企业,旗下有传统的商业地产、住宅、物业,随着业务的拓展也有酒店、旅游门票,甚至会发展出社区零售的业务。如果这家企业选择中台架构,那么商品中心应该是什么样子?

从任何一个单一维度去看这家企业对商品的需求,可能差异都非常大,商业地产类的商品是租售的铺位,住宅类的商品是商品房,物业是服务类商品,酒店和旅游门票是类似于电子凭证类的虚拟商品,社区零售是通常意义上的百货商品。我们对这些商品模型进行每种业务场景的建模,都会面对这些模型的业务术语、模型结构,它们完全不一样。地产商品属性特别多,商品描述复杂但是模型结构单一,需要支持复杂组合查询;社区零售类商品种类会比较多,变化比较快,用户并发量较高,商品描述结构都比较简单;酒店和旅游门票类商品要求分类特别清晰,简单易管理。

如果基于“烟囱式”架构来设计,针对这几种商品都可以推导出相应的模型。如果用中台架构,就需要对这几种业态的商品模型需求进行再一次抽象,用一个通用的模型支持多种场景需求。可以用主子类目来满足商品分类管理需求;用产品、属性、属性值、子属性来满足多业态商品多样化描述需求;用标签来支持商品离散化管理需求;用前后台类目分离来满足基于前台类目的营销和基于后台类目管理的需求。通过这样的抽象,我们建立了如图4-10所示的业务模型。

注意,基于这样的方法设计的业务模型,需要与上层业务对接的业务术语做一个统一。比如,对于地产类业务,如果原来是基于项目、分期、楼栋建立的树形结构,就要对应到现在的类目体系上(对地产业态建立业务约束规范实现对接);如果原来是社区零售业务,应该对应到现在的商品类目管理体系下,这就是中台的业务模型。

商品偏于主数据模型结构,但是不要因此就误以为服务中心的模型都是主数据模型,交易时要统一交易流程,营销时要统一规则:针对不同的业务领域,有不同的建模诉求;基于业务但一定要高于业务。如果做不到模型层面的抽象统一,那就只是具体业务形态的模块下沉,中台的价值难以发挥。

经典数字化转型案例,一文通解架构设计流程及方法(下)

维度二:数据模型

数据模型是服务中心底层的数据层实现,包括OLTP和OLAP两种场景。根据业务的需求,可能需要结合分布式数据库技术。与交易相关的业务场景中,最常见的数据模型方案是定义实体关系模型,如果对扩展性有要求,则可结合分布式数据库技术形成方案。数据模型的第一个职责是明确数据的业务规范,为业务数据化和数据中台建设做好基础准备工作。

维度三:服务能力

服务能力是中台业务能力对外的服务契约,外部系统通过接入中台的服务来使用中台。服务列表包括两部分:第一部分是针对中心的外部用户部分,这部分要明确服务的接口契约,包括使用的通信协议、安全鉴权方案、服务的请求报文和响应报文、服务的具体业务含义以及调用的上下文、异常情况等;第二部分是服务的开发实现,这部分内容需要设计者画出服务的业务流程、业务边界、异常处理等。

上面已经完成了中台的设计,在进入具体的开发之前,为了保证设计的中台模型能满足真实的业务场景,最好将中台的服务放入具体的业务流程中进行验证,也可以基于服务的mock实现来进行验证。这个过程可能比较烦琐,但是通过这个验证过程,可以发现中台的业务模型抽象是否正确,使用是否方便,服务是否完整,发现设计中模型的问题,再快速迭代修改。如果所有的业务场景都能通过这样的验证,那么中台的设计方案是可行的。

(4)开发实现

开发实现基于服务接口规范、数据模型和业务流程进行,当数据模型和服务能力都具备后,开发者就能进行详细设计和开发了。这里并没有特殊之处,但需要开发人员掌握分布式、服务化相关的一些开发原则和技术,特别是在分布式体系下,引入了一些在传统一体化架构体系下不太关注的技术原则,比如分布式事务、异步、幂等问题。相关技术可参考《企业IT架构转型之道》一书。

文章部分素材源自:《数字化转型的道与术:以平台思维为核心支撑企业战略可持续发展》,作者:钟华

展开阅读全文

页面更新:2024-04-14

标签:架构   维度   分布式   建模   抽象   模块   模型   场景   服务中心   流程   需求   案例   能力   数据模型   业务

1 2 3 4 5

上滑加载更多 ↓
推荐阅读:
友情链接:
更多:

本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828  

© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号

Top