在本书的第一部分，我们学习了预想构架，为分析软件架构奠定了基础，陈述了当设计师开始构建系统时的各种影响因素，并指出了特定的质量属性要求通常产生于组织的业务目标。而本书的第二部分的重点就是设计师如何创建构架。
首先探讨的是可能适合构架的不同类型的质量属性。在构架商业周期部分，已经学习到商业目的决定了系统构架必须满足的一些质量属性。这些质量属性是高于对系统功能（即对系统能力、服务和行为）的基本要求的。因为功能性和质量属性之间是正交关系，（）功能性指系统能够完成所期望的工作的能力）所以功能选择将会规定安全性、性能、可用性或易用性的级别。而对于每个质量属性，都可以独立地选择所期望的级别，但是并不是说可以用任何功能实现任何质量属性的所有级别。因为处理复杂的图形图像或对巨大的数据库进行排序在本质上都是非常复杂的，所以不可能会有非常快速的性能。但却可以做到对所选择的任何功能，设计师都将确定每个质量属性的相对级别。在大量可能的结构中，可以通过使用任意一个结构来实现功能性。但是在实际上，如果功能性是系统的唯一需求的话，整个系统就可以是一个根本没有内部结构的单一模块。相反，系统被分解成多个模块，以使其变得可理解，并支持各种其他目的。所以，功能性在很大程度上是独立于结构的。当其他质量属性很重要时，软件构架会限制各结构的功能分配。
没有任何一个质量属性是完全依赖于设计的，它也不完全依赖于实现或部署。满意的结果就是使总体蓝图（构架）以及细节（实现）正确。易用性涉及构架和非构架两个方面。例如，非构架方面包括使用户界面清晰、易用。但是设计细节方面的问题，都是不需要再构架层次上解决的问题。然而，系统是否能为用户提供取消操作、撤销操作或重用以前的数据的能力则属于构架方面的问题。可修改性由划分功能的方式和模块中的编码技巧（非构架方面的）决定。系统性能则是一个既依赖于构架又不完全依赖于构架的质量属性。
所以，在构架设计过程中应考虑到这些质量属性，并在构架层次上进行相应的评估。而对我们所关心的许多质量属性的实现而言，构架有着非常重要的意义。构架提供了实现质量属性的基础，单也必须要关注细节实现，所以构架并不能独自实现质量属性。