【架构优化过程思考】架构优化倒底优化的是什么
在每一个产品(本文中以系统代替)的生命周期中,系统的技术架构,都会经过从无到有的构建,也会根据需要而进行重构,那么每次架构优化工作的目标是什么?倒底优化的是什么呢?有一段时间,一直困扰着我,架构优化的价值何在?倒底有多么的重要?经过长时间的思考之后,得出来的一个关键词就是“赋能”,直接的讲,就是给系统赋予新的能力,可以基于新的架构实现更多的事情,实现当下不可实现的能力,赋予系统更多的可能性,这些可能性是在当下的架构是不能很好的支持或不可能实现的。
而基于当前架构而进行的优化,实现新的能力或使用不同的技术方式对已有的能力进行重构,必然会带来变化,这些变化的影响不仅是影响系统本身,同样对于系统的研发迭代过程也会产生影响,只要与架构相关的人或事,都会产生影响。因为架构优化的过程产生的变化,与架构直接的或间接有关的人或事都会产生影响,这些影响也不限定于研发过程,而是较长的一个时间周期,直到这个架构被彻底的重构,所以在进行架构优化工作之时,就得知晓这些相关的节点带来的变化,在不同的阶段需要引用什么样的方法使得这些降低影响面,使得在保证质量及效率的前题下低成本的推进架构优化的相关工作落地。总结来说,优化的影响分为以下几个方面
-
优化的是系统当下面临的问题:首先,当次架构优化工作的前题应该是优化的当下的架构存在的问题,这个问题是基于系统/技术的需要而产生,并且在解决当下架构的问题同时,还需要保证相关的业务不会劣化。对于解决问题的方式,主要为两种1)构建新能力,并与现有能力建立联系;2)优化现有的能力,使能力可更好的提供服务;这两种方式解决的问题也会有所不同,当系统能力缺失时,那优化的目标就是构建相关的能力;当系统能力已经存在,在其它的层面存在不足,这时的优化会涉及实现,流程,结构,层次,依赖关系等因互素的调整。问题的本质是与目标的差距,当架构优化的背景不清晰,问题不清楚及目标不明确,实际上架构优化的意义就不存在,投入的资源也就没有必要性。
-
优化的是业务迭代支撑的骨架:这个支撑的骨架主要通过技术手段构建,根据业务的需要,和当次优化要解决的问题,进行基础能力的抽象,最终实现对应的支撑能力。技术骨架在整个系统中有存在的必要性,对应的输出是一套可描述的标准,基于该标准相关的业务可在技术骨架之上可实施,可低成本的实现业务的需要。同时基础技术架构也会承担业务的衔接能力的构建,包含某个具体的业务内的流程支撑,也包含业务之间的流程支撑。总而言之架构的优化过程对于基础技术骨架的优化是一个系统性的行为,应该优先确定,这部分相当于在优化的方案设计阶段就要确定下来。
-
优化的是系统中能力间的关系:确定了目标及问题,确定了技术方案,并实施,这相当于对系统的技术实现进行了调整,这时对于已有的能力(模块)进行了拆分,合并,删除,修改,甚至也需要进行构建一些新的能力。这些能力基于新的技术方案进行了实现,能力之间的关系进行了重组,最终把新的技术方案的工作流程逻辑建全,再为系统中相关的业务需要进行赋能。在这个过程中,模块的能力会产生变化,对外公开的接口也会产生变化,工作流程同样也会产生变化。
-
优化的是研发人员的工作习惯:技术架构进行了升级优化,必然业务接入的方式或架构的维护工作也会产生变化,这时对于原来的研发习惯也会产生影响。主要来自于
- 系统/模块的能力变化:模块被拆分,模块的接口重构,模块合并等等都会产生模能力的变化,这些的变化同样也带来了系统架构能力的变化。
- 系统/模块的依赖变化:同样模块的拆分,合并,边界的变化等也会产生依赖的变化,对于整个系统中分层的变化模块的层级也会产生变化。
- 系统/模块的流程变化:模块增加能力,接口优化,内部的实现的重构等行为也会产生流程的变化,以全局的视角来看,整个系统的流程也产生了变化。
对于研发人员主要为系统架构使用方和维护方两个角色,系统/模块带来的变化,在研发过程都需要了解并应用,这些变化需要持续的影响及宣传,及时的同步给相关的研发人员。
-
优化的是业务迭代的生产模式:一个系统的研发由一个或多个团队共同构建,每个团队都有着不同的研发流程及协同模式,架构优化的带来的基础技术骨架,分层,模块的变化,实际上对于业务的生产模式也会产生变化。当研发团队规模极小,技术架构对于研发过程的流程及协同影响相对比较小,而当团队规模超过一定规模,就会产生任务并行或任务有先后依赖的情况,技术架构的优化对于模块的边界设定,粒度的拆分,依赖关系同样也产生影响,这些影响对于研发人员在生产过程的学习、沟通、协同、研发,测试及发布等工作都会产生变化,间接的看就是研发效能的变化。
总结来说,架构优化工作是一个持续性的行为,对于软件研发的过程的各个阶段都会产生影响,技术架构的优化工作,不仅是从问题的梳理及方案的设计,同时也是基于系统的现状,企业目标,系统的需要推进技术方案进行应用,最终把架构优化的目标的达成。这个过程中唯一不变的就是变化,对于架构优化产生的变化,需要提前进行准备以及相关方的沟通,并通过系统化、流程化、标准化的方式明确系统的运行机制,同时通过文档,规范,宣讲、分享等手段进行相关方的知晓,传达有效的准确的信息,最终实现架构优化及其在新的架构之上的业务的相关工作高质量的推进。
其它参考
- 【架构优化过程思考】质量高于效率
- 【架构优化过程思考】避免随机试错
- 【架构优化过程思考】持续技术创新
- 【架构优化过程思考】规范在研发工作中的价值
- 【架构优化过程思考】研发过程组件化收益小结
- 【架构优化过程思考】因事定人优于因人定事
- 【架构优化过程思考】CR的五个关键点
- 【架构优化过程思考】技术方案评估的三个维度
- 【架构优化过程思考】沟通的意义
- 【架构优化过程思考】平台生态优先
- 【架构优化过程思考】技术需求排序原则
- 【架构优化过程思考】主动沟通的基本准则
- 【架构优化过程思考】架构优化工作与功能迭代工作的区别
- 【架构优化过程思考】假定数据不置信
- 【架构优化过程思考】评审的价值体现
- 【架构优化过程思考】多端方案对齐
- 【架构优化过程思考】风险的分类及规避
- 【架构优化过程思考】如何保持有效的技术决策
- 【架构优化过程思考】如何降低隐性的资源投入
- 【架构优化过程思考】足够深入理解业务流程