一些人对在敏捷环境中现代软件开发方法中软件架构师的适用性产生了质疑。技术领导者需要赋予架构师架构可观测性的能力。
翻译自 What Is the Role of Software Architect in an Agile World? 。
在当今快节奏的商业环境中，围绕敏捷软件开发生命周期（SDLC）中软件架构师的角色存在着持续的争论。虽然软件对组织在竞争力和业务运营方面具有重要意义，但潜在的软件开发架构决策变得越来越关键。它们影响着现代化、技术债务、工程指标、客户满意度和成本等各个方面。
然而，传统的架构实践以及架构师本身的角色面临怀疑。一些人对架构师在现代软件开发方法（尤其是敏捷环境）中的适用性提出了质疑。
敏捷宣言本身强调最佳架构、需求和设计是由自组织团队形成的，这使得架构师在这个过程中找到自己的位置变得困难。随着每个迭代中的架构漂移和技术债务的累积，架构师正在寻找方法来积极参与更快、更有机的敏捷过程。
显然，架构团队和每天与应用程序互动的人之间存在差距。即使在微服务架构的背景下，不遵循最佳实践可能导致混乱的局面，可能迫使回到单体结构，就像我们在亚马逊网络服务中所见到的那样。
我认为，有必要将架构转向前端，并为架构师提供更好的工具，以主动识别架构漂移和技术债务的累积，并将架构考虑融入特性待办列表。
由于缺乏了解架构或识别架构漂移的工具，架构师的角色成为广泛讨论的话题。每个开发人员都应该负责架构吗？大多数公司都有一个制定标准、目标和计划的架构师。然而，在高度复杂且非常详细的软件项目中，这个高层次的角色往往会与日常开发过程脱节。现代的开发组织引入了各种新角色和工具，导致对谁拥有架构、谁拥有技术债务以及有效解决问题所需的最低工具要求产生困惑。尽管重要性，技术债务的所有权仍未明确，导致停滞不前的局面。因此，缺乏所有权以及缺乏正确的工具和对架构的洞察，架构师最终制定的应用程序计划可能与实际结果大相径庭。开发人员偏离计划，技术架构方面的问题得不到优先考虑，从而导致一些人认为软件架构师的角色不再必要。于是，技术债务开始积累。
考虑用于评估软件质量和性能的度量标准。安全性、代码覆盖率和圈复杂度是其中的一些因素。测试显然是一种必要的实践，而代码覆盖率测量有助于确定测试过程的质量。但即使在这里，架构也是一个不同的挑战，并且确定特定软件架构的适当测量技术和指标仍然是一个挑战。在我看来，架构师的角色已经发展到一个缺乏必要工具、洞察力和指标的程度，无法真正在解决技术债务方面产生积极影响，而技术领导者在赋予架构师这方面的支持也不足。
技术领导者需要赋予架构师架构可观测性。什么是架构可观测性？它是一种软件工程的最佳实践，为架构师提供详细的可见性和上下文，了解现有应用程序的架构，对应用程序的架构进行概要和基线分析，收集可观测的动态操作和静态数据，以主动检测漂移、识别重要的架构事件并修复架构异常。
架构师必须利用架构可观测性来了解代码在应用程序中的运行方式，并定义软件架构（不仅仅是代码）必须满足的质量指标。这种方法将为架构师提供适当的工具、洞察力和指标，以有效地履行他们的职责并做出明智的决策。也许在这种情况下，软件架构师在现代敏捷世界中的角色将不再成为持续争论的话题。