架构决策的制定过程


自 20 世纪 90 年代软件架构诞生以来，架构决策 (AD) 一直在回答有关设计选项的“为什么”问题。捕捉它们的方法应该成为每个架构师工具箱的一部分。

少即是多——只有关键的广告才能证明这一努力的合理性，只有清晰而合理的理由才能说服读者。让我们看看如何到达那里。

动机
让我们从一个真实的故事开始举例说明：1

一个敏捷软件开发团队迎来了一名新成员，我们假设他是一名外部顾问。这位新成员立即开始对当前的设计提出挑战：

  • "你们为什么决定采用服务器端渲染，在浏览器中执行 JavaScript 的单页面应用程序（SPA）响应速度更快、效率更高？
  • "客户端和服务器不是应该使用 JSON 而不是 XML 来交换数据吗？
  • "你怎么能把产品的未来押在 JSF 这样过时的技术上？

这些问题讨论了很多次，但没人记得考虑了哪些方案，哪些标准推动了最后的部分。事实上，一些意见领袖已经离开了项目或公司。留下来的人也不记得当时的思路和详细论证了--从那以后发生了太多的事情。

这听起来是不是很熟悉？如果一次又一次地重新考虑同样的问题，渐进式迭代就会变成 "我们以前来过这里 "的循环。决策日志可以回答这些问题，让新手（可能是出于好意）"闭嘴"。

一点历史
架构决策（AD）一直都很重要。有些团队会比其他团队更明确地做出决定，但我们都希望在最负责任的时刻做出决定，即使是最敏捷的团队也会以某种方式捕捉到重要的决定。

因此，方法工程师和实践领导者在 AD 方面有很多话要说，而且现在依然如此。我们可以确定认识和采用的三个阶段：

崛起/分化阶段。
与 UML 或 ADL 等符号相比，AD 在 20 世纪 90 年代受到的关注要少一些，但它们确实已经存在：

  • 在 1992 年的一篇研究论文中，"原理 "一词作为软件体系结构的三个组成部分之一被提出。
  • 软件供应商和专业服务公司为其员工建立了模板，但通常并不公布（这是在博客和开放源代码流行之前）。例如，IBM 全球服务方法中的工作产品 ARC-100 被称为--令人吃惊，令人吃惊--架构决策3。
  • 商业化的 Rational Unified Process（RUP）4 也包括一个决策指南，但现在已经很难在网上找到了（例如，在 OpenUP 中）。


趋势/繁荣阶段
2000 年代，架构知识管理 (AKM) 和 ADs 成为软件架构研究的热门话题，业界资深架构师开始与公众分享他们的 AKM 实践：

  • 2004 年的格罗宁根研讨会拉开了深入研究的序幕。例如，A. Jansen 设定了场景，P. Kruchten 捐赠了分类法。R. Capilla、U. van Heesch 和其他人建议让决策形成一个专门的观点。
  • J.来自 CapitalOne 的 Tyree 和 A. Akerman 从 IBM 电子商务参考架构（带有预填充的 AD 记录）中获得了灵感，并在《电气和电子工程师学会软件》（IEEE Software）的一篇文章中阐述了 AD 为何重要，该文章还提供了一个丰富的模板。
  • 在我的博士论文中，我研究了在多个项目中使用类似设计时是否会再次出现 AD 问题，以及是否可以从获得的经验中挖掘出决策树。我提出了一种方法，可以系统地识别对 AD 的需求以及需求和风格定义中的可用选项。以服务为导向的架构（SOA）作为一种示范性的架构风格，我尝试了我的方法和模型。其中一个决策模型成为了公司内部的知识资产；所有概念以及有关 AD 问题、选项和标准的许多示例都出现在我当时的研究论文中。
  • ISO/IEC/IEEE 42010 标准发布。该标准建议捕捉决策依据，并给出了范围界定和筛选建议（还澄清了许多其他概念），可以说是有史以来可读性最强的标准之一。
  • WICSA 和 ECSA 等学术会议以及科学杂志介绍了大量研究成果，其中一些成果已付诸实践，或对其他成果有所启发。例如，许多研究人员对 AD 与模式之间的联系进行了研究（ArchPaD 是我与 Uwe Zdun 的合作成果）。Springer 出版的 "软件架构知识管理 "一书汇集了世界各地许多 AKM/AD 研究人员撰写的章节；我有幸参与了关于 SOA 基础架构决策重用的案例研究。Antony Tang 等人撰写的 "架构知识管理工具比较研究 "一书中介绍了全部工具（截至 2010 年）。

商品/必备阶段（自 2010 年起）
反倾销协定现已成为行业项目的主流：

  • M.Nygard 的《架构决策记录》（ADR）博文引起了广泛关注。该主题经常出现在 SATURN 等软件架构会议上。
  • 架构文档模板 arc42 第 9 节专门讨论了 AD，并给出了九条相关提示。
  • 工具发布。我参与开发的开源工具包括 Markdown Architectural Decision Records (MADR)（由 Oliver Kopp 发起，他的硕士生项目需要一个模板），以及 Enterprise Architect 的插件 AD Mentor（与 ABB 的 Heiko Koziolek 和 Thomas Goldschmidt 共同开发）。

因此，20 世纪 90 年代的 ARC-100 工作成果是正确的："没有理由不拥有这种工作成果"。AD 将继续存在。现在，维基百科上甚至有关于反倾销广告的页面。

