艰难历程 ：永续架构的决策与治理
导读
业务需求：业务架构应与组织的业务目标和要求保持一致。
技术要求：技术架构应基于系统的技术要求，例如可伸缩性、安全性、性能和可维护性。
最佳做法：架构应遵循行业最佳实践和既定的设计模式，并充分考虑自身发展需求。
可伸缩性：架构的设计方式应使其能够根据需要轻松扩展或缩减，而不会影响系统的功能或性能。
灵活性：架构应具有灵活性，并可适应业务需求和技术环境的变化。
可维护性：架构应该易于维护，具有清晰的文档和职责分离。
安全性：架构应包含安全措施来保护敏感数据并确保系统的机密性、完整性和可用性。
性能：架构应设计为满足性能要求，例如响应时间和吞吐量。
评估这些因素之间的权衡并做出明智的决策以平衡组织需求与技术环境的现实也很重要。根据需要定期审查和更新架构有助于确保它继续满足不断变化的业务需求。
架构决策
如果问一个软件从业者，架构活动最明显的输出是什么，很多人可能会指向一张突出关键组件及其交互的精美图表，而且往往图表的颜色越多、复杂程度越高越好。
通常来说，这种图表在普通页面上很难阅读，而且需要特殊的大型打印机来制作。架 构师想让自己看上去很聪明，通过制作复杂的图表来显示自己有能力解决极其困难的问题。虽然这种图表看似能够控制住作图者和看图者，但实际上对推动架构变化的影响往往很有限。
一般来说，大家对这些图表的理解都不太一致，在没有作图者加入画外音的情况下， 很难进行有效解读。此外，这种图表还很难更改，最终会与生产环境中运行的代码产生分 歧，从而在制定架构决策时让人产生困惑。
这就给我们带来了一个问题：
架构师(或架构工作) 的工作单元是什么？
是花哨的图 表、逻辑模型还是运行中的原型？
持续架构指出架构师的工作单元是架构决策。
因此，任何架构活动最重要的输出之一就是在软件开发过程中做出的一系列决策。但是，对于以一致且容易理解的方式达成并记录架构决策，大多数组织所付出的精力少之又少，这点让我 们非常惊讶。
当然，在过去几年中，我们也看到了这一问题在不断得到纠正。
GitHub中对记录架构决策的关注就是一个很好的例子。
架构决策应该是什么样的，重点如下：
❑清楚阐明与决策相关的所有约束条件非常重要——从本质上来说，架构就是在给定
的约束条件内找到最佳(即足够好)的解决方案。
❑聚焦质量属性，而不仅仅是功能性需求。明确解决质量属性需求的重要性。
❑必须阐明所有考虑过的选项以及做出决策的理由。
❑应考虑不同选项之间的权衡以及该决策对质量属性的影响。
最后，对于架构决策至关重要的一点是：谁做出了这个决策，何时做出了这个决策？适当的问责制能增加人们对决策的信任。
架构决策的制定和治理
让我们看看企业中不同类型的架构决策。
下图展示了一个典型企业做架构决策的方法，这种方法也是我们所推荐的。
假设一个企业已经建立了批准决策的治理机构，那么该治理机构的级别越高，所做的 决策和审查自然就越少。譬如，与产品级治理委员会相比，企业架构委员会做出的决策要少得多。值得注意的是，架构决策的范围和重要性会随着规模的增加而增加。但是，大多 数可能影响架构的决策都是由开发团队实地推动的。
离实施越近，做的决策就越多。尽管这些决策的范围通常比较有限，但随着时间的推移，这些决策会对整体架构产生显著影响。
在开发这个级别，做更多的决策本身没有错，我们反对的是给需要敏捷的开发团队造成不必要的负担和官僚主义。为交付软件系统，开发团队必须快速做出决定。从持续架构的角 度来看，有两大要素能使我们有效利用敏捷的项目团队，扩大架构决策治理的范围：
❑指导方针：实际上，如果开发团队有明确的指导方针要遵守，它破坏架构的可能性就会大大降低。
比方说，如果我们在何处实现以及如何实现存储过程方面有明确的 指导方针，就能避免在架构的任意地方编写存储过程从而导致整体架构变脆弱的情况。上级治理机构的主要工作不是做出决策，而是制定指导方针。
❑可视化 ：如前所述，我们不想妨碍开发团队按照自己的交付节奏做出决策。同时，我们也不希望系统或企业的整体架构因开发团队的决策而受到损害。回到之前所举 的存储过程的例子，我们可以想象这样一个场景：团队随意放置了一些存储过程以 满足它的即时交付。在某些情况下，团队甚至忘记了这些存储过程的存在，从而导致了一个重构成本极高的脆弱架构。
在一个组织的各个级别实现架构决策的可视化 并在不同团队之间共享这些决策将大大降低重大架构妥协发生的可能性。从技术层 面上讲，实现决策可视化并不困难，只需要就如何记录架构决策达成一致即可。读者可以使用我们第一本书中提供的模板或架构决策记录表，也可以利用组织中现有的通信和社交媒体渠道来分享这些决策。虽然技术难度不高，但培养架构决策共享的企业文化目前依然很难实现， 因为它需要原则、毅力和开放的沟通。让每个人都可以看到你的决策，同时在工作时与团队保持密切联系(例如，进入它的Git 仓库 查看)，这两者之间也天然存在一种紧张的关系。
让我们简单看一下持续架构几大准则是如何帮助我们处理架构决策的。这些准则与领 域驱动设计的方法是一致的，它是一种非常强大的软件开发方法，可以用来解决持续架构 所面临的类似挑战。
❑应用准则 (利用“微小的力量”，面向变化来设计架构)，创造松散耦合的内聚组件，组件内的架构决策对其他组件的影响有限。某些架构决策仍然会影响其他组件(譬如最低限度来说，如何定义组件及其集成模式)，但我们可以通过制定专门针对该组件的一些决策来单独解决。
❑应用准则 (在完成系统设计后，开始为团队做组织建模)，以建立专注于组件交付的协作型团队。当团队间以合作的方式开始运行时，相关架构决策的知识共享也会变得更加自然。
敏捷项目中的架构决策
现在，让我们研究一下敏捷开发环境中的架构决策。
大多数技术从业者都对来自象牙塔的高层架构方向持谨慎态度。
团队会做出必要的决策并在需要时对这些决策进行重构。
我们支持这种观点。
持续架构强调应明确关注架构决策，而非在激烈的讨论中忘记它们。
架构决策应该被视为重要的软件工件，这是使敏捷扩展到更广泛的企业环境并与更广泛的企业环境相关联的关键。
明确定义所有已知的架构决策，其实是在创建一个架构的待办事项。这些架构决策包 括你已经做出的决策以及你知道自己必须要做的决策。
显然，该架构决策列表会随着你做出 的一个个决策以及产品的开发而不断演进。但重要的是，我们有这样一个已知的架构决策列表，然后确定哪些问题是需要立即解决的。
牢记准则——在绝对必要的时候再做设计决策。
要将架构决策与产品待办事项结合起来，主要有两种方式。
一种方式是将架构决策的待办事项分离开来。
另一种方式是将它们作为产品待办事项的 一部分，但进行单独标记。
具体采用哪种方法应基 于自身情况而定，选择适合自己的，关键是不要忘记这些架构决策。
下图说明了架构决策待办事项如何在逻辑上与单个产品待办事项相关联。
如果基于风险进行优先级排序，应优先关注架构上重要的场景，然后在前几个冲刺周期专注于做出关键的架构决策。
之后，如果能让其他团队和相关架构团队看到
架构决策和产品待办事项
你的架构待办事项，那么它们就能完全无障碍地了解你的架构演进方式。
尽管关注架构决策是一项基本活动，但对架构进行一定程度的描述来实现架构的分享和交互仍然十分必要。我们认为，50% 以上的架构是关于沟通和协作的。你需要借此来培训新的团队成员并向不同涉众解释你的系统。
这些案例只是示例，并不是一整套完整的决策。此外，我们只抓取每个决策的一些基本信息，如下表 所示。对于大多数架构决策，我们希望能捕捉更多的信息，包括与分析及决策理由相关的约束条件 和细节。
决策日志条目示例
推荐阅读