架构师角色的演变：从发号施令到与团队合作

不断变化的世界

与传统的科学相比，软件可以算是一门非常年轻的科学。但即使是在它的婴儿期，它的关键组成部分之一——架构及其形成方式已经发生了重大变化。架构蓝图——花几个月时间完成可以解决所有问题的完整设计——一去不复返了，也没有了由一人负责管理所有东西的场景。之所以发生这种模式转变，一部分是因为行业创造出了更好的工具，还有一部分是因为用户行为发生了变化。他们的交互模式从事务性服务转变为消费驱动型服务，将用户行为从记录系统转变为参与系统，用户现在有了更主动和及时的需求。软件架构需要随之一起演化并拥抱可用的工具才能满足这些新的需求。现在的架构更多的是关于决策而不是结构，更多的是关于对不断发生的变化做出响应而不是遵循规划，更多的是关于频繁交付而不是一次性大型交付。这对架构师所扮演的角色的影响是非常深远的。

在这篇文章中，我们将探讨共享架构的文化变化和架构师角色的演变。从之前依赖架构师的权威和独特视野，变成了在系统设计问题浮出水面时需要整个团队的投入一起解决。这导致了一种控制反转式的团队关系，向共享所有权转变的团队可能正在为融合这种新范式做着苦苦的挣扎。

我们将分享我们是如何经历这一变化的。我们有超过 25 年在一个团队中担任多个职务的经验，从工程师、产品负责人到团队教练和经理。这些角色中的每一个都让我们能够与架构师接触，因此目睹了行业和架构师角色的演变。我们希望能够为那些在转变过程中苦苦挣扎以及那些希望进一步增强和推广他们的架构的人提供指导。

变化因素

职责的变化

传统的架构师有许多基本职责，其中之一就是关于应用程序的可伸缩性。架构师需要考虑许多不同的因素，确保能够处理系统的预期负载。这些决策包括：哪种语言最适合用来处理这种类型的应用程序？如何处理 I/O？阻塞还是非阻塞？数据库采用怎样的策略？需要多少个 CPU 核心？内存呢？存储呢？这些考量因素影响到了部署策略、特定硬件或芯片组的可用性，甚至是应用程序的部署位置。这些决策为我们提供了有关应用程序生命周期的整体概要、它的预期使用以及更新节奏和策略。

在现代环境中，开发团队通过使用工具减少了之前架构师需要考虑的问题。例如，自动伸缩功能解决了应用程序的计算资源消耗问题。Kubernetes 这样的编排平台让部署和处理突发负载变得非常简单，这些平台可以根据需要增加应用程序实例，并在流量减少时逐步减少实例。分析工具，从圈复杂度的静态分析到性能分析指标，再到 API 功能的可视化，现在已经在整个团队层面提供了丰富的信息。这些工具现在已经出现在标准的工作规范中，这意味着架构师以前的专业知识自然而然地分布到了整个团队中，知识生成和数据见解远远超出了单个角色在团队中所能分享的程度。这意味着这个领域的一些所有权和责任已经转移到了整个团队，而不是在某个个体身上。共享所有权已经成为一种现象。现在，团队通常会根据行业标准、用户期望和公司内部的技术一致性来决定采用什么工具。

用户使用模式的变化

云计算（或 SaaS 文化和模型）的快速发展要求我们在如何发布、何时发布以及发布什么方面变得更加灵活。现在的重点是提供更健壮的服务和支持，让团队能够快速改变他们的关注点。功能的增加会带来更多的用户使用，了解用户的使用情况就成为开发和演化功能的关键决策。在以前，这一强化要素是一项长达数月关于稳定性、伸缩性和健壮性的思考，而如今已让位于实验性的意愿。

技术预览版功能（不要在生产环境中使用的警告通常会被故意忽略）可以让应用程序的演化与用户的需求同步，消除了用户与团队之间的脱节。在以前，这种关系通常由业务系统分析师或产品负责人等角色负责维护。现在，团队的用户意识更强了，有时甚至强过架构师。他们了解用户是如何与系统交互的，并通过遥测应用程序的见解知道用户何时与系统发生交互，了解用户需要什么、为什么需要以及如何需要。这为应用程序的开发带来了强大的多层面观点，因为现在整个团队——拥有不同的背景、技能和专业知识——可以为更大的愿景做出贡献，真正地从个体角色转变为主要由团队驱动并与用户需求进行协作的角色。

