軟體中的系統架構，其實是從建築行業中的架構設計參考過來的，但是軟體中的系統架構又有很大的特殊性。特殊性表現在，軟體的架構可以在設計完畢後，專案進行的過程中進行相應的變化，或者可以推到重來，但是建築行業中卻不能這麼做。軟體行業有著很大的變化性。
架構總體來說就是實現需求功能的較複雜元件的設計與不能精簡的較複雜元件。iso與ieee對系統架構的定義：一致認為軟體密集型系統的架構分為主要模組，組織模組與支撐模組3部分。
功能：功能上必須滿足需求。
可靠性：系統系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。
可用性：系統必須可用。
可維護性：系統的維護包括兩方面，一是排除現有的錯誤，二是將新的需求反映到現有系統中去。乙個易於維護的系統可以有效地降低技術支援的花費
安全性：系統所承擔的交易的商業價值極高，系統的安全性非常重要。
可擴充套件性：必須能夠在使用者的使用率、使用者的數目增加很快的情況下，保持合理的效能。只有這樣，才能適應使用者的市場擴充套件得可能性。
系統分析員通過與專案干係人的溝通或者是與客戶的溝通整理出來功能需求，形成需求文件，然後將文件交付給系統架構師，系統架構師負責將分析員整理的需求轉換為詳細設計說明書。這個詳細設計書作為與開發人員溝通的主要工具。
系統架構師可以通過使用uml建模工具,在詳細設計說明書中書寫每個元件的設計用力圖或者流程圖，或者是通過ibm的relations rose工具來實現相應的建模。
系統架構師在設計時遵循的原則是：
1、低耦合：就是要求不同的組建之間的耦合度最低。每個組建的功能應盡量的分離，他們直接的呼叫關係進行把物件的引用轉換為介面的引用。
系統架構師作為需求分析師與軟體開發工程師之間的核心關鍵。好的系統架構不但可以滿足軟體的功能需求有更好的擴充套件性，可維護性，安全性，可靠性的等等。
系統架構師必須參與到開發的全過程。
一般來說。系統的需求分為：功能性需求與非功能性需求。
系統架構師在進行系統設計的時候一般採用的方式是通過邏輯分層將功能相像的模組放在單獨的層中，然後通過分層來實現系統的功能分離與低耦合、高內聚的原則。
系統架構的設計與系統採用的開發方式有關，軟體的開發方式可簡單分為：傳統方式與敏捷開發。
敏捷開發：則是遞增需求的迭代開發。每個階段都會新增乙個需求，完成這個需求之後變發布軟體，雖然軟體的功能不全，但是至少是可以使用的。
系統架構師的設計方案，最後由專案干係人進行確定，確定採用哪個設計方案，當然最後也可能不採用，造成這樣的結果，可能的原因是非功能性需求的原因。非功能性的需求：例如與之前系統的繼承，硬體裝置，網路環境等等。
系統架構可以簡單的分為隱式架構與顯示架構，例如：蓋乙個小狗的棚子，有經驗的架構師在自己的腦海中就已經有了如何去架構。這就是隱式架構。有些情況下：系統的功能比較複雜和細化，我們不可能在腦海中就能想出來如何架構，需要通過做demo或者模組化的劃分來設計，這就是顯示架構。
系統的架構設計，必須考慮設計的可行性，可擴充套件性，健壯性，可用性，高效性，安全性等方面，還要考慮軟體所處的環境等等，各方面的因素都要考慮，否則等軟體開發的過程中發現系統架構設計中的不足再去修改，代價是很昂貴的。
因為本人初次寫博。部分描述不清楚的部分在所難免，錯字方面還請見諒，還請大家多多提出交流意見，大家共同提高。
最後callhot
系統架構師 基礎到企業應用架構 系列索引
一篇都是自己在系統架構過程中的總結和經驗，每一篇我都會抱著認真的態度去完成，寧缺毋濫的原則。希望本系列看完之後不但能夠幫助看過這個系列的人對系統架 構有深刻的認識，並且能夠掌握系統架構中的必備知識，應用到自己的工作中去，更可以共同提高大家的個人能力。本系列希望能夠拋磚引玉，希望大家能夠多提出寶 貴意...
系統架構師 基礎到企業應用架構 系列索引
系統架構師 基礎到企業應用架構 索引 一篇都是自己在系統架構過程中的總結和經驗，每一篇我都會抱著認真的態度去完成，寧缺毋濫的原則。希望本系列看完之後不但能夠幫助看過這個系列的人對系統架 構有深刻的認識，並且能夠掌握系統架構中的必備知識，應用到自己的工作中去，更可以共同提高大家的個人能力。本系列希望能...
系統架構師 基礎到企業應用架構系列之 開卷有益
由於是自己對這些技術的學習總結和心得體會，錯誤之處在所難免，懷著技術交流的心態，現在發表出來，所以希望大家能夠多多指點，這樣能使一部分人受益同時也能糾正我的錯誤觀點，以便和各位共同提高！軟體架構可以被簡單的描述為，一系列元件之間的組合，互動，繼承的關係。當然這樣的解釋基本上人人都可以接收。不過在我們...