企业级业务架构的设计难点

简介: 本书后边再讲,现在还是先讨论下实现这一目标,业务架构设计所面临的最大难点——标准化工作。

企业级业务模型的建设离不开标准化过程,因为做企业级模型要横向对比分析企业所有业务领域,以期望在设计上实现“以更少支持更多”,这是很多企业级系统建设或者企业级转型工程的目标,希望能够同时实现快速的灵活响应和减少重复开发这两个目标。这个愿望是非常美好的,关于对这一点的体会,本书后边再讲,现在还是先讨论下实现这一目标,业务架构设计所面临的最大难点——标准化工作。

一、基本的标准化方法

业务架构模型的标准化包括数据标准化和任务标准化两部分。

(一)数据标准化

标准化最重要的是数据标准化,数据建模中已经提到了,企业级数据模型要保证数据实体和属性的唯一性,这样就不会由重复的概念产生,重复的概念会造成数据的“同义不同名”。影响数据的使用和统计结果,数据模型的唯一性从工具角度比较容易控制,通过对定义、取值的比较,能够筛查出多数概念问题,但是依然有些定义问题不易发现,这就需要通过与流程模型的配合,从语义层面逐一澄清了。

(二)任务标准化

任务的标准化其实很难操作,因为没有非常严格的标准用于做判断,而且,任务标准化也是切忌“机械”操作的。其基本过程如下:

1. 将流程模型与数据模型进行语义对接

当多数的数据概念重复问题已经通过工具筛查、语义分析解决了,数据实体和属性基本保持唯一,这时可以将数据与流程对应起来,对应的主要方式就是识别任务需要使用的数据实体,包括读和写两类。这种对接要更多地从语义方面去理解流程和数据的关系,而不要简单地执行流程与数据之间的关系“勾挑”,要通过语义分析判断任务、数据实体的颗粒度是否合适。

2. 分析重复的业务动作

在对应过程中,经常会遇到多个不同的任务都可能要对同一个数据实体在不同时间进行写操作的情况,比如,个人客户初次到一个银行存钱,申请银行账户时,银行要建立客户的信息,会包括姓名、证件类型、证件号码等基本信息,也会包括电话等联系信息,或者邮寄地址等地址信息,这时的整体业务场景是存款。而客户过了一段时间再次来办理业务时,联系信息可能会有变化,这需要更新客户信息,但是此时的场景有可能发生变化,不再是来存款,可能是来购买实物黄金,从业务的角度看,这就是两个不同的业务领域了。

在进行企业级标准化以前,对客户信息的建立和修改完全有可能在存款和实物黄金的业务领域中各有一套流程,可能是任务级别的重复,也能是在不同的任务中包含的内容上有重复,实际上,以前做竖井式开发的时候,这是很常见的现象,每个业务系统都是独立的、完整的,都各自有一套客户信息,不仅重复,最重要的是经常会不一致。当我们通过企业级数据模型去除重复的数据概念之后,通过任务与实体之间的写操作对应关系,会清晰地发现重复的操作。

3. 做出关于标准化的建模判断

找到重复动作后就需要做出建模的决策,是分开建模还是将所有对客户信息进行写操作的部分集中到一起建模。还是参考上文中的例子,在FSDM提供的数据模型上,“参与人”这个分类中可以容纳与客户信息相关的所有数据,建模上可以把此类实体聚集在一个主题域下,比如叫做客户主题域,那么从企业级的角度也就可以将各业务领域中与之相关的任务或者涉及到该操作的任务中的客户信息部分全部抽离出来,集中到起来组成一个组件,而其他领域的任务经过调整后,不再包含此类内容,这样就完成了一个标准化过程。

二、避免“过度整合”

上述操作是相对较为简单、清晰的标准化过程,还有些标准化过程要更难以判断,可能因此出现“过度整合”的问题。这种情况通常出现在流程看似相近的业务领域,以及一个领域内部的多个产品之间,后者其实更难判断,因为一个业务领域内部的流程本就相近,会很容易让人产生“整合”的冲动,因为业务建模毕竟是一种“纸上操作”,分、合都是很容易的,调整下结构而已,而整合对建模者来讲又有很大吸引力。

为了避免这种错误,需要从业务和数据两方面下手,配合检查。业务上自然是要重新审视、理清业务流程,搞清楚具体差异;而数据上要重新检视数据实体划分的颗粒度是否正确,是否包含的属性太多而导致内聚性不够。数据实体的颗粒度太小,会放大业务差异,而颗粒度太大,则会抹杀业务差异,二者都会导致不合理的标准化结果。流程模型与数据模型之间的语义互查是进行合理标准化的关键,也是一个反复锤炼的过程。

三、何以解忧,唯有“融合”

尽管标准化问题很重要、很困难,不幸的是,并没有什么很好的方法能够帮助各位快速解决问题,这就又回到了之前说的,模型质量严重依赖建模者的经验,除了经验之外,还要依靠高质量的建模输入,既包括完善的业务资料,更需要有丰富经验的业务人员,看资料是学不会业务的,尤其是业务中经常会有“活情况”。

