架构师十年总结：成为架构师，你必须具备这五点能力

在过去的 20 年里，作为一名软件工程师和软件架构师，我与不同领域和不同学科的软件工程师聊过很多次。他们中有一些人是有着 8 到 10 年经验的工程师，有许多人还在职业生涯早期，有着 3 到 5 年的经验。其中一些人是我的同事。有些人是求职者。聊到后，他们几乎都会问到同样一个问题：

“我想成为一名解决方案架构师。了解更多架构相关内容的资源有哪些？“——很多软件工程师都会问的一个问题。他们问错了问题。如果你读下去，就会知道为什么我这么说。此外，撰写本文时我的公司正在招聘首席软件架构师，所以我正好解释一下什么是软件架构师以及如何成为一名软件架构师。

首先什么是软件架构？提到软件架构师这个头衔，就经常听到拿建筑的架构与之作比。建筑架构师设计建筑的蓝图。工程师们将其实体按照该蓝图建造起来。我认为从很多方面来看，这都是一个糟糕的类比。

建筑的类比使人们过于关注系统的静态面。在这方面，城市建设是一个更好的类比，因为它既包括道路、建筑和桥梁等静态元素，也包括交通流量和城市居民等动态元素。城市架构师提出城市设计，制定计划来安排如何建设城市以及如何将所有东西组合在一起。后但并非不重要的是，城市架构师有一个城市将如何发展的愿景。但是软件架构还不仅如此。有时软件架构师需要放大或缩小”城市“，以确保计划可行。架构师可能不会太关心建筑的室内设计，而把重点放在决定在哪里放置红绿灯上。架构师需要广泛且深厚的技术知识，才能构建像城市一样复杂的软件。架构师还需要在不涉及所有技术细节的情况下向业务涉众传递一致的消息。

建筑架构的类比意味着架构师是团队中的人，他做出所有关键的决定，预先创建设计规范，然后在实现过程中执行设计。起初，在很多人看来，成为那个有经验的人，达到技术级别的顶端，是一件很酷的事情。让整个团队都听你的，服从你的命令和决定，可能会让你感觉好极了。但是，你再好好想想，这给了架构师一定要做出正确决策的巨大压力，而这在项目的早期阶段通常是不太可能的。在敏捷团队中，这意味着开发团队不是自组织的，架构师成了团队变得敏捷的障碍。架构师剥夺了团队的所有自主权。谁愿意在如此高的压力下担任这样的职位？

软件架构可以被视为位于业务目标和支持业务以满足这些目标的软件系统之间的中心。

软件架构的角色

软件架构用于满足业务目标。它是基于要实现的业务目标而设计的。然后，按照设计实现软件系统，使其遵从设计。这应该是一个迭代过程。正如我前面提到的，在项目的早期阶段通常不可能做出正确的决定。好的决定是你仍然不必决定的决定。架构师将创建刚好能够满足业务需求的设计。这就关闭了反馈循环，就像你在敏捷和 DevOps 实践中看到的一样。这里的想法是，随着世界的变化，业务需求也会变化，软件架构应该随需求演变以支持业务接受变更。

软件架构是一个非常具有挑战性的话题，您必须设计一个同时满足所有业务需求和所有质量属性的系统。这几乎不可能一个人完成，通常是架构师和领域专家团队合作的结果。

通用软件架构质量属性

软件架构不仅仅是图、框和线。让我们以其中一项质量属性安全性为例。只看高层次的设计图，只看一些线线连着框框，可能无法看到任何安全问题。我甚至不知道这个设计是否真的能行。保护系统安全的是代码。因此，架构师编写代码并与开发团队密切合作是很重要的。另外，架构师要能够阅读代码并经常与开发团队交流。这就是当软件架构师放大或缩小设计时所发生的事情，就像我在城市设计类比中所提到的。如果架构师不与开发团队沟通，也不编码，他们就会脱离现实，所设计的架构就不实用。

过去，软件架构师是在纸上勾画逻辑流程规范，然后交给另一个团队 (称为打孔者) 来生产穿孔卡片并使软件工作的团队。

图片来源:  Wikimedia Commons

随着技术的进步，我们不再需要这样的过程，软件架构师的定义也变得不那么明确了。在现代 IT 中，软件架构师不是一个头衔或级别，因为他们不会在一夜之间给你高的软件开发权。在 Scrum 团队中，这个角色和其他任何角色一样。我认为软件架构师是有趣的角色，与医生、土木工程师、心理学家、社会工作者或会计师不同，您不能通过单一的培训课程获得软件架构师资格。事实上，世界上几乎没有一所大学提供软件架构学位。软件架构师对几乎所有事情都需要广泛且深入的了解，以便完成前一节中提到的目标。那么软件架构师使用这些技能和知识做什么呢？

图片来源：https://dilbert.com/strip/2008-03-04