从代码层面来看，微服务的兴起最能体现其实际影响。随着所有权和需求发生变化，应用程序需要处于能够独立演变的位置，允许一些服务尝试不同的东西、测试一个功能，能够为部分或所有用户打开和关闭某些功能。这创造了一个良性循环，这种开发方法催生了一套支持工具和服务，（如 API 网关）来管理服务合约，还有消息传递系统（如 Apache Kafka）和支持 Spring Boot、Flask 和其他特定语言框架的微服务。工具的可用和成熟反过来使得团队更容易自行选择微服务架构风格，从而进一步推动在工具上的投入。

对于架构师来说，他们不能再按照自己的蓝图来设计架构了。现代用户使用模式对灵活性的要求更高。架构师必须不断调整系统设计来满足快速变化的用户需求，必须促进架构向前演化。

思维模式的变化、机遇、挑战和现在的架构师需要掌握的新技能

在了解了这些变化因素之后，我们相信对于现代架构师来说，他们需要做出改变，需要应对挑战和抓住机遇，并练习和掌握新的技能。

软件架构一直在演化

软件架构是一个演化的旅程，有着不同的路线和影响，这是当今软件架构的一个基本原则。这种演化意味着我们需要根据了解到的东西改变我们的思维，而架构师在促进架构对话方面发挥着关键作用。以下引用了我们在 Red Hat 与一位首席架构师进行互动时说的两句话，反映了当今架构师的一些想法和担忧：

康威定律的影响是一个关键主题：系统的架构反映了组织的结构。

 

架构对话的另一个作用是提出一些没有人意识到的问题，或者每个人都意识到但不愿意谈论的问题。把这些问题提出来讨论是必要的。不是只关注如何解决和实现，而是更多地讨论它们，这样每个人都知道该怎样前进，或者可以随着设计的演化做出适当的调整。有时候，这些讨论最重要的输出是认识到有些问题在当时并不是问题。这种清晰度对每个人来说都很重要。它可以让人们专注于即将到来的任务，而不是被阴影所笼罩。换句话说，它消除了一些无法言喻的负担。

 

—— Emmanuel Bernard，Red Hat 杰出工程师和架构师

假设大多数人会倾向于同意这些想法，但他们的架构决策过程是否进化到与这种想法相匹配的程度？他们考虑到组织结构了吗？他们是否放弃了预先设计而引入了预先对话？任何变化的第一步都是先意识到，然后才是接受。

影响产品/服务变化的主要因素之一是用户互动和反馈，用户有可能是内部团队，也可能是付费客户。在现代市场中，反馈循环是持续进行的，架构师必须充分利用这个机会。与持续反馈相应的是期望更频繁或尽可能接近持续反馈的频率进行交付。这给架构师、团队和组织结构带来了挑战，因为持续交付很少能够独立实现，它通常需要在组织层面才能成功实现。

实现频繁交付的小型迭代很适合这种时间窗口。然而，当引入潜在的更大的功能块（例如架构重构）时，它可能不像人们期望的那么简单。这对架构师和团队提出了挑战，他们要能够频繁地交付组件，同时要确保服务能够高质量运行，能够满足 SLA 和质量期望。更重要的是，在开发的早期，在强制的演化发生之前提出解决方案路径会带来一种对强制的变更拥有所有权的感觉。

在很多情况下，设计决策时机可以与业务需求挂钩。及时地将业务需求与系统设计决策结合起来是架构师及其团队需要解决的真正挑战。传统的架构重点关注最终目标，现在却变成了“接下来需要做些什么来充分解决未来几个月的业务需求”。这可能会导致我们做出一些后续可能需要再次改变的决策，但它们在当时是正确的。我们通过构建产品来获得经验，我们的客户通过与我们的产品交互来获得经验，这为我们提供了紧密的反馈循环。这是系统架构的自然演变，提前了解并制定策略来处理最好的情况和最坏的情况是团队需要的关键技能。架构曾经被认为是一条笔直的道路，但它不是，或者说将来都不应该是。架构的演化是一条曲折的路，每一次转弯都为我们带来一个学习机会。

这并不是说架构师必须忽略架构的最终目标（他们曾经唯一的关注点）。在当前的环境下，产品负责人成为架构师非常重要的合作者，这意味着最终目标和愿景成为共享的经验。对于架构师来说，与产品负责人就产品/服务的愿景展开讨论、合作并达成一致是确保方向性的必要条件，即使这个方向可能并不总是非常明确。相反，这种讨论让产品所有者的愿景变得更加贴近现实，他们可能需要做出妥协，知道什么是可实现的、什么样的时间表是现实的。这个愿景成为技术决策过程的另一个重要输入。

架构不再是单个人的职责

