中台之上(十四):尝试构建轻量级架构设计工具

本文介绍了将构件模型应用于构建轻量级架构设计工具的思路。阐述了构件模型的逻辑关系,基于此形成的工具便于业务人员理解深层设计,能加快需求分析等速度,还可累积项目数据。此外,设想了该工具在分析和管理新需求方面的应用场景。

上一篇介绍了通过构件模型支持组装式设计的思路,本节再讲讲将其应用于构建轻量级架构设计工具的思路。

轻量级架构设计工具

首先,我们再来总结下构件模型的抽象结构,结构如下图所示:

\"image\"

每个业务领域下都可能有一到多个装配模板用于设计产品;装配模板则由若干个构件组成,产品的组装式开发就表达为构件与模板间的对应关系,可以在构件中记录复用推荐度,以方便后续做设计时使用;构件中会对应多个参数,参数尽量使用数据模型中的数据项,但是实际操作中也可能需要列入一些与业务无关的技术字段,此外,应该给每个参数注明是否为可装配参数,不可装配的参数不提供面向业务人员的配置功能;一个构件对应一到多个实际的服务,构件此时代表的是一个服务集合,所谓复用不是任意去复用构件对应的服务,而是这些服务整体对外提供一个能力,这才是“零件”的含义,否则,构件就不是一个真实的存在,如果原有构件中的一部分服务又被集合成了新的能力,则应再增加一个构件进行对应;服务由于可以被调用,因此会对应报文,既包括请求报文也包括响应报文,报文中又会包含构件对应的参数,二者可以合二为一,也可以分开表达;装配模板在生产中,经过赋值产生可售产品;每个可售产品又会有描述性的属性信息,这些信息的集合就形成了产品目录。以上就是构件模型的逻辑关系,基于这个逻辑关系,结合系统设计原理,可以形成一个轻量级的架构设计和管控工具,其逻辑示意图如下:

\"image\"

从系统设计原理的角度来讲,系统的设计主要关注行为和数据两个方面,金融领域中,系统设计主要是为了实现产品,因此,系统是为了支持一到多个产品而存在的,系统及其支持的产品是用户视角的系统可见部分;过渡到设计部分,可售产品由装配模板配置而成,装配模板实际上是一种领域模型,不同领域的产品可能差异较大;装配模板之下是构件,构件代表了一个领域的具体组成部分,是“零件”,构件中包含数据,也就是参数;这些又进一步分解为服务,服务实际上既包含了行为,又包含了对应的数据,“微服务”在设计上尤其如此,服务作为设计上的底层核心元素,可以从统计角度包含归属组件、归属系统、归属用例、语言类型、代码行数、原初开发或累积的人月数、归属团队等等可用于项目管理的信息,其中有些信息可以通过工具和配置信息获得,有些需要人工维护,但是其所累积起的项目信息库对于大型企业的项目管理而言非常有价值。进一步将其工具化后,可以基于构件模型建立起一个从业务直通深层实现的轻量级架构工具。

该工具优势如下:

  1. 便于业务人员理解深层设计,从而加大业务人员参与度,提升业务与技术的融合;
  2. 能够有效表达系统的可组装程度和组装方式,加快需求分析、定位和设计的速度,提高沟通效率,尤其是对于跨组件、跨部门、跨团队的设计;
  3. 通过对底层服务的详细描述,可以累积项目自身的数据信息,便于进行快速的成本测算、可行性评估,项目预算其实一直是大企业的困扰,缺乏有效的估算方式,又难以结构化地利用历史数据,通过这种方式,将成本分摊到细节开发元素,能够提升评估的准确性,减少项目预估结果的波动性,再基于实际支出情况不断调整,可以逐渐提升其精确性。

不足之处,显然,需要投入一定精力去维护,不过这种精力上的支出应该是与项目同步付出的,不要搞成后补之类的处理方式。

应用场景设想

作为架构设计和管控工具,自然要通过它去分析和管理新需求,通过上节的介绍,构件模型可以形成新的流程表达方式,不同于业务模型是基于角色和职责,构件模型基于系统结构和关系,通过一条顺序流“串”起构件,形成完整的业务处理过程,因此,新需求可以快速定位到系统的修改位置,如果是需要新增构件,则很容易可以定位到需要增加构件的位置,分析新构件与原有构件的关系,最重要的是,这一切可以很方便地由产品经理、业务人员完成,并加快业务人员和技术人员的沟通速度。过程示意图如下:

\"image\"

模型最重要的是形成通用语言,而语言最重要的练习方式是经常使用,要想经常使用则必须与行为活动密切相关,所以,模型必须与设计有紧密联系,才能够被经常使用,使用越多则沟通越容易,也越被大家接受去用于沟通,沟通多了自然就通用了。所以,一旦选择了做企业级的业务模型、业务架构,则要记住《红楼梦》中贾宝玉的“通灵宝玉”和薛宝钗的“金锁”后边的铭文:“莫失莫忘,仙寿恒昌;不离不弃,芳龄永继”。

