如何持续架构治理？我们和 ChatGPT 聊了一会？

Posted 2023-03-04 Phodal

在上周的 QCon 北京 2022 大会上，我和我的同事黄雨青一起分享了《组织级架构治理的正确方式》，以帮助开发人员对组织级架构治理体系全貌一瞥，并厘清治理工具的设计思路和核心功能内容。

结合我们在 ArchGuard 的探索经验，我们：

1. 基于 “视点与视角” 构建架构治理的工具全景。以帮助组织了解架构治理的整体情况

2. ”点-线-面” 策略。以帮助组织围绕关注点，设计举措，引导架构的演进。

3. 建议以探索的方式构建量化工具。以使工具更加适用和实用。

4. 工具构建的要点：定义问题、捕获数据、归纳指标。以保证工具构建的准确性和有效性。

考虑到我在 QCon 上讲的时候，可能有点紧张，所以并不是很完全，便想结合 ChatGPT 写一篇文章再介绍一下。

一、构建架构治理全景： “视点与视角、利益相关者”

在构建 ArchGuard 时，我们尝试过结合不同的前辈和他们架构理念，从而从不同的维度来构建治理的全景：

用途	模型	书籍
可视化	C4 模型	《程序员必读之软件架构》
分析架构	体系结构视图	《实用体系软件结构》
治理全景	视点与视图、利益相关者	《软件系统架构：使用视点和视角与利益相关者合作》

从起初单一的开发者 C4 视角，到现在利益相关者的视角，它是我们与不同利益相关者碰撞的结果。如下，是我们结合上述的《软件系统架构》一书，构建的全景图示例：

它与我们在设计架构时类似，每个利益相关者都有自己的利益，要考虑的问题也有所不同。

诸如于，业务人员往往只考虑为什么响应速度慢，并不会关注于代码质量。

而与普通的开发人员相比，技术负责人、架构师会更关注于开发规范性。对于一个组织而言，我们需要考虑方方面面的因素，才能尽可能满足大部分人的需求。除此，量化的角度来说，我们需要将问题划到到时机 —— 创建态、设计态、开发态、运行态等不同的时态，以能更好地选择合适的工具。时机视不同的软件系统，也存在各种的差异。

二、“点-线-面” 策略

PS：本小节，由作者（Phodal）提供输入，最后由 ChatGPT 生成。

“点-线-面” 定义

"点-线-面" 策略是一种规划和管理软件架构的方法。

• "点" 指的是重点关注的领域，例如性能、安全等。我们需要通过工具来监控这些关注点。

• "线" 指的是连接各个关注点的活动，例如评估、监控等。这些活动可以帮助我们了解当前架构的状况，并且帮助我们持续改进。

• "面" 指的是整个架构，我们可以通过不断的评估和改进来实现架构的演进。

总的来说，"点-线-面" 策略可以帮助我们在关注重要领域的同时，通过持续的评估和改进来实现架构的演进。

“点-线-面” 核心思想

点-线-面 策略的核心思想是工具化、可视化和指标化。

• 工具化：将架构治理的各种实践放入到开发流程中，通过工具化的方式简化实现。

• 可视化：围绕着不同的关注点，通过可视化的手段（如可视化图形、报告等），对系统的架构进行监控。

• 指标化：通过不断地对系统进行评估和度量，并通过指标化的方式来描述系统的表现。

这样的策略旨在帮助开发人员更好地了解系统的架构，并对其进行持续的改进。

“点-线-面” 示例

工具化、可视化、指标化方法的选择取决于具体需求和场景。它们可以通过一些已有的开源工具或者定制的工具实现。例如：

• 工具化：代码检查工具（Linter），代码风格管理工具，代码生成工具等。

• 可视化：系统架构图（例如 C4 model），应用性能监测工具（APM）、架构文档（如 Archimate）、可视化系统（如 Archimate Viewer）等。

• 指标化：代码度量工具（如 SonarQube）、度量和报告工具（例如 InfluxDB + Grafana）等。

它们能帮助团队对软件系统架构进行标准化、可视化和指标化，以确保系统质量和一致性，并有序地演进。

其它工具

适用于架构治理的工具通常还包括：

1. 架构建模工具：用于捕捉和模拟系统架构，帮助开发人员更好地了解系统的构建和行为。

2. 架构文档工具：用于管理架构文档，使团队能够保持一致的架构治理标准。

3. 架构模型工具：用于创建和管理架构模型，帮助团队更好地控制和管理架构的复杂性。

4. 可视化工具：用于展示架构和系统信息，帮助团队更直观地理解系统状态。

5. 架构审核工具：用于审核架构设计，帮助团队确保架构设计符合架构治理标准。

6. 架构版本管理工具：用于管理架构版本，帮助团队跟踪架构的变化和演进。

不同的需求可能需要结合不同的工具，因此最终的选择应该在实际使用中评估和确定。

三、探索式架构工具开发

由于业内对于架构治理没有统一的定义，所以我们将其持续架构治理模式。为了管理各种不确定性（诸如工作量无法估算、技术选择的不确定性、缺乏清晰的架构治理框架等），并快速交付包含架构治理模型、有价值的软件。我们采用了两个与共同业务成果相一致的工作流：

• Discovery，进行试验、评估以确定所选技术的可行性和性能，以更好地分配开发资源。

• Development，用于持续构建和发布成功的实验和其他产品功能，并结合迭代反馈。

它们的优点是（ChatGPT 说）：

1. 更好的风险管理：通过 Discovery 阶段的试验和评估，可以确定所选技术的可行性和性能，从而减少技术上的风险。

2. 更快的交付：通过 Development 阶段的持续构建和发布，可以快速交付含有架构治理模型的有价值的软件。

3. 更高的效率：通过 Discovery 阶段的试验和评估，可以更好地分配开发资源，从而提高开发效率。

4. 更好的迭代反馈：通过 Development 阶段结合迭代反馈，可以快速修正问题，并不断提高产品质量。

5. 更好的合作：通过与共同业务成果相一致的工作流，可以更好地沟通和协作，从而提高团队效率。

诸如于我们在构建 ArchGuard 代码中的 SQL Lint 分析功能时，开发 MyBatis 的 SQL 生成的工作量时，实际 = 评估 * 4。

四、治理工具构建要点

对于架构治理而言，我们要考虑的是：

1. 标准化能力/实践。通过寻找针对于大部分团队或场景都适用的方法和策略，提高团队的标准化能力，更好地推进架构治理工作。

2. 持续分析与检测。持续探索和完善已有工具不支持的规范与标准化实践，保证架构治理的有效性和可靠性。

3. 多维度度量。通过结合不同治理工具的数据和指标框架，构建适合于自身组织的指标，对架构治理的效果进行客观评价。

对应的，我们将其核心点总结为：

1. 定义问题：首先，架构师需要定义架构治理的问题，诸如系统性能不佳、质量问题等。

2. 捕获数据：其次，架构师需要捕获数据来了解系统的运行情况，例如，使用应用性能监测（APM）工具获取系统性能数据，使用代码度量工具（如SonarQube）获取代码质量数据等。

3. 归纳指标：最后，架构师需要归纳指标来评估系统的情况，例如，评估系统的性能是否满足需求，评估代码质量是否符合标准等。

总之，通过定义问题、捕获数据、归纳指标等步骤，架构师可以更好地控制和管理系统的架构，从而提高系统的质量和性能。