1、啟發(fā)性的問題回答以下問題： 什么是系統(tǒng)架構(gòu)? 為什么系統(tǒng)架構(gòu)重要? 在一個項目里為什么需要系統(tǒng)架構(gòu)? 系統(tǒng)架構(gòu)師的角色是什么? 誰是在一個項目里對系統(tǒng)架構(gòu)要負責任的? 誰是負責系統(tǒng)架構(gòu)文檔資料的? 一般來說, 用什么樣的圖或模型來表示系統(tǒng)架構(gòu)? 什么是系統(tǒng)架構(gòu)思維?第1頁/共67頁IT架構(gòu)師的側(cè)重點 IT架構(gòu)師負責提供如何利用IT技術(shù)幫助一個企業(yè)或組織開展業(yè)務和支持業(yè)務發(fā)展 系統(tǒng)架構(gòu)師側(cè)重于如何架構(gòu)支持業(yè)務系統(tǒng)實現(xiàn)的IT基礎設施 IT產(chǎn)品專家側(cè)重于產(chǎn)品開發(fā)和項目的實施第2頁/共67頁系統(tǒng)架構(gòu)思考方式 它可以把復雜的系統(tǒng)簡單化 它可以分析需要的功能, 從而找出需要的模塊 它提供了建設具體物理系統(tǒng)

2、的基礎 它定義如何連接系統(tǒng)各個部分的結(jié)構(gòu)和策略 它提供組合以及拆散系統(tǒng)元素或模塊的規(guī)則 它幫助分析系統(tǒng)非功能性的需求從而設計達到這些要求的方案 它提供了做架構(gòu)決策的記錄,從而可以在未來進一步擴展系統(tǒng)功能第3頁/共67頁優(yōu)秀IT系統(tǒng)架構(gòu)師的訣竅 永遠都把自己放在不斷學習新東西的位置。 (my experience) 尋求最好的團隊一起工作。不但你所參加的項目成功機會大, 而且在團隊中學到更多的東西。 不斷學習的心態(tài)可使你成為一個優(yōu)秀的系統(tǒng)架構(gòu)師。即使你不想成為系統(tǒng)架構(gòu)師, 也可以成為一名優(yōu)秀的技術(shù)骨干, 從而增加你在團隊中的價值。第4頁/共67頁成功的架構(gòu)師必備的特征l 溝通的能力(commun

3、ication)l 富有激情地去做自己需要做的事情(passion)l 判斷別人的能力和做事的特性(character)l 技術(shù)知識和能力，了解技術(shù)發(fā)展趨勢(technical trend)l 對一兩個技術(shù)方向具備精深的掌握。(technical specialty)l 行業(yè)知識(industry knowledge) 了解客戶, 明白客戶需求 從客戶的角度思考和理解l 具備很好的個人,銷售,場景和能力技能(4 quadrant skills)l 最重要的是具備結(jié)果導向的執(zhí)行能力(result-oriented approach)第5頁/共67頁如何溝通 增加銷售說服力第6頁/共67頁如何定義

4、“系統(tǒng)架構(gòu)”? IBM Architectural Description Standard (ADS)定義: IT系統(tǒng)架構(gòu)是一種包括軟件和硬件模組的結(jié)構(gòu)。它描述了這些模組對外的接口屬性以及模組之間自身的關(guān)系. F. Brooks & W. Buchholz in Planning Computer Systems: Computer architecture, like other architecture, is the art of determining the needs of the userand then designing to meet those needs as