相关文章:
中台之上(一):重视业务架构,不要让“业务的归业务、技术的归技术”
中台之上(二):为什么业务架构存在 20 多年,技术人员还觉得它有点虚?
中台之上(三):战略和组织结构,业务架构设计中不应被忽视的关键因素
中台之上(四):面对复杂的流程和数据,我们总结出了一个分析套路
中台之上(五):业务架构和中台的难点,都是需要反复锤炼出标准模型
中台之上(六):如何为一个商业银行设计业务架构?
中台之上(七):不神秘但很麻烦的业务架构落地过程
中台之上(八):企业级业务架构的实现需要不断沟通和调整
中台之上(九):如何基于企业级业务架构管理业务需求?
中台之上(十):业务架构设计“笨重”,它能跟敏捷沾边吗?
中台之上(十一):企业级业务架构设计的“五难”
中台之上(十二):如何快速设计业务架构?
中台之上(十三):探讨支持组装式开发的业务架构设计方法

作者介绍:付晓岩,原国有大行资深业务架构师,负责业务架构设计、项目管理,热衷新技术探索与实践,具有丰富的银行业务经验和企业级项目业务架构设计经验,曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号:晓谈岩说。

付晓岩:虽然做了六年的企业级业务架构,但是总觉得业务架构不是个好讲的东西,业务架构离不开业务模型,所以讲它就会搬出一堆枯燥的模型来,甚至会让人觉得业务架构就是建模。但建模只是个手段,建模的目的是把现象总结成模式,再从模式中找到结构,将业务上看到的结构传递给技术,如果二者能够基于同一结构思考,沟通上将产生最大的便利,这就是通用语言的基础,其实说通用语言,还不如说通用结构,因为说语言,经常会把人带到语法层面,纠结于规则、概念、标准之类似是而非的东西。所以,我总结建模的原则无非是把握整体、穿透现象、保证落地,建模即不能死守规则、冥顽不化,也不能脑洞大开、信马由缰,必须从一开始就关注如何落地。建模不是建个自圆其说的乌托邦,而是传给后续过程的设计图纸。业务建模可以有前瞻性,但是所谓的前瞻性是能够看清分阶段实施路径的前瞻性。 业务架构是不断演进和迭代的,它有生命力,可以成长,如果架构管理工具本身支持历史记录和模式比对,你也可以看到企业架构的演进历史,而不是只看得到现在,只能听别人讲讲过去,过去是可以看见的。这种可视化的历史是一种宝贵的学习资源,人是从历史中学习未来的,毕竟有很多行业还是需要积淀的。 但是,业务架构的形成过程的确是在一种看起来科学的方法论下,不完全科学地操作的,这点我曾经也很纠结,后来软件架构的书看多了,再加上到项目中的观察,也逐渐释然了。软件架构其实很羡慕建筑架构,觉得建筑架构有力学基础做支持,有很多可以计算的东西,但是软件架构却没多少能算出来的。在开源思想时兴之前,行业内部交流分享较差,都比较愿意看别人的架构,而不想亮出自己的,很多研究者都抱怨这个非常需要标准的行业反倒是很隔离的。开源为架构和软件带来新的成长方式,共享让思维发展更快、普及更快,但是,软件架构本身却只是增加了大量的案例,依旧难以标准化,哪怕是同一个行业的企业,给这家做的软件也不一定能直接搬到另一家去,很多商用化了的系统软件也还是离不开个性的本地化改造过程。云计算带来的 SaaS 虽然让软件应用省去了许多部署过程,但是,依然难以改变这个行业个性化程度严重的局面。软件架构尚且如此,业务架构也就不需要纠结了。 业务架构设计可以很快,也可能很慢。快无非是两种情况,一是架构师自身炉火纯青、天生慧眼,设计能力超强;二是原有业务模型已经很清晰,可以快速分析业务变化,形成架构设计,我们可以追求的是第二种,这也意味这首次建模,尤其是首次建设企业级模型,不要过快,对模型设计方法、业务流程分析、标准化过程,都要细致点儿,基本功扎实了,才有后边的“敏捷”。企业级转型没有轻松的,不少企业是把转型仅当成一个项目,而忽视了对自身的调整。一个普通士兵变成一个特种战士,不是因为给了他一身价值 10 万的装备,而是经过了地狱般的训练。上至最高管理者,下至普通员工,人的思维不转变,哪来的企业转变呢? 为了推动企业真正的数字化转型,业务架构设计人员永远不要忘记,业务架构最重要的职责不是传递需求,而是藉由自身的努力,推动业务和技术的深度融合,桥梁作用才是业务架构最重要的职责,如果不能实现这一目标,也就不能真正实现一个快速响应内外部变化的企业级业务系统。 其实中台并非万能,客观地讲,一个优秀的架构设计人员是不会“迷信”于任何一种架构设计方式的,也不会执着甚至偏执于方法间的争论,没有哪种设计方式是完美无缺的,软件行业没有“银弹”,任何一种方法都需要坚持与灵活的结合,都需要通过长期的实践不断总结和改良,如果一个方法没有被坚持数年以上,可能连入门都谈不上吧。我对中台认识更多还只能算个一般观察者,论述中难免有失,感谢读者朋友们能够宽容地看我一路“叨叨”下来。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值