正如我前面所说的，软件架构位于业务目标和满足它们的软件系统之间。软件架构师将业务与使用不同语言、以不同方式思考并具有不同关注点的开发团队联系起来。具有多层管理和开发团队的竖井只会使交流变得更糟。拥有专业知识并掌握相关信息的软件工程师并不是决策者，而管理团队中的那些人则是不掌握相关信息的决策者，这种情况并不少见。为了解决相互冲突的权衡并推动组织前进，软件架构师在公司的阶梯上爬上爬下，在技术细节上扮演着至关重要的角色。

一名宇航员——由 NASA 拍摄

相比之下，如果大家在一些组织中冠有软件架构师的头衔，但他们只停留在企业阶梯的顶端，或者他们只关注图片时，他们就与现实脱钩了。正如 Joel Spolsky 所说，这些人被称为架构宇航员，他们没有贡献，也没有生产力。许多大的组织似乎都能负担得起很多这种人！

对于软件架构师这个角色来说，对每一件事情都有经验至关重要。它让你知道什么时候该充当公司的桥梁，当放大或缩小架构图时该关注什么。当在不同的上下文中应用特定的架构设计时，您还将观察模式。在十多家公司工作过之后，我终进入了 Zuhlke 咨询公司，在那里我不再需要换工作来获得不同的经验了。我的项目几乎涵盖了无数种行业，包括金融科技、保险科技、物流、制造业、品时尚、初创企业，这份列表还在不断增长。

对某些业务领域的深入了解对于软件架构师的成功是至关重要的，因为您不仅要知道它是什么，还要知道它将是什么，或者可能是什么，以及为什么。客户经常找到软件架构师，要求向他们展示行业正在做什么以及如何做。领域知识还可以帮助软件架构师说一种商业通用的语言，这反过来帮助他们成为连接管理和开发团队桥梁。

软件架构师也是一个伟大的沟通者。许多的软件工程师发现很难晋升为软件架构师，因为他们没有展示自己的技能，如倾听、口头和书面沟通、推进、冲突管理、演示、谈判和说服。这份工作所需技能的具体类型取决于你工作的特定公司环境。

在我的公司，我有机会在安全的环境中练习这些技能，比如我们称之为“祖尔克日”和“祖尔克营”的环境。我的雇主也在这些方面为我提供了正式的培训。后，公司的建设性反馈文化支撑着许多人成长了起来。

单独任何一张大学文凭都无法证明你是一个软件架构师。你需要学习软件工程的所有领域，包括软件设计、编码、质量保证、DevOps、性能分析、软件安全、项目管理、软件支持等等。这些技能对于创建满足软件架构“能力”的解决方案至关重要。当与开发团队中的专家交流时，软件架构师能够更好地理解相关信息，因为他们已经具备了这些领域的实践经验。

作为一名开发团队成员，我可以胜任各个领域的日常工作，包括后端、前端和 DevOps。这让我能够以人称视角看到幕后发生了什么，并让我能够与团队保持较近的距离。

业务过程描述了一个组织的业务操作，并定义了业务需求，而这些业务需求通常没有清晰地表述为软件项目需求。软件架构师应该知道，或者至少应该知道向谁询问业务流程的相关信息。一个向行业组织交付解决方案的软件架构师，需要干上几年时间才能成为领域专家，这种情况并不少见。

理解技术过程、软件开发生命周期和佳实践的重要性与了解业务过程一样重要。这是因为软件架构师通常在确保业务和开发过程之间的一致性方面扮演着关键的角色，如此，才能做到迭代交付，才能有现实的项目计划。

现在，您应该非常好奇软件架构师如何掌握所有这些知识和技能了吧。好吧，我告诉你，他们并没有掌握！一个人是不可能掌握所有这些的。伟大的产品需要一个有能力的专家团队来开发。成功的软件架构师通常是有效的，他们的团队中拥有伟大的成员，并使成员们成长得更加伟大，而不仅仅是个体。

软件架构师通常被视为团队的代表。他们在领导、管理业务和技术方面投入了大量的精力。虽然人们常常认为只在站在前面指挥，但有时在一个项目中需要五种领导风格。我们公司提供的领导力培训就是这么教的。

你准备好成为一名软件架构师来寻求职业生涯的进一步发展了吗？现在是行动的佳时机！

作者介绍：

Alan Tai 是 Zuhlke 的首席软件架构师，Zuhlke 是一家优质的全球咨询公司，为我们的业务伙伴提供高质量的解决方案。

原文链接：

https://ayltai.medium.com/what-it-takes-to-become-a-software-architect-fa7788962c8c

译者介绍：

冬雨，小小技术宅一枚，现从事研发过程改进及质量改进方面的工作，关注研发、测试、软件工程、敏捷、DevOps、云计算、人工智能等各个领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。