5、 effective as possible. IT目前比較接受的定義: IT系統(tǒng)架構(gòu)師通過使用合理的IT技術(shù)來制定解決客戶商業(yè)問題的方案。這個方案是通過系統(tǒng)管理架構(gòu)來展示和描述的, 它包括系統(tǒng), 應用和應用模組之間的流程。類似一個建筑設計師, IT系統(tǒng)架構(gòu)師的工作是側(cè)重于方案設計階段的工作。在方案實施過程中, 系統(tǒng)架構(gòu)師扮演了一個與客戶溝通的橋梁, 確認系統(tǒng)是按照所規(guī)劃的架構(gòu)來實施的, 并且對施工方提供技術(shù)指導和引導.第7頁/共67頁歸納一下系統(tǒng)架構(gòu)師是個什么樣的人? 實際做事的人 不同意見和選擇的協(xié)調(diào)人 結(jié)果導向的 知識廣而多, 而不是少而精 是個技術(shù)專家 是一個產(chǎn)品專家, 但知道產(chǎn)品的能

6、力 不是項目經(jīng)理 不僅僅是個設計高手 絕對不是個孤獨的思想家對于系統(tǒng)架構(gòu)的誤解(myths)系統(tǒng)架構(gòu)和系統(tǒng)設計是一回事架構(gòu)和基礎結(jié)構(gòu)是一回事系統(tǒng)架構(gòu)等同于硬件組合好的系統(tǒng)架構(gòu)是靠一個架構(gòu)師獨立做出來的系統(tǒng)架構(gòu)凌駕于軟件架構(gòu)之上架構(gòu)是不可以衡量和確認的架構(gòu)是門科學架構(gòu)是技術(shù), 基礎結(jié)構(gòu), 數(shù)據(jù)和網(wǎng)絡的組合第8頁/共67頁架構(gòu)決策決定于要解決的問題和涉及到的方架構(gòu)決策決定于要解決的問題和涉及到的方面面第9頁/共67頁什么是系統(tǒng)思考? (System Thinking)第10頁/共67頁系統(tǒng)和系統(tǒng)架構(gòu)思考 系統(tǒng)性思考是一種架構(gòu)設計過程,為了解各個部分是如何工作的 它是被人們認為在事件的背后, 尋找事

7、件和功能的模式從而找出系統(tǒng)之間負責功能模式和事件的關(guān)系 系統(tǒng)性思考是為了闡述一種宏觀的看法。宏觀的看法是要代表如何解釋系統(tǒng)組件之間關(guān)系的最基本基礎 負責系統(tǒng)之間的關(guān)系以及方式 系統(tǒng)之間的關(guān)系使得我們可以理解不同事件的處理模式 選擇系統(tǒng)的邊緣界線有助于理解系統(tǒng)之間的互動 如何系統(tǒng)邊緣的定義或選擇是錯的話, 我們的理解就會受阻 思考的方法是循環(huán)性的, 架構(gòu)師要學會如何調(diào)整系統(tǒng)邊緣, 從而更深理解整體系統(tǒng)架構(gòu)設計的思考是基于以下幾方面建立在系統(tǒng)思考之上的: 使用從上到下和滿足需求的方法 有能力把一堆亂麻整理成清晰的線條 利用結(jié)構(gòu)來確認系統(tǒng)需求是可以滿足的第11頁/共67頁系統(tǒng)架構(gòu)思考支持系統(tǒng)架構(gòu) 把

8、復雜的系統(tǒng)簡單化 分析需要的功能, 從而找出需要的模塊 建設具體物理系統(tǒng)的基礎 定義如何連接系統(tǒng)各個部分的結(jié)構(gòu)和策略 提供組合以及拆散系統(tǒng)元素或模塊的規(guī)則 幫助分析系統(tǒng)非功能性的需求并設計達到這些要求的方案 提供了架構(gòu)決策的記錄,可在未來進一步擴展系統(tǒng)功能第12頁/共67頁從不同的角度看IT架構(gòu)思維 IT架構(gòu)概念可以想成是某種程度的提煉和封裝(hiding of details) 把在一定場景或狀況下的細節(jié)隱藏起來。一旦場景發(fā)生變化, 所要隱藏的細節(jié)也會改變 IT架構(gòu)設計需要考慮多方面的因素和質(zhì)量。但經(jīng)常這些質(zhì)量之間會有沖突。因此決定架構(gòu)時,我們要不斷進行選擇平衡(trade-off) 從不同

