首先我已经了解了一般意义上的架构，并分析了软件架构与其他领域的架构之间有何相似与差异。接下来我们将注意力转到“如何”设计软件架构。当架构师创建
软件系统的架构时，她应该关注什么？
软件架构师的首要关注点不是系统的功能。
这是正确的—软件架构师的首要关注点不是系统的功能。
例如，如果我们请你来设计一个“基于Web的应用”，你首先问我们页面布局和导航树，还是问下面这些问题：
• 谁提供应用主机托管？托管的环境有什么技术限制吗？
• 你想运行在Windows服务器上还是在LAMP栈上？
• 你想支持多少并发用户？
• 应用需要怎样的安全性？有需要保护的数据吗？应用将运行在公网上还是在私有的内部网上？
• 你能为这些答案排列优先级吗？例如，用户数是否比响应时间更重要？
根据我们对这些问题和一些其他问题的回答，你就可以开始画出系统架构的草图。我们还没有谈到应用的功能。
好吧，我们承认耍了点计谋，因为我们问的是“基于Web的应用”，这是一个大家熟悉的领域，所以你已经知道了哪些决定会对你的架构产生最大的影响。类似地，如果我们
问的是一个电信系统或一个航空电子控制系统，在这些领域有经验的架构师将考虑到一些功能需求。但是，你仍然可以不必过多担心功能就开始设计架构。你关注的是需要满
足的品质。
品质关注点指明了功能必须以何种方式交付，才能被系统的利益相关人所接受，系统的结果包含这些人的既定利益。利益相关人有一些关注点，架构师必须重视。稍后，我们
将讨论为了确保系统具有要求的品质，通常会提出的一些关注点。正如我们前面所说的，架构师的一项职责是确保系统设计能满足客户的需要，我们将利用品质关注点来帮助我
们理解这些需要。
这个例子突出了成功架构师的两项关键实践：让利益相关人参与以及同时关注功能和品质。作为一名架构师，你首先问我们想从系统中得到什么，有怎样的优先级。在实际项目中，你会找出其他的利益相关人。典型的利益相关人和他们的关注点包括：
• 投资人，他们想知道项目是否能够在给定的资源和进度约束下完成。
• 架构师、开发人员和测试人员，他们首先考虑的是最初的构建和以后的维护与演进。
• 项目经理，他们需要组织团队，制定迭代计划。
• 市场人员，他们想通过品质特点实现与竞争者的差异化。
• 用户，包括最终用户、系统管理员，以及安装、部署、准备、配置人员。
• 技术支持人员，他们关注帮助平台电话呼入的数目和复杂性。
每个系统都有自己的品质关注点。有些关注点可能定义得很好，如性能、安全、可伸缩性等。但是，另一些同样重要的关注点却可能没有详细规定，如可变性、可维护性和可用性等。利益相关人希望把功能放到软件上，而不是放到硬件上，这主要是为了很容易、很快速地修改，然后通常在品质关注方面又对可变性轻描淡写。这很奇怪，不是吗？哪些改变能够迅速、容易地实现，哪些改变需要花时间并且很难实现，架构决定将对此产生重要影响。所以，架构师难道不应该在理解功能需求的同时，也理解利益相关人在
“可变性”这样的品质方面的期望吗？
当架构师理解了利益相关人的品质关注点之后，接下来该做些什么？考虑折中。例如，对信息加密将加强安全性，但会损失性能。利用配置文件将增加可变性，但会降低可用性，除非我们能够验证配置是有效的。我们是否应该对这些文件使用标准的表示方式，如XML，还是使用自己发明的格式？创建系统的架构将涉及许多这样的艰难折中。
架构师的第一项任务，就是与利益相关人协作，理解这些品质关注点和约束，并为它们排列优先级。为什么不从功能需求开始？因为通常有许多种可能的系统分解方式。例如，从数据模型开始可能得到一种架构，而从业务处理模型开始则可能得到不同的架构。在极端的情况下，系统没有分解，被开发成单一的软件。这可能会满足所有的功能需求，但可能不会满足品质需求，如可变性、可维护性、可伸缩性等。架构师通常必须进行架构层面的系统重构，例如为了满足伸缩性或性能的要求，将单机部署迁移到分布式部署，从单线程转向多线程，或者将硬编码的参数移到外部配置文件中，因为原来从不改变的参数现在需要修改了。
尽管有许多架构都能满足功能需求，其中却只有一少部分能够满足品质需求。让我们回到Web应用的例子。请考虑提供Web页面的诸多方式—Apache和静态页面、CGI、
Servlet、JSP、JSF、php、Ruby on Rails、ASP.net等。选择其中的一种技术是一种架构决定，它将对你满足特定品质需求的能力产生重要影响。例如，像Ruby on Rails这样的方式可能提供快速推向市场的好处，但可能更难维护，因为Ruby语言和Rails框架都在不断地快速发展。也许我们的应用是基于Web的电话，我们需要让电话“响铃”。如
果你为了满足性能的要求，需要从服务器向Web页面发出真正异步的事件，那么基于Servlet的架构可能更容易测试和修改。
在真实的项目中，满足利益相关人的关注点需要做出更多的决定，而不仅是选择一个Web框架。你是否真的需要一个“架构”，并需要一名“架构师”来做出这些决定？谁
将做出这些决定？是编程人员吗？他们可能会做出许多无意识的、隐含的决定。还是由架构师来做出这些决定？他们全面了解整个系统、利益相关人和系统的演进，然后做出
明确的决定。不论哪种方式，你会有一个架构。它是否应该明确地形成并记入文档？或者它应该是隐式的，需要通过阅读代码才能发现？
当然，这种选择通常不是这么死板。但是，随着系统的规模、复杂度和开发人员数目的增长，这些早期决定以及它们的记录方式将产生越来越大的影响。
我们希望你现在已经理解，如果你的系统要满足其品质要求，架构决定是很重要的，你需要注意架构，有意识地做出这些决定，而不只是“让架构自动出现”。
如果系统非常大，情况会怎样？我们之所以运用“分而治之”这样的架构原则，一个原因就是为了降低复杂性，让工作能够并发进行。这让我们能够创建越来越大的系统。架
构本身是否能够分解为多个部分，这些部分是否能由不同的人并行开发？考虑到计算机的架构，Gerrit Blaauw和Fred Brooks断定：
⋯⋯如果，在采取了所有让任务能够由单人处理的方法之后，架构任务仍然巨大而复杂，不能由一人来完成，那么产品肯定是太复杂了，以致不实用且不应
构建。换言之，单个用户必须能够理解计算机的架构。如果计划的架构不能由一个人设计，那它也不能被一个人理解。（1997）
你是否需要理解架构的所有方面，才能使用它？架构会分离关注点，所以在大多数情况下，利用架构来构建或维护系统的开发人员或测试人员，不需要一下面对全部的架构，而是只要面对必要的部分，就能完成指定的功能。这让我们能够创建超出个人可以理解的、更大的系统。但是，在我们完全忽略IBM System/360（最长寿的计算机架构之一）创造者的建议之前，让我们先来看看他们为什么这样说。
Fred Brooks说，概念完整性是架构最重要的特征：“最好是让系统⋯⋯反映一组设计思想，而不是让系统包含许多好的思想，而这些思想却彼此独立而不协调”（1995）。正是这种概念完整性，让开发者在知道了系统的一部分之后，能够迅速理解系统的另一部分。概念完整性来自于处理问题的一致性，如分解的判据、设计模式的应用和数据模式。这让开发者运用在系统中的一部分工作的经验，来开发和维护系统的其他部分。同样的规则应用于整个系统各处。当我们转向“众系统之系统”时，在集成了这些系统的架构中
也必须保持概念完整性。例如，可以选择发布/订阅消息总线这样的架构风格，然后将这种风格统一地应用于“众系统之系统”的系统集成中。
架构团队的挑战在于，在创建架构时保持同一种思考方式和同一种哲学。让团队保持尽可能小，让他们在充分沟通、高度协作的环境工作，让一两个“首席架构师”担任仁慈
的独裁者，最终做出所有决定。这种架构模式常见于成功的团队，不论是公司开发还是开源开发，由此而得到的概念完整性是美丽架构的一种特性。
好的架构师通常来自于更好的架构师提供的现场指导（Waldo 2006）。原因之一可能是有一些关注点几乎在所有项目中都会出现。我们已经提到过一些，但这里有一份更完整的清单。每个关注点都以问题的方式表述，架构师在项目过程中可能需要考虑它。当然，具体系统会有其他关键的关注点。
功能性（Functionality）
产品向它的用户提供哪些功能？
可变性（Changeability）
软件将来可能需要哪些改变？哪些改变不太可能发生，不需要特别容易进行这些改变？
性能（Performance）
产品将达到怎样的性能？
容量（Capacity）
多少用户将并发使用该系统？该系统将为用户保存多少数据？
生态系统（Ecosystem）
在部署的生态环境中，该系统将与其他系统进行哪些交互？
模块化（Modularity）
如何将编写软件的任务分解为工作指派（模块），特别是这些模块可以独立地开发，并能够准确而容易地满足彼此的需要？
可构建性（Buildability）
如何将软件构建为一组组件，并能够独立实现和验证这些组件？哪些组件应该复用其他的产品，哪些应该从外部供应商处获得？
产品化（Producibility）
如果产品将以几种变体的形式存在，如何开发一个产品线，并利用这些变体的共性？产品线中的产品以怎样的步骤开发（Weiss和Lai 1999）？在创建一条软件产品
线时，要进行哪些投资？开发产品线中不同变体的选择，预期会得到怎样的回报？特别是，是否可能先开发最小的有用产品，然后再添加（扩展）组件，在不改变以前编写的代码的情况下，开发产品线的其他成员？
安全性（Security）
产品是否需要用户认证，或者必须限制对数据的访问？数据的安全性如何得到保证？如何抵挡“拒绝服务”攻击或其他攻击？
最后，一个好的架构师会认识到，架构会影响组织机构。Conway指出，系统的结构会反映构建它的组织机构的结构（1968）。架构师可能会认识到，