书本一开始指出了过去软件设计的模式：人们将技术需求文档扔进设计室，然后设计者就必须按照这样的需求文档给出令人满意的设计，即设计产生于需求，而系统又产生于设计。即便现代开发者认识到这种模式的单向直接性，提出了各种从设计者到分析员的反馈回路，实际上，这些方法还是基于设计是系统技术需求的产物这一前提。
构架作为设计过程的重要组成部分，亦是本书的主题。系统的构架是抽象的，它不考虑实现、算法和诸多数据如何进行表示的细节。对构架进行定义：程序或计算机系统的软件构架是该系统的一个结构，它由软件元素，元素的外部可见属性以及它们之间的关系组成。
软件构架是软件系统的核心，是软件工程师的智慧的结晶，是若干商业和技术决策的结果，是软件设计师根据软件系统的技术需求进行的设计，可以说设计产生于需求，而系统又产生于设计。但是我们可以从瓦萨战舰的失败案例中可以得出系统需求决定构架的观点是错误的，在形成软件构架的过程中还有其他的一些因素在起作用。软件构架是技术、商业和社会等的诸多因素作用的结果，而软件的存在反过来又会影响技术、商业和社会环境，从而影响到未来的构架。这就形成了软件构架的商业周期（ABC）——从环境到构架又返回到环境。
软件系统从设计到使用离不开人的影响，同样软件构架作为软件的一部分必然也受到系统的涉众的影响，一个得到各方认可的系统需要在性能、可靠性、可用性、平台兼容性、内存的利用、网络使用程度、安全性、可修改性、易用性、与其他系统的互操作性以及行为等方面要达到相应的要求。这些各个方面都会影响到接受此系统的某个涉众对该系统的评价。
软件构架是由若干组件及其之间的相互联系组成的。我们要分析出来软件的构架中的各个元素，这些元素的实质是什么，元素的实质是什么，元素之间的联系是什么，等等。首先，构架定义了软件元素；第二，明确指出系统可能而且确实由多个结构组成；第三，具有软件的每个计算系统都有一个软件构架；第四，元素的行为就是构架的内容。软件的构架的要点有结构、元素以及元素之间的关系。
软件构架不仅对企业非常重要，还对涉众之间的交流、早期设计决策和可传递的系统抽象非常重要。构架是涉众进行交流的手段，构架是早期设计决策的体现，构架决定了开发组织的组织结构，构架阻止或支持系统的质量属性的实现，通过研究构架来预测系统质量，构架使推理判断和控制更改更简单，构架有助于循序渐进的原型设计，可以通过构架进行更准确的成本和进度估计。
