Question

如果写软件是你日常工作的一部分，那么你的软件很可能不会孤立存在。在项目小团队里，我们会感到安全，特别是当每个人都相互认识、团队情绪高涨的时候。我们甚至建立起开发流程来帮助更好地沟通，设定优先级，最终交付更好的软件。然而，很多软件项目仍然由远离用户和运行环境的团队孤立地开发。

敏捷方法的成功告诉我们，要定期与最终用户或他们的代表沟通，才能确保我们构建的软件符合他们的需要。但其他的利益相关者怎么办？项目团队对软件应该做什么可能有清晰的愿景，但你经常会听到下面这样的说法，交付周期总是延迟。

“没人告诉我们你需要在这个服务器上创建一个生产数据库。”

“我们不能在那台服务器上升级到[Java 7|.NET 4]，除非X系统兼容。”

“我们没有多余的生成许可证。”

“对不起，这违反了我们的安全政策。”

“对不起，在把你的应用程序推送到生产环境之前，我们需要做一些操作验收测试。”

“我们到底应该怎样支持该应用程序？”

“我不在乎你是否有一个完全自动化的发布流程……我不会把你的配置文件所需的生产数据库凭据给你。”

“我们需要运行这个才能通过风险和合规团队。”

“绝对不能让你的系统运行在公有云上。”

软件开发不只是交付特性

软件的使用者只是利益相关者的一类。通常还有很多其他的类型，包括下面这些。

当前的开发团队：当前的团队需要了解架构，知道驱动力是什么，这样他们给出的解决方案才会与架构一致，并且“管用”。

未来的开发团队：任何未来的开发、维护团队都需要掌握相同的信息，这样他们才会明白解决方案如何运作，才能以一致的方式修改它。

其他团队：你的软件往往需要和环境中的其他系统集成，从定制的软件系统到厂商的现成产品，因此每个人对它如何工作达成共识是至关重要的。

数据库管理员：有些组织有单独的数据库团队，他们需要了解你的解决方案如何使用他们的数据库服务（比如，从设计和优化到容量规划和归档）。

执行/支持人员：业务人员通常需要了解如何运行和支持你的系统（比如，从配置和部署到监测和故障诊断）。

遵守、风险和审计：有些组织有必须遵守的严格规定，你的组织可能也需要证明你们确实遵守了这些规定。

安全团队：对安全也是如此。有些组织有专门的安全团队，系统要经过他们的评审才允许进入生产环境。

这些只是一部分可能和你的架构有利害关系的利益相关者，可能还有其他的，这取决于你的组织及其运作方式。如果你认为自己能闭门造车独立完成一个软件架构，你很可能错了。软件架构并非是孤立的，软件设计过程是一个交流的平台。五分钟的交流就有助于捕捉那些往往不起眼的架构驱动力，提高成功交付的机会。