架构师在软件开发当中扮演独立角色的情况一去不复返了。系统架构现在是一项团队运动。团队具备跨职能交付产品的能力，由为交付软件过程增加价值的人组成，其中仍然包括架构师。之所以会这样，正如前面所说的，部分原因是软件开发生态系统涉及技术、语言（不仅是开发语言，还有业务和技术语言）、体验（开发和用户）和利益相关者。没有哪一个人能够覆盖到所有这些方面。这种变化意味着架构师需要转变思维方式。对于架构师来说，他们的工作成为了团队的一部分，这有很大的好处，但也存在挑战。

依靠他人并将职责移交给他人，这是一项需要掌握的重要技能。这包括在架构师和团队成员之间建立信任。他们必须共享技术方向的所有权，并信任同事能够驱动系统的某些方面或组件。架构演化已经从单一的自上而下的指挥转变为团队联合参与贡献，所有人都可以有不同的观点。

信任是双向的，有时候需要对判断意见加以保留，允许新的想法和见解不断涌现。架构师需要成为建立团队心理安全防线的主要人物。

团队层面的失败不应被视为无能，而应被视为把事情做好的机会。更频繁的交付节奏有助于实现这种模式，因为他们可以快速采取行动。

架构师需要接受架构设计已经从一个单独的个人职责演变为一个共享的团队职责的事实。接受了这样的事实，他们就可以利用团队可以提供的一系列好处。对于那些戴惯了传统架构师帽子的人来说，为了成为团队成员的一部分而降低自己的身份是一种挣扎。不幸的是，我们已经亲眼看到，一些架构师对团队在创新阶段提出的想法、建议或改进表现出了挑战的姿态。

这就导致了僵持的局面，随着时间的推移，团队慢慢变得沉默，他们知道自己的建议没有被采纳，而架构师无法调和自己的局限性，也就无法规划前进的道路。这变成了一场对抗头衔、不愿放弃控制权、承认自己认知和能力不足的斗争。在我们的团队中，这种行为持续存在——成为所有变更的审查者，这破坏了更有能力的团队成员的成长，减缓了交付的速度。我们已经在多个行业的一些公司中看到了这种模式，而在以云为中心的环境中，技术栈的快速发展让这成为一个更大的挑战。

这意味着架构师不再是技术方面的唯一权威，因为改进的速度要求工具也不断改进，技术栈和方法的改变发生在每个开发者身上，更重要的是整个行业使之成为一场技术军备竞赛。如果架构师不愿意信任和授权他们周围的人，这将无意中导致支持、信任和实现技术栈改进失败。对于团队来说，这是一场注定失败的战斗，因为架构师觉得他们需要让自己的知识跟上变化的速度才能做出决策，然而，开发者每天都在积极地编码、调试、实验和学习，而且是在架构师无法达到的更深层次上。如果这种知识鸿沟未能被弥合，就会导致团队人员流失和丧失心理安全感。解决这个问题需要强有力的领导，更重要的是需要强有力的支持，帮助架构师克服他们正在经历的恐惧。架构师和整个团队都需要意识到，对团队来说最好的东西可能对个人并不是最好的，但通常会让个人获得最大的收益（在产品或服务的改进方面）。

为了确保团队能够达成共同理解而放慢发布节奏就是这方面的一个例子。之前的公司有一个主题专家（SME），他被授予了架构师的头衔，并几乎独自在设计方面推动功能的实现。他们的架构愿景是重构现有的面向组件的设计模式，使之成为一种更加模块化的基于插件的架构。这种想法源于他们在架构最佳实践方面的丰富经验，以及与客户的深度联系。他们的愿景被认为是一个强大的概念证明，用一封电子邮件解释了它们的基本原理，并建议在出现下一波客户流失之前进行重构。不可否认，愿景、激情和能力是我们（工程师 Chris，工程经理 Leigh）想要挖掘的东西，但团队内部弥漫着一股不安的气氛。这是一个架构上的转变，整个团队对新技术知之甚少。在这种情况下，SME 将在下一次出现客户流失大约三个月后领导另一个项目，并且已经按照合同期待交付，这意味着将会产生延迟成本。

我们决定支持 SME 的愿景，但要求他们更详细地阐述这么做的好处（更好的互操作性、更顺畅的客户集成、更容易的调试），然后与客户协商我们的发布承诺。这为淡化个人主义提供了一个安全的基础，更重要的是让整个团队适应了技术和变化。结果是我们得到了一个可持续的架构，但更重要的是，其他五个开发者培养了可持续的技能，他们将长期参与这款产品的演化。毫无疑问，这给销售团队和客户端带来了压力，但在接下来的 18 个月里，开发团队获得的回报是显而易见的，因为他们正在协商新的业务功能需求。这是一个皆大欢喜的结局，但更广泛的接受度源于工程领导为团队和产品的进化创造安全感而进行的诚实对话。

只具备技术敏锐性是不够的