9、角度看IT架構(gòu)時, 都會覺得需要改變。這是自然的因為任何一個角度看都只是一種架構(gòu)的表示而已.所以, IT架構(gòu)思考涉及到內(nèi)容輸入, 思考和結(jié)果輸出第13頁/共67頁IT架構(gòu)設計使用的語言功能方面的架構(gòu) 組件 它是軟件功能單元。它的使用是通過一個或多個接口達到的 子系統(tǒng) 任何一種在IT系統(tǒng)里組件的組合 組件協(xié)同使用(collaboration) 使用場景的代表, 它的實現(xiàn)是通過多個組件按一定順序使用來達到的 組件互動(interaction) 代表兩個組件之間的交互,通過接口來執(zhí)行的.部署方面的架構(gòu)節(jié)點 架構(gòu)中的物理單元, 軟件在其之上運行連接 代表節(jié)點與節(jié)點之間的物理連接, 如局域網(wǎng), 廣域網(wǎng)等

10、部署單元 代表一個或多個組件, 共同部署在同一個節(jié)點上 部署單元的執(zhí)行, 狀態(tài)和部署三個方面都可以是分開來考慮的(execution, state, installation)第14頁/共67頁描述和標示架構(gòu)方法第15頁/共67頁描述和標示架構(gòu)方法 4+1視圖第16頁/共67頁邏輯視圖（Logic View） 邏輯視圖主要是用來描述系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務。在邏輯視圖中，系統(tǒng)分解成一系列的功能抽象、功能分解與功能分析，這些主要來自問題領域（Problem Definition)。在面向?qū)ο蠹夹g(shù)中，通過抽象、封裝、繼承,可以用對象模型來代表邏輯視圖，可以用類圖（Class Di

11、agram）來描述邏輯視圖。如下圖: 構(gòu)件(Components)：類、類服務、參數(shù)化類、類層次 連接件(Connectors)：關(guān)聯(lián)、包含聚集、使用、繼承、實例化 第17頁/共67頁開發(fā)視圖(Development/Module View) 開發(fā)視圖主要用來描述軟件模塊的組織與管理（通過程序庫或子系統(tǒng)）。服務于軟件編程人員， 方便后續(xù)的設計與實現(xiàn)。它通過系統(tǒng)輸入輸出關(guān)系的模型圖和子系統(tǒng)圖來描述。要考慮軟件的內(nèi)部需求：開發(fā)的難易程度、重用的可能性，通用性，局限性等等。開發(fā)視圖的風格通常是層次結(jié)構(gòu)，層次越低，通用性越好（底層庫：Java SDK，圖像處理軟件包）。 第18頁/共67頁進程視圖 進

12、程試圖側(cè)重系統(tǒng)的運行特性，關(guān)注非功能性的需求（性能，可用性）。服務于系統(tǒng)集成人員，方便后續(xù)性能測試。強調(diào)并發(fā)性、分布性、集成性、魯棒性（容錯）、可擴充性、吞吐量等。定義邏輯視圖中的各個類的具體操作是在哪一個線程（Thread）中被執(zhí)行。第19頁/共67頁物理視圖 物理視圖主要描述硬件配置。服務于系統(tǒng)工程人員，解決系統(tǒng)的拓撲結(jié)構(gòu)、系統(tǒng)安裝、通信等問題。主要考慮如何把軟件映射到硬件上，也要考慮系統(tǒng)性能、規(guī)模、可靠性等?？梢耘c進程視圖一起映射。 第20頁/共67頁場景(Scenarios) 場景用于刻畫構(gòu)件之間的相互關(guān)系，將四個視圖有機地聯(lián)系起來。可以描述一個特定的視圖內(nèi)的構(gòu)件關(guān)系，也可以描述不同視

