在已经了解了提出软件构架的时代背景和系统需求之后，首先我从构架商业周期和软件构架的概念和各种构架结构的运用部分深入了对软件构架的学习和认识。
系统的构架视图是抽象的，它不考虑实现、算法和数据表示的细节，集中研究“黑盒”元素的行为和交互。在设计具有所期望属性的系统时，开发软件架构是第一步。关于软件架构，已有的定义是：程序或计算机系统的软件构架是该系统的一个（或多个）结构，它由软件元素、元素的外部可见属性以及它们之间的关系组成。我认为构架受很多因素的影响，而且这些影响因素的实现又随着构架所处环境的不同而异。即使是相同的一个设计师设计某个系统，如果出现时间很紧迫或时间很宽松的情况，所做出的决策也会不同。在系统的每一次开发过程中，系统需求都能够明确反映出对系统的最终特性的某些期望。并不是系统需求中的所有内容都和系统最终具备的特性直接相关。开发过程或某个工具的选用可能会受到系统需求的制约，但对系统需求的表述仅仅是第一步，我们需要通过确定与构架有关的影响因素开始构建ABC。构架还是受系统涉众的影响的，这些涉众所关注的问题各不相同，但是都要求系统能够在他们所关注的方面提供保证或优化。一个得到认证的系统需要在各个方面达到相应的要求：性能、可靠性、可用性、平台兼容性、内存的利用、安全性以及与其他系统的互操作性以及行为。这些因素都是可以影响到该系统。构架同样受到开发组织、设计师的素质和经验、技术环境等因素的影响。另外，构架并不是注定就是好的或坏的，各种构架总是能够或多或少地满足某些系统的要求。
关于构架的概念方面，首先构架定义了软件元素。构架中包含了关于各元素应如何彼此相关的信息，即构架必须省略各元素中与其交互无关的信息，因此构架首先是除了不影响它们如何使用、其他元素如何使用以及与其他元素如何交互的细节的对系统的抽象。第二，定义中明确指出系统可能而且确实由多个结构组成。第三，定义意味着具有软件的每个计算系统都有一个软件架构。第四，只要某个元素的行为可以从其他元素的角度观察到或区别开，这个元素的行为就是构架的内容。最重要的是，这个定义并不涉及对构架优劣的评价。
我们众所周知的一个软件构架模式即分层架构，用这种方式推导出来的所有过程的完整集合构成一个子集。这种被允许使用的结构向我们展示了在运行时各模块的过程是如何相互交互来完成任务的。
这三个模块都是属于预想构架的部分，也就是准备的阶段。书中讨论了软件设计师开始创建或预想时所用到的各种知识和技能。我感到惊讶的是软件架构对从事软件开发的组织产生深远影响的方式，构架并不是要绑定到开发的软件系统上，而是构架和其开发组织要相互影响，相互帮助。