我们现在知道了反倾销的重要性和历史--但我们仍然不确定应该关注哪些反倾销以及如何捕捉它们。后一个主题（如何捕捉）将在本文章中讨论；而前一个主题（捕捉哪些）则需要等待下一篇文章--如果您等不及，请参阅 arc42 中的提示 9-1："只记录与架构相关的决定"，或者这篇研讨会论文（论文中的 "元问题 "适用于任何风格）。

Y-Statements 和其他模板
作为 IBM 的咨询 IT 架构师，我一直沿用 ARC 100 模板，但通常会稍作删减（遵循我采用方法的第一法则："如果有疑问，就不要用它"）。在 SOAD 博士项目中，我提出了一个更丰富的元模型，针对决策重用（即所需决策，而非所做决策）进行了优化。然而，我必须学会不要做得太过分：填写完整的决策记录（项目之间共享）的维护工作变得相当繁重。

我接下来的两个项目的发起人都是高级经理和技术负责人，他们不愿意把宝贵的时间花在审阅冗长的文本文件上。引用我工作中的一句话："你能把每个决定都写在一张演示幻灯片上吗？给人们他们想要的东西并不一定是个坏主意，尤其是如果这些人赞助了你的项目。因此，我重新思考了我的 AD 捕捉和共享方法，并试图将重点放在决策的基本要素上。

成果：(WH)Y-statements，在 2012 年 SATURN 会议上发表，用于大型 C 级企业转型和物联网云项目，并发表在 IEEE Software/InfoQ 文章中：


在网店服务上下文方面、
在网店服务中，用户会话数据需要在不同的网店实例中保持一致和最新、
我们决定采用数据库会话状态模式
而忽略了客户端会话状态或服务器会话状态。
以实现云弹性、
会话数据库需要设计、实施和复制。


在上例中，每个模板元素都出现在一行中：

  • 上下文：功能需求（用户故事或用例）或架构组件、
  • 面向：非功能性要求，例如期望的质量、
  • 我们决定：决策结果，可以说是最重要的部分、
  • 忽略：未选择的替代方案（不能忘记！）、
  • 实现：效益，完全或部分满足要求、
  • 同时考虑到：缺点、对其他属性/环境的影响以及精力/成本。

这个模板比我之前的尝试要精简得多。它的六个部分组成了一个（相当长的）句子，可以用字母 "Y "来表示，发音就像单词 "why"，这也是模板名称的由来：

以下是我的 Y 报表与其他流行模板的比较：

我想说的是，Y 语句在这种比较中表现得相当不错（就精简而言）；而 Nygard 的 ADR 和 arc42 提示中各有五个部分，可能会变得相当长。该表格和更详细的比较见这篇 WICSA 2015 论文（其中也介绍了 ADMentor）。您可以在 e-ADR 中找到这种六部分结构的 Java 注释。

我在教学中使用 Y 语句。其他人也在使用。由 innoQ 架构师发起的 "分析和反思注定失败的软件的卡片"（card42）计划将其作为众多精美卡片的第三6张。决策故事方法和论文就是从它们开始的。Herberto Graca 似乎在他的 ADR 模板的摘要部分使用了这些卡片，参见他的博文 "记录软件架构"。LinkedIn 上也进行了热烈的讨论。

好的和坏的理由
让我们看看哪些论据有机会通过 AD 记录审查员的审查（使用我的 Y 格式还是其他格式并不重要，但总要回答为什么的问题）：

  • "我们已经在成功的项目中多次应用了这种设计（模式、技术、产品），这些项目在类似的背景下解决了类似的需求"。
  • "我们进行了概念验证（PoC）或技术验证（PoT），结果令人信服；这种方法将帮助我们实现所要求的质量。
  • "市场上有成功应用这种技术的技能，使用这种技术可以增加聘用到优秀软件工程师的机会"。

我还看到过以下 "论点 "的变体，但它们的反响并不那么好：

  • "大家都这么做。有人告诉我这是个不错的选择"。
  • "我们一直都是这么做的。"或者 "我不知道有什么替代方案，也没有时间去找。"
  • "这种模式、技术和/或产品方面的经验在我的简历上会非常漂亮"。
  • 我在 SATURN 2012 演讲中还举了更多的例子和反例。

练习：查找团队最近做出的一些决策。这些决策的记录如何--它们回答了为什么吗？理由是否让你信服？

收获和下一步
如果你能牢记这一点，你将会享受到制作和捕捉 AD 的乐趣，并成为一名更好的建筑师：

  1. 为什么？"问题的答案与设计中的其他问题一样重要。没有理由不记录你的关键决策，并为所选方案（模式、技术和产品）提供简短而可靠的理由。
  2. 避免伪理由和套话；在决策记录中参考实际需求和经验证据。对备选方案进行比较！
  3. 不要记录所有内容；超过 100 条的 AD 日志可能会让读者（和你自己）昏昏欲睡，而且很难维护。把重点放在具有重要架构意义的需求和决策上--那些重要的需求和决策，那些难以改变且代价高昂的需求和决策。在这里可以找到一些更具体的提示和定义。
  4. 有许多模板，只需选择一个并坚持使用。或者创建一个并坚持使用。
  5. 选择任何适合你的文化和设置的 "工具"。在这里，"工具 "可以是纯文本文件、wiki 或用于其他目的的应用程序（例如敏捷问题跟踪器或任务板、UML 建模工具、版本控制系统）。试试 Markdown!