13、圖間的構(gòu)件關(guān)系。文本、圖形表示皆可。 第21頁/共67頁IT架構(gòu)設計方法第22頁/共67頁Asset-based設計與其他方法比較 One-of-a-kind設計方法每次都從頭開始設計，耗用大量人力 Systematic-use-of-assets設計每次僅利用系統(tǒng)概念 Asset-based設計方法，每次最大可能地重用資產(chǎn)，可以最大地節(jié)約成本，擴大利潤 必須采用Asset-based設計方法，以保障市場競爭力第23頁/共67頁Asset-based設計方法 知識資產(chǎn)（Assets） 資產(chǎn)必須基于通用方法描述（ADS） 公司必須有一組通用的Assets 公司必須知道怎樣得到Assets 技能（

14、Skills） ITA必須具有技能將知識資產(chǎn)與客戶需求對應，形成解決方案 方法論（Methods） 方法論是怎樣重用Assets的規(guī)則 只有遵循統(tǒng)一的方法論才能有效地重用Assets 只有遵循統(tǒng)一的方法論才能有效地建立Assets 第24頁/共67頁架構(gòu)設計方法論及工作文檔第25頁/共67頁架構(gòu)文檔分類第26頁/共67頁架構(gòu)設計交付必須的文檔第27頁/共67頁業(yè)務分析工作文檔 項目描述 信息來源: 客戶訪談, 標書內(nèi)容 價值: 基本信息。幫助了解項目概況以及要解決的業(yè)務問題 業(yè)務的目標 信息來源: 客戶訪談, 與客戶業(yè)務部門交流, 標書內(nèi)容 價值:對架構(gòu)師非常重要, 對說服客戶內(nèi)部也是重要的

15、業(yè)務關(guān)系圖 信息來源: 你自己或是別人對這個客戶業(yè)務的分析 價值: 對架構(gòu)師非常重要, 對客戶有時也是重要的 遵循的IT標準 信息來源: 客戶訪談, 與客戶IT部門交流, 標書內(nèi)容, 你的建議 價值: 基本約束。決定了建議的方案架構(gòu)是否被客戶拒絕 目前客戶IT環(huán)境 信息來源: 客戶訪談, 與客戶IT部門交流, 標書內(nèi)容, 客戶IT文檔 價值: 基本知識。幫助你設計方案架構(gòu), 幫助客戶理解你的架構(gòu)理由第28頁/共67頁項目描述與目標 與客戶共同制定客戶的要達到的最終目標, 宏觀遠景, 和關(guān)鍵項目成功因素 有一個與客戶達成共識的決策基礎。在項目執(zhí)行過程中, 許多決定都要基于這個基礎 定義了如何衡量

16、項目是否成功的標準 每一個跟項目相關(guān)的團隊成員都應該對項目目標有共識。這對項目執(zhí)行過程中涉及到問題的解決事關(guān)重要第29頁/共67頁業(yè)務關(guān)系圖 業(yè)務關(guān)系圖是用來描述一個IT方案涉及到的業(yè)務范圍以及范圍內(nèi)的業(yè)務內(nèi)容。并且也描述這個范圍內(nèi)的內(nèi)容和其它相關(guān)聯(lián)業(yè)務方面的關(guān)系。這些業(yè)務單元之間的關(guān)系解釋了它們之間的信息是如何流通的以及通過何種手段流通的。對這些問題的明白和理解才能使架構(gòu)師知道要建設的系統(tǒng)在業(yè)務中的位置，從而更好地滿足業(yè)務需求。 另外, 業(yè)務關(guān)系圖還提供: 業(yè)務單元之間所發(fā)生的事件。這會對系統(tǒng)模塊之間接口的制訂有很大的幫助 它也提供了一個框架, 使我們可以獲取業(yè)務范圍內(nèi)的流程以及它們之間的業(yè)

