架构师如何赋能程序员团队？ - esilva

本文启发来自 Gregor Hohpe的一篇文章（关于架构策略的参考，有许多关于此主题的著作和书籍）。

在该文中，Gregor 涉及一个非常重要的主题：我们可以采用的拓扑（模型/形式）来处理我们组织团队中的架构。

这是许多组织处理不当或采取静态/极端方法的主题，即：

• 在极端情况下，象牙塔架构师负责指挥和控制团队内外的所有“重要决策”（格雷戈尔模型中的“仁慈的独裁者”） ;
•  或者另一个极端，没有架构师（“因为我们很敏捷”），因此我们不关心团队中的架构纪律（Gregor 模型中的“隐式架构”）。

非常重要的是，我们在团队中处理架构的方式也将随着团队和周围环境的变化而发展。

下面我分享一些关于 Gregor 分享的模型的笔记和见解；接近架构的拓扑结构；进化模式；然后是关于架构范围的一些见解和注释。

团队内架构

Gregor 分享的模型特别强调“团队范围架构”，即：如何在团队拥有的系统中处理架构。所呈现的模型具有四种基本拓扑。可能会有变化和组合，但我认为这四种拓扑提供了一个很好的基础。

• #1：仁慈的独裁者”

架构师“告诉团队该做什么”（与团队的单向交互）。这是一个相当经典的建筑师定义/原型（我什至会说我在谈论建筑师时从人们那里听到的最常见的联想之一）。正如 Gregor 所说，“应谨慎使用此模型”，并且很可能仅在短时间内对架构成熟度较低的团队和组织有意义。即使真的需要它，我也会说在尽可能短的时间内保持这种拓扑结构。然后将元素放置到位以移动到#2（以及何时/如果可能的话）#3。当此拓扑用于其他目的时（例如：控制重要决策），

• #2：Primus inter pares（架构师 - 作为功能 - 在团队中）

架构师成为另一个团队成员 - 同行 - 在团队中。该模型修复了模型#1 中存在的单向交互模式。这使得架构活动在团队中更加明确。这意味着团队将有更多的能力来应对和解决他们在日常活动中面临的“重要决策”，这应该会带来更高的敏捷性和适应性（或者正如Michael Nygard 所说的“更高的机动性”) 对他们的环境做出反应。虽然这个模型确保架构在团队中得到明确的解决，但它仍然定义了只有团队中的一个人专注于架构（这里会有灰色区域——因为大多数时候人们都参与架构，但这个模型定义了一个架构师在团队中发挥作用，这会产生某些动态，例如团队中有一个架构决策的守门人）。因此，我们可能也不想“永远”保持这种模式。

• #3：没有架构师的架构（多个/所有团队成员之一的架构师角色）

没有人具有架构师的功能，多人（甚至团队中的每个人）扮演架构师的角色。该模型减轻了模型 #2 可能存在的“中心化瓶颈”。这是一个强大的地方，因为团队可以扩展他们处理架构的方式。我之前讲过这个并称之为“每个人的架构师”，虽然这是一个难以实施的模型，但纯粹的努力（并确保每个人都关心“重要决策”）能够创建强大的团队最终共享架构所有权。

• #4“隐式架构”

（没有人具有架构师的功能，也没有架构师的角色）：这是一个危险的领域，因为没有人在看架构（即使显然有）。这（以及混合模型 #1 的模型）是一个相当普遍的模型，尤其是在错误解释敏捷原则的团队和组织中。

进化模式

我真正喜欢这篇文章的另一部分是 Gregor 进入“进化模式”这一事实。承认这一点至关重要，因为我们的架构方法取决于许多不断变化的因素（团队成熟度、组织文化、周围系统等）。这对于确保我们的架构方法不断发展以更好地支持团队及其环境中的新条件至关重要（即：我们的架构方法与组织中正在发生变化的其他动态不冲突）。

Gregor 有两种常见的模式（但可能还有其他模式）：

• 右移：当我们从团队之外的架构师（例如：首席架构师）开始时，例如架构被长期忽视时，就会发生这种情况；但随后我们采取措施将架构师（职能）整合到团队中；一旦团队成熟，多人可以在团队中扮演架构师的角色。在这种模式中，Gregor 建议停留在模型 #3，即：不要走得太远，没有明确地处理团队中的架构。
• Bounce Back：当“Shift to Right”模式不成功时会发生这种情况，即：我们尝试在团队中有一个架构师，或者甚至团队中有多个人扮演架构师的角色，但效果不佳. 在那些时刻，我们可能会“恢复”让外部经验丰富的架构师明确为团队/与团队一起解决架构问题。这可能又是一个临时活动，以解决在先前迭代中不起作用的点。这听起来像是倒退了一步，但在一个复杂的系统中，您不知道系统将如何反应，因此您必须采取行动来学习（正如Cynefin 框架所提倡的那样）。

还有其他进化模型，如果我们考虑团队周围的范围，这将变得更加明确。观察这些演化模式不仅很重要，而且在团队所属的系统中“连接范围”也很重要——这是架构的关键。在下一节中，我将提供有关此特定主题的一些意见。

架构作用域

查看团队范围周围的范围以全面解决团队范围并将其连接到周围的范围（和系统）是关键。

事实上，这是由 Gregor 在其他关于他的“建筑师电梯”比喻的文章中广泛发展的——即：“将顶层公寓与机房连接起来”。也在文章“系统级架构设计存在意义：极简主义架构  ”中

赋能架构师

将这个特定的团队定义为“结构赋能团队”。原因来自这样一个事实，即一般来说，这是一个赋能团队（根据书籍定义）存在的时间有限。另一方面，架构团队往往会无限期地存在。

这种“架构作为赋能团队”的定位也意味着我们在组织中有一个架构师网络，具有明确的使命（使能团队），他们可以在领域知识上进行协作，也可以交流做架构的知识，从而培养架构师的技能。在组织中做架构（在架构师之间，以及与他们合作的团队）。这将意味着我们处理架构的方式也将不断发展（例如：新人加入，新挑战出现等）并且我们明确关注迎合架构（即使在特定时刻我们有不那么明确的架构师职能） - 例如：如果这只是文化的一部分，我们需要正式的架构师在场）。

例如，一个人可能具有架构师职能，在多个相关团队中工作，这些团队共同构建产品或为客户的共同价值流做出贡献（例如：公司产品组合中的产品）。下图描绘了这个想法（注意：这是一个简化的表示，旨在展示架构师在此拓扑中的可能定位方式）。

正如我们在图中看到的，这个人（在这种情况下我称她为“产品架构师”）在“产品范围”（围绕团队范围的系统）工作。她将与团队（以及领域以下范围）在产品范围的架构上保持一致。此外，她还可以在指导和支持每个团队在团队范围内（存在不同的应用程序）处理架构方面发挥作用。因此，这成为 Gregor 共享的拓扑 #1 版本的一种升级（具有双向交互），但同时团队（应该）负责团队自己范围架构（即：使用拓扑#3，或在某些情况下#2）。这种组合可以接近解决架构所需的不同范围。