IT架構師在項目中的角色，IBM的架構流程規範，IBM的架構師在檢查自己設計架構的是否可行性，是否可用性，是否可實施性對以及對其擴展性手段和標準。IBM的架構在電子商務的模式的參考框架。方法論的東西，我認爲是架構思路培訓，具體怎麼樣實施還應該根據實際情況而定。對不同的業務模式有所不同，需要形成具體業務模型的方法學。
下面內容從幾個方面談談我的感受：
1.1 如何成爲優秀的IT架構師，即需要哪些條件或特質。
1.對一兩個技術方面具備非常深的專業知識和技術。
2.針對某個行業有着非常強的行業知識。
3.具備很好的“聽”的能力和溝通能力。
4.具備很強的解決問題，處理問題的能力。
5.有對項目的一個生命週期的負責的能力。
6.領導能力。
7.個人魅力，個人特質。
8.項目管理能力(不需要項目經理那麼強)。
9.與客戶建立信任
總結：上面的9個方面能力的確對要想成爲架構師的我們提出很高的要求，架構師不僅僅是業務方面的專家，更是溝通、領導能力方面的專家，是一個全方位的能人，因此，我們下一步對自己的努力方向應該要有明確目標，一個方面一個方面的去加強。
1.2 IT架構師在項目中的角色，以及如何和項目經理在項目整個週期中配合。
這點給我一個很大啓發就是在IBM軟件工程體系和所謂RUP過程中角色：項目經理(項目資源管理，項目進度管理，項目實施部署和維護等，把握中與客戶和內部人員協調工作)，架構師，產品專家(負責系統在行業產品化模式)，技術專家(負責系統高新技術的技術方案包括細節化類級設計模式)，編程員的角色。沒有所謂SA(系統分析)--這是因爲IBM認爲它角色(責任)很不清晰和尷尬，即不是需求控制，也沒有項目生命週期全程權責。IT架構師和產品專家側重點不一樣：IT架構師側重系統設計(對客戶建立信任度責任)，而產品專家側重產品的開發和項目的實施。IT架構師在整體項目週期中，從一開始的投標中的需求分析、出方案就要介入其中，和項目經理配合，項目中標之後，做具體設計以及監督它的實施，保證當初的設計被最大限度的實施了，在測試階段，要配合測試經理進行單元測試和集成測試，以及最後的發佈驗收。
架構師不僅僅負責軟件的架構，也負責硬件的架構，用他語言就是組件模型(組件可以軟硬件主要針對功能性需求--例如業務功能分類，硬件功能分類，抽象的功能節點)和運營模型(組件的運營環境主要體現非功能性需求--組件的支撐環境，性能，安全，擴容，擴量，容錯，擴展，未來需求)，其中組件模型包括組件的定義，組件的對外接口，組件的使用;模型中體現非功能性需求，其中有一個叫未來需求(其實就是我們常常在架構是採用的高擴展服用架構動力，包括硬件設備未來--加節點分佈式，帶寬擴展考慮，業務未來需求--具有前瞻業務變更擴展或者更高一手，可定製業務變動適應力)。
總結：好的架構師是既懂軟件又懂硬件的，這對我們這些以做產品技術爲主的工程師來說有很大的挑戰。對我來說，雖然以前也做過開發，但是新的開發技術不斷出來，尤其基於j2ee架構的技術還需要進一步提高，以便能夠滿足做架構師的要求。
1.3 架構流程規範
個人的理解如下：
需求分析(use case 的分類和抽象)->用例建模(用例圖，use case 的初步定製)->業務建模(業務概況圖)->參考模型(已有資源利用)->組件模型(系統關係圖，組件定義，組件的對外接口，組件的使用)->數據模型(包括數據庫，系統內的資訊格式)->運營模型(系統架構模型)->架構模型->可行性分析(用例邏輯驗證)->實現(包括詳細架構，編碼，測試，遞歸過程)->部署->實施->總結。
在架構的過程中要注重在架構決策在可用性需求分析過程中要記錄起來(這是爲了評估/和出問題時候的迴歸決策)
總結：其實我們的大部分項目都是安照這個思路來做的，只是希望能做到更認真些。
1.4 架構師在檢查自己設計架構的是否可行性，是否可用性，是否可實施性對
以及對其擴展性手段和標準。
個人的理解是：
1.可用性是指從客戶的角度來對系統的要求--使用者感受(連續性，方便性，穩定性，持續性)，性能和容量，可管理性，安全，可維護性，可靠性，利潤，可擴展性;
2.性能，在設計架構時候就應該考慮到性能的需求，而不能等到實施編碼的時候或測試的時候才注意。
3.評估的時候還要從用戶角度看(交換角色的觀點看架構)：主要看使用者的感受，可用性包括兩個層面：a.組件出現問題的時候如何恢復，B.可用性，結合其他層面(中間件/OS/硬件層面);同時要注意在對架構決策平衡的觀看架構決策是否合理。
4.從項目管理角度和運營方面評估和審查架構是否可行性：包括時間，成本，服務的重要性—〉組件模型，運營模型，未來需求，架構決策—〉參照用戶對服務的列表，服務對組件的矩陣，計劃維護的矩陣(基本的);組件失敗影響分析，詳細對用戶服務矩陣，組件可行性分析—〉運營模型，組件模型，服務水平特徵，非功能性需求，現有IT的環境，架構決策。
5.組件間鬆耦合(方便處理可用性)和緊耦合(提高性能)的決策，同時要檢查容錯性。
6.性能架構師的估算和建模：初步估算，不斷增加細節，應用設計更改，從技術方案原形獲取的資訊，配置更改，容量資訊，數據庫設計進化，數據庫使用模式(同步，備份，容量)，應用使用場景建立，從系統測試獲取資訊，從系統執行過程獲取資訊。
7.同時要定義性能和容量的測試的標準，必須在架構時候初步獲得系統架構的數量級極點(最高，最低，弱點，峯值)在測試的標準必須訂立和找出系統的系統明顯性能慢下來的點，系統崩潰臨界點(這樣可以找出系統的在不同狀態的臨界值，更能把握架構是否合符需求)。正常工作(或者在比例較多的時候—時間比例儘可能大)在極限值臨界值訂立標準有：CPU最大值75%左右，硬盤使用率40%，網絡使用率30%作用。
8.從系統架構生命週期來考慮架構(非功能性需求，產品的生命週期)這個包括業務的(業務變更擴展處理張力)和非業務的(物理邏輯擴展處理張力);可以透過以下步驟：a.需求和限制條件(系統關係圖和描述來看)-〉架構功能方面考慮(組件模型和功能規範)-〉數據模型(數據庫接口內容，資訊載體內容)-〉系統運營架構方面考慮(非功能性，安全，網絡，應用部署，數據管理，系統管理等等)-〉系統運營架構外部接口(組件整合規範)-〉系統性能方面 -〉系統可用性(包括硬件，網絡，系統功能，業務)-〉系統可靠性(備份和恢復，注意業務上應用場景德恢復)-〉項目的團隊的實施能力(項目管理和運營管理的資源環境)
總之，如果可能，希望在我們的項目評估中引進這些方法，以更能準確評估一個系統的可行性以及能力。
1.5 架構的模式
這部分個人感覺對架構的描述和標示架構方法這部分有些體會：
對於架構設計的描述和方法，目前採用四個視圖、一個場景方式，其中大家對進程視圖比較關注，因爲我們一般開發人員更多關注邏輯視圖和開發視圖，而物理視圖一般是系統工程師比較關注的，我們感機密覺對於大多數項目來說，都沒有做到，如果做到對進程模型的把握幾乎就能夠對整體系統架構軟、硬件的把握，可以很清楚系統的瓶頸之所在。因此，在以後的工作中希望能夠加強這一部分工作。