17、務“界面”, 從而明白這些流程背后的理由和原因 具體描述需要建設系統(tǒng)所要覆蓋的業(yè)務范圍。不同的業(yè)務關(guān)系圖可以用來和客戶溝通討論。這也是確認最終系統(tǒng)實施范圍的關(guān)鍵依據(jù)和步驟。討論的結(jié)果包括哪些業(yè)務功能是在項目范圍之內(nèi)的, 哪些業(yè)務功能是在范圍之外的, 以及哪些是潛在未來的業(yè)務需求。第30頁/共67頁IT技術(shù)遵循標準與目前IT系統(tǒng)環(huán)境 IT技術(shù)遵循的標準文檔具體列舉了所有項目必須遵循的標準和使用的技術(shù), 甚至具體的產(chǎn)品. 這些標準可能是來自之前的工作, 企業(yè)內(nèi)部的IT規(guī)范. IT標準總是存在的, 無論是公開的還是不言而喻的. 這些事實的記錄會幫助IT架構(gòu)師規(guī)劃系統(tǒng)方案架構(gòu). 這個文檔也記錄了在方案

18、規(guī)劃或者執(zhí)行過程中要繞過這些IT標準的理由和原因 另外, 任何系統(tǒng)模塊還沒有標準遵循時, 這種信息也要記錄下來.這是為了將來這些實施的標準可以變成企業(yè)IT標準 目前系統(tǒng)環(huán)境文檔是個系統(tǒng)清單, 包括硬件, 軟件和其它IT功能環(huán)境,如防火墻, 網(wǎng)絡地址分配,等等第31頁/共67頁可行的 vs. 不可行的第32頁/共67頁人-機分工平衡以取綜合最優(yōu)第33頁/共67頁非功能需求 非功能需求用來: 針對要建設的IT系統(tǒng), 定義關(guān)鍵系統(tǒng)特征和限制要求. 用來估算系統(tǒng)容量和成本 評估系統(tǒng)的可行性和生存能力 用于系統(tǒng)部署模型的重要依據(jù) 非功能需求經(jīng)常是系統(tǒng)架構(gòu)的重要因素之前描述的非功能性需求是用這個工作文件記

19、錄下來的第34頁/共67頁可行性分析 可行性分析報告是探討, 解釋和描述建議的方案是否可行。 編寫可行性報告的過程就是思考和組織建議方案的不同部分。 可行性分析經(jīng)常是針對某部分系統(tǒng)需求, 功能或某種技術(shù)的使用。 可行性分析也是用來找出潛在可能存在的問題和風險. 這對與客戶溝通以及架構(gòu)師設計時都是一個重要方面。 可行性報告應該是不斷更新和審核的. 同時它是作為質(zhì)量保證審核以及實施計劃的重要依據(jù)。第35頁/共67頁可行性分析舉例 使用不同的顏色(紅/黃/綠)來標示不同程度的問題 不要把風險, 問題, 假設和依賴因素混為一談 提早從客戶獲取信息進行風險分析 例如, 如果客戶不提供所需要的資料或信息,

20、 這個問題帶來的風險是高的. 可以有依據(jù)向客戶盡早獲取資料第36頁/共67頁系統(tǒng)運行模型 提供宏觀的系統(tǒng)邏輯運行架構(gòu), 用來理解整體系統(tǒng)是如何滿足業(yè)務需求的用來考慮系統(tǒng)主要基礎架構(gòu)是如何部署的以及系統(tǒng)組件應該如何部署 用來確認客戶對系統(tǒng)實施的傾向和限制因素 用來執(zhí)行早期的系統(tǒng)基本功能的流程執(zhí)行驗證(walk-through) 基于以上幾個方面, 用來考慮系統(tǒng)的非功能性需求應該如何滿足 用來選擇實施系統(tǒng)組件功能的產(chǎn)品或應用, 衡量它們的可用性 用來估算相關(guān)系統(tǒng)硬件和基礎建設的成本 作為選擇軟件和硬件產(chǎn)品的選擇基礎第37頁/共67頁系統(tǒng)運行模型圖舉例 用來估算硬件的成本及軟件license的數(shù)量第

