软件架构和自组织团队

原文链接：Software architects & autonomous teams

近年来，我一直在多个组织担任软件架构师，包括技术公司和高增长初创公司，既是个人贡献者，也是架构团队的经理。我所学到的是，软件架构师角色是最多样化的角色之一，也是最不了解的角色之一。让我们看看业界对软件架构师的看法。

软件架构师是一名软件专家，负责制定高级设计并指定技术标准，包括软件编码标准，工具和平台 - Wikipedia

最常见的理解是，架构师是一个接受并决定决策的人。在许多人的理解中，这不符合软件工程的许多其他现代原则，例如自主的跨职能团队，独立的微服务或团队的软件所有权（您构建它，运行它）。此外，还有平台小组的概念，它关注共同点和一套合理的共同标准。那么，为什么在现代工程组织中有人会做出决定而不是团队呢？这是一个很棒的问题。

软件架构师，永远不应该做出团队可以自己做出决定的决定

当团队无法自己做出最佳决策时，需要软件架构师。这不是技术专长。架构师不是房间里最聪明的工程师。虽然，软件架构师确实应该是一位资深且知识渊博的人，但非凡的技术专业知识，并不是拥有软件架构师的原因。主要原因是对大局和广泛关注的了解。以下是我在软件架构角色中看到的主要优点。

复制成功案例

如今，不同的团队通常不共享代码库。此外，微服务可以帮助团队更灵活，更独立，更快地行动。因此，团队对其他人的工作知之甚少。特别是在人们甚至在地理上分布的大公司。一个团队可能正在努力解决另一个团队是专家的问题。通过与多个团队合作，软件架构师可以帮助找到，并复制成功的决策。两个团队可能正在解决类似的问题，而不承认这一点。但与他们两个合作的人肯定会。我已经多次看到，团队计划开发另一个团队已经实现的一些功能：弹性解决方案，平台升级甚至是微服务。

确定战略改进

该系统与其最薄弱的环节一样强大。在每个组织中，都有一个不如其他组织强大的功能。通过识别和改善最薄弱的环节，我们大大改善了整个系统。它可能是系统弹性、域隔离、DevOps 成熟度或性能。每个团队都应该致力于技术卓越。但是，如果他们在不同的方向上工作，那么结果可能比整个组织优先考虑一个方向的影响要小。架构师可以识别并突出显示系统中最薄弱的环节，并帮助其他团队定义最显着的改进。

保持决策务实

好工程师喜欢他们的工作。此外，他们喜欢学习新东西。当你手上拿着一把锤子时，每个问题都可能看起来像一个钉子。架构师肯定应该为代码库做出贡献，但是他们不像开发人员那样花费太多时间编写代码。因此，架构师在技术决策上的情感依赖程度较低。此外，架构师对组织了如指掌，并且更关注预算影响，因为他们通常了解全球基础设施成本和全局。这有助于保持务实，而不是过度工程。切勿与切角混淆实用。务实主要是关于不做某事，而不是以不可维护的方式做某事。同时，应始终保持合理的实验和学习感。

专注于技术卓越

工程团队通常以领域和功能为导向。这意味着他们专注于提供客户价值。架构师通常不是功能团队的一部分。相反，他们可以专注于并促进技术卓越，并成为产品团队和交付压力的反制力量。这有助于在组织中找到技术卓越，交付和可扩展性之间的正确平衡。虽然遵循既定的敏捷流程是每个人的责任，但可能会有一个 Scrum Master 来管理这一切。同样，虽然确保长期系统可维护性是每个人的责任，但软件架构师可以帮助实现这一目标。

吸引，促进和发展人才

软件架构师角色吸引了强大的工程师，他们喜欢全系统关注并与其他人合作。软件架构师是一个允许应用软技能，而不是软件工程师角色的角色，但没有人们不喜欢的人员管理职责。许多软件架构师，不会以软件工程师或工程经理的身份交换此角色，因为他们非常擅长软件架构师的工作。这个角色将高级技术人才，吸引到可能没有申请的公司。此外，这是一个很好的选择，让您的经验丰富的工程师更加投入。扮演架构师的角色，确实是一个伟大的职业发展步骤。

如您所见，没有精确定义软件架构师职责使这个角色无法替代。软件架构师的职责可能由其他人承担。

没有架构师，公司很可能能够生存下去。但我相信，熟练的架构师可以为任何工程组织带来显着的价值。

软件架构师的关键价值在于，通过帮助其他工程师做出更好的决策，来节省时间和金钱。熟练的架构师可以成为神秘的10倍工程师，比他或她实际花费的开发天数节省 10 倍。当人们想知道为什么架构师决定决策时，软件架构师角色的主要缺点可能是：权威造成的挫败感。要成为一名技术娴熟且有价值的软件架构师，仅仅是一名技术强大的技术人员是不够的。还应该掌握沟通，演讲和领导技能，并实践以业务为导向的思维。