架构工作的本质 - 第5部分

# 架构工作的本质 - 第五部分 来源：https://www.ufried.com/blog/essence_of_architecture_5/ ## 架构工作的本质 \- 第五部分 在上一篇文章（https://ufried.com/blog/essence_of_architecture_4/）中，我们通过探讨架构工作的认知层面与人文层面，结束了对架构工作*为何存在*（其目的）的讨论。我们也简要提到，除非反复解决已解问题，否则AI代理无法满足架构工作的这些特性。 在本文中，我们将转向架构工作的下一个维度——*是什么*，并讨论构成架构工作的各项不同活动。 ## 架构工作的定律 在讨论构成架构工作的活动之前，让我们先简要回顾一下“架构工作的两条定律”（https://ufried.com/blog/laws_of_architectural_work/）。如参考博文所述，它们与其说是真正的定律，不如说是“来之不易的发现”。第一条定律是： > **每个决策都有其代价。没有免费的决策。** 这意味着在架构工作中没有免费的午餐。每个决策都有其优势和劣势。架构工作中没有绝对的“对”或“错”，只有更合适或不那么合适的决策1 (https://www.ufried.com/blog/essence_of_architecture_5/#fn:1)。因此，无论有些人试图让你相信什么（通常是为了推销他们的产品或服务），请放心，他们所谓的“完美”架构并不完美。他们只是决定隐藏所做决策的弊端。 询问如何评估优劣势，便引出了第二条定律： > **一个决策只能在其特定的上下文中进行评估。** 架构决策的优劣取决于它们被制定的上下文。一个决策在某个地方可能非常合适，但在另一个地方可能毫无意义。简而言之：上下文很重要——正如常理。 ## 4E框架 有了这两条“定律”，我们来讨论定义架构工作的各项活动。我开发了一个小型框架来组织这些活动。请放心：我不会搬出一个TOGAF重量级的框架。虽然这类框架在特定场景下也可能有其价值，但我本人并不热衷于此。我更倾向于最小化的框架，而非最大化的框架。框架的目的应是辅助你组织和引导思考与工作，而非试图囊括所有可能的细节并强迫你进行“裁剪”。 4E框架也不例外。我设计它时借鉴了Simon Brown的C4模型（https://c4model.com/）的理念：简单、实用、易于记忆。其核心就是4个词2 (https://www.ufried.com/blog/essence_of_architecture_5/#fn:2)。和C4模型一样，你或许可以指出它在某些细节上的缺失，确实如此。4E框架的目的并非捕捉每一个可能的细节。其意图在于捕捉架构工作的*精髓*，我认为它很好地做到了这一点。 让我以轶事的形式解释这个框架的四个部分（这样能进一步简化记忆过程）。 我曾与许多人讨论过架构工作，他们通常是，但不总是，开发人员。当我询问他们架构工作的核心活动是什么时，他们几乎不假思索地回答：*探索*（Explore）。 ## 探索（Explore） \- 寻找解决方案选项 *探索*关乎设计解决方案选项：设计结构与行为，组合框架、工具、技术等等——设计架构所需的一切。请注意，大多数人谈论的是设计*那个*解决方案，即他们使用的是单数形式，而非我用的复数形式。我将在下一篇文章中解释为何这种区分很重要（链接稍后提供）。 架构设计是一项必不可少的活动，也无法被省略，因为每个解决方案都有其架构，也就是说我们总是在设计架构。我们只能选择是显式地设计架构，还是隐式地、即偶然地将其作为编码的副产品来设计。虽然我知道在敏捷热潮的顶峰期，有过一些支持隐式架构设计的倡导者，称之为“涌现式架构”，但我强烈推荐显式设计的变体。3 (https://www.ufried.com/blog/essence_of_architecture_5/#fn:3) 很多时候，架构工作被简化为*探索*活动。仅设计解决方案的问题在于，你不知道该方案是否以及如何满足我们在前面文章中讨论过的架构的*为何*（目的）。也许它能创造一个可运行的解决方案。至少我们希望如此。但是，它能在不损害运行时行为正确性的前提下，最小化系统生命周期内的累计成本吗？它能精炼并结构化问题域，并在解决方案域中提供指导和方向吗？它能改善受影响人群的生活吗？ 也许能。也许不能。我们不知道。我们只是基于自己在真空中的信念设计了这个方案（这也是架构常常成为激烈却缺乏依据的争论主题的另一个原因）。 因此，我告诉我的同行们，*探索*是好的、也是必要的，但还不够充分。我要求他们再想想。通常，这会让他们思考片刻。然后有人提到架构师倾向于大量沟通，因此这必定是另一项活动。也就是说，他们触及了*执行*（Execute）。 ## 执行（Execute） \- 帮助利益相关者做出最佳决策 *执行*是我所称的，帮助所涉及的利益相关者在其上下文中做出最佳决策。我指的不是作为架构师亲自做决策，而是支持他人做决策，因为大多数时候，我们架构师并不直接做决策。决策由其他利益相关者做出。即使我们认为是自己做的决策，多半也是一种幻觉。 例如，许多架构师认为他们决定了哪种架构会被实现。但实际上，是开发人员决定了他们实现哪种架构。如果他们相信我们设计的架构是好的，他们就会实现它。否则，他们会运用自己强大的脑力来避免实现它。即使我们试图通过增加评审和其他流程控制来强制他们实现“我们的”架构，他们也会找到绕过的方法。此外，这是一场徒劳的战斗。浪费的精力本可用于更好的地方。 因此，我更愿意说，作为架构师，我们是支持其他利益相关者做出良好决策。这需要大量的沟通、协作、说服等等。关键在于，人们通常做出糟糕的决定，不是因为他们无知或恶意，更多时候是因为他们缺乏相关信息。作为架构师，我们与多个利益相关者群体交流，这常常给我们带来其他群体所缺失的信息。整理并共享这些信息，从而支持不同利益相关者群体基于更全面的基础做决策，最终会导向更好的决策。 因此，这是另一项至关重要的活动。 ## 忽视相关的利益相关者群体 一个典型的项目涉及十几个或更多利益相关者群体。每个群体的需求、对项目的看法、所使用的语言等都大相径庭。因此，作为一名架构师，如果你真的想支持他们在其上下文中做出最佳决策，学会理解他们就至关重要。 我常常在这里看到不足。大多数自称架构师的人，通常落入以下两类： - “开发者架构师” - “非开发者架构师” 第一类通常是资深开发人员，他们开始承担更多责任，因此开始自称“架构师”，这往往被企业职业路径所强化——将“架构师”置于“开发者”之上。然而，这些人通常仍然是开发者，只是经验丰富。对他们来说，继续编码很重要，这使得他们很少有时间去探索软件开发之外的领域。因此，他们的视野常常局限于开发者的需求和诉求。虽然他们倾向于竭力优化与开发时间相关的质量目标，但常常忽视所有其他利益相关者群体及其需求。 这并不奇怪，因为他们从未抽出时间离开自己的开发者领域去探索其他利益相关者的领域，更不用说理解他们的需求、诉求和痛点。然而，他们有限的视角阻碍了他们识别最佳解决方案（不仅仅是针对开发者，而是所有利益相关者群体）。这也阻碍了他们与其他利益相关者群体进行做出最佳决策所需的讨论，因为他们从未理解其他群体，也从未建立起进行此类讨论所需的同理心。 第二类是那些从未（或极少）编写过代码的人。他们通常来自不同领域，但擅长结构化思维、问题解决和沟通——这些都是成为优秀架构师所需要的。他们通常非常擅长理解IT部门以外的利益相关者群体。但他们通常也不擅长理解开发者及其需求和诉求。他们常常认为，要从事架构工作，无需深入理解开发者的工作。 虽然开发者工作和架构工作确实是不同的活动，但它们在多个方面仍然相互关联。首先，如果不理解开发者的需求、诉求和痛点，我们就遗漏了一个至关重要的利益相关者群体。这也降低了我们设计出能在生命周期内以高概率最小化整体成本的解决方案的可能性。不理解开发者的需求，我们就无法理解变更的成本。 最后但同样重要的是，开发者是*实现*架构的人。如果他们不相信架构，就不会去实现它。要说服他们，你需要接近他们并展现同理心。在这方面，开发者与其他任何利益相关者群体并无二致。因此，最好不要忽视开发者。他们也是利益相关者——而且是重要的利益相关者。 最后，这两类架构师都倾向于忽视运维部门，因为他们既非开发者，也非非IT领域的利益相关者。但是，如果我们关心系统在生产环境中的可靠运行，最好也关心他们。 因此，无论你是哪种类型的架构师，最好确保你涵盖所有相关的利益相关者群体。 如果你更偏向“开发者架构师”，这意味着少编码，多学习理解其他领域的人。但这正是成为架构师的意义所在。这并不意味着你完全停止编码。但架构师不是技术负责人。将它们区分为两个角色是有充分理由的。 如果你更偏向“非开发者架构师”，这意味着学习理解IT人员、开发人员以及运维人员。你也应该尝试理解一点技术，甚至可能尝试写点代码。你不会编写生产代码。但能够阅读代码（这要求你自己曾写过一点代码）并与开发人员结对，在与开发人员的讨论中会非常有帮助。 ## 继续前进 即使我们发现了第二项必要的活动，我们仍然没有解决*为何*缺失的问题。我们仍然只能向其他利益相关者群体告知我们设计的解决方案。但我们无法向他们解释为什么这是一个明智的解决方案，只能寄希望于他们会喜欢它而不提出质疑。 因此，我告诉讨论中的同行们，*执行*同样至关重要，但这仍然不够，我要求他们再想想。然后，沉默通常会持续更久一点。最终，有人举手说类似这样的话：“架构师总是谈论‘权衡取舍’（trade-offs）。所以，我觉得这与此有关。”这个人刚刚提到了*评估*（Evaluate）。 ## 中场休息 在进入4E框架的第三个“E”之前，让我们稍作休息。否则，这篇文章会变得太长，而我这次想避免这种超长文章（即使我并不总是成功）。 在本文中，我们讨论了“架构工作的两条定律”，并介绍了4E框架的理念。我们讨论了两个“E”，并点明了第三个。 在下一篇文章中（链接稍后提供），我们将讨论剩余的两个“E”，完成整个框架。敬请期待……