何谓软件架构？
书上是这么定义的：软件架构是系统的抽象，定义了元素以及它们之间的交互，忽略了纯粹属于局部的信息，元素的细节不属于架构。架构还关注元素的外部可见属性，有元素提供的服务，元素需要的服务，以及元素具备的性能特性、容错特性、对共享资源的使用等。
架构本身是系统的抽象，其定义同样比较抽象，不便于理解，甚至至今对于架构都没有一个精确的定义。因此，经常有人将架构与框架混为一谈。这里通过解释两者的区别，来进一步了解架构的定义。简单点讲，框架是软件，而架构不是软件，如下图。
框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”
软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。或许，人们常把架构和框架混为一谈的原因就在于此吧！我们不能指着某些代码，说这就是软件架构，因为软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。
根据关注角度的不同，架构可分为逻辑架构、物理架构、运行架构、开发架构和数据架构。分别介绍如下：
逻辑架构，描述职责的划分，以及职责间的协作关系；
物理架构，描述物理节点，及节点间的拓扑关系；
运行架构，描述控制流及控制流组织；
开发架构，描述程序单元和程序单元间的组织；
数据架构，描述持久数据单元及数据的储存格式；
按照ADMEMS软件架构设计体系，软件架构分为三个阶段，分别为：Pre-Architecture（预架构）阶段、Conceptual Architecture（概念架构）阶段、Refined Architecture（细化架构）阶段。
个人认为，所谓架构，应该是根据已知的需求，提供一套兼顾软件成本、质量及扩展维护等各方面特性的解决方案。