掌握技术知识一直都是架构师所必备的，而商业头脑和对市场的了解无疑增加了其重要性。但是，架构师需要做出的最大改变是对软件生命周期中涉及的所有人员进行指导。这听起来可能过于简单化了，但在日益增长的快节奏软件开发行业中，对于架构师来说非常重要。他们倾听和消化业务视角、技术需求、来自开发人员的需求以及管理层快速交付的需求的能力变得至关重要。架构师需要能够使用“强大的开放性问题”作为激发更深层次思考和引出不同观点。

“为什么”这样的提问方式带有评判的味道，例如，“你为什么要采取这种方法”。如果将问题改为“是什么让你决定采用这种方法”，会促使被问者解释他们的想法，而不是为他们的决定辩护，因为当被问及“为什么”时，他们可能会认为自己的决定是不是不正确的。这种简单的改变，以及使用开放、好奇的语言，可以在整个团队中创造包容性，更重要的是，创造一种支持的氛围，而不是一种被认为是挑战的氛围。

架构师已经成为一个通晓多种语言的人，除了传统的技术语言，他们还使用了商业语言和从工程团队中获得最佳观点和想法所必需的语言。

实用技巧

经过总结，这里为架构师提供了 6 个实用的技巧，也为正在转变泥潭中挣扎的团队提供了 6 个实用技巧。

给架构师：

1. 成为帮助团队架构理解的导师，而不是障碍。公开主动地分享你的知识。

2. 为那些只有你自己感觉到但团队可能没有意识到的挑战寻求指导，来帮助你克服内心的挑战。不要独自承受，支持性的指导有助于你的角色演化。

3. 欢迎来自客户、团队和环境的挑战。这种反馈循环可能会让人感到筋疲力尽，但可以带来巨大的回报。

4. 用你的经验将对话引向你的专业知识告诉你会遇到的挑战。

5. 了解团队的动态、他们的优缺点、他们对工具的掌握，以及他们日复一日地构建应用程序的实际情况。帮助你在正确的时间组织你的输入，在哪里可以带来最大的价值。

6. 成为人际关系的建设者。培养你的软技能，建立起人际网络，从销售团队到产品负责人，从工程经理到技术中小企业。每天都要培养和维护这些关系。

给团队：

1. 为非领域专家总结使用工具的经验，带他们踏上理解之旅。

2. 利用架构师丰富的经验来洞察你可能有的想法、挑战或主意。他们现在是你团队的一员了。

3. 简单明了地表达你的想法、优点和缺点，准备好接受开放性和有挑战性的反馈，构建心理安全感。

4. 把头衔和自负留在门外，拥抱团队环境，向团队里的每一个人学习。在当今的软件设计当中，你对设计过程的影响是真实存在的。

5. 培养你的演讲、沟通和指导技能，并每天使用它们，在快节奏的团队中进行信息交流是至关重要的。

6. 尽你所能留住你的架构师。他们深厚的专业知识对团队的成长和壮大是无价的，不要让他们感到孤立，让他们觉得自己是团队的一部分，是未来解决方案的一部分。

结论

对于软件行业，更重要的是对于我们的用户来说，架构师的角色已经发生了根本性的变化。我们与用户互动的方式，我们构建、发布和支持软件的方式都发生了变化。这种变化对整个开发团队和他们之前的支持角色（如质量工程/质量保证）进行了赋能。现在，每个人都可以发声，关于系统如何随时间的推移而演化，他们有自己的意见和有效输入。与此相辅相成的是两个独立但相关的变化。首先是终端用户期望的变化，现在要求有更快速的反馈，通过不完美的服务来指导实现他们的需求以及何时实现。其次，出现了一套支持开发者日常工作的工具。这为以前只能由架构师解决的问题带来了解决方案，并允许开发者对性能、伸缩性和设计有更多的见解，并自然地渗透到团队中。架构师需要扮演的基本角色发生了变化。他们多年的经验和丰富的最佳实践现在需要重新渗透到团队的日常流程中。这是一个提升整个团队经验水平的机会，为我们如何构建软件创建了一个更多样化的视图。实现这种改变可能很困难，它需要管理层和团队的支持。它还要求这个角色愿意面对挑战，提供比以往任何时候都更多的价值，为了团队、产品和客户的改善而放弃对头衔的渴望。

原文链接：

https://www.infoq.com/articles/architecture-architecting-role/

相关阅读：

成为架构师需要点亮哪些知识树

硬核！阿里出品 2023 版 Java 架构师面试指南，涵盖 Java 所有核心技能

架构师是怎样炼成的

P5 直升 P7！“阿里爸爸”最新出品年薪 30W~120WJava 架构师学习路线