軟體架構師類似於建築的工程師，都是站在總體的角度考慮問題，樓房是建築師的產品，建築師在設計樓房的時候要考慮樓房的高度，地基的大小，建造的材料，樓房的用途等因素；同樣的，軟體架構師也要考慮各個方面的因素，例如：執行環境，軟體功能，核心技術，適用人群等。
我們在課堂上**了《夢想改造家》這個節目，這期節目主要講述了王平仲設計師怎樣設計並改造了乙個上海的小房間。他的有些想法讓人眼前一亮，他的改造使乙個房子重新煥發生機，在解決使用者問題的同時也想到了一些潛在的問題並進行預防，而且充分考慮到了使用者的經濟水平，節約了成本。我們應該從他身上學到這種統籌規劃的能力，考慮到軟體的各個方面，這樣做出來的軟體才有市場，才會受到使用者的歡迎。
首先，軟體架構是用來溝通的，軟體架構必須滿足軟體專案所有步眾代表都有自己立場與視角的模型、文件說明，且這些模型文件說明僅清晰包含自己立場與視角關注與有關的事物，不能有任何遺漏，也最好不要有多餘。
其次，軟體架構的每一步都是決策過程，而且關鍵需求決定架構，軟體架構必須充分清楚地表達出這些決策與決策理由。眾多的需求中為什麼這些需求是關鍵需求？為滿足這些關鍵需求，採用了什麼樣的關鍵機制、核心技術與第三方框架？什麼選擇這些關鍵機制、核心技術與第三方框架而不選用其它的？為什麼說它們是可行的？
再則，軟體架構必須為以後的開發提供足夠的指導與限制，因此軟體架構必須確定系統各元素間的關係、職責、互動介面與協作機制。僅僅劃出幾個層與層中包含的元素而不約束它們間的關係、職責、互動介面與協作機制，就如同乙個公司，它的組織結構圖就掛在牆上——再清晰不過了，但如果介面不清、機制不明，來了任務、出了事情不清楚找誰、如何匯報、怎樣處理。
然後，軟體架構必須突出強調通訊機制、持久化機制和訊息機制等公用模組的深入設計。通訊機制、持久化機制和訊息機制等公用模組較多的涉及軟體的不同部分之間的互動，對系統的功能實現、非功能滿足等成功因素起著舉足輕重的作用。
最後，由於軟體專案的不同、開發組織結構的不同、開發團隊情況的不同，軟體架構的設計粒度是不一定的。比如，航天航空領域中的軟體系統對系統的可靠性等質量屬性要求非常高甚至可以認為是荷刻，這種情況下對架構的設計詳細程度的要求也會比較高；象ibm這樣的大的團隊中又有小的團隊共同開發，架構的設計粒度到子系統級就足夠了，各個小團隊精通的技術各不相同，可以讓其對子系統採用敏捷開發，對縮短工期、人盡其材有好處；有類似專案經驗或專案團隊所有成員整體技術水平較高的團隊架構粒度可適當粗獷，而分布團隊或涉及外包的情況則更強調架構的明確性。總之，架構設計對軟體的不同部分的設計程度不應是整齊劃一的，特別是具體的業務功能模組在架構設計中往往設計程度不深。
架構師的工作流程
通過課堂上 夢想改造家這個節目，我想到了軟體架構師的工作流程，在夢想改造家中，王仲平這個建築師首先是了解使用者需求，然後根據使用者需求制定相應的方案和改造計畫，其中考慮到了使用者的方便性，安全性，重用性，空間利用性。對於我們軟體架構師來說，同樣如此，非常相似。軟體架構師在需求分析階段介入。在這一階段...
軟體架構師如何工作
通過閱讀構架漫談，軟體架構師工作需要了解一下幾個方面 首先要理解什麼是架構，為什麼需要架構 架構是規劃 設計和建造建築物和其他物理結構的過程和產物。人們完成一項任務，因為每個人的能力不同，所擅長的方向不同，所以如果自己去完成一項任務一般要花費很長的時間，效率很低，但是人們對目標有更高的要求，所以需要...
軟體架構師如何工作
要理解軟體架構師如何工作，在閱讀了架構漫談九篇部落格後，不妨先來看看架構是什麼。內容如下 1.根據要解決的問題，對目標系統的邊界進行界定。2.並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。3.並對這些切分出來的部分，設立溝...