业务人员与技术人员融合得越好,就越能产生高质量的模型和系统,这也难怪高盛、大摩这些金融机构中数字化转型的坚定执行者,会引入占员工比例约15%甚至20%的技术人员,并直接派驻到业务部门与之共同工作。相比之下,一般国外金融机构技术人员占比不足8%,国内通常为4%左右,近几年才刚刚有所增加。目前似乎也可以讲,除了科技企业,其他行业中还很少有哪个企业真的达到了与信息时代、数字化时代相称的人员结构。

尽管标准化过程很痛苦、自身又似乎很不“标准”,但是因其对企业级业务系统的构建意义非凡,因此,所有做企业级转型、希望建设企业级业务系统的企业和开发者,都必须认真对待这一过程,尽管这一过程未免有点“纸上谈兵”,但它的优势也在这里,这一阶段的任何调整都是代价极低的,而不合理的设计一旦传导到开发上,就将产生较大的纠正成本。

对于大型复杂系统而言,因其面对的问题域异常庞大,所以需要一套清晰的业务与IT的架构映射关系指导企业的持续建设,这就如同人们对地图的需要一样,只有践行标准化才能提供一张准确的地图。这种标准化也是识别中台能力的基础,就算是阿里的中台,也应当是在技术人员与业务人员的不断融合、反复的标准化与去重过程中沉降下来的。

以上内容摘自《企业级业务架构设计:方法论与实践》一书,经出版方授权发布

文章来源:微信公众号 刘超的通俗云计算

目录
相关文章
|
30天前
|
设计模式 架构师 前端开发
JavaEE企业级分布式高级架构师课程
本课程主要面向1-5年及以上工作经验的Java工程师,大纲由IT界知名大牛 — 廖雪峰老师亲自打造,由来自一线大型互联网公司架构师、技术总监授课,内容涵盖深入spring5设计模式/高级web MVC开发/高级数据库设计与开发/高级响应式web开发/分布式架构设计等主流核心技术。
22 1
JavaEE企业级分布式高级架构师课程
|
5月前
|
存储 人工智能 架构师
基于 TOGAF 和 WAF 的企业级架构
基于 TOGAF 和 WAF 的企业级架构
65 0
基于 TOGAF 和 WAF 的企业级架构
|
7月前
|
存储 架构师
企业级业务架构设计:方法论与实践 学习笔记
最近在项目中涉及到这一领域,也借着这个契机做一次对企业级业务架构设计的深入学习。
377 0
|
8月前
|
NoSQL Java 测试技术
破防了!阿里用17个真实企业级项目阐述Java系统分析与架构设计
最近,有小伙伴问我,有没有能够在短时间内快速增长软件项目的系统分析与架构设计能力的方法。 想了很久还是决定把这份用17个真实企业级项目阐述的《Java系统分析与架构设计》手册分享出来。 这份手册按照一个完整的软件项目周期: 立项→业务需求→软件需求分析→架构设计→模块设计→代码开发→软件测试→项目部署→系统维护 深入浅出地讲解了需求分析技术、软件开发架构设计、关系型物理表设计、Redis应用实战、MongoDB 开发与应用、Web服务器与数据库的集群部署等内容。
108 0
|
10月前
|
SQL 存储 网络协议
|
11月前
|
消息中间件 Cloud Native RocketMQ
带你读《企业级云原生白皮书项目实战》——6.3.1 行业背景
带你读《企业级云原生白皮书项目实战》——6.3.1 行业背景
103 0
|
11月前
|
消息中间件 Cloud Native 大数据
带你读《企业级云原生白皮书项目实战》——6.3.2 RocketMQ 在陪伴体系中的应用
带你读《企业级云原生白皮书项目实战》——6.3.2 RocketMQ 在陪伴体系中的应用
126 0
|
11月前
|
消息中间件 Cloud Native RocketMQ
带你读《企业级云原生白皮书项目实战》——6.3.3 RocketMQ 事务消息的金融应用场景(1)
带你读《企业级云原生白皮书项目实战》——6.3.3 RocketMQ 事务消息的金融应用场景(1)
153 0
|
11月前
|
消息中间件 存储 Cloud Native
带你读《企业级云原生白皮书项目实战》——6.3.3 RocketMQ 事务消息的金融应用场景(2)
带你读《企业级云原生白皮书项目实战》——6.3.3 RocketMQ 事务消息的金融应用场景(2)
122 0
|
11月前
|
消息中间件 Cloud Native RocketMQ
带你读《企业级云原生白皮书项目实战》——6.3.3 RocketMQ 事务消息的金融应用场景(3)
带你读《企业级云原生白皮书项目实战》——6.3.3 RocketMQ 事务消息的金融应用场景(3)
126 0