- 每个项目都应该对架构进行编档：错误。
要进行自驾游，自然需要在之前指定计划，可是，你会为每日早晚的上下班制定计划吗？模型确乎能够帮助你解决问题，降低风险；然而，针对不同问题，各有取舍之道，有的适用于模型，有的则可以直接解决。
- 架构文档应该综合全面：错误。
你或许会决定编写一个大而全的架构文档，不过，这仅限于某些场景——或许仅为了与人交流设计。大多数情况下，只需对与风险有关的部分进行建模，例如，对于具有可伸缩性风险的项目，就应该针对可伸缩性建立专门的模型。
- 设计总是先于编码：错误。
从某种意义上将，这是对的，倘若你没有想清楚到底该创建什么，代码并不会从你指尖自然流出。但坚信设计（就软件过程而言）一定优先于编码，则大谬不然。事实上，早期编码能够帮助你发现最难的问题。
因此，我们应该将这些似是而非的想法抛诸脑后。使用软件架构模型的真正原因是他们可以帮助我们像教练而非新手那样行事。若还未达到教练的水平，就应尽快提高。标准的架构模型代表了浓缩的知识主题，使我们能够有效地了解软件架构与设计。之后，你会发现你所有拥有的标准模型能够将你的思想从对问题的关注中解放出来，不用伟每个问题创造一个新模型。
- 概念模型加速学习
若想达到教练那样的高效，或许要等到老了，你才能积累足够的经验。所有软件开发者最终都能从架构中有所收获，即使这种知识的撷取是靠着一种间接的方式，这无非就是在构建系统时实践，实践，再实践。然而，这种方式问题多多。首先，并非只有年长的软件开发者才最有效率。其次这种方法需呀耗费数十年光阴。最后，每个人通过这种方式对架构的理解都是独一无二的，很难与其他人交流，反之亦然。
考虑另一种方式，这种方式可以让你站在别人的肩膀上看得更远。或许我们仍在期待软件工程中的艾萨克·牛顿，然而，在我们之前已有诸多构建了软件的人值得学习。他们不仅为我们提供了具体可见的编译器和数据库，还提供了一整套的编程思想理论。一部分抽象概念已经根植于编程语言中——函数、类、模块。其余内容则包括组件、端口和连接器。
一些人天生惊才绝艳，但对于我们常人而言却非如此，怎样站在前任肩膀上才更为有效？设想一下，除开17世纪顶尖的几位大师，你或许就是一位很棒的数学家。不错，数学大师需要天赋与苦练，但今日的你却可以从数个世纪精炼的知识总获益。在读完高中时，你就能解决几百年前需要大师才能解决的数学难题。由此上溯，17世纪的数学大师同样从之前发明的按位计数系统与零的概念中获益。因此，在考虑这两种方式时，需要明白二者其实是并行不悖的：学习前人精炼的架构知识，然后实践，实践，再实践。
- 概念模型能解放思维
一种精炼的理解方式可以采用概念模型的形式。教练的概念模型包括攻防战略、位置和战术。当观察到球员在球场上运动时，他会根据他的概念模型对观察到的内容进行分类。他看到的球员动作不仅仅是比赛的组成元素，还是战略的一部分。由于概念模型有限，新手观察到的内容则少之又少。
概念模型加速了诸多领域的进程。如果你曾经学习过物理，即使学过的大部分方程已经忘却，仍然能理解物体的作用力。物理课程旨在灌输概念模型。同样，倘若你曾经研究过设计模式，就不会由自主在程序中辨别遇到的模式。
概念模型因其能快速识别，并保持一致，从而节省时间，增强分析能力。Alfred Whitehead说道：“要大脑脱离所有不必要的工作，则一个好的概念就能免其役，专注于更为高深的问题，从而有效提升思维能力。”（Whitehead, 1911）这样同样使用与概念模型。
正如序言所述，Alan Kay看到“一个视图价值80点智商”，他认为我们之所以优于罗马时代的工程师，皆因我们有更佳的问题表现方式（Kay，1989）。
架构模型的基本要素与技术是共通的，即使不同的作者强调不同的方面。例如，软件工程研究所（SEI）强调质量属性建模技术（Bass，Clements & Kazman, 2003; Clements et al., 2010）。
统一建模语言（UML）阵营强调功能建模的技术（D,Souza & Wills, 1998；Cheesman & Daniels，2000）。