21、38頁/共67頁系統(tǒng)運行模型圖舉例 系統(tǒng)LPAR的節(jié)點配置方案第39頁/共67頁系統(tǒng)運行模型圖舉例 系統(tǒng)節(jié)點描述第40頁/共67頁Q & A第41頁/共67頁IT Infrastructure 架構(gòu)設計 邏輯層面的運營架構(gòu)模型 規(guī)范層面的運營架構(gòu)模型 物理層面的運營架構(gòu)模型 總結(jié)第42頁/共67頁運營架構(gòu)模型八步規(guī)劃法 八步法是按順序來講的. 但在實際制作過程中, 有些步驟是同步進行的或重復使用的. 是否是這種情況決定于限定因素或條件, 以及是否使用參考架構(gòu) 在做每一步時, 關(guān)鍵的非功能性需求對架構(gòu)模型的影響一定要不斷核實 系統(tǒng)可用性, 性能, 系統(tǒng)管理, 安全 這個做法也包括如何制作

22、以下工作文檔: 部署單元 更新的架構(gòu)決定 可行性報告第43頁/共67頁第一步:找出業(yè)務功能的位置和區(qū)域 信息來自于： 業(yè)務角色和位置 系統(tǒng)關(guān)系圖 目前IT環(huán)境第44頁/共67頁第二步: 找出邏輯節(jié)點第45頁/共67頁邏輯節(jié)點舉例第46頁/共67頁第三步: 為了滿足系統(tǒng)管理需求的特殊邏輯節(jié)點第47頁/共67頁第四,五,六步: 找出展示, 執(zhí)行和數(shù)據(jù)部署節(jié)點第48頁/共67頁第七步: 找出需要的連接節(jié)點第49頁/共67頁第八步: 回顧目前所達到的結(jié)果第50頁/共67頁建議以場景進行驗證第51頁/共67頁第52頁/共67頁IT Opertion 架構(gòu)設計 邏輯層面的運營架構(gòu)模型 規(guī)范層面的運營架構(gòu)模

23、型 物理層面的運營架構(gòu)模型 總結(jié)第53頁/共67頁規(guī)范架構(gòu)是把邏輯架構(gòu)改變成一個技術(shù)規(guī)范架構(gòu)技術(shù)規(guī)范架構(gòu)過程1.在限制因素范圍內(nèi)和滿足非功能需求的前提下, 找出必要的技術(shù)需求和功能服務用來提供業(yè)務功能2.考慮一些不同的選擇或方法滿足同樣的需求, 進行選擇平衡, 對目前的架構(gòu)做適當?shù)男薷?.設計邏輯技術(shù)連接4.評估目前架構(gòu)的可行性, 對相關(guān)的架構(gòu)文檔進行更新第54頁/共67頁輸入-組件模型, 非功能需求, 用戶需求和邏輯模型第55頁/共67頁尋找技術(shù)規(guī)范節(jié)點 系統(tǒng)管理考慮 不同節(jié)點是如何運作的 監(jiān)控(系統(tǒng)狀況監(jiān)控, 性能監(jiān)控, 可用性監(jiān)控) 任務執(zhí)行(開機, 關(guān)機, 日志控制, 配置控制等等) 安裝, 配置,變更管理 數(shù)據(jù)分布, 同步, 備份, 回復 系統(tǒng)使用以管理記錄 問題處理 做法 從每個節(jié)點, 層次, 位置和整體方案角度找出不同系統(tǒng)管理的考慮因素 找出每個涉及到系統(tǒng)管理流程和數(shù)據(jù)存儲的節(jié)點 在不同層次和區(qū)域中找出其它涉及到系統(tǒng)管理和數(shù)據(jù)存儲的節(jié)點第56頁/共67頁參考架構(gòu)是邏輯和技術(shù)架構(gòu)的結(jié)合第57頁/共67頁IT Infrast