如何落地复杂系统的架构治理?
原文参见本人博客:如何落地复杂系统的架构治理
之前的一篇架构治理相关文章《如何度量软件架构》在Thoughtworks洞见发布后,收到路人甲的一个评论:
复杂系统且持续快速迭代的系统的架构治理有个很大的痛点,通过方法论和标准化的工具扫描和度量出来海量问题后,没有合理的成本可控风险可控的解决方案,只管杀不管埋,就导致无疾而终,或者就是一通治理之后引来了更大的问题。
这个评论讲到了复杂系统架构治理的痛点和难点,值得拿来聊一聊:
对于多年复杂遗留系统,问题是非常多的,细究起来可能是“体无完肤”,哪哪都有问题,到处都需要改,无从下手。
不知如何衡量成本与收益,一但开始,不是从价值大小入手,更多的是哪些故事更好听,哪些优先级更高。
急功近利,两三个月就要上线。技术架构优化通常都是底层优化,牵一发而动全身,测试不全面,急于上线引出更大的问题,被各方指责,直接回退,后续的优化动作被迫停止,无疾而终。
这些问题都是经历过复杂系统的架构治理才能提的出来。大部分底层架构的变动技术复杂度都非常高,也正因此,落地实施的难度更大,阻力也更大,但往往最大的阻力不在于技术层面,而在于管理实施过程中。
就像前几年非常火爆的中台,很多公司纷纷效仿,却很难获得构建中台的实际收益,大部分只是照猫画虎,有形而无神。究其原因,中台的实施是对企业组织的一次再造,对业务模式的一种变革,并不单纯是技术问题,如果组织问题和业务问题无法解决,中台便无法起到实质作用。
复杂系统的架构治理虽不如构建中台般大张旗鼓,但在实施上的痛点有相似性。结合上面的问题,我们重点谈谈两个大的方面:
如何在海量问题中,结合成本与收益,设定优先级?
如何实施一个复杂系统的架构治理活动,保证不影响业务?
业务价值导向的优先级定义
在之前的文章软件架构治理 之 架构优化方向 中介绍过如何识别软件架构中的治理优化点。当我们找到大量的优化的方向,能投入的成本往往是有限的,如何从众多的方向中挑选在当前的情况下最有必要去做的优化呢?
这时候还是要回归到架构治理的初衷上来看,架构治理之所以有必要,在于它可以帮助组织解决业务问题。如果单纯从技术维度出发,确实有很多问题也很严重,比如有些服务的代码和内部设计很差,但目前的功能相对稳定,问题不多,而且从中长期来看,并没有可见的需求,那这个优化的优先级就不高。
为了让架构治理的收益最大化,可以利用上图中的象限将找到的架构治理优化项进行优先级排序。成本高低很容易通过工作量的评估来判断,但判断一个架构治理优化项的价值高低相对困难,这里我们可以参考几个维度:
业务重要程度:架构治理优化项涉及核心业务场景,能够助力组织的战略目标,现在不做优化,未来的业务扩展会被影响,则优先级较高。
紧急程度:架构治理优化项涉及的内容可能导致重大影响,是迫切需要解决的问题,优先级会较高。比如数据库的存储无法长久支撑业务发展,需要尽快考虑大数据方案或更换分布式存储方案。
风险高低:架构治理优化项不处理,会有潜在的风险,包括技术风险、安全风险和业务风险,涉及高风险的优化项需要尽快处理,优先级较高。
利益相关者意见:这点很少被提及,但实际操作很难忽略,是非常关键的维度。核心利益相关者对系统的定义或者诉求,直接影响着架构治理的大方向,也就影响着优先级,比如整个团队的核心方向就是构建业务中台,那么架构治理也必须围绕这个大的战略目标来做,优先级自然也很容易定义清楚。
除了上述关键的维度,把哪些内容纳入到架构治理的计划中,还有很多因素需要考虑,比如资源可用程度,包括人力资源和预算资源,如果资源有限,很多成本较高的优化项的优先级就会被降低。因此,在实际定义优先级过程中,要参考以上关键维度,也要按照项目的实际情况做适度调整。
分阶段落地复杂系统的架构治理
在定义好优先级之后,许多项目负责人会像做业务功能开发一样推进架构治理,按照工作量的评估直接排计划,例如 10 个人干 1 个月能做完,那就安排开发 1 个月后上线。在大部分情况下,这种方法的效果会很差,甚至会引发非常严重的线上事故。
这其中有几个比较关键的问题:
架构治理项目中业务分析师的参与度会非常低,甚至没有业务分析师,架构师和 Tech Lead 会更多从技术视角来做架构的分析和拆解,对业务的影响往往评估不足。
解决方案的大方向设定之后,在任务细化过程中,开发角色很难像业务分析师拆解业务功能那样细致,并且大部分的技术实现细节隐藏在代码中,很难分析全面,在实际开发过程中会有很多隐藏的问题暴漏出来,导致项目无法继续推进,或者项目延期。
架构治理项目有些会涉及新技术栈替换就技术栈,而开发团队对于新技术栈的开发经验往往比较有限,或者只有个别人非常熟练,新技术栈的开发很难保证效率和质量。
因此,落地复杂系统的架构治理很难借助普通业务功能开发的经验来推进。需要分阶段进行逐步细化,迭代推进,如下图:
从实际落地效果来看,方案验证(POC)阶段和试点推进阶段非常关键,通过这两个阶段的进一步细化,可以进一步识别架构治理涉及的技术细节和实施风险,包括新技术栈带来的挑战和坑,针对性的给出解决方案。
值得强调的是,这里的方案验证(POC)要做的更深入,产出更多,可以结合项目的情况和开发团队的能力进行定义。因为后面紧跟着进一步的试点和全面推进,在 POC 的过程中,除了验证方案的可行性,还要进一步的产出落地的规范和开发模板。架构治理所涉及的开发工作技术难度较大,比传统的业务开发涉及的技术难点更多,为避免开发人员经验不足导致的问题,需要通过 POC 产出架构专项治理的开发步骤,每个步骤的规范以及验证方式。
另外在试点和全面推进阶段,一定要设计回退方案,架构治理通常是底层技术架构的调整,涉及大量业务功能,一旦有问题,影响面非常大,很难确保万无一失,所以要设计完善的回退方案或灰度验证方案,把影响降到最低。
版权声明: 本文为 InfoQ 作者【码猿外】的原创文章。
原文链接:【http://xie.infoq.cn/article/0e729ca69f4a71a1146f5c05b】。
本文遵守【CC BY-NC-ND】协议,转载请保留原文出处及本版权声明。
评论