演化架构与紧急设计: 研究架构和设计

“制定 IEEE 定义的 RUP 把架构定义为 ‘环境中最高级别的系统概念。软件系统的架构（在特定时间点上）是通过接口交互的重要组件的组织或结构，这些组件由越来越小的组件和接口组成。’”

如上所述，此定义在应用程序架构领域内非常恰当。虽然有些含糊，但是它捕捉到了架构职责的本质：最高级别的概念。

Fowler 随后引用了 Ralph Johnson 的话，Ralph Johnson 在此邮件列表的回复中对前面的定义提出了争议 ：

“更好的定义是：‘在大多数成功的软件项目中，从事该项目的专家开发人员对设计系统的设计存在共识。这种共识被称为 “架构”。这种共识包括如何将系统分为组件以及组件如何通过接口进行交互。’”

Johnson 提出了一个很好的观点，强调软件开发对通信的依赖要多于对技术的依赖，而该架构实际上代表关于系统的共识，而不是特定于语言、框架和其他短暂存在的技术。

在前述论文中，Fowler 自己提供了一个我最喜欢的架构定义：

“架构是重要的事物，无论它是什么。”

这个定义有一点含糊，但同时也是描述性的。关于架构和设计的许多争论都反复思考对于重点的误解。对于业务分析师和企业架构师来说，他们所认为的重要内容是有差别的。此定义很好地概况了这样一个概念：您必须在自己的环境中 定义术语，然后才可以尝试定义其他内容。

Fowler 的定义还强调了定义像架构一样微妙的内容的另一个重要方面。“重要内容” 不仅因个人和团体而异；这些差别实际上可能互相排斥。例如，实际上所有 SOA 都在灵活性与速度之间实现了一种平衡。现在使用的旧客户机/服务器系统的速度几乎肯定比取代它的基于 Web 的、portlet 式引擎、基于服务的版本快。除非新应用程序是由很糟的开发人员编写的，否则提供灵活性的附加层意味着用户的响应时间将增加，使响应变得更慢。架构师可能会对用户说，“顺便说一句，我们正在安装的新 SOA 内容将为我们提供更多好处，但是您的工作现在将花费更多时间，抱歉”。可能那就是架构师比开发人员工资高的原因。