软件架构
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构會包括軟體組件、組件之間的關係，組件特性以及組件間關係的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，開發系統以及計劃進行的基础，可以列出開發團隊需要完成的任務。
软件架构是在軟體的基礎架構上進行決策，一但決定後，再修改的代價很大。软件架构中的決策包括在軟體設計時的一些特殊結構性選項，例如要控制太空船登陸艇的系統需要快速而且可靠,因此需要選擇適合实时计算的語言，而且為了滿足可靠度的需求，程式需要有數個冗餘的複本，各複本運作在不同的硬體上，以便比對各程式的結果。
將軟體架構文档化有助於和之間的溝通，在高層設計時就可以提早進行決策，也可以在各專案之間復用設計組件。
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，或者系统架构师陈述软件架构以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
软件架构师与客户商谈概念上的事情，与经理商谈广泛的设计问题，与软件工程师商谈创新的结构特性，与程序员商谈实现技巧，外观和风格。
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。
软件架构的範圍有許多不同的定義：
在軟體架構、設計、需求工程之間，沒有具體明顯的分界。這些是「一連串意圖的結合」，從高階的設計意向到低階的設計細節。
软件架构有以下這些特點：
眾多的關係人：软件架构需配合許多的關係人（stakeholder），例如業務經理、部門主管、使用者及運營商。每一個關係人都有各自關注的內容。在設計系統中，如何平衡這些關注，並展示他們所關注的訊息，也是一個重點。因此，軟體架構中就包括了處理眾多的關注及關係人，因此在本質上就是跨領域的。
关注点分离：架構師降低複雜度的可行方式，就是將驅動設計的各关注分開。架構文件會呈現相關者關注的所有內容，會以建構的方式表示，另外也會用各相關者關注的角度來描述軟體的架構。這種分開來的說明稱為架構視圖，例如4+1架構視圖。
品質導向：傳統的软件设计方法（例如杰克逊结构化编程）是依需求的機能以及資料在系統中流動的方式所驅動，不過目前的見解是軟體系統的架構和其品質屬性（例如故障容許度、向下兼容、、可靠度、、可用性、資料安全等）的關係更高。相關者的關注可以轉換為有關這些品質屬性上的需求，一般會稱為非功能性需求、額外功能性需求、行為需求或品質屬性需求。
重覆的風格：軟體架構和建築類似，在處理一些重覆出現的事務時會發展出標準化的作法。標準化作法有許多不同的名稱，其中也有不同程度的抽象化。常見的術語有架構風格 、tactic、及架构模式。
概念完整性：這是佛瑞德·布魯克斯在寫作《人月神話》一書時提及：軟體系統的架構是有關軟體系統該作什麼以及不該作什麼的實體觀點。這些觀點應和軟體的實現分開。架構師的角色是「觀點的看守者」，確認系統中增加的部份是符合此架構，因此可以保有概念完整性。
認知制約：程式設計師马尔文·康威在1967年論文發表了康威定律，其中提到一個組織開發的軟體，其架構會反映其組織架構。佛瑞德·布魯克斯在寫作《人月神話》一書時，就在書上時提到此例子，命名為「康威定律」。
软件架构是複雜系統「在智力上能理解」（intellectually graspable）的抽象，此抽象有以下的好處：
早在1960年代，诸如艾茲格·迪傑斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在和Microsoft内部的相关活动，软件架构这个概念开始越来越流行起来。
卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做"Software Architecture perspective on an emerging discipline"的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。
開發軟體架構的過程會和許多的活動有關。軟體架構師一般會和專案經理一起工作，和專案關係人討論、設計軟體架構、評估設計、和設計師及專案關係人溝通、撰寫架構設計的文件等在軟體架構設計中，有四個核心活動，分別是架構分析、架構合成、架構評估和架構演進。這些核心的架構活動會反覆的出現，也會出現在軟體開發生命週期的初始階段，及後續階段。
架構分析（Architectural analysis）是瞭解計劃的系統要運作的環境，以及決定系統的需求。分析活動的輸入或是需求可以來自專案關係人，也可能會包括以下項目：分析活動的產出是在軟體系統架構上有相關影響的需求，這些稱為是（architecturally significant requirements）。
架構合成（Architectural synthesis）或架構設計是指產生架構的過程。針對在架構分析時生的架構重要需求、設計的目前狀態、及評估活動的結構，可以進行設計，也可以針對設計進行改善。
架構評估（Architecture evaluation）是在分析過程中確認現有設計整體（或其部份）滿足各需求程度的程序。架構評估的時機可以在架構設計師進行設計決策中的時候，部份設計已完成時，細節設計完成後，或是系統已架設完成之後。有些分析軟體架構的技術，例如（ATAM）及Tiny Architectural Review Approach（TARA）等。有些可以比較這些技術的框架，例如SARA Report及《架構評審：實務及經驗》（Architecture Reviews: Practice and Experience）。
架構演進（Architecture evolution）是指維護已有的軟體架構並且調整，以符合環境及需求變化的過程。軟體架構提供軟體系統的基本架構，其演進及維護必然會影響軟體基礎架構。因此，架構演進一方面關注的是加入新的功能，另一方面也要維護原有的機能以及系統行為。
架構設計需要關鍵性的支持活動。這些支持活動也和核心的軟體架構過程中一起出現。這些支持活動可以協助軟體架構師進行分析、合成、評估及演進。例如軟體架構師需要在分析階段搜集資訊、進行決策，並且撰寫文件。這些活動包括知識管理、交流、設計推理、決策以及撰寫文件。軟體架構描述包括建模以及實現其架構的原理以及實務，其中會使用架构描述语言、架構視圖及架構框架等。
架构描述语言（ADL）用于描述软件的体系架构。现在已有多种架构描述语言，如Wright（由卡内基梅隆大学开发），Acme（由卡内基梅隆大学开发），C2（由UCI开发），Darwin（由伦敦帝国学院开发）。ADL的基本构成包括组件、连接器和配置。
軟體架構的敘述常會整理成視圖模型（view model），如同在建筑学中的不同种类的蓝图。每一種視圖會著重一些系統的事務，依循其約定的觀點（viewpoint），觀點是指為了要以特定關係人（stakeholder）及其關注點的角度說明系統架構，因此針對標示、模型、分析技巧的說明方式的規範（）。觀點不但指定框架的關注點，也指定說明的方式、使用的模型、使用的習慣，以及可以和其他視圖維持一致性的規則。
以下是一些可能的视图：
目前已開發了许多描述软件架构的语言，但是大家對於要用何種的符号集和视图系统，还没有达成共识。一些人相信UML将建立软件架构视图的标准。
架構框架（architecture framework）可以定義為「特定應用或/及特定群體在敘述架構時的習慣，原則以及實務」（）。框架一般會用一個或多個視圖或ADL來表示。架構框架的例子有：、开放组体系结构框架、Kruchten的4+1架構視圖、等。
架构模式是針對在特定情境下軟體架構上的常見問題，通用性，可複用的解決方案。 架构模式也像设计模式一樣有對應的文件。
架构模式的概念類似傳統的建築，軟體架构風格是有關架構的特定作法，有各自的特徵。
有許多知名的架构模式及風格，舉例如下：
有些人將架构模式和架构風格視為是同一件事，有時則是將架构風格視為是架构模式的實例，不過將架构模式和架构風格都是架構師常用的語言，在描述系統類型時「提供共用的語言」 或「字彙」。
也有研究者認為軟體架構造成太多的，尤其敏捷開發的提倡者更是如此認為。有許多的方式設計要在早期設計以及敏捷之間作取捨，其中包括敏捷式的（DSDM），其中強制一個「基礎」階段，只要列出「夠用的」架構基礎即可。《IEEE软件》曾特別探討敏捷和軟體架構之間的關係。
軟體架構腐蝕（或退化）是指軟體系統設計的架構以及實現時實際架構之間的落差。軟體架構腐蝕會出現在實現時的決策沒有完成達到原先設計的架構，或是有一些違反架構原則或是限制的情形。這種設計架構和實際架構之間的落差有時也會以技术负债的方式表示。
例如，考慮嚴格抽象化的系統，每一層都只能用往下一層所提供的服務。若程式碼元件無法遵守此一限制，就違反了架構。若此問題沒有修正，此架構違反會讓系統架構變成無法分層的架構，在程式理解性、可維護性和發展性都有不良影響。
針對軟體架構腐蝕，有提出有許多的處理方法：  「這些方法，包括工具、技術及流程，主要可以分為三大類，設法減小、預防及修復架構腐蝕。在這三大類以下，各方法都可以再細分，反映為了解決侵蝕而採取的高階策略。例如流程導向架構一致性、架構演進管理、架構設計強化、架構到實現的連結、包括恢復、發現以及調節的自適應及架構恢復技術。」
針對偵測架構違反，有二種主流的技術：反射模型（Reflexion model）和領域特定語言（domain-specific languages）。反射模型技術會比較系統架構師提供的高階模型，和程式碼的實現特定領域的語言。領域特定語言則是專注在標示及檢查架構上的限制條件。
軟體架構恢復（重建，或逆向工程）包括從已有資訊（包括程式實現以及已有文件）中找到軟體架構的方式以及技巧。若是遇到軟體的文件過舊、架構腐蝕（軟體的架構和後來的實現及維護不一致），又需要進行決策時，就需要進行軟體架構恢復。常見的技巧包括靜態程序分析，軟體架構恢復也是軟體智能實務中的一部份。
软件架构是设计的一部份，不過不是所有的設計都和架構有關。實務上，架構師會劃分出軟體架構（架構設計）以及細節設計（非架構設計）的分界。有沒可以符合所有情形的規則或指引，不過仍有許多人設法要將找到分界的固定體系。
依照「內涵/局部性假說」（Intension/Locality Hypothesis），架構設計和細節設計的分界在於「局部性準則」（Locality Criterion），此準則認為若滿足此設計的程式可以擴充進一個不是以此設計的程式，則軟體設計屬於架構性（非局部性），這也是軟體設計屬於架構性的唯一條件。
舉例，主從式架構是架構（策略）設計，因為以主從式架構撰寫的程式可以擴充到一個不是主從式架構（例如對等網路節點）的程式裡。
需求工程和軟體架構可以視為是互補的二個方法：軟體架構專注在或是「如何進行」，需求工程專注在或是「要做什麼」。需求工程會展開需求获取、需求分析、软件需求说明、、需求可追蹤性及需求管理。需求工程和軟體架構都和專案關係人的關注、需要及期待有關。
在需求工程和軟體架構之間有相當大的重疊，有一個針對五個軟體產業架構方法的研究，結論是：「輸入（目的、限制等）一般定義的不好，要到開始建立架構時才會發現，或是比較深入的瞭解。」以及「大部份的架構關注都以是系統需求來表示，不過其中也包括了強制的設計決策。」。簡單來說，需求的行為會影響解決方案的架構，架構又會產生新的需求。像Twin Peaks model等方式就是要利用需求以及架構之間的協同關係。