架构（Architecture）原意为建筑学设计和建筑物建造的艺术与科学。
软件架构（Software Architecture）是软件系统的高层描述，它给出了关于软件系统组织结构的一系列高级的，重要的抽象，包括：系统组成和结构性构件；组件构件之间的接口；组件相对系统其他部分的可视化行为；构件之间所采取的交互和写作关系。软件架构在RUP中的定义是指系统核心构件的组织或结构，这些核心构件通过接口与不断减少的构件与接口所组成的构件进行交互。
人们在软件过程中积累了丰富的架构只是，形成了特定的架构风格，这些架构风格为高层次的软件复用技术建立了坚实的基础。例如，C/S架构，管道/过滤器，分层架构，解释器架构，黑板架构等等，而各种分布式的组件技术如DCOM，EJB，Web-Services也都是和软件架构密切相关。
长期以来，人们一直在女里软件架构更加精准的形式化描述，力图用一种类似于某种编码语言的形式来描述软件架构，如Rapide，Weight，Aesop，Unicon，ACME等。XML描述与软件建模UML技术的发展为软件架构描述语言注入了新的发展思路，新一代的架构语言（如xArch，xADL等）充分应用利用这些新的描述手段的特点，同时，伴随着架构描述技术的进步，架构评估等研究也在不断的深入。
软件架构能够知道整个系统的设计和演进，它是软件需求分析的结果，同时是下一代进行软件设计的规格和蓝图。对于复杂软件系统而言，在架构阶段，系统的架构和规格的说明非常重要，而在软件设计阶段，算法和数据结构更重要。
软件架构师对系统的描述，借鉴了建筑工程设计的思想，通过各种视图从不同角度以规范、一致、易理解的“语言”表达系统的各种规格和行为。以某一特定角度看到的架构的规格和行为，主要是结构、核心构件和主要控制流等
软件架构是风险承担者进行交流的手段。所谓风险承担者是针对软件系统某方面或层次负责的人员，软件系统在某方面如果存在缺陷或问题，对此负责任或受影响的人员。风险承担着包括最终用户、系统设计师、程序员、经理、项目管理师等。
软件架构师可传递、可重用的模型
软件架构是软件工程早期设计决策的体现，而且在整个开发周期中不断演进，软件架构对软件质量（功能属性、非功能属性）都有重要影响。
“4+1”视图模型是最重要的软件架构模式，该模型由5各视图组成
PS：并不是所有的软件架构都需要“4+1”视图。无用的视图可以从架构描述中省略，例如，单机软件可以省略物理视图；如果仅有一个进程或程序可以省略过程视图。对于非常小型的系统甚至可能逻辑视图与开发视图非常相似，而不需要分开描述。
逻辑视图（Logical View）：描述了设计的对象模型，支持系统的功能需求
系统分解为一系列图的关键抽象，这些关键抽象（大多数）来自于需求分析中所提出的功能需求，以对象或类的形式来表示（采用抽象、封装和集成）。分解并不仅仅是为了功能的分析，而是用来识别遍布系统各个部分的通用机制和设计元素。系统的功能需求来自于最终用户，最终用户是逻辑视图对应的风险承担者。
进程视图（Process View）：描述了设计的并发和同步特征，支持系统的运行特性
利用进程视图可解决系统的并发性、分布性、系统完整性和容错性等。另外它还可以表达逻辑视图的主要抽象控制在哪个控制线程上被实际执行。风险承担着主要是系统集成人员，组件元素是任务
物理视图（Physical View）： 描述了软件到硬件的映射，反映了分布式特性，支持系统的拓扑、安装和通信需求
用来表达软件系统的各种元素（元素可以理解为组件或过程）被映射或部署至不同的网络计算机节点上。风险承担者是主要的系统实施工程师。
开发视图（Development View）：描述了在开发环境中的软件在静态组织结构，支持软件开发的内部需求
开发视图关注软件开发环境下实际模块的组织（程序库或子系统），它们可以由一位或多位开发者开发。子系统可以组织分层结构，每个层为上一层提供良好定义的接口。风险承担着主要是编程人员和软件项目管理人员
场景（Scenarios）：用来说明重要的系统活动，是其他4个视图在用例驱动下的综合
在某种意义上场景是最重要的需求抽象。该视图是其他视图的冗余（因此“+1”）， 但它起到了两个作用：首先场景可用来发现架构过程中的架构元素，其次场景可作为架构设计结束后的功能验证。她可作为架构圆形测试的出发点。风险承担着是最终用户和开发人员，组件元素是步骤
系统大多数关键功能是以场景（或用例）的形式被捕获。所谓关键是指系统最重要的功能（或系统存在的理由），或使用频率最高的功能，或其应用减轻了一些重要的技术风险。急于场景驱动的迭代式设计过程如下。
1.开始阶段。基于风险和重要性为某次迭代选择了一些场景。场景可能被归纳为对若干用户需求的抽象；对场景进行“描述”，易识别主要的抽象（类、机制、过程、子系统）；将所发现的架构元素分布到4各视图中；然后实施、测试、评估该架构，这个过程可能检测到一些缺点或现在的增强要求：捕获经验教训
2.循环阶段。重新评估风险，选择能减轻风险或提高结构覆盖的额外的少量的场景，然后试着在原先的架构中描述这些场景，发现额外的架构元素，或找出适应这些场景所需要的重要架构变更，更新4个重要制图；根据变更修订现有的场景；升级实现工具（架构原型）以支持新的、扩展了得场景集合。
3.测试。如果有可能（比如，在已有可重用的组件下快速实现系统），在实际的目标环境和负载下进行测试。
4.评审这5个视图，检测架构在简洁性，可重用行和通用性方面可能存在的潜在的问题。
5.更新设计准则和基本原理。
6.捕获经验教训
对于实际的系统，初始的就爱狗原理需要不断进行演化。一般的情况是在经过2次或3次的迭代，当找到了主要的抽象，子系统和过程都已经完成并且已经实现所有的接口，系统架构可认为趋向于稳定。