写点什么

如何落地复杂系统的架构治理?

作者:码猿外
  • 2023-08-15
    北京
  • 本文字数:2354 字

    阅读完需:约 8 分钟

如何落地复杂系统的架构治理?

原文参见本人博客:如何落地复杂系统的架构治理


之前的一篇架构治理相关文章《如何度量软件架构》Thoughtworks洞见发布后,收到路人甲的一个评论:

复杂系统且持续快速迭代的系统的架构治理有个很大的痛点,通过方法论和标准化的工具扫描和度量出来海量问题后,没有合理的成本可控风险可控的解决方案,只管杀不管埋,就导致无疾而终,或者就是一通治理之后引来了更大的问题。


这个评论讲到了复杂系统架构治理的痛点和难点,值得拿来聊一聊:

  1. 对于多年复杂遗留系统,问题是非常多的,细究起来可能是“体无完肤”,哪哪都有问题,到处都需要改,无从下手。

  2. 不知如何衡量成本与收益,一但开始,不是从价值大小入手,更多的是哪些故事更好听,哪些优先级更高。

  3. 急功近利,两三个月就要上线。技术架构优化通常都是底层优化,牵一发而动全身,测试不全面,急于上线引出更大的问题,被各方指责,直接回退,后续的优化动作被迫停止,无疾而终。


这些问题都是经历过复杂系统的架构治理才能提的出来。大部分底层架构的变动技术复杂度都非常高,也正因此,落地实施的难度更大,阻力也更大,但往往最大的阻力不在于技术层面,而在于管理实施过程中。

就像前几年非常火爆的中台,很多公司纷纷效仿,却很难获得构建中台的实际收益,大部分只是照猫画虎,有形而无神。究其原因,中台的实施是对企业组织的一次再造,对业务模式的一种变革,并不单纯是技术问题,如果组织问题和业务问题无法解决,中台便无法起到实质作用。


复杂系统的架构治理虽不如构建中台般大张旗鼓,但在实施上的痛点有相似性。结合上面的问题,我们重点谈谈两个大的方面:

  • 如何在海量问题中,结合成本与收益,设定优先级?

  • 如何实施一个复杂系统的架构治理活动,保证不影响业务?

业务价值导向的优先级定义

在之前的文章软件架构治理 之 架构优化方向 中介绍过如何识别软件架构中的治理优化点。当我们找到大量的优化的方向,能投入的成本往往是有限的,如何从众多的方向中挑选在当前的情况下最有必要去做的优化呢?


这时候还是要回归到架构治理的初衷上来看,架构治理之所以有必要,在于它可以帮助组织解决业务问题。如果单纯从技术维度出发,确实有很多问题也很严重,比如有些服务的代码和内部设计很差,但目前的功能相对稳定,问题不多,而且从中长期来看,并没有可见的需求,那这个优化的优先级就不高。

为了让架构治理的收益最大化,可以利用上图中的象限将找到的架构治理优化项进行优先级排序。成本高低很容易通过工作量的评估来判断,但判断一个架构治理优化项的价值高低相对困难,这里我们可以参考几个维度:

  • 业务重要程度:架构治理优化项涉及核心业务场景,能够助力组织的战略目标,现在不做优化,未来的业务扩展会被影响,则优先级较高。

  • 紧急程度:架构治理优化项涉及的内容可能导致重大影响,是迫切需要解决的问题,优先级会较高。比如数据库的存储无法长久支撑业务发展,需要尽快考虑大数据方案或更换分布式存储方案。

  • 风险高低:架构治理优化项不处理,会有潜在的风险,包括技术风险、安全风险和业务风险,涉及高风险的优化项需要尽快处理,优先级较高。

  • 利益相关者意见:这点很少被提及,但实际操作很难忽略,是非常关键的维度。核心利益相关者对系统的定义或者诉求,直接影响着架构治理的大方向,也就影响着优先级,比如整个团队的核心方向就是构建业务中台,那么架构治理也必须围绕这个大的战略目标来做,优先级自然也很容易定义清楚。


除了上述关键的维度,把哪些内容纳入到架构治理的计划中,还有很多因素需要考虑,比如资源可用程度,包括人力资源和预算资源,如果资源有限,很多成本较高的优化项的优先级就会被降低。因此,在实际定义优先级过程中,要参考以上关键维度,也要按照项目的实际情况做适度调整。

分阶段落地复杂系统的架构治理

在定义好优先级之后,许多项目负责人会像做业务功能开发一样推进架构治理,按照工作量的评估直接排计划,例如 10 个人干 1 个月能做完,那就安排开发 1 个月后上线。在大部分情况下,这种方法的效果会很差,甚至会引发非常严重的线上事故。


这其中有几个比较关键的问题:

  1. 架构治理项目中业务分析师的参与度会非常低,甚至没有业务分析师,架构师和 Tech Lead 会更多从技术视角来做架构的分析和拆解,对业务的影响往往评估不足。

  2. 解决方案的大方向设定之后,在任务细化过程中,开发角色很难像业务分析师拆解业务功能那样细致,并且大部分的技术实现细节隐藏在代码中,很难分析全面,在实际开发过程中会有很多隐藏的问题暴漏出来,导致项目无法继续推进,或者项目延期。

  3. 架构治理项目有些会涉及新技术栈替换就技术栈,而开发团队对于新技术栈的开发经验往往比较有限,或者只有个别人非常熟练,新技术栈的开发很难保证效率和质量。


因此,落地复杂系统的架构治理很难借助普通业务功能开发的经验来推进。需要分阶段进行逐步细化,迭代推进,如下图:

从实际落地效果来看,方案验证(POC)阶段和试点推进阶段非常关键,通过这两个阶段的进一步细化,可以进一步识别架构治理涉及的技术细节和实施风险,包括新技术栈带来的挑战和坑,针对性的给出解决方案。


值得强调的是,这里的方案验证(POC)要做的更深入,产出更多,可以结合项目的情况和开发团队的能力进行定义。因为后面紧跟着进一步的试点和全面推进,在 POC 的过程中,除了验证方案的可行性,还要进一步的产出落地的规范和开发模板。架构治理所涉及的开发工作技术难度较大,比传统的业务开发涉及的技术难点更多,为避免开发人员经验不足导致的问题,需要通过 POC 产出架构专项治理的开发步骤,每个步骤的规范以及验证方式。


另外在试点和全面推进阶段,一定要设计回退方案,架构治理通常是底层技术架构的调整,涉及大量业务功能,一旦有问题,影响面非常大,很难确保万无一失,所以要设计完善的回退方案或灰度验证方案,把影响降到最低。

发布于: 14 小时前阅读数: 12
用户头像

码猿外

关注

功不求戾,但求有恒 2018-10-07 加入

麻广广,Thoughtworks Principal Consultant,CAC认证专业敏捷教练,资深软件架构师 专注于分布式软件架构设计、微服务架构设计、软件架构治理和敏捷软件开发管理。 个人主页:https://www.maguangguang.xyz

评论

发布
暂无评论
如何落地复杂系统的架构治理?_架构设计_码猿外_InfoQ写作社区