理想的架构并不总是和理想的技术相关

根据公认的定义，软件架构师的角色是定义“系统的宏观方面，这个系统则基于来自其利益相关方的投入。”这意味着架构师不能只由技术因素来驱动。他们需要记住不同利益相关方的需求，这往往制约着对技术和架构设计做出选择。

Phillip Calçado 在他的 blogpost 上强调，除了系统用户和项目赞助商之外，软件开发团队也是一个重要的利益相关方，因为开发者会直接受到架构决策的影响。因此，尽管开发环境可能会限制架构师的选择，甚至会导致放弃对项目而言客观上最好的技术，但架构师还是应该考虑开发环境。

举例来说，Calçado 强调考虑团队的技术背景是极其重要的：

试想你加入一个长期从事 VB6 开发的团队去开发一个新的网站。尽管你知道 Ruby on Rails 是完成这项工作最好的工具，但是没有人有 Ruby on Rails 的相关经验。而这个网站又必须在短时间内交付，没有时间进行培训。你还会主张选择最好的技术吗？

另一个限制因素可能会来自团队的分布，无论是不是物理分布。在 Claçado 举的例子中，为证券交易所经纪人开发的系统有三个部分——数据采集、用户交互和事务，其中每一个部分由不同的团队处理。从技术上讲，即使将系统设计为单一模块可能是最好的选择，但是架构师将不得不设计三个黑盒模块，以便“团队在完全独立的组里面工作。”

总的来说，Calçado 强调道“收集那些受你的决定影响最大的小组的反馈、尊重他们的意见是很有必要的”。评论家 Alberto Brandolini 用“持续性架构（sustainable architecture）”的概念来支持同样的思路，持续性架构要求架构师保证他的“架构设计能由团队成员完成交付。”

将这种制约因素考虑在内对项目的成功是非常重要的。但是，这并不意味着因为团队在时间和技能可用度方面的约束和阻力，就一定要放弃那些真正为项目增值的技术。架构师的角色实际上是为引入变更创建策略，并将策略整合到设计当中：

[……] 架构师应该在系统的线路图中包含一个移植方案。[……] 举例来说，无论任何时候需要一段脚本或小程序，你就可以开始使用 Ruby[或任何需要的技术]、慢慢引入新的 Web 开发平台。最重要的是，你应该对系统以后应该是什么样子、以及怎么实现它有一个清楚的认识。

查看英文原文： Ideal Architecture is not always about Ideal Technology or Techniques