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