構架是涉眾進行交流的手段 軟件系統的涉眾--客戶、用戶、項目經理、程序員、測試人員等--分別關注系統的不同特征，而這些特征都受構架影響。例如，用戶關心的是系統的可靠性和可用性；客戶關心的是構架能否在規定時間內實現，并且開支不超出預算；項目經理關心的是如果按此構架進行開發，能否保證各小組的任務在很大程度上都獨立完成，各部分的交互方式是否規范、可控；而設計師所關心的則是實現構架的所有這些目標的策略。
構架提供了一種共同語言，有關各方可借助它表達和協商各自的需求，并理性地找到解決方案，即使對大型、復雜系統的開發也是如此。如果沒有這樣一種語言，要想充分理解大型系統并理智地做出對系統質量和易用性都具有重要影響的早期決策將十分困難。構架分析不僅依賴于而且促進了這個層次上的交流。
構架是早期設計決策的體現 構架明確了對系統實現的約束條件。如果系統實現遵循構架設計中所做出的關于系統結構的決策，則系統實現將能夠體現出構架的特色。
資源分配方面的決策也制約著系統實現。這些決策對從事各元素開發的實現人員來說可能是不可見的。這些限制條件使將各方關心的問題分離開成為可能，從而使管理者能夠做出科學的決策，最大限度地利用人才和計算資源。各元素的開發者對自己所從事的開發任務的要求必須十分清楚，但沒有必要了解在構架上所做的權衡。相反，構架設計師未必要精通算法設計或編程語言的各個方面，但必須能夠做出構架上的合理權衡。
構架決定了開發組織的組織結構。因為系統的構架中包含了對系統的最高層次的分解，因而一般被作為工作分解結構的基礎；這反過來也規定了計劃、調度及預算的單元，組內交流的渠道，配置控制和文件系統的組織，集成與測試計劃和規程，甚至提出了對一些瑣事的要求。各開發小組根據構架中各主要元素的接口規范進行交流。一旦進入維護階段，維護活動也會反映出軟件的結構，常由不同的小組分別負責各具體部分的維護。
建立工作分解結構的一個副作用：它限定了軟件構架的某些方面。如果已經將某個子系統的開發交由某個小組完成，則該小組會對將此任務分派給其他小組提出異議。如果這種責任劃分已經用合同的形式確定下來，則改變任務分配的代價可能是昂貴的。對分配到各小組的任務的進展情況的跟蹤也要困難得多。
因此，一旦對構架達成一致，不管是由于管理上的還是商業傷的原因，想要對它進行修改，幾乎都是不可能的。這也是為什么在確定某個大型系統的構架之前必須進行全面分析的原因之一。
構架阻止或支持系統的質量屬性的實現。 系統能否具有所期望的質量屬性主要是由其構架決定的。第5章將詳細討論構架和質量屬性之間的關系，現在僅需牢記以下幾點：
- 如果您的系統要求高性能，就需要管理元素基于時間的行為以及元素間通信的頻率和數量。
- 如果可修改性很重要，就需要給元素分配責任，以使對系統的修改不會產生很大的影響。
- 如果系統必須非常安全，就需要管理和保護元素間的通信以及允許哪些元素訪問哪些信息。可能還需要在構架中引入專門的元素（如受信的內核）
- 如果您認為系統需要可擴展性，就必須仔細定位資源的使用，以有利于引入容量更高的更換組件。
- 如果項目需要交付系統的增量式子集，就必須仔細管理組件間的使用。
- 如果希望可以在其他系統中重要該系統的元素，就需要限制元素間的耦合，以便提取元素時，它能發揮作用，且不會與當前環境有過多依賴。
這些和其他質量屬性策略都與構架有很大關系。然而，僅靠構架也無法保證系統功能和質量屬性的實現，理解這一點非常重要。
通過研究構架來預測系統質量。能否在系統開發和部署前就知道做出了適當的構架決策（也就是系統是否將表現出所期望的質量屬性）？ 所幸的是，僅僅依靠對構架的評估來預測系統未來的質量屬性是可能的。
構架使推理判斷和控制更改更簡單。每個構架都將可能的更改劃分為3類：本地的、非本地的和構架上的。本地更改只需修改某一個元素就可以實現。非本地更改的實現則需對多個元素進行修改，但并不改動構架。構架的更改會影響各元素之間交互的基本方式--即構架模式--并很可能要求系統做全面的修改。顯然，僅做本地更改是最理想的。所以，一個富有生命力的構架應該是這樣的：最有可能發生的更改也是最容易進行的更改。 構架有助于循序漸進的原型設計。一旦確定了構架，就可以對其進行分析，并將其原型構造為一個骨架系統。這從兩個方面協助開發過程的順利進行：
- 在產品生命期的早期就能得到一個可執行的系統。隨著原型中的各部分逐漸被真實系統各部分的最終實現所代替，原型的這種真實性將越來越明顯地體現出來。原型的各組成部分可能與系統的最終實現有較大差異，也可能能夠比較逼真地處理和產生數據。
- 使系統在早期執行的一個特例就是在產品生命期的早期確定潛在的性能問題。
可以通過構架進行更準確的成本和進度估計。 成本和進度估計是一個重要的管理工具，它能夠使管理人員獲得必要的資源并了解項目開發中是否遇到了困難。與了解整個系統相比，了解系統的某些部分本質上可以使成本估計更加準確。正如我們已經說過的，項目的組織結構基于它的構架。與項目經理相比，每個小組能夠對其所開發的部分進行更準確的估計，并且在使估計成為現實的過程中，擁有強烈的主人翁責任感。第二，構架的最初定義意味著已經評審了系統的需求，從某種意義上來說，已經對需求進行了驗證。對系統范圍了解的越多，估計就會越準確。
構架是可傳遞、可重用的模型 在整個生命期中，重要的越早，收益就越大。代碼的重用能帶來極大的便利，而在構架層次上的重用則為具有類似需求的系統開發提供了有利的手段。不僅可以實現代碼的重用，還可以實現決定構架選用的系統需求及構建構架的經驗的重用。如果構架決策能夠在多個系統中得到重用，則也可以獲得上面講到的早期決策所帶來的所有好處。 產品線共享一個公共的構架。 軟件產品線或家族是一組軟件密集型系統，這些系統共享一個公共的、可管理性的特性集，滿足了待定市場或任務的具體需要，是 按照規定的方式根據一組公共的核心資產開發的。在這些核心資產中，主要部分就是設計用來處理整個家族需要的構架。產品線設計師通過制定在早期適用與整個家族的設計決策，以及在后期僅適用于單個成員的其他決策，來選擇一個滿足產品線的所有預想成員的構架。該構架定義了對產品線的所有成員來說，什么是固定的，什么是可變的。對多系統開發來說，軟件產品線是一種強大的開發方法，它可以在上市時間、成本、生產率和產品質量方面實現極大的回報。構架的強大源于范例的核心。與其他資本投資類似，產品線的構架將成為開發組織的核心資產。 系統開發可以使用大型的、由其他組織開發的元素。以前的軟件范例總是將編程作為最根本的任務，把編寫了多少行代碼作為衡量項目進展情況的依據。基于構架的開發則更強調對各元素的組合或裝配，而這些元素很可能已分別甚至是完全獨立地開發實現了。由于構架定義了可以集成到系統中的元素，因此，這種組合是可能的。構架從元素與環境的交互、對控制的接收和釋放、所能使用或產生的數據、訪問數據的方式、通信方式以及用于通信和資源共享的協議等方面對可能做的更換做了種種約定。 元素結構、接口和操作概念的組織是構架的一個重要方面。互換性是這種組織的最重要的原則。 商業組件、子系統、兼容的通信接口都是基于互換性原則的。 少就是多：限制選擇范圍是值得的。隨著所積累的構架模式和設計模式越來越多，我們將會越來越清楚地認識到：雖然計算機程序可以以近乎無限的方式來組合，但涉及到程序的協調和交互時，有意識地限制在一定范圍內選擇將使我們受益匪淺。也就是說，我們希望使所構建系統的設計盡可能簡單。這種方法的優勢包括：重用程度更高、更易于理解和交流的簡單規范的設計、更為透徹的分析、更短的選擇時間、更強的可互操作性。 軟件設計的特性來自于構架模式的選擇。那些更適用于某個特定問題的構架模式將改善設計方案的實現，這可能通過更輕松地在相沖突的設計要求之間進行權衡、提高對設計環境的人認識和/或使需求描述中的不一致性更為突出等方式體現出來。 系統構架與軟件構架。在過去的5到10年中，我們在很多場合對軟件構架進行了討論。每次總會有人提出如下問題：為什么談論軟件構架？系統構架是否同軟件構架一樣重要？或者說軟件構架和系統構架之間的區別是什么？ 在創建軟件構架時，通常很少考慮系統。 如果您想讓構架具有很高的性能，就需要了解該系統將運行的硬件平臺的物理特性以及該系統將與之交互的任何設備的特性，您通常還會關注網絡的特性。如果您需要構架具有很高的可靠性，也需要關注硬件，在這種情況下就是關心其故障率和冗余處理或網絡設備的可用性。如此等等，不一而足。設計師很少考慮硬件。 因此，設計軟件構架時，大概需要考慮整個系統--硬件和軟件，否則就是蠻干。當僅規定了系統的一部分時，任何一個工程師都不可能預測系統的特性。 但我們主要談論的仍然是軟件構架而非系統構架。這是為什么呢？因為大多數設計師在軟件方面都可以做出選擇，而在硬件方面則沒有這種自由。 構架使基于模板的開發成為可能。構架體現了關于元素交互方式的設計決策。這些決策雖然是每個元素的實現中體現出來的，但卻能夠局部化，只需編寫一次即可。可以在某處用模板將元素間的交互機制描述清楚。 構架可以做為培訓的基礎。 在對項目新成員介紹所開發的系統時間，可以首先介紹系統的結構，以及對組件之間如何交互從而實現系統需求的高層次的描述。我們曾經指出，軟件構架的重要用途之一就是支持并促進各涉眾之間的交流，這進一步印證了我們的觀點。構架是一個公共的參考點。