最终选择了单体应用,放弃了微服务架构

今年年初,刘润老师在他的一个短视频号上发布了一段视频:《钱越来越难赚了,怎么办》,在他看来钱越来越难赚了的原因主要有五个:效率被技术推动、行业稀缺性流动、消费者需求变化、组织内部熵增、经济形势不好;他认为的最佳应对策略是:卷与熬,巩固基础、修炼内功,让自己别死掉,直到春天来临。,这段视频在企业内部激起了不小的讨论,在当前的这个钱越来越难赚的行业背景下,数禾应该如何卷和熬成为了数禾人必须思考的问题, 聚焦到技术团队内部,呼应公司层的决策,也采取了一系列举措:建立BizDevops流程体系、引入DDD指导应用架构实践、建立研发效能度量体系;然而这些举措还是无法清晰回答“研发投入和系统完备度之间的关系”,例如:信贷核心系统做了这么久,为什么还是需要投入这么多研发资源 ?,我们虽然有研发效能度量,但是这套度量指标主要是针对BizDevops流程的多、快、好、省而制定的指标,能够反馈出来我们的研发资源投入情况,但是很难回答为什么需要投入这些研发资源;而要回答这个问题,就需要结合系统建设情况做关联分析。,在结合系统建设情况做关联分析的时候,我们又遇到了新的问题,我们每天都在说“应用、系统、领域、产品”,这些词到底是不是同一个意思?再基础性的概念问题都没有说清楚的时候,我们更加无法回答,资源投到哪里去了?,为了解决这一系列产研的问题,我们经过无数次的探讨,总结了一套思路,我们称之为“产品化体系建设”,本文主要是介绍产品化体系建设的三步主要是怎么做的,并且在文末给出了一个详细的产品梳理的案例。,最终选择了单体应用,放弃了微服务架构,产品化体系建设三步走,企业架构是定义企业各个组成部分如何构建,企业各个组成部分之间的关系以及企业各个组成部分演变的原则和规定,主要包括:业务架构、数据架构、应用架构、技术架构。,企业架构是战略和数字化项目的桥梁,向上衔接战略规划,向下连接项目实施。“协调”与“对齐”是企业架构的重要特性和作用之一,纵向协调战略、规划、实施、运营各层级一致性。横向对齐业务、数据、应用与技术。,最终选择了单体应用,放弃了微服务架构,企业架构在企业中的位置,数禾企业架构框架(SEAF):是一个符合数禾的企业现状的,参考了TOGAF和华为企业架构而形成的一套轻量化、可落地的企业架构方法。框架本身需要遵循下面的四条原则:,企业架构模型:是对于架构核心概念要素的精确定义和描述,元模型构成了架构设计的“基本语言要素”,通过元模型及其关系的表达,就可以通过结构化的方式对于架构进行描述和展现,元模型是企业级架构框架的核心,是对于架构描述的“统一语言”。,最终选择了单体应用,放弃了微服务架构,数禾企业架构元模型,最终选择了单体应用,放弃了微服务架构,企业架构核心要素,对公司已有的产品资产进行梳理,形成一个产品全景图基线,并且建立完善的产品生命周期管理体系,以提高产品成熟度为过程目标,最终实现三大目标:减少产研投入人力、提高产研质量、沉淀科技能力。,每一个产品的梳理都应该做到:梳理业务流程,识别业务对象、业务过程和使用的业务规则。首先实现对象、过程的系统化管理,记录业务对象的全量、全生命周期数据,记录业务活动的执行或操作轨迹,实现业务规则的结构化、配置化管理。然后进一步向业务流程自动化、业务决策智能化的方向发展。,最终选择了单体应用,放弃了微服务架构,金融科技企业产品地图,产品标准是通过经验积累,将一个产品必备的能力组合形成一套用于指导产品如何变好的标准。但是并不是符合产品标准就一定是一个好产品, 产品标准是用于提高产品下限的,要做好产品,还需要产品经理不断探索,把产品做精做透。,最终选择了单体应用,放弃了微服务架构,产品标准框架,最终选择了单体应用,放弃了微服务架构,产品运营体系,本案例是以贷后催收业务为背景,从催收业务流程触发,逐步分析最后产出一套基于企业公共能力、满足催收业务场景的解决方案。,1. 从业务流程中识别业务活动和业务对象,2. 基于业务活动和业务对象划分业务功能模块,最终选择了单体应用,放弃了微服务架构,核心业务功能模块,业务功能模块类型,从业务功能模块进一步分解到业务功能,可以参考以下方法:对于基于业务活动划分的功能模块,通常可以按照业务场景来划分功能点,如“分案”业务模块按照业务场景可以分为“规则码分案”、“坐席分案”等 对于基于业务对象划分的功能模块,通常包括一组相关对象的生命周期管理,如“通知管理”包括“短信模板配置”、“AI提醒模板配置”等。,最终选择了单体应用,放弃了微服务架构,业务功能矩阵,将上一步梳理出来的业务功能各类到各个产品中。,最终选择了单体应用,放弃了微服务架构,产品业务功能矩阵,产品架构由产品功能模块和产品功能组成。 面向特定业务领域的产品往往只出现在单一解决方案中,其产品架构形态也与业务功能矩阵比较类似。,最终选择了单体应用,放弃了微服务架构,产品架构,产品架构中的每个产品功能都应该有明确的应用来承载。从产品架构到应用架构只是将产品功能划分到对应的应用。基于应用架构设计原则,结合技术架构标准,进一步拆分应用,形成最终版本的应用清单,输出最后的应用架构图。,最终选择了单体应用,放弃了微服务架构,应用架构,解决方案由产品+实施组成。 一套解决方案通常包含N个产品,在此基础上完成产品配置和集成的实施工作,从而实现特定领域内的业务能力。 产品所属领域划分:,最终选择了单体应用,放弃了微服务架构,解决方案架构,架构管理是一个复杂的系统工程,只靠一套方法论和少数运动式的项目是无法达成目标的;要达到期望的目标既需要企业架构这样的方法论,从顶层做好规划,也需要敏捷开发这样的实践方法,创建MVP而不是追求完美,在实践过程中快速迭代。我们的应用架构管理实践之路才刚刚开始,路漫漫其修远兮,在实践的过程中自我迭代也是非常重要的, 只有自我认知跟得上,才是实践成功的最大保障。

文章版权声明

 1 原创文章作者:cmcc,如若转载,请注明出处: https://www.52hwl.com/22233.html

 2 温馨提示:软件侵权请联系469472785#qq.com(三天内删除相关链接)资源失效请留言反馈

 3 下载提示:如遇蓝奏云无法访问,请修改lanzous(把s修改成x)

 免责声明:本站为个人博客,所有软件信息均来自网络 修改版软件,加群广告提示为修改者自留,非本站信息,注意鉴别

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023年3月5日 上午12:00
下一篇 2023年3月7日 下午10:34