為了確保架構(gòu)功能在企業(yè)中能夠被成功地運用,，企業(yè)需要通過建立適當?shù)慕M織結(jié)構(gòu)、流程,、角色,、責任和技能來實現(xiàn)其自身的企業(yè)架構(gòu)能力，而這也正是TOGAF的架構(gòu)能力框架（Architecture Capability Framework）的關(guān)注點所在,。架構(gòu)能力框架為企業(yè)如何建立這樣一種架構(gòu)能力提供了一系列參考材料,，從而為各企業(yè)架構(gòu)能力的創(chuàng)建提供了幫助，不過TOGAF的架構(gòu)能力框架在當前還不是一套全面的關(guān)于如何運用架構(gòu)能力的模板,，它只是為企業(yè)架構(gòu)能力建設(shè)和運用過程中的各項關(guān)鍵活動提供了一系列導(dǎo)則和指南,。

如圖所示，企業(yè)的架構(gòu)能力一定是運行在某一成熟度水平之上,，并且在此背景之下,，治理組織（Governance Bodies）將對企業(yè)中各架構(gòu)功能的運作進行監(jiān)管、評測和指導(dǎo),。圖中間部分所表述的就是架構(gòu)功能得以被成功運用所需的各種元素,，包括了：

• 用于管理架構(gòu)功能的實現(xiàn)和維護所必需的各種角色、責任以及其所需技能的技能資源池（Skilled Resource Pool）,。

• 架構(gòu)功能的實現(xiàn)和維護最終需要落實到一個個的實施項目（Project/Portfolios）之上,，而這些項目在其整個生命周期內(nèi)都需要處在一定的架構(gòu)治理（Project/Portfolios Governance）之下，從而使其能夠與架構(gòu)的定義始終保持一致，而為了在明確和標準化的前提下達成這一目標,，這些實施項目與相應(yīng)的項目治理之間需要通過合同（Contract）來進行溝通和約束,。

技能資源池為各實施項目以及項目治理設(shè)定了相應(yīng)的參與角色和責任，并對能夠勝任這些角色和責任的專業(yè)人員其所需的各種技能進行了定義和組織,，同時通過培訓(xùn)的建設(shè)來建立或提高專業(yè)人員所需的各種技能,。對于處于架構(gòu)能力框架主導(dǎo)地位的治理組織來說，它除了對技能資源池的建設(shè)提供指導(dǎo)之外,，還需要為各實施項目的治理設(shè)定優(yōu)先級和關(guān)注點,，并對項目治理的成效進行評測。由于企業(yè)的內(nèi)部以及其所處的外部環(huán)境是不斷變化的,，因而企業(yè)本身也需要適應(yīng)這些內(nèi)外的變化,，而企業(yè)日常的業(yè)務(wù)運營（Business Operation）狀況對于架構(gòu)來說正是這種內(nèi)外變化的最佳反映，它為針對各架構(gòu)實現(xiàn)項目所進行的治理的優(yōu)先級排序以及關(guān)注點的設(shè)定提供了參照,，同時各架構(gòu)實現(xiàn)項目也為企業(yè)的業(yè)務(wù)運營提供了合適的解決方案,。

在之前的各部分中已經(jīng)提到過，企業(yè)架構(gòu)的各項內(nèi)容最終要存放到架構(gòu)資源庫（Architecture Repository）之中,，因而在架構(gòu)能力框架中也將這一元素包括了進來,，用于對在各項目中所產(chǎn)生的架構(gòu)工作產(chǎn)品進行保存和維護，并通過引入企業(yè)連續(xù)體（Enterprise Continuum）來對這些工作產(chǎn)品進行分類歸納,。

綜上所述,，架構(gòu)能力框架為企業(yè)中架構(gòu)能力的建設(shè)提供了指南。這里所說的架構(gòu)能力簡單來說就是企業(yè)能夠成功建設(shè)和運用架構(gòu)的能力,，而其實現(xiàn)方式是在企業(yè)中建立相應(yīng)的組織結(jié)構(gòu)和流程,，并對所需的角色、責任和技能進行定義和分配,，從而為企業(yè)中的各架構(gòu)的交付和治理提供環(huán)境和資源,。TOGAF針對上面這些內(nèi)容從如下方面分別給出了導(dǎo)則和指南：

• 架構(gòu)能力建設(shè)：用于指導(dǎo)企業(yè)如何通過架構(gòu)開發(fā)方法的引入來對架構(gòu)能力進行建設(shè)。

• 架構(gòu)治理（Architecture Governance）：架構(gòu)能力的目標就是通過對企業(yè)中各個架構(gòu)的合理治理來保障整個企業(yè)架構(gòu)建設(shè)和運作的順利,，并且此部分對于架構(gòu)治理以及與此過程相關(guān)的組織結(jié)構(gòu)的建立,、架構(gòu)合同（Architecture Contracts）和架構(gòu)合規(guī)性（Architecture Compliance）都進行了較為詳盡的描述。

• 架構(gòu)成熟度模型（Architecture Maturity Models）：不論企業(yè)清楚與否,，其企業(yè)架構(gòu)的建設(shè)和運作一定處于某種成熟度水平之上,，而為了讓企業(yè)能夠了解自己企業(yè)架構(gòu)的成熟度水平，并借此針對薄弱環(huán)節(jié)進行識別和改善,，都需要成熟度模型的引入,。

• 架構(gòu)技能框架（Architecture Skills Framework）：架構(gòu)能力的實現(xiàn)需要為參與架構(gòu)實現(xiàn)項目和架構(gòu)治理的各種角色、其所需的技能和技能掌握水平進行定義,，從而明確企業(yè)架構(gòu)過程中相關(guān)角色的職責和要求,，并借此遴選合適的專業(yè)人員。TOGAF的架構(gòu)技能框架便為這一目標的實現(xiàn)提供了參考和指南

1. 架構(gòu)能力的建設(shè)

在前面的敘述中我們應(yīng)該已經(jīng)了解到，企業(yè)可以通過應(yīng)用企業(yè)架構(gòu)開發(fā)方法（ADM）來為其建設(shè)各種業(yè)務(wù)能力,，而如果把視界放開一點,，我們會發(fā)現(xiàn)企業(yè)架構(gòu)開發(fā)方法可以應(yīng)用到企業(yè)中任何能力的建設(shè)方面，這當然也包括架構(gòu)能力,。在架構(gòu)能力的建設(shè)中,，對于架構(gòu)開發(fā)方法的成功運用可以使企業(yè)獲得一個可持續(xù)并以客戶為中心的增值型架構(gòu)實踐，從而幫助企業(yè)達成其各項業(yè)務(wù)目標,、最大化投資價值,，并能夠明確各種獲得業(yè)務(wù)利益和管理風險的機會。不過這一架構(gòu)實踐的建設(shè)并不是一個一次性的項目,，而應(yīng)該是一種持續(xù)性的實踐過程,，從而為組織中其他架構(gòu)的交付提供環(huán)境和資源。

在TOGAF的眼中,，任何一種企業(yè)能力的建設(shè)都需要對如下四種領(lǐng)域進行設(shè)計,，這當然也包括針對這一可持續(xù)性架構(gòu)實踐建設(shè)：

• 業(yè)務(wù)架構(gòu)：此領(lǐng)域中的內(nèi)容突出了架構(gòu)治理、架構(gòu)流程,、架構(gòu)組織結(jié)構(gòu),、架構(gòu)信息需求以及架構(gòu)產(chǎn)品等方面。

• 數(shù)據(jù)架構(gòu)：此領(lǐng)域中的內(nèi)容定義了組織中架構(gòu)連續(xù)體和架構(gòu)資源庫的結(jié)構(gòu),。

• 應(yīng)用架構(gòu)：此領(lǐng)域中的內(nèi)容描述了用于支持此可持續(xù)架構(gòu)實踐的功能和/或應(yīng)用服務(wù),。

• 技術(shù)架構(gòu)：此領(lǐng)域中的內(nèi)容描述了此架構(gòu)實踐中用于支持各架構(gòu)應(yīng)用和企業(yè)連續(xù)體的基礎(chǔ)設(shè)施需求和部署方式。

TOGAF對于這一可持續(xù)性架構(gòu)實踐的建設(shè)有著更加詳盡的指南,，在本節(jié)的后續(xù)部分中我們將以架構(gòu)開發(fā)方法各階段為基礎(chǔ)來對企業(yè)架構(gòu)能力的建設(shè)進行進一步探討,。

1.1 架構(gòu)愿景階段

此階段的目的在于定義或?qū)彶檫@一架構(gòu)實踐的愿景、干系人和原則,。TOGAF對于此過程的具體步驟做了如下建議：

• 建立項目：此步驟應(yīng)該關(guān)注于定義與此架構(gòu)實踐有關(guān)的各個干系人。這些干系人包括了參與到架構(gòu)實踐活動中的角色和組織單元,，以及那些會從架構(gòu)實踐所產(chǎn)生的交付物中獲益的干系人,。

• 明確干系人和其關(guān)注點、業(yè)務(wù)需求和架構(gòu)愿景：此步驟將會針對此架構(gòu)實踐從業(yè)務(wù)信息系統(tǒng)和技術(shù)的角度產(chǎn)生第一個關(guān)于基線和目標環(huán)境的高度概括定義,。

• 明確業(yè)務(wù)差距和業(yè)務(wù)驅(qū)動力：對業(yè)務(wù)目標和驅(qū)動力的了解對于促成此架構(gòu)實踐和業(yè)務(wù)之間的協(xié)調(diào)是非常重要的,。

• 定義范圍：針對此架構(gòu)實踐范圍的定義將會產(chǎn)生一份高度概括的項目規(guī)劃，用以概括在接下來的一個時間區(qū)間內(nèi)需要被解決的問題,。

• 定義約束：此步驟的關(guān)注點在于企業(yè)范圍內(nèi)會對所有架構(gòu)項目產(chǎn)生影響的各種約束,。

• 審查架構(gòu)原則（包括業(yè)務(wù)原則）：此步驟的意圖在于定義用于治理和指導(dǎo)這一架構(gòu)實踐運行的各種原則。與通常的架構(gòu)原則用來治理架構(gòu)交付物所不同,，架構(gòu)實踐原則將被用來明確架構(gòu)實踐的組織,、內(nèi)容、工具和相關(guān)流程。

• 開發(fā)架構(gòu)工作說明書和安全認證,。

• 另外一個需要在此階段被考慮進來的步驟是進行架構(gòu)成熟度評估（請參閱2.4.4.6架構(gòu)成熟度模型部分的描述）,。

1.2 業(yè)務(wù)架構(gòu)階段

此階段的目標在于建立或提煉架構(gòu)實踐的業(yè)務(wù)架構(gòu)，而這需要關(guān)注如下幾個關(guān)鍵領(lǐng)域：

• 架構(gòu)本體論（Architecture Ontology）：定義了各種架構(gòu)的術(shù)語和定義,，用于在組織中建立起關(guān)于這些內(nèi)容的共識,。

• 架構(gòu)流程（Architecture Process）：以架構(gòu)開發(fā)方法為基礎(chǔ)并按照組織的需要和架構(gòu)實踐的愿景來對架構(gòu)開發(fā)方法所進行的定制，并且所需的架構(gòu)治理流程也應(yīng)該被包含到整個架構(gòu)流程之中,。

• 架構(gòu)視角和視圖（Architecture Viewpoints and Views）：列舉出所有架構(gòu)實踐所涉及到的視角和視圖,，而針對這些內(nèi)容的定義工作應(yīng)由此前被識別出來的架構(gòu)實踐干系人來進行指導(dǎo)。

• 架構(gòu)框架（Architecture Framework）：描述了將會由架構(gòu)實踐所產(chǎn)生的各種架構(gòu)交付物以及他們之間的交互,、依賴關(guān)系,，此外還包括了種種用于管理這些交付物的設(shè)計的規(guī)則和指南。那些在之前被定義的架構(gòu)視角和視圖也應(yīng)該被用來指導(dǎo)架構(gòu)框架的定義

• 架構(gòu)問責矩陣（Architecture Accountability Matrix）：定義了架構(gòu)實踐所涉及到的各種角色,，以及為這些角色所分配的關(guān)于架構(gòu)交付物和流程的責任,。

• 架構(gòu)性能指標（Architecture Performance Metrics）：明確和描述了用于與架構(gòu)實踐愿景和目標進行比對和監(jiān)督的各項架構(gòu)實踐性能指標。

• 架構(gòu)治理框架（Architecture Governance Framework）：是一個與之前定義的架構(gòu)流程和架構(gòu)責任矩陣相關(guān)的特定視圖,。

1.3 信息系統(tǒng)架構(gòu)階段（數(shù)據(jù)）

架構(gòu)實踐的數(shù)據(jù)架構(gòu)對組織的企業(yè)連續(xù)體和架構(gòu)資源庫進行了描述和治理,。數(shù)據(jù)架構(gòu)的定義應(yīng)該基于組織所選擇的架構(gòu)框架，并且有時也被引用為架構(gòu)實踐的元模型,。

1.4 信息系統(tǒng)架構(gòu)階段（應(yīng)用）

架構(gòu)實踐的應(yīng)用架構(gòu)定義了用于產(chǎn)生,、維護、發(fā)布,、分發(fā)以及治理架構(gòu)交付物的各種功能,，而這其中一個關(guān)鍵點在于用來建模的各種建模工具組。

1.5 技術(shù)架構(gòu)階段

架構(gòu)實踐的技術(shù)架構(gòu)應(yīng)該對用于支持架構(gòu)實踐的技術(shù)基礎(chǔ)設(shè)施進行定義,。

1.6 機會與解決方案階段

在這樣一個與架構(gòu)實踐建設(shè)規(guī)劃相關(guān)的階段中,，組織需要審慎考慮的重要一點是所需的組織變更，以及達成這一變更的方法,。

1.7 遷移規(guī)劃階段

此階段的關(guān)注點不僅要放到信息系統(tǒng)架構(gòu)組件之上,，還需要將業(yè)務(wù)架構(gòu)包括在內(nèi)，而對于架構(gòu)流程和框架的采用將會對組織中架構(gòu)實踐的整體建設(shè)產(chǎn)生主要的影響,。

1.8 實施治理階段

針對架構(gòu)實踐的業(yè)務(wù)架構(gòu)的實現(xiàn)應(yīng)該是此階段的關(guān)注重點,。將組織中的實踐活動改變?yōu)橐环N更加結(jié)構(gòu)化和有紀律的方法非常具有挑戰(zhàn)性，因而需要通過適當?shù)慕M織變更技術(shù)來達成,。

1.9 架構(gòu)變更管理階段

此階段需要對架構(gòu)實踐中各種架構(gòu)的變更進行管理,，而這些變更通常是在各個架構(gòu)項目的執(zhí)行過程中被觸發(fā)的。一個典型的變更往往會成為對于新架構(gòu)交付物的需求,，并會對架構(gòu)實踐中的所有架構(gòu)領(lǐng)域產(chǎn)生影響,。

1.10 需求管理

了解和管理架構(gòu)實踐的需求是非常關(guān)鍵的,，并且這些需求需要被清晰地描述出來，并與架構(gòu)實踐愿景相一致,。

2. 架構(gòu)治理

簡單來講,，企業(yè)架構(gòu)能力是指企業(yè)對于其內(nèi)各種架構(gòu)的建設(shè)能力，而這里所說的建設(shè)能力不僅指的是企業(yè)中各架構(gòu)的實現(xiàn),，而且還需要保證架構(gòu)的實現(xiàn)是處在一個透明且受控的環(huán)境之中,，從而使架構(gòu)的建設(shè)得以正確進行。架構(gòu)能力中有關(guān)這種保障架構(gòu)建設(shè)和交付的內(nèi)容就是架構(gòu)治理（Architecture Governance）,，而這也是架構(gòu)能力中最為核心的部分,。

無論何種企業(yè)總有其需要進行管理的地方，因而即便是沒有涉及到任何架構(gòu)的企業(yè)也總會有著針對其他方面的治理體系,，這也注定了架構(gòu)治理必定不會獨立并隔絕地存在著,，而應(yīng)該存在于一個層次化的治理結(jié)構(gòu)之中，這對于大型企業(yè)來講尤其重要,。按照所處領(lǐng)域的不同,，TOGAF將這一層次化的治理結(jié)構(gòu)劃分為如下四種，其中的每一種都具有其各自的規(guī)則和流程,，并且可以存在于多個地理區(qū)域?qū)哟沃希òㄈ?、地區(qū)和本地這三種地理區(qū)域種類）：

• 公司治理（Corporate governance）

• 技術(shù)治理（Technology governance）

• IT治理（IT governance）

• 架構(gòu)治理（Architecture governance）

以上這幾種治理體系之間并不是絕對隔離的，不同的治理體系所包含的活動和行為多少都會有所交疊,，但由于其所面對的領(lǐng)域各不相同,，其管理的范疇以及所具備的規(guī)則、流程和活動具有很大的差異性,。由于公司治理,、技術(shù)治理和IT治理的內(nèi)容范疇超過了一個企業(yè)架構(gòu)框架理論內(nèi)容范圍，TOGAF中相關(guān)部分的描述重點還是放在了架構(gòu)治理這一方面,，不過它對治理的共性以及技術(shù)治理和IT治理還是做出了簡要的描述,。

2.1 治理的共性

在進一步介紹架構(gòu)治理之前，我們需要對“治理”這一概念有一個清晰的認識,。這里所說的治理并不像其字面上那樣,，僅僅代表顯式的管控和對于規(guī)則的嚴格遵守，而是更加傾向于為有效且公平的使用各種資源提供指南,，從而確保組織的戰(zhàn)略目標的可持續(xù)發(fā)展。根據(jù)所處領(lǐng)域不同,，在前面提到過治理可以被細分為若干治理層次,，但無論其種類為何，“治理”的最終目標在于確保業(yè)務(wù)得以順利進行,，并且在這些種類不同的治理都遵循著相同的原則,。經(jīng)合組織（OECD：Organization for Economic Co-operation and Development）曾經(jīng)針對這些基礎(chǔ)共通原則做出了如下概括：

• 關(guān)注于各種干系人的權(quán)力,、角色以及針對他們的公平處置。

• 信息披露,、透明度和委員會的責任,。

• 確保組織中良好的戰(zhàn)略指南。

• 確保委員會進行有效管理監(jiān)督,。

• 確保委員會對于公司與相關(guān)干系人之間的問責,。

• 委員會的責任包括：

• 審查和指導(dǎo)戰(zhàn)略。

• 設(shè)置并監(jiān)督管理績效目標的進展,。

除了這些共同原則之外,，TOGAF還概括出了治理的各種共同特性，用以突顯治理作為一個被組織在其內(nèi)以及與其他有關(guān)團體之間所采用的方法的價值和必要性：

• 紀律性（Discipline）：所有牽涉的團體需要承諾遵循由組織建立的各種程序,、流程和權(quán)利結(jié)構(gòu),。

• 透明性（Transparency）：被授權(quán)的組織和各供應(yīng)商應(yīng)該可以對所有實施行動和他們的決策支持進行檢查。

• 獨立性（Independence）：所有流程,、決策制定以及所采用機制的建立應(yīng)最小化或避免潛在的利益沖突,。

• 問責性（Accountability）：所有在組織中被確定的團隊需要被授權(quán)，并且需要為他們的行為負責,。

• 責任性（Responsibility）：每個簽訂契約的團體需要對組織以及他們的干系人采取負責任的行為,。

• 公平性（Fairness）：所有的決策、使用的流程以及針對他們的實現(xiàn)不應(yīng)對任何團體產(chǎn)生不公平的利益,。

2.2 不同治理領(lǐng)域的特性

在前面提到過的四種領(lǐng)域中的治理除了具備上一節(jié)所述的共同原則和特性之外還分別具備各自的特點,。由于公司治理的內(nèi)容范疇超過了一個企業(yè)架構(gòu)框架所應(yīng)覆蓋的范圍，所以在這里并不會進行專門的描述,，而接下來我們將針對其余的三種治理體系,，亦即技術(shù)治理、IT治理和架構(gòu)治理,，分別進行描述,。

2.2.1 技術(shù)治理

技術(shù)治理控制了一個組織如何將技術(shù)應(yīng)用于針對其產(chǎn)品和服務(wù)的研究、開發(fā)和生產(chǎn)之中,。技術(shù)治理與IT治理關(guān)系非常緊密,，而且技術(shù)治理往往會涵蓋IT治理中的各種活動，但技術(shù)治理的內(nèi)容范疇則更為廣闊,。在現(xiàn)代企業(yè)中,，越來越多的組織將注意力的重心逐漸放到無形資產(chǎn)之上，而不是僅僅關(guān)注于有形資產(chǎn)管理,。由于大部分無形資產(chǎn)是信息化或數(shù)據(jù)資產(chǎn),，這正說明現(xiàn)代企業(yè)的業(yè)務(wù)與IT之間的關(guān)系也越來越緊密，因而針對IT的治理（亦即IT治理）也成為技術(shù)治理的一個重要組成部分,。這一針對無形資產(chǎn)逐漸重視的趨勢同時也突顯了企業(yè)的業(yè)務(wù)不僅僅依賴于信息本身,，還依賴于用于產(chǎn)生,、交付和使用這些信息的各種流程、系統(tǒng)和結(jié)構(gòu),。此外,，隨著無形資產(chǎn)價值比重在各個行業(yè)中的不斷攀升，風險管理也需要作為一個重點而加以考慮,，從而使得新的挑戰(zhàn),、威脅和機會能夠得以被理解和緩和。

需要注意的是,，不僅僅是組織的運營和盈利越來越依賴于IT,，組織的聲譽、品牌以及最終他們的價值也都依賴于這些信息和支持技術(shù),。

2.2.2 IT治理

IT治理為IT資源和信息與企業(yè)目標和戰(zhàn)略之間的聯(lián)系提供了框架和結(jié)構(gòu),，并且IT治理為規(guī)劃、采購,、實現(xiàn)和監(jiān)督IT績效指定了各種最佳實踐,，從而確保企業(yè)的IT資產(chǎn)對其業(yè)務(wù)目標的支持。

2.2.3 架構(gòu)治理

架構(gòu)治理是為了在全企業(yè)范圍內(nèi)對企業(yè)架構(gòu)以及其他各種架構(gòu)進行管理和控制而需要借助的各種實踐和方向,，它具有如下幾個方面的特性：

• 實現(xiàn)一個系統(tǒng)來控制所有架構(gòu)組件和活動的創(chuàng)建,，并對它們進行監(jiān)督，從而確保在組織內(nèi)有效地引入,、實現(xiàn)各種架構(gòu),，并保障這些架構(gòu)的順利演進。

• 實現(xiàn)一個系統(tǒng)用于確保各種架構(gòu)對于企業(yè)內(nèi)外的標準和法律法規(guī)的遵守,。

• 建立各種流程,，用于在已達成共識的各因素的約束之下，對上述流程的有效管理進行支持

• 開發(fā)各種實踐,，用于在組織內(nèi)外確保對于一個經(jīng)過清晰定義的干系人團體的問責性,。

在前面有關(guān)企業(yè)架構(gòu)開發(fā)方法的介紹中，我們已經(jīng)在“實施治理”階段見過了“治理”一詞,。這個階段所關(guān)注的是通過各個變更項目來對架構(gòu)進行實現(xiàn),，因而此階段的治理僅僅是關(guān)于架構(gòu)實現(xiàn)這一方面，不過對于架構(gòu)治理來說,，這一實施治理只是一個非常重要的方面,，架構(gòu)治理的范疇要更為廣闊，它涵蓋了針對企業(yè)架構(gòu)以及其他各種架構(gòu)在其開發(fā)和演進過程中所有方面的管理和控制,。作為一個企業(yè)架構(gòu)框架,，TOGAF為支持架構(gòu)治理的實現(xiàn)提供了一個架構(gòu)治理框架（Architecture Goverance Framework），用于幫助企業(yè)明確各種有效的治理流程,，從而使得與架構(gòu)治理相關(guān)聯(lián)的各種業(yè)務(wù)職責得以被鑒別出來,，并能夠?qū)ζ溥M行有效地管理和溝通。

2.3 架構(gòu)治理框架

架構(gòu)治理框架包括兩個部分的內(nèi)容,，其一是用來概括架構(gòu)治理各流程以及相關(guān)內(nèi)容的概念結(jié)構(gòu),，另外一個是TOGAF對于架構(gòu)治理所建議的組織結(jié)構(gòu)。在接下來的內(nèi)容中我們將分別對這兩個方面進行探討,。

2.3.1 概念結(jié)構(gòu)

架構(gòu)治理框架的概念結(jié)構(gòu)包含了架構(gòu)治理中的種種概念,，這其中最為重要的是對一個有效的架構(gòu)治理所應(yīng)具有的各種流程以及與它們相關(guān)的內(nèi)容所進行的定義。這一架構(gòu)治理的概念結(jié)構(gòu)采用了一種內(nèi)容無關(guān)的方式,，將流程,、流程所涉及的內(nèi)容以及背景元素進行了分離，從而使得新的治理材料的引入不會過度地影響到各個治理流程,，同時也保證了這一治理框架的靈活性,。

上圖展示了架構(gòu)治理框架的概念結(jié)構(gòu)，其中涵蓋了這一框架中的各種概念,，而這其中最關(guān)鍵的是與治理流程有關(guān)的各種概念,。治理流程被用來識別、管理,、審計和傳播所有與架構(gòu)管理,、合同和實現(xiàn)相關(guān)的信息，從而確保對所有架構(gòu)制品,、合同,、原則以及運營級別協(xié)議（operational-level agreements）進行持續(xù)地監(jiān)督，并且所做的各項決策也具有了清晰的可審計性,。這些治理流程相關(guān)的概念總結(jié)如下：

• 策略管理與內(nèi)容引入（Policy Management and Take-On）：為了注冊,、驗證、批準,、管理和發(fā)布新的或經(jīng)過更新的內(nèi)容,，所有針對架構(gòu)修訂、合同和支持性信息的引入都需要處在一個正規(guī)流程的治理之下,。這些流程將確保與現(xiàn)存治理內(nèi)容的有序整合,，從而使得所有相關(guān)的團體、文檔,、合同和支持信息得以被管理和審計,。

• 合規(guī)（Compliance）：針對服務(wù)水平協(xié)議（SLAs：Service Level Agreements）、運營水平協(xié)議（OLAs：Operational Level Agreements）,、現(xiàn)行各項標準和法規(guī)需求的合規(guī)性評估需要在一個持續(xù)的基礎(chǔ)上進行,，從而確保針對穩(wěn)定性、一致性和性能的監(jiān)督,。這些評估的進行需要以在治理框架中所定義的各項標準為準繩,。

• 豁免（Dispensation）：當主題域（設(shè)計,、運營、服務(wù)水平或技術(shù)）的內(nèi)容在合規(guī)性評估中被判為不合規(guī)時,，該部分內(nèi)容將可能會被否定,，而此時將會存在如下幾種處理方式：

• 對這些不合規(guī)內(nèi)容進行調(diào)整，從而使其滿足合規(guī)性需求,。

• 申請一份豁免,。當合規(guī)評估未能通過時，豁免就成為了一條用來達成臨時性一致的備選路線,?；砻庵粫嬖谟谝欢螘r間區(qū)間內(nèi)，并在其整個生命周期內(nèi)被強制設(shè)置明確的服務(wù)和運行條件,?；砻獠⒉粫谰糜行В皇潜挥脕碜鳛橐环N在確保服務(wù)水平和運營水平得以滿足的同時附加一定水平的靈活性的機制,?；砻獾臅r限性特征確保了它們是合規(guī)性評估循環(huán)的一個主要觸發(fā)因素。

• 監(jiān)督和匯報（Monitoring and Reporting）：性能管理被用來確保運營和服務(wù)元素的管理是基于一系列經(jīng)過協(xié)定的標準之上,，這包括了監(jiān)督服務(wù)水平和運營水平協(xié)議,、對于調(diào)整的反饋以及針對這些結(jié)果的匯報。

• 業(yè)務(wù)控制（Business Control）：業(yè)務(wù)控制與各個流程相關(guān),，這些流程的引發(fā)被用來確保與組織的業(yè)務(wù)策略相符合,。

• 環(huán)境管理（Environment Management）：明確了各種服務(wù)，這些服務(wù)確保了以資源存儲庫為基礎(chǔ)的環(huán)境對治理框架進行支持是有效且高效,。這包括了針對所有用戶的物理和邏輯資源存儲庫的管理,、訪問、溝通,、培訓(xùn)和評審,。為了形成一個受管的服務(wù)和流程環(huán)境，治理環(huán)境中將會定義一些管理流程,，這些流程包括了用戶管理,、內(nèi)部服務(wù)水平協(xié)議（為了控制這些管理流程本身而定義）以及針對管理信息的匯報

2.3.2 組織結(jié)構(gòu)

在架構(gòu)治理框架的概念結(jié)構(gòu)中，TOGAF以一種內(nèi)容無關(guān)的方式明確了一個有效的治理所涉及的各種概念,，并借此概括了各種架構(gòu)治理流程以及與這些流程相關(guān)聯(lián)的各種內(nèi)容，但如果要確保一個架構(gòu)治理的順利進行,，還需要在企業(yè)中設(shè)立專門負責治理舉措施行的組織結(jié)構(gòu),。在實踐中憑空創(chuàng)建這些用于架構(gòu)治理的組織結(jié)構(gòu)其實是不現(xiàn)實的，企業(yè)應(yīng)該組合現(xiàn)有的各種IT治理流程,、組織結(jié)構(gòu)和能力來對其進行創(chuàng)建,。通常來講，企業(yè)中的治理組織結(jié)構(gòu)可被分為如下幾個層次：

• 全局治理委員會

• 本地治理委員會

• 設(shè)計部門

• 工作組

TOGAF提出了如下圖所示的治理組織結(jié)構(gòu),，各個企業(yè)可以按照各自的需求以此圖所示的組織結(jié)構(gòu)為基礎(chǔ)而進行改造：

如圖所示,，架構(gòu)治理框架的組織結(jié)構(gòu)可以被分為三個重點區(qū)域,，他們分別是：開發(fā)（Develop）,、實現(xiàn)（Implement）和部署（Deploy），它們中的每一個都代表了在架構(gòu)生命周期的每一個階段中各個相關(guān)小組所應(yīng)盡的責任,。尤其是對于開發(fā)區(qū)域來講,，這里的開發(fā)責任、流程和組織結(jié)構(gòu)都與架構(gòu)開發(fā)方法過程有著緊密的關(guān)聯(lián),，而對于實現(xiàn)區(qū)域來講，其所包含的實施責任,、流程和組織結(jié)構(gòu)與架構(gòu)開發(fā)方法的實施治理階段也是密不可分的：

• 在開發(fā)區(qū)域中,，架構(gòu)委員會（Architecture Board）對主架構(gòu)師進行任命，并且通過兩者的合作來對企業(yè)架構(gòu)的設(shè)計和落實進行指導(dǎo),，并最終將企業(yè)架構(gòu)細化成為各個面向具體問題的領(lǐng)域架構(gòu)。

• 在實現(xiàn)區(qū)域中,，受架構(gòu)委員會授權(quán)和委派的項目管理辦公室（Program Management Office）對用于實現(xiàn)各個領(lǐng)域架構(gòu)的實施項目進行管控,，從而保障其順利施行。

• 在部署區(qū)域中,，由于各個架構(gòu)實現(xiàn)項目的實現(xiàn)和部署改變了企業(yè)當前的運營狀態(tài)，因而受管理辦公室委派的服務(wù)管理組織（Service Management Organisation）需要對企業(yè)的各運營系統(tǒng)進行監(jiān)督,，從而發(fā)現(xiàn)新的問題和需求,，并借此啟動新的一輪架構(gòu)開發(fā)循環(huán),。

除了以上這三個核心區(qū)域之外,，我們還應(yīng)注意到企業(yè)連續(xù)體的再次出現(xiàn),。企業(yè)連續(xù)體之所以會在這里出現(xiàn)是因為它是架構(gòu)治理的一個不可或缺的部分，因為它不僅承載了與架構(gòu)相關(guān)的各種內(nèi)容,，也同時存儲了與架構(gòu)治理過程相關(guān)的種種材料。

2.4 架構(gòu)治理實踐導(dǎo)則

在實踐中,，為了實現(xiàn)一個成功的架構(gòu)治理方法，并對架構(gòu)合同進行有效的管理,，企業(yè)需要考慮如下幾個關(guān)鍵因素：

• 與架構(gòu)策略,、程序,、角色,、技能,、組織結(jié)構(gòu)和支持服務(wù)的提交,、采用,、重用,、回報和廢止相關(guān)的各種最佳實踐。

• 用于支持架構(gòu)治理的流程以及達成匯報需求的組織結(jié)構(gòu)及其責任,。

• 對各種工具和流程進行整合,，從而便于在程序上和文化上執(zhí)行各個流程。

• 與架構(gòu)治理流程,、豁免、合規(guī)性審查,、SLAs和OLAs的控制相關(guān)的各種指標。

• 組織內(nèi)外對于所有架構(gòu)治理相關(guān)信息,、服務(wù)和流程在有效性,、效率、保密性,、完整性、可得性,、合規(guī)性和可靠性這些方面的需求,。

除了上面幾項對于架構(gòu)治理成功因素的描述，TOGAF還指出了一個在企業(yè)中獲得接受和成功的架構(gòu)所應(yīng)具備的三個主要的架構(gòu)治理戰(zhàn)略元素：

• 需要在最高管理層的支持下建立一個跨組織的架構(gòu)委員會（Architecture Board,，見2.4.4.3架構(gòu)委員會）來對IT治理策略的實現(xiàn)提供監(jiān)督,。

• 需要建立一套全面的架構(gòu)原則，從而對組織如何通過使用信息技術(shù)來完成自身的任務(wù)而進行指導(dǎo)和支持,。

• 需要采用一種架構(gòu)合規(guī)性策略（見2.4.4.4架構(gòu)合規(guī)性）,，從而通過具體的措施來保證架構(gòu)的合規(guī)性，這包括了項目影響評估,、正式的架構(gòu)合規(guī)性審查流程,，同時也可能包括在產(chǎn)品采購過程中架構(gòu)團體所進行參與。

3. 架構(gòu)委員會

正如前面所說,，一個用來對架構(gòu)治理策略的實現(xiàn)進行監(jiān)督的跨組織的架構(gòu)委員會是架構(gòu)治理策略成功的主要要素之一,。架構(gòu)委員會應(yīng)該能夠代表所有主要干系人的需求，并且通常還需要對整個架構(gòu)的審查及維護活動負有高級行政職責,。通常來講,，架構(gòu)委員會需要對如下目標的達成進行負責：

• 子架構(gòu)之間的一致性。

• 確定可重用組件,。

• 保證企業(yè)架構(gòu)的靈活性：

• 滿足不斷變化的業(yè)務(wù)需求,。

• 盡可能的利用不斷出現(xiàn)的新技術(shù)。

• 嚴格確保架構(gòu)合規(guī)性,。

• 改善組織中架構(gòu)規(guī)程的成熟度水平,。

• 確保采用以架構(gòu)為基礎(chǔ)的開發(fā)規(guī)程。

• 為所有關(guān)于架構(gòu)變更的決策提供基礎(chǔ),。

• 為超出范圍的決策提供升級的能力,。

如果從執(zhí)行的角度來看，架構(gòu)委員會還需要承擔如下責任：

• 有關(guān)架構(gòu)合同的監(jiān)督和控制的所有方面,。

• 定期舉行會議,。

• 確保針對架構(gòu)進行有效并且一致地管理和實現(xiàn)。

• 解析不清楚的地方,，并對各種問題以及已經(jīng)升級了的沖突進行解決,。

• 提供各種建議、指導(dǎo)以及信息,。

• 確保各種架構(gòu)的合規(guī)性,，并在確保與技術(shù)戰(zhàn)略及目標一致的基礎(chǔ)上授予豁免。

• 當相似的豁免被申請并被通過時,，架構(gòu)委員會需要考慮進行策略變更,。

• 確保所有與架構(gòu)合同的實現(xiàn)相關(guān)的信息在可控的條件下被發(fā)布，并可被經(jīng)過授權(quán)的團體所獲得,。

• 對匯報的服務(wù)水平,、成本節(jié)約等方面進行驗證,。

如果從治理的角度來看，架構(gòu)委員會還需要承擔如下責任：

• 產(chǎn)生各種可用的治理材料和活動,。

• 通過共識和被授權(quán)的發(fā)布來為架構(gòu)的正式接受和批準提供一種機制,。

• 為確保架構(gòu)的有效實現(xiàn)而提供一個基本控制機制。

• 在架構(gòu)的實現(xiàn),、包含在企業(yè)架構(gòu)中的架構(gòu)戰(zhàn)略和目標,，以及業(yè)務(wù)的戰(zhàn)略目標之間建立關(guān)聯(lián)，并對其進行維護,。

• 為了通過豁免或策略更新來進行調(diào)整,，架構(gòu)委員會需要明確架構(gòu)與計劃開展的活動之間的差異。

3.1 架構(gòu)委員會的建立

一個架構(gòu)委員會的建立往往受如下事件的觸發(fā)：

• 新CIO的任命,。

• 兼并或收購,。

• 考慮采用一個新的計算形式。

• 認識到IT與業(yè)務(wù)的契合度很差,。

• 渴望通過技術(shù)來達成競爭優(yōu)勢,。

• 一個企業(yè)架構(gòu)方案的創(chuàng)建。

• 重大的業(yè)務(wù)變更或業(yè)務(wù)的快速發(fā)展,。

• 需要復(fù)雜且跨越諸多功能的解決方案,。

在很多公司中，最初的領(lǐng)導(dǎo)級架構(gòu)贊助者通常都是CIO,，然而為了在企業(yè)中獲得廣闊的支持,，一個贊助組織的影響力往往超過某個個人，這樣一個贊助組織在這里被稱為一個架構(gòu)委員會,。架構(gòu)委員會是一個高級領(lǐng)導(dǎo)層組織,，用來為戰(zhàn)略架構(gòu)及其子架構(gòu)的審查和維護進行負責。雖然架構(gòu)委員會是企業(yè)中架構(gòu)的贊助者,，企業(yè)架構(gòu)委員會自己本身也需要獲得企業(yè)高層的贊助和支持，并且這一支持需要貫徹整個規(guī)劃過程,，延伸到針對架構(gòu)項目的維護之中,。

架構(gòu)委員會的常駐人員規(guī)模不宜過大，按照TOGAF的建議,，一個架構(gòu)委員會的常駐人員規(guī)模應(yīng)包含四至五人,，或不超過十人。為了使架構(gòu)委員會隨著事件的推移而一直保持合理的規(guī)模,，并同時確保其在企業(yè)范圍內(nèi)的代表性,，架構(gòu)委員會的成員需要采用輪換制，從而給予各個高級經(jīng)理決策權(quán)和相關(guān)責任,。除此之外,，由于現(xiàn)實中的各種原因這一輪換機制還有其存在的必要性,，例如當有些架構(gòu)委員會成員受時間所限而不能長期承擔其職責時。雖然采用了輪換制,，但為了確保架構(gòu)委員會的決策不會變化無常,，企業(yè)需要主動的采用某種機制來確保其核心理念的穩(wěn)定，例如為成員設(shè)置任期,，并將不同成員的離退時間交錯開來,。

3.2 架構(gòu)委員會的運行

架構(gòu)委員會的運行的核心以及在形式上的表現(xiàn)就是按照清晰的日程安排所進行的架構(gòu)委員會會議，并且這些日程安排需要具有明確的目標,、所涵蓋的內(nèi)容和經(jīng)過定義的行為,。架構(gòu)委員會會議需要為如下幾個方面提供指導(dǎo)：

• 對高質(zhì)量的治理材料和活動的產(chǎn)生進行支持。

• 通過共識和被授權(quán)的發(fā)布來為架構(gòu)的正式接受提供一個機制,。

• 為確保有效的架構(gòu)實現(xiàn)提供一個基本控制機制,。

• 在架構(gòu)的實現(xiàn)、包含在企業(yè)架構(gòu)中的架構(gòu)戰(zhàn)略和目標以及業(yè)務(wù)的戰(zhàn)略目標之間建立關(guān)聯(lián),，并對其進行維護,。

• 為通過豁免或策略更新來與合同進行重新校準而對合同和規(guī)劃活動之間的差異進行明確。

每個會議的參與者在開會前會收到一份日程描述和相關(guān)支持文檔,，他們需要在開會前對這些內(nèi)容進行熟悉,，并且被分配進行某項活動的與會人員還需要報告其執(zhí)行進度。此外,，每個與會人員還必須確認其是否參加架構(gòu)委員會會議,。

由此可見，會議的日程描述是有關(guān)整個會議內(nèi)容的核心,，TOGAF對于其內(nèi)容項目做了如下建議：

• 前期會議紀要：以前的架構(gòu)委員會會議的詳細紀要,。

• 變更請求：此條目之下的內(nèi)容通常包含了針對架構(gòu)、原則等內(nèi)容進行修訂的變更請求,，此外也可以包含對于架構(gòu)合同的業(yè)務(wù)控制（例如,，確保針對某一付費號碼的語音流量（例如天氣預(yù)報）被禁止，以及對于某一特定網(wǎng)站進行訪問的數(shù)據(jù)流量需要被控制）,。任何一個變更請求的設(shè)置需要在制定者的授權(quán)范圍之內(nèi),，并采用在架構(gòu)合同中已經(jīng)定義好的參數(shù)。

• 豁免：豁免被用來作為一個對現(xiàn)存架構(gòu),、合同和原則等方面內(nèi)容進行更改的申請,。豁免只會在一定的時間區(qū)間中以及定義明確的在整個豁免期間需要被貫徹的服務(wù)和運營條件下被認可,。

• 合規(guī)性評估：合規(guī)性的評估是針對服務(wù)水平協(xié)議,、運營水平協(xié)議、成本目標等方面而進行的,。根據(jù)在架構(gòu)治理框架中定義的條件標準,，通過審查后,，這些評估結(jié)果或者被接受亦或者被拒絕，并且架構(gòu)合規(guī)性評估報告還應(yīng)包含所描述的各個細節(jié),。

• 爭議解決：經(jīng)過架構(gòu)合規(guī)性審查和豁免過程而依然未被解決的爭議需要在這里被明確,，從而為下一步的行動提供目標，并且這些內(nèi)容需要被記錄到架構(gòu)合規(guī)性評估和豁免文檔之中,。

• 架構(gòu)戰(zhàn)略和方向文檔：這里所描述的內(nèi)容僅被全局架構(gòu)委員會所制定,，它包含了架構(gòu)的戰(zhàn)略、方向及其優(yōu)先級順序,。

• 行動分配：這是一個關(guān)于前期架構(gòu)委員會會議所分配行動情況的報告,。在此報告中，一個行動跟蹤記錄被用來記錄和保持所有在架構(gòu)委員會會議中被分配的行動的狀態(tài),，其內(nèi)容至少應(yīng)該包含如下幾個方面：

• 參考材料

• 優(yōu)先級

• 行動概述

• 行動所屬者

• 行動詳細描述

• 開始日

• 到期日

• 狀態(tài)

• 類型

• 決議通過之日

• 合同文檔管理：這是為架構(gòu)文檔的后續(xù)發(fā)布而對其進行的有關(guān)更新和改變的正式認可,。

• 其他事項（AOB：Any Other Business）：關(guān)于上述內(nèi)容所沒有覆蓋的問題的描述。這些內(nèi)容也許不會被描述在會議日程之中,，但應(yīng)該在會議開始時被提出,。

• 會議安排：所有會議的時間和內(nèi)容安排應(yīng)被詳細描述，并公之于眾,。

4. 架構(gòu)合規(guī)性

針對架構(gòu)合規(guī)性的審查是架構(gòu)治理戰(zhàn)略的核心環(huán)節(jié),，也是決定其能否成功的重要因素。架構(gòu)合規(guī)性審查是針對各個具體項目與已經(jīng)建立的架構(gòu)標準,、精神以及業(yè)務(wù)目標的相符合情況所進行的審議,，而一個關(guān)于這些審議的正規(guī)流程正是企業(yè)的架構(gòu)合規(guī)性策略的核心內(nèi)容。通過架構(gòu)合規(guī)性審查,，企業(yè)可以達成如下幾點（或部分）目標：

• 首先且最重要的目標是企業(yè)得以盡早在項目架構(gòu)中發(fā)現(xiàn)錯誤,，從而減少在整個生命周期的后期進行更改的風險和成本，而這也意味著整體的項目時間得以縮減,，并且各項業(yè)務(wù)也能夠盡早地獲得架構(gòu)所帶來的底線收益（bottom-line benefit）,。

• 確保將各種最佳實踐應(yīng)用到架構(gòu)工作當中。

• 提供一份關(guān)于架構(gòu)與強制性企業(yè)標準的符合度的概略,。

• 明確標準本身需要進行修改的地方,。

• 明確能夠作為企業(yè)基礎(chǔ)設(shè)施的組成部分，卻在當前只為特定應(yīng)用提供支持的各個服務(wù),。

• 將關(guān)于團隊合作、資源共享以及其他能夠跨越多個架構(gòu)團隊的協(xié)同增效方面的戰(zhàn)略進行文檔化,。

• 充分利用技術(shù)所帶來的先進性,。

• 對項目的技術(shù)準備狀態(tài)進行溝通。

• 確定采購活動的關(guān)鍵標準,。

• 明確重大的架構(gòu)性差距,，并就此與產(chǎn)品和服務(wù)供應(yīng)商進行溝通,。

除了上面這些與質(zhì)量保證有關(guān)的目標之外，架構(gòu)合規(guī)性審查的進行還在特定情況下具有著傾向于以政治為導(dǎo)向的動機：

• 由于具有決策能力的人通常會參與到審查當中,，并能夠從對業(yè)務(wù)最優(yōu)的角度進行決策指導(dǎo),，而不僅僅注重技術(shù)的優(yōu)劣，這使得架構(gòu)合規(guī)性審查成為了一種在各種架構(gòu)選擇之間進行選擇的好方法,。

• 架構(gòu)合規(guī)性審查的輸出是為數(shù)不多的用來匯報給CIO,，并輔助其決策制定的可測性交付物之一。

• 架構(gòu)審查可以作為一條架構(gòu)組織借以參與到開發(fā)項目之中的途徑,，否則各個開發(fā)項目的進行將會與企業(yè)的架構(gòu)功能相脫節(jié),。

• 架構(gòu)審查可以為企業(yè)業(yè)務(wù)團體給出快速且正面的支持：

• 企業(yè)架構(gòu)以及架構(gòu)合規(guī)性可以幫助確保各IT項目與業(yè)務(wù)目標的符合度。

• 架構(gòu)師有時可以被視為深入到技術(shù)基礎(chǔ)設(shè)施之中而遠離核心業(yè)務(wù)之外,。

• 由于架構(gòu)合規(guī)性審查傾向于將主要注意力放到一個系統(tǒng)的關(guān)鍵風險區(qū)域內(nèi),，所以此審查經(jīng)常可以為系統(tǒng)所有者凸顯各種主要的風險,。

4.1 架構(gòu)合規(guī)性審查發(fā)生時點

架構(gòu)合規(guī)性審查并不是一個一次性的活動,，它應(yīng)該在適當?shù)捻椖坷锍瘫蝽椖可芷诘母鱾€檢查點進行，并且其具體的審查要點應(yīng)包括：

• 架構(gòu)開發(fā)自身的合規(guī)性,，亦即對于架構(gòu)開發(fā)方法的符合度,。

• 架構(gòu)實現(xiàn)的合規(guī)性，亦即各個實施項目與架構(gòu)的符合度,。

針對架構(gòu)項目審查的時點應(yīng)包括：

• 項目啟動

• 初步設(shè)計

• 主要設(shè)計變更時

• 其它特定時刻

4.2 架構(gòu)合規(guī)性審查進行的情景概括

就架構(gòu)合規(guī)性審查的進行,、治理以及參與的人員來說，TOGAF針對此審查的進行總結(jié)出了如下三種情景：

• 對于小規(guī)模的項目,，這一審查流程可以只是由項目架構(gòu)師或項目組長制定一系列問題（可以通過對后面將要列出的問題清單進行定制而獲得）,，再將答案收錄到某種形式的報告中，并對其進行管理,。進行這樣一個流程的需求通常要被包含在整個企業(yè)范圍的IT治理策略中,。

• 如果處于審查之下的項目并沒有一個全職的架構(gòu)師的參與（例如，一個應(yīng)用級的項目）,，那么就需要借助于企業(yè)中具有架構(gòu)功能的組織的專業(yè)性架構(gòu)能力了,。這種情況下，企業(yè)架構(gòu)功能組織將負責對這一審查進行組織,、領(lǐng)導(dǎo)和執(zhí)行,，并保證各業(yè)務(wù)領(lǐng)域?qū)＜业膮⑴c。需要注意的是,，這樣的審查并不是要取代架構(gòu)師對于項目的參與,，而是對架構(gòu)師參與的一個有效的補充。此外，在這種情景下也許還需要引入一套數(shù)據(jù)庫系統(tǒng),，從而對在大型系統(tǒng)或系統(tǒng)組的分析中所產(chǎn)生的大量數(shù)據(jù)進行管理,。

• 對于大多數(shù)情況來說，尤其是對于大型項目來說,，組織中具有架構(gòu)功能的組織可能已經(jīng)深入地參與到（或領(lǐng)導(dǎo)）處于合規(guī)性審查之下的開發(fā)項目之中,。在這種情況下，這一審查應(yīng)該由主架構(gòu)師來進行協(xié)調(diào),。主架構(gòu)師需要組織一個包含業(yè)務(wù)和技術(shù)領(lǐng)域?qū)＜业膱F隊,，并將合規(guī)性審查中各個問題的答案編織成某種形式的報告。合規(guī)性審查中各個問題的制定需要由各個業(yè)務(wù)和技術(shù)領(lǐng)域?qū)＜乙黄饋韴?zhí)行,。除了由主架構(gòu)師領(lǐng)導(dǎo)之外,，架構(gòu)合規(guī)性審查也可以由架構(gòu)委員會的代表或其他在全企業(yè)范圍內(nèi)具有相似能力的組織來領(lǐng)導(dǎo)。

在上面這些情景中,，架構(gòu)合規(guī)性審查的進行都需要高級管理層的支持,，并通常被作為企業(yè)架構(gòu)治理策略的一個重要部分來加以強制。一般來講,，企業(yè)的CIO或企業(yè)架構(gòu)委員會將對所有主要項目進行強制性審查,，并在之后形成年度審查的慣例。

4.3 架構(gòu)合規(guī)性審查流程

4.3.1 流程

TOGAF對于架構(gòu)合規(guī)性審查的流程做了如下圖所示的總結(jié)：

4.3.2 參與流程的各角色及職責

4.4 架構(gòu)合規(guī)性審查問題參考列表

架構(gòu)合規(guī)性審查是針對各個項目與架構(gòu)的符合度而進行的審議活動,，而這一活動的具體實施需要圍繞著一份問題清單來進行的。為了幫助這一份問題清單的制定,，TOGAF根據(jù)架構(gòu)的各個方面提出了一系列備選問題,，而負責問題清單開發(fā)的領(lǐng)域?qū)＜铱梢愿鶕?jù)所審查架構(gòu)的特性在這些備選問題中進行選擇和定制。需要注意的是,，這里所列出的問題并不適用于針對業(yè)務(wù)領(lǐng)域架構(gòu)或跨越多個項目的架構(gòu)的審查,。針對這些架構(gòu)的審查的流程雖然相似，但是其所使用的問題清單的類別和內(nèi)容將會有所不同,。（有些問題并不是以提問的形式出現(xiàn),，而是通過簡短的描述來對引發(fā)問題的緣由，以及答案中所應(yīng)包含的內(nèi)容方向進行了闡述,，從而使得相關(guān)人員可以按照各自情況編制出合適的問題）

4.4.1 硬件和操作系統(tǒng)問題清單

• 項目生命周期方法是什么,？

• 項目目前處在生命周期的哪個階段,？

• 已經(jīng)被明確的或被用作分析的，在項目中用來對網(wǎng)絡(luò),、服務(wù)器以及終端設(shè)備的硬件和操作系統(tǒng)進行評估的關(guān)鍵問題是什么？

• 將要參與到大量和/或高頻率數(shù)據(jù)傳輸中去的系統(tǒng)能力是什么,？

• 系統(tǒng)設(shè)計是如何影響或涉及到終端用戶設(shè)備的,？

• 所進行的使用、數(shù)據(jù)存儲和處理的數(shù)量及分布（地區(qū)性和全局性）是什么,？

• 通過對比數(shù)據(jù),、應(yīng)用服務(wù)等方面的相似性，應(yīng)用與項目的關(guān)聯(lián)有哪些,？并且數(shù)據(jù)與項目的關(guān)聯(lián)程度為何,？

• 在系統(tǒng)關(guān)鍵元素的功能性設(shè)計之前就已經(jīng)做出的關(guān)于硬件和操作系統(tǒng)的選擇是什么？

• 是否關(guān)于硬件和操作系統(tǒng)的決策制定超出了項目的控制,？

• 項目對于那些決策的理由有什么樣的認識,？

• 當系統(tǒng)設(shè)計成型時，項目是如何影響那些決策的,？

• 是否選擇了非標準化的內(nèi)容,？

• 不使用公司標準的關(guān)鍵業(yè)務(wù)和技術(shù)需求是什么？

• 是否被業(yè)務(wù)案例所支持,？

• 在業(yè)務(wù)案例中的假設(shè)是否已被審查,？

• 用于評估硬件和操作系統(tǒng)的全生命周期成本的流程是什么？

• 公司財務(wù)管理是如何被引入到生命周期成本評估中去的,？

• 是否進行了供應(yīng)商的財務(wù)分析,？

• 是否對供應(yīng)商提出了承諾？

• 是否堅信需求僅被一個供應(yīng)商所滿足,？

4.4.2 軟件服務(wù)和中間件問題清單

• 描述錯誤條件是如何在應(yīng)用組件之間被定義,、產(chǎn)生和傳播的。

• 描述在各個應(yīng)用模塊中關(guān)于方法定義和排列的通用模式,。

• 描述在各個應(yīng)用模塊中關(guān)于方法參數(shù)定義和排列的通用模式,。

• 描述用來最小化服務(wù)器和客戶端之間調(diào)用次數(shù)的方法，這對于在進程間進行具有復(fù)雜數(shù)據(jù)結(jié)構(gòu)的調(diào)用尤其重要,。

• 描述在主要系統(tǒng)組件之間進行傳遞的主要數(shù)據(jù)結(jié)構(gòu),。

• 描述在主要系統(tǒng)組件之間進行通信所采用的協(xié)議。

• 描述在不同系統(tǒng)組件之間所使用的編組（marshaling）技術(shù),，并針對所使用的特定編組安排進行描述,。

• 描述系統(tǒng)在多大程度上設(shè)計有狀態(tài)（stateful）和無狀態(tài)（stateless）組件？

• 針對有狀態(tài)和無狀態(tài)組件來描述如何以及何時進行狀態(tài)保存,。

• 相比于對象池中對象的重用,，描述在什么范圍內(nèi)對對象進行創(chuàng)建,、使用和銷毀。

• 描述系統(tǒng)依賴于線程或臨界區(qū)代碼的程度,。

• 描述在系統(tǒng)內(nèi)部用來記錄方法,、方法參數(shù)和方法功能的方式和內(nèi)部文檔。

• 描述代碼審查流程,。

• 描述用來測試系統(tǒng)組件的單元測試,。

• 描述包含在各種系統(tǒng)模塊中的前置和后置條件測試。

• 描述包含在系統(tǒng)中的斷言測試,。

• 各個組件是否具備了它需要支持的所有接口,？亦或某些關(guān)于何種類型組件采用語言綁定或其它形式的編組（marshaling）方式來調(diào)用其它組件的假設(shè)是否被制定,？

• 描述在何種程度上對跨平臺的大字節(jié)或小字節(jié)數(shù)據(jù)格式問題進行了處理,。

• 描述在不同平臺上是否對數(shù)字和字符串的處理采用不同的方式,。

• 描述是否軟件需要對浮點舍入誤差進行檢查。

• 描述時間和數(shù)據(jù)是如何應(yīng)對千年蟲問題的,。

• 描述何種工具和流程被用來就內(nèi)存泄漏,、可達性（reachability）或一般魯棒性（general robustness）來對系統(tǒng)進行測試的。

• 描述系統(tǒng)服務(wù)軟件的分層情況,。描述主要系統(tǒng)組件之間的連接的一般數(shù)量,。是否系統(tǒng)大量采用點對點方式進行聯(lián)系，還是主要通過消息路由的方式,？

• 描述系統(tǒng)組件松耦合或緊耦合的程度,。

• 就共享庫、通信協(xié)議支持,、負載平衡,、事務(wù)處理、系統(tǒng)監(jiān)控,、命名服務(wù)或其它基礎(chǔ)服務(wù)來講,，系統(tǒng)對于底層基礎(chǔ)設(shè)施的需求是什么？

• 描述系統(tǒng)和系統(tǒng)組件是如何通過設(shè)計來達成重構(gòu)性的,？

• 描述相對于采用點對點的通信結(jié)構(gòu),，系統(tǒng)或系統(tǒng)組件是如何依賴于通用消息基礎(chǔ)設(shè)施的？

4.4.3 應(yīng)用問題清單

• 基礎(chǔ)設(shè)施應(yīng)用

• 是否需要一些企業(yè)標準基礎(chǔ)設(shè)施應(yīng)用產(chǎn)品并沒有提供的能力,？例如：

• 團隊協(xié)作方面：

• 應(yīng)用共享

• 視頻會議

• 日程安排

• 電子郵件

• 工作流管理

• 出版/文字處理應(yīng)用

• HTML

• SGML和XML

• 可移植的文檔格式

• 文檔處理（專有格式）

• 桌面發(fā)布系統(tǒng)（Desktop publishing）

• 電子表格應(yīng)用

• 展示應(yīng)用

• 業(yè)務(wù)展示

• 圖片

• 動畫

• 視頻

• 音響

• 基于計算機的培訓(xùn)系統(tǒng)（CBT：Computer-Based Trainning）

• Web瀏覽器

• 數(shù)據(jù)管理應(yīng)用

• 數(shù)據(jù)庫接口

• 文檔管理

• 產(chǎn)品數(shù)據(jù)管理

• 數(shù)據(jù)倉庫/集市

• 項目管理應(yīng)用

• 項目管理

• 項目可見度（Program visibility）管理

• 描述標準產(chǎn)品所不能滿足的對于企業(yè)基礎(chǔ)設(shè)施應(yīng)用能力的業(yè)務(wù)需求,。

• 業(yè)務(wù)應(yīng)用

• 是否用于支持一條或多條業(yè)務(wù)線應(yīng)用的標準產(chǎn)品提供了所需要的能力？例如：

• 業(yè)務(wù)采購應(yīng)用：

• 銷售和市場

• 工程應(yīng)用

• 計算機輔助設(shè)計

• 計算機輔助工程

• 數(shù)學和統(tǒng)計分析

• 供應(yīng)管理應(yīng)用

• 供應(yīng)鏈管理

• 客戶關(guān)系管理

• 生產(chǎn)應(yīng)用

• 企業(yè)資源規(guī)劃（ERP）應(yīng)用

• 制造執(zhí)行系統(tǒng)

• 制造質(zhì)量

• 制造工藝工程

• 機器和自適應(yīng)控制

• 客戶支持應(yīng)用

• 航空物流支持

• 維護工程

• 財務(wù)應(yīng)用

• 人員應(yīng)用

• 設(shè)施應(yīng)用

• 信息系統(tǒng)應(yīng)用

• 系統(tǒng)工程

• 軟件工程

• Web開發(fā)工具

• 集成式開發(fā)環(huán)境

• 生命周期類別

• 功能類別

• 專業(yè)類別

• 計算機輔助生產(chǎn)

• 電子商務(wù)支持

• 業(yè)務(wù)流程工程

• 統(tǒng)計質(zhì)量控制

• 描述標準產(chǎn)品所不能滿足的對于業(yè)務(wù)應(yīng)用能力的流程需求,。

• 應(yīng)用集成方法

• 架構(gòu)的目標集成點（業(yè)務(wù)流程/活動,、應(yīng)用、數(shù)據(jù),、計算環(huán)境）是什么,？

• 所采用的應(yīng)用集成技術(shù)是什么（通用數(shù)據(jù)對象,、標準數(shù)據(jù)定義（STEP、XML等）,、通用用戶界面展示）,？

4.4.4 信息管理問題清單

• 數(shù)據(jù)價值方面

• 用于對數(shù)據(jù)的管理和使用進行標準化的流程是什么？

• 用于支持數(shù)據(jù)錄入和驗證的業(yè)務(wù)流程是什么,？數(shù)據(jù)的用處為何,？

• 與數(shù)據(jù)的創(chuàng)建和修改相關(guān)的業(yè)務(wù)行為是什么？

• 與數(shù)據(jù)的刪除相關(guān)的業(yè)務(wù)行為是什么,？是否這些數(shù)據(jù)被認為是業(yè)務(wù)記錄的一部分？

• 業(yè)務(wù)用戶對于數(shù)據(jù)質(zhì)量的需求是什么,？

• 當前用于支持數(shù)據(jù)引用完整性和/或規(guī)范化的流程是什么,？

• 數(shù)據(jù)定義方面

• 所購買的應(yīng)用的數(shù)據(jù)模型、數(shù)據(jù)定義,、結(jié)構(gòu)以及主機選項（hosting options）都是什么,？

• 用于定義和維護數(shù)據(jù)需求規(guī)則以及對信息系統(tǒng)中所有組件所進行的設(shè)計是什么？

• 何種共享資源庫被用來保存數(shù)據(jù)模型內(nèi)容和數(shù)據(jù)的支持性信息,？

• 用于設(shè)計數(shù)據(jù)庫的物理數(shù)據(jù)模型定義是什么,？

• 所選擇的軟件開發(fā)和數(shù)據(jù)管理工具是什么？

• 已明確的對如下事項進行負責的數(shù)據(jù)擁有者都有哪些,？：

• 通用數(shù)據(jù)定義

• 計劃外冗余的消除

• 穩(wěn)定可靠性的提供

• 信息的及時性和準確性

• 防止數(shù)據(jù)被濫用和破壞

• 安全/保護方面

• 為了防止數(shù)據(jù)被無意及未授權(quán)的更改,、泄露和散布，對于數(shù)據(jù)實體及其屬性的訪問應(yīng)該制定什么樣的規(guī)則,？

• 用于保護數(shù)據(jù)免于被外界進行未授權(quán)訪問的數(shù)據(jù)保護機制是什么,？

• 采用何種機制來控制企業(yè)內(nèi)部臨時駐留性外部資源對于數(shù)據(jù)的訪問？

• 托管,、數(shù)據(jù)類型和共享方面

• 用于將單一授權(quán)數(shù)據(jù)作為一個邏輯數(shù)據(jù)源進行管理的規(guī)程為何,？這一邏輯數(shù)據(jù)源為貯存在不同平臺上的物理數(shù)據(jù)定義了更新規(guī)則。

• 用于對復(fù)制數(shù)據(jù)進行管理的規(guī)程為何,？這些復(fù)制數(shù)據(jù)來源于運行中的單一授權(quán)數(shù)據(jù),。

• 已經(jīng)明確的用于儲存高級或中級重要度的運行數(shù)據(jù)的層級數(shù)據(jù)服務(wù)器為何？

• 已經(jīng)明確的用于儲存C類型運行數(shù)據(jù)的層級數(shù)據(jù)服務(wù)器為何,？

• 已經(jīng)明確的用于儲存包含在一個數(shù)據(jù)倉庫中的決策支持數(shù)據(jù)的層級數(shù)據(jù)服務(wù)器為何,？

• 所實現(xiàn)的數(shù)據(jù)庫管理系統(tǒng)為何？

• 通用服務(wù)

• 標準化的分布式數(shù)據(jù)管理服務(wù)（例如,，數(shù)據(jù)驗證,、一致性檢查、數(shù)據(jù)編輯,、加密以及事務(wù)管理）為何,？這些服務(wù)存在于何處,？

• 訪問方法

• 對于標準文件、消息和數(shù)據(jù)管理的數(shù)據(jù)訪問需求為何,？

• 對于決策支持數(shù)據(jù)的訪問需求為何,？

• 數(shù)據(jù)存儲庫和應(yīng)用邏輯位置為何？

• 采用何種查詢語言,？

4.4.5 安全方面問題清單

• 安全意識：

• 是否已確保正在使用的公司安全策略和導(dǎo)則是最新的版本,？

• 是否已經(jīng)閱讀了最新版本的公司安全策略和導(dǎo)則？

• 是否了解所有相關(guān)的計算安全合規(guī)性和風險接受流程,？

• 識別/認證：對于一個用戶是如何被應(yīng)用所識別,，以及此應(yīng)用是如何驗證該用戶確為其所聲稱那個人的過程流進行圖形表述。對這一圖形表述提供支持性文檔,，從而對用戶界面和應(yīng)用/數(shù)據(jù)庫服務(wù)器之間的交互流程進行解釋,。是否符合公司關(guān)于賬戶、密碼等方面的策略,？

• 授權(quán)：提供一個流程來展示一個用戶如何申請訪問某個應(yīng)用,，從而指明了相關(guān)的安全控制以及責任的劃分。這一流程應(yīng)該包括：

• 申請是如何被適當?shù)臄?shù)據(jù)擁有者所批準,？

• 用戶是如何被歸入到適當?shù)脑L問級別分類設(shè)定檔中的,？

• 用戶賬號、密碼和訪問是如何建立的,，并如何提供給用戶的,？

• 如何通知用戶對于應(yīng)用的使用責任？

• 如何變更密碼,？

• 應(yīng)向誰請求幫助,？

• 其他。

• 訪問控制：記錄用戶的賬戶,、密碼和訪問配置是如何被增加,、更改、刪除和記錄的,？這一文檔還應(yīng)該包括對這些流程進行負責的人員,。

• 敏感信息保護：提供確定了需要額外保護的敏感數(shù)據(jù)的文檔。明確對這些數(shù)據(jù)進行負責的數(shù)據(jù)擁有者,，以及用來保護數(shù)據(jù)存儲,、傳輸、打印和分發(fā)的流程,。這包括：

• 如何對密碼文件或字段進行保護,？

• 如何防止用戶查看他人的敏感信息？

• 與外部團體之間是否具有著信息保護的協(xié)議,？如果是,，具體責任和義務(wù)為何,？

• 審計跟蹤和審計日志：

• 明確并記錄被多個用戶或應(yīng)用支持所需要的組賬戶。

• 明確并記錄個人賬戶和/或具有超級用戶權(quán)限的角色,。

• 這些權(quán)限為何,？

• 何人可以訪問這些賬戶？

• 如何對這些賬戶的訪問進行控制和跟蹤,，以及如何對其進行日志記錄,？

• 如何處理密碼的變更和分發(fā)？

• 明確審計日志：

• 何人可以讀取審計日志,？

• 何人可以修改審計日志,？

• 何人可以刪除審計日志？

• 如何保護和存儲審計日志,？

• 用戶賬戶在審計日志中是否記錄不清,？

• 外部訪問注意事項：

• 是否應(yīng)用只是內(nèi)部使用？

• 如果不是內(nèi)部使用,，那么是否符合公司的外部訪問需求？

4.4.6 系統(tǒng)管理問題清單

• 必須被分發(fā)出去的軟件更新的頻率為何,？

• 采用何種工具進行軟件分發(fā),？

• 是否在產(chǎn)品中允許使用多個軟件和/或數(shù)據(jù)版本？

• 用戶數(shù)據(jù)的備份頻率以及期望的回復(fù)時間為何,？

• 如何對用戶的賬戶進行創(chuàng)建和管理,？

• 系統(tǒng)授權(quán)的管理策略為何？

• 需要采用何種通用系統(tǒng)管理工具,？

• 需要采用何種特定的服務(wù)管理工具,？

• 如何接受和發(fā)送服務(wù)調(diào)用？

• 描述如何卸載系統(tǒng),。

• 描述用于檢查系統(tǒng)是否被正確安裝的流程或工具,。

• 描述用于監(jiān)督系統(tǒng)健康狀況和性能的工具或儀器。

• 描述用來確定系統(tǒng)被安裝在何處的工具或流程,。

• 描述用于捕捉系統(tǒng)歷史（特別是在一次意外發(fā)生之后）的審計日志的格式,。

• 描述系統(tǒng)將其錯誤消息發(fā)送給服務(wù)人員的能力。

4.4.7 系統(tǒng)工程/整體架構(gòu)問題清單

• 一般性問題

• 需要整合進來的其他應(yīng)用和/或系統(tǒng)為何,？

• 描述集成度水平和戰(zhàn)略,。

• 用戶群的地理分布為何？

• 系統(tǒng)對于其他企業(yè)內(nèi)外用戶團體的戰(zhàn)略重要性為何,？

• 需要什么樣的計算資源來為企業(yè)內(nèi)的用戶,、處于企業(yè)外并使用企業(yè)計算資產(chǎn)的用戶，以及處于企業(yè)外并使用他們自有資產(chǎn)的用戶提供系統(tǒng)服務(wù),？

• 處于本地交付環(huán)境之外的用戶如何訪問企業(yè)的應(yīng)用和數(shù)據(jù),？

• 當前應(yīng)用的平均壽命為何,？

• 描述用于適應(yīng)來源于用戶群、存儲的數(shù)據(jù)以及交付系統(tǒng)技術(shù)的變化的設(shè)計,。

• 用戶群的規(guī)模以及他們的期望性能水平為何,？

• 采用何種性能和壓力測試技術(shù)？

• 軟件和數(shù)據(jù)組件的整體組織方式為何,？

• 整體的服務(wù)和系統(tǒng)配置為何,？

• 軟件與數(shù)據(jù)是如何被配置和映射到服務(wù)及系統(tǒng)配置之上的？

• 此系統(tǒng)需要何種專門的軟硬件技術(shù),？

• 描述每個版本的軟件是如何隨著時間的推移而被重制和重新部署的,？

• 描述當前的用戶群，以及在之后的三到五年中對其變化的預(yù)期,。

• 描述當前的用戶群地理分布,，以及在之后的三到五年中對其變化的預(yù)期。

• 描述在當前或未來需要通過移動或離線方式來對應(yīng)用進行使用的用戶數(shù)量,。

• 描述應(yīng)用的通常行為,、其主要組件以及主要的數(shù)據(jù)流。

• 描述包含在應(yīng)用中并用于監(jiān)督其健康和性能狀況的儀器,。

• 描述系統(tǒng)的業(yè)務(wù)緣由,。

• 從初始開發(fā)成本對比長期維護成本的角度出發(fā)，描述選擇系統(tǒng)開發(fā)語言的理由,。

• 描述用于產(chǎn)生系統(tǒng)架構(gòu)及其產(chǎn)品選擇階段的系統(tǒng)分析流程,。

• 除了原來的客戶之外還有誰會通過對此系統(tǒng)的使用而獲益？

• 通過瀏覽模式和更新模式來使用此系統(tǒng)的用戶比例為何,？

• 事務(wù)性的申請數(shù)量通常為多少,？

• 是否需要嚴格保障的數(shù)據(jù)傳輸或更新？系統(tǒng)是否容錯,？

• 系統(tǒng)的正常工作時間需求為何,？

• 描述系統(tǒng)架構(gòu)符合或不符合標準的地方。

• 描述運用在項目中的項目規(guī)劃和分析方法,。

• 處理器/服務(wù)器/客戶端方面

• 描述客戶/服務(wù)器應(yīng)用架構(gòu),。

• 通過標注圖示來闡述執(zhí)行應(yīng)用功能的地方。

• 客戶端方面

• 除了展示之外用戶設(shè)備是否還具有其他功能,？

• 描繪數(shù)據(jù)和流程所提供的幫助功能,。

• 描述“從屏到屏”的導(dǎo)航技術(shù)。

• 描述用戶如何在此應(yīng)用與其他應(yīng)用之間進行導(dǎo)航,。

• 如何從用戶設(shè)備上對此應(yīng)用以及其他應(yīng)用進行啟動,？

• 是否具有應(yīng)用之間的數(shù)據(jù)和流程共享能力？如果是，描繪所共享的內(nèi)容,，以及采用何種技術(shù)來實現(xiàn)共享,。

• 描述傳輸?shù)娇蛻舳松系臄?shù)據(jù)量。

• 對于支持應(yīng)用的本地緩存數(shù)據(jù)的額外需求是什么,？

• 對于支持應(yīng)用的本地軟件存儲/內(nèi)存的額外需求是什么,？

• 是否存在由其他應(yīng)用需求或會對用戶產(chǎn)生影響的情況而導(dǎo)致的軟硬件沖突或容量限制？

• 描述當前應(yīng)用與其他現(xiàn)存應(yīng)用之間展示層的感觀效果的對比情況,。

• 描述客戶端在多大程度上支持異步和/或同步通信,。

• 描述系統(tǒng)的展示層是如何與其他計算或數(shù)據(jù)傳輸層相分離的。

• 應(yīng)用服務(wù)器方面

• 展示層和應(yīng)用層是否可以運行在不同的處理器之上,？

• 應(yīng)用層和數(shù)據(jù)訪問層是否可以運行在不同的處理器之上,？

• 是否此應(yīng)用可以被放置到一個應(yīng)用服務(wù)器之上，并獨立于其他所有應(yīng)用,？如不可以,，則需要解釋這些應(yīng)用之間的依賴關(guān)系。

• 是否可以比較容易地添加額外的平行應(yīng)用服務(wù)器,？如果可以,，負載平衡機制為何？

• 是否應(yīng)用的資源需求被測量過了,，且其值為何,？如果已被測量，那么是否規(guī)劃的服務(wù)器容量已在應(yīng)用和總體級別上被確認了,？

• 數(shù)據(jù)服務(wù)器方面

• 是否存在其他應(yīng)用必須與當前應(yīng)用共享數(shù)據(jù)服務(wù)器,？如果是,，則需要對這些應(yīng)用進行明確,，并描述其數(shù)據(jù)和數(shù)據(jù)訪問需求。

• 是否應(yīng)用的資源需求被測量過了,，且其值為何,？如果已被測量，那么是否規(guī)劃的服務(wù)器容量已在應(yīng)用和總體級別上被確認了,？

• 商用現(xiàn)成品（COTS）方面

• 廠商是否穩(wěn)定,？

• 當廠商消亡時企業(yè)是否會收到產(chǎn)品源代碼？

• 是否軟件按照企業(yè)的用途而進行了配置,？

• 是否存在特有的架構(gòu)和設(shè)計方面的數(shù)據(jù)或流程,，從而阻礙了針對軟件的使用？

• 是否此軟件在當前是可得的,？

• 是否廠商使用或闡明的規(guī)模/可用性/服務(wù)水平與企業(yè)的需求相類似,？

• 描述廠商過往的財務(wù)和市場份額歷史。

4.4.8 系統(tǒng)工程/方法與工具問題清單

• 是否具有對當前業(yè)務(wù)操作方法的評定指標,？

• 系統(tǒng)擁有者是否已經(jīng)創(chuàng)建了用于指導(dǎo)當前項目的評估標準,？如果有,，則對如何使用這些評估標準進行描述。

• 是否對于現(xiàn)存架構(gòu)的研究已經(jīng)完成,，從而使得當前的工作成果能夠得以被充分利用,？描述在這一研究中所使用的發(fā)現(xiàn)和認識方法。是否現(xiàn)存的這些架構(gòu)需要被整合,？如果是,，解釋將會采用的方法。

• 描述將會應(yīng)用到項目中的方法：

• 用于定義業(yè)務(wù)戰(zhàn)略的方法,。

• 用于定義需要改善的領(lǐng)域的方法,。

• 用于定義基線和目標業(yè)務(wù)流程的方法。

• 用于定義過渡流程的方法,。

• 用于管理項目的方法,。

• 用于團隊溝通的方法。

• 用于知識管理,、變更管理和配置管理的方法,。

• 用于軟件開發(fā)的方法。

• 用于引用標準和方向說明的方法,。

• 用于交付物的質(zhì)量保證的方法,。

• 用于設(shè)計審查和交付驗收的方法。

• 用于達成指標的方法,。

• 是否各個方法已被記錄,，并被分發(fā)給了每個團隊成員？

• 團隊成員在多大程度上熟悉這些方法,？

• 采用何種流程來確保方法執(zhí)行的符合性,？

• 描繪當前所采用的用于支持方法使用的基礎(chǔ)設(shè)施。

• 如何提供咨詢和故障排除,？

• 如何協(xié)調(diào)安排培訓(xùn),？

• 如何合并和關(guān)聯(lián)各種變更和改進？

• 如何獲取經(jīng)驗教訓(xùn),，并對其進行溝通,？

• 關(guān)于項目所采用的工具為何？（指定版本和平臺）,。團隊成員對這些工具的熟悉度為何,？

• 描繪當前所采用的用于支持此工具使用的基礎(chǔ)設(shè)施。

• 如何提供咨詢和故障排除,？

• 如何協(xié)調(diào)安排培訓(xùn),？

• 如何合并和關(guān)聯(lián)各種變更和改進？

• 如何獲取經(jīng)驗教訓(xùn)，并對其進行溝通,？

• 描述項目如何促進對其交付物及所交付內(nèi)容的重用,。

• 在項目實現(xiàn)后此架構(gòu)設(shè)計是否還會存續(xù)？描述用來將變更合并入此架構(gòu)設(shè)計的方法,。

• 當前流程是否被定義,？

• 是否各種問題已經(jīng)被記錄和評定，并與當前流程關(guān)聯(lián)起來,？如果沒有,，那又如何得知已經(jīng)出現(xiàn)問題的地方正在被修正？

• 是否現(xiàn)存或規(guī)劃的流程改善活動已被明確,，并與當前流程關(guān)聯(lián)起來,？如果沒有，那又如何知道此活動與其他工作說明書中的內(nèi)容不會發(fā)生沖突或相互冗余,？

• 當前是否存在各種評估指標,？當前是否存在預(yù)測指標？如果沒有,，那又如何得知獲得了改善,？

• 采用何種流程來收集、評估和匯報各種指標,？

• 新的設(shè)計對于現(xiàn)存業(yè)務(wù)流程,、組織結(jié)構(gòu)和信息系統(tǒng)有什么樣的影響？是否這些影響已經(jīng)被記錄到文檔之中,，并與其他干系人進行共享,？

4.5 架構(gòu)合規(guī)性審查實踐導(dǎo)則

4.5.1 裁剪和定制問題清單導(dǎo)則

• 關(guān)注于：

• 高風險區(qū)域。

• 預(yù)期的（突發(fā)的）差異,。

• 對于清單中的每條問題,，需要理解：

• 問題本身的含義。

• 問題背后的原則,。

• 在回應(yīng)中需要尋找什么樣的內(nèi)容,。

• 尋求領(lǐng)域?qū)＜业囊庖姟?/p>

• 根據(jù)自身需要對清單中的問題進行修補,。

• 時刻牢記需要架構(gòu)委員會的反饋,。

4.5.2 架構(gòu)合規(guī)性審查執(zhí)行導(dǎo)則

• 理解審查的目標，并始終保持在正確的軌道之上對提出的問題提供適合的交付物,。例如,，人們通常希望了解正在架構(gòu)的系統(tǒng)的對錯之處，而不是希望了解諸如所采用的開發(fā)方法是否正確,、管理組織結(jié)構(gòu)是否合理等這些方面,，因而在審查中就會經(jīng)常偏離主題。

• 隨著審查討論的進行，其他一些需要被解決的問題將會逐漸顯現(xiàn),，而且這些問題還常常會超出當前審查的范圍,。在這種情況下，我們需要在此次審查會后對其進行處理,，并依照這些問題的重要性來制定一份用于解決這些問題的計劃,。

• 保持科學的態(tài)度。與其說“我們期望看到大型數(shù)據(jù)庫放置在ABC之上而不放在XYZ”,，我們更應(yīng)該說“XYZ數(shù)據(jù)庫環(huán)境之下的停機時間遠遠超過在ABC數(shù)據(jù)庫環(huán)境之中的狀況,。因此我們不推薦將M和N系統(tǒng)放置到XYZ環(huán)境中”。

• 詢問開放性問題,。

• 在審查的征詢過程中經(jīng)常會存在隱藏的日程或有爭議的問題,，而這些內(nèi)容在前期是無法預(yù)知的，因而采用一個非個性化的方法來進行討論將會彌合這些差距而不是加劇他們,。

• 尊重面談的對象,。他們可能不會采用合適的方法來構(gòu)建系統(tǒng)，但是他們可能在其所處的環(huán)境中已經(jīng)盡了最大的努力,。

• 在練習中增長經(jīng)驗,。

• 審查應(yīng)該包括針對架構(gòu)的詳細評估活動，并確保其結(jié)果被存儲到企業(yè)連續(xù)體之中,。

5. 架構(gòu)合同

架構(gòu)合同是在開發(fā)團體和贊助者之間關(guān)于架構(gòu)的交付物,、質(zhì)量以及適用目標的聯(lián)合協(xié)議，并且通過有效的架構(gòu)治理將會促使這些協(xié)議的成功施行,。通過對合同的管理施行一個治理方法,，如下幾點將會得到保障：

• 一個連續(xù)監(jiān)測系統(tǒng)，用于檢查完整性,、變更,、決策，并對組織內(nèi)所有架構(gòu)相關(guān)活動進行審計,。

• 與現(xiàn)存的或正在開發(fā)中的架構(gòu)相關(guān)的原則,、標準和需求得以被堅持。

• 明確存在于架構(gòu)的開發(fā),、實現(xiàn)和運營中的各種風險,。

• 一系列流程和實踐得以被制定，從而保障針對所有架構(gòu)制品的開發(fā)和使用的問責性,、責任和規(guī)章,。

• 對于為合同進行負責的治理組織、其權(quán)威等級以及它所負責的架構(gòu)范圍產(chǎn)生一個正式的理解,。

在企業(yè)架構(gòu)開發(fā)方法的各階段中經(jīng)常會見到架構(gòu)合同的身影,，例如架構(gòu)愿景階段中的架構(gòu)工作說明書等,。但無論是何種架構(gòu)協(xié)議，我們都要牢記企業(yè)架構(gòu)開發(fā)的終極目標是創(chuàng)建一個動態(tài)的企業(yè)架構(gòu),，亦即該架構(gòu)可以適應(yīng)外界技術(shù)和業(yè)務(wù)環(huán)境的變化而靈活地演進,，而架構(gòu)合同對于促成這一動態(tài)企業(yè)架構(gòu)的實現(xiàn)，以及針對此實現(xiàn)的治理是非常重要的,。

5.1 各架構(gòu)合同內(nèi)容

5.1.1 架構(gòu)工作說明書

架構(gòu)工作說明書產(chǎn)生于架構(gòu)開發(fā)方法的架構(gòu)愿景階段,，它是架構(gòu)組織和企業(yè)架構(gòu)贊助者之間的所簽訂的協(xié)議，其具體內(nèi)容請參見之前架構(gòu)內(nèi)容框架中的相關(guān)內(nèi)容,。

5.1.2 架構(gòu)設(shè)計和開發(fā)團隊之間的合同

此合同是一份為設(shè)計和開發(fā)企業(yè)架構(gòu)而簽署的意向說明,，亦或是其中一個重要部分。此合同所涉及到的團隊組織包括系統(tǒng)集成者,、應(yīng)用提供者和服務(wù)提供者,。隨著合作分工的逐漸細化，針對一個或多個架構(gòu)領(lǐng)域（業(yè)務(wù),、數(shù)據(jù),、應(yīng)用和技術(shù)）的開發(fā)已經(jīng)越來越多的被外包出去，而企業(yè)架構(gòu)組織則主要負責在整體上進行監(jiān)督和協(xié)調(diào),，并且在有些情況下,，這一監(jiān)督性角色的任務(wù)也被外包到企業(yè)之外。但無論怎樣安排這些外包任務(wù),，這些安排都需要在架構(gòu)合同的治理之下來進行,。這些架構(gòu)合同定義了所開發(fā)架構(gòu)的交付物、質(zhì)量,、適用目標以及架構(gòu)開發(fā)團隊之間進行合作的各種流程,。通常來講，這些架構(gòu)的內(nèi)容包括如下幾點：

• 背景介紹

• 協(xié)議性質(zhì)

• 架構(gòu)范圍

• 架構(gòu)和戰(zhàn)略的原則和需求

• 一致性需求

• 架構(gòu)開發(fā)和管理流程及相關(guān)角色

• 目標架構(gòu)評測

• 針對交付物所定義的各個階段

• 按照優(yōu)先級排序的聯(lián)合工作計劃

• 時間窗口

• 架構(gòu)交付和業(yè)務(wù)指標

5.1.3 架構(gòu)功能組織和業(yè)務(wù)用戶之間的合同

當企業(yè)架構(gòu)被實現(xiàn)之后,，在架構(gòu)功能組織（或整合了架構(gòu)功能的IT治理組織）和業(yè)務(wù)用戶（他們將會在所設(shè)計的架構(gòu)環(huán)境中創(chuàng)建和部署各個應(yīng)用系統(tǒng)）之間就需要達成一份架構(gòu)合同（此合同還可以被用來在架構(gòu)變更階段中對企業(yè)架構(gòu)變更進行管理）,，而這份業(yè)務(wù)用戶架構(gòu)合同（Business Users’ Architecture Contract）的內(nèi)容通常包括如下幾點：

• 背景介紹

• 協(xié)議性質(zhì)

• 范圍

• 戰(zhàn)略需求

• 用于滿足業(yè)務(wù)需求的架構(gòu)交付物

• 一致性需求

• 架構(gòu)采用者

• 時間窗口

• 架構(gòu)業(yè)務(wù)指標

• 服務(wù)架構(gòu)（包括SLA，即服務(wù)水平協(xié)議）

5.2 架構(gòu)合同與架構(gòu)治理

在企業(yè)架構(gòu)開發(fā)方法過程的實施治理階段中所產(chǎn)生的各種架構(gòu)合同文檔主要處于架構(gòu)治理領(lǐng)域之中,。在架構(gòu)治理的背景之下,，這些架構(gòu)合同經(jīng)常被用來作為驅(qū)動架構(gòu)變更的一種手段。為了確保這些架構(gòu)合同的效能,，如下幾個治理框架的方面需要被引入到實施治理階段之中：

• 精簡的流程

• 以人為本的授權(quán)方式

• 強有力的溝通

• 及時的反饋,，以及有效的上報流程

• 專門用作支持的組織結(jié)構(gòu)

• 針對架構(gòu)實現(xiàn)進行狀態(tài)跟蹤

6. 架構(gòu)成熟度模型

由于各個組織所處的環(huán)境并不是一成不變的，因而能夠?qū)@些變化進行快速反應(yīng)并與之相適應(yīng)的組織將會比那些缺乏應(yīng)變能力的組織獲得更大的優(yōu)勢,。隨著IT技術(shù)的日益發(fā)展以及與組織業(yè)務(wù)聯(lián)系的日趨緊密,，每個組織都知道為了管理所有可能出現(xiàn)的變化需要不斷地改其與IT相關(guān)的開發(fā)流程,，但對于很多組織來說,，在哪些方面進行改進以及如何改進的確是個讓人頭疼的問題,。所以在實踐過程中，有的組織要么由于不知如何下手而投入過少,，要么進行漫無目標的投入而導(dǎo)致投資回報率過低,。那么各個組織如何才能解決這一問題，從而使得其所做的改進努力更加有目的性,，并得到足夠好的回報呢,？其實這一問題的答案就是在組織中建立和運用能力成熟度模型（CMMs：Capability Maturity Models）。通過使用這些模型,，組織可以得到如下效益：

• 這些模型描述了各種經(jīng)過總結(jié)的實踐,，借此組織可以改進其流程。

• 這些模型提供了一系列衡量尺度,，借此組織可以對其能力狀態(tài)進行周期性評測,。

• 這些模型提供了一個經(jīng)過驗證的框架，借此組織可以對其所付出的改進努力進行有效管理,。

能力成熟度模型并不是專為企業(yè)架構(gòu)而生,，其實它最初目標是為了改善軟件和系統(tǒng)工程的過程，只是隨著企業(yè)架構(gòu)理論的發(fā)展以及業(yè)界針對這一領(lǐng)域的關(guān)注逐漸加強,，人們才開始考慮將這一模型應(yīng)用到企業(yè)架構(gòu)的領(lǐng)域之中,，從而為評測和改進企業(yè)架構(gòu)的過程提供導(dǎo)向。在TOGAF 9中并沒有為企業(yè)架構(gòu)專門設(shè)計一套成熟度模型,，它只是通過例舉兩種成熟度模型來介紹當前企業(yè)架構(gòu)是如何與能力成熟度模型相結(jié)合的,，以供讀者借鑒。

6.1 美國商務(wù)部架構(gòu)能力成熟度模型（US DoC ACMM）

在前面已經(jīng)提到過,，美國政府可以說是施行企業(yè)架構(gòu)的先行者之一,，因而所有的美國聯(lián)邦政府部門都被要求提供成熟度模型以及相應(yīng)的打分機制來作為他們的IT投資管理和審計需求的一部分。以美國商務(wù)部（US Department of Commerce（DoC））為例,，他就已經(jīng)開發(fā)出了一套企業(yè)架構(gòu)能力成熟度模型（ACMM：Architecture Capability Maturity Model）來幫助其內(nèi)部的企業(yè)架構(gòu)成熟度評測,。這一成熟度模型在2007年12月時發(fā)布了1.2版本。ACMM提供了一套框架,，其中包含了一個富有成效的企業(yè)架構(gòu)過程所應(yīng)具備的各種關(guān)鍵組件,，其目標在于通過明確企業(yè)架構(gòu)的薄弱環(huán)節(jié)并提供一條定義良好的演進改善路線來提升企業(yè)架構(gòu)的成功幾率。ACMM包含如下三部分內(nèi)容：

• 企業(yè)架構(gòu)成熟度模型

• 各個運行單元的流程在不同成熟度水平上的企業(yè)架構(gòu)特性,。

• 企業(yè)架構(gòu)能力成熟度模型記分卡,。

在上述三個部分的內(nèi)容中，前兩部份描述了架構(gòu)能力成熟度水平,、相應(yīng)的企業(yè)架構(gòu)元素,，以及用在成熟度評測中的每個成熟度水平的特性；最后一個部分被用來獲取用于向商務(wù)部首席信息官（CIO）進行匯報的架構(gòu)能力成熟度水平,。

6.1.1 ACMM企業(yè)架構(gòu)評定元素

ACMM從如下九個方面對企業(yè)架構(gòu)的成熟度水平進行評定：

• 架構(gòu)流程（Architecture process）

• 架構(gòu)開發(fā)（Architecture development）

• 業(yè)務(wù)聯(lián)系（Business linkage）

• 高層管理的參與（Senior management involvement）

• 運行單元的參與（Operating unit participation）

• 架構(gòu)溝通（Architecture communication）

• IT安全性（IT security）

• 架構(gòu)治理（Architecture governance）

• IT投資和并購戰(zhàn)略（IT investment and acquisition strategy）

6.1.2 ACMM成熟度水平

ACMM將每個企業(yè)架構(gòu)成熟度評估元素的成熟度水平分為如下五個檔次：

• 無（None）

• 初步（Initial）

• 在開發(fā)（Under development）

• 已定義（Defined）

• 受管理的（Managed）

• 可計量的（Measured）

6.2 能力成熟度模型集成（CMMI）

截至到目前,，成熟度模型已經(jīng)在很多行業(yè)中得到了接受和施行,，而且每個行業(yè)幾乎都具有符合其自身特點的成熟度模型，但是正是由于這種廣泛的接受性導(dǎo)致了成熟度模型過于繁雜,。為了管理這一由于過多成熟度模型所帶來復(fù)雜性,，SEI（Software Engineering Institute）開發(fā)了一個名為能力成熟度模型集成（CMMI：Capability Maturity Model Integration）的框架。該框架綜合了各領(lǐng)域成熟度模型的最佳實踐,，它使得組織可以：

• 將管理和工程活動與業(yè)務(wù)目標更加明顯地聯(lián)系在一起,。

• 擴展產(chǎn)品生命周期和工程活動的范圍和可見度，從而確保產(chǎn)品或服務(wù)滿足用戶的期望,。

• 納入從其他領(lǐng)域的最佳實踐中汲取的經(jīng)驗教訓(xùn),。

• 實現(xiàn)更加堅固的高成熟度實踐。

• 實現(xiàn)對產(chǎn)品和服務(wù)來說非常重要的額外的組織功能,。

• 更加充分的遵循相關(guān)ISO標準,。

由于CMMI并不是隸屬于某個特定行業(yè)的綜合性成熟度模型，因而在企業(yè)架構(gòu)的成熟度方面也可以對其進行借鑒,，而這其中最為重要的就是標準過程改進評估方法（SCAMPI ：Standard CMMI Appraisal Method for Process Improvement）,。此方法是與CMMI相關(guān)連的評估方法，被用來與CMMI參考模型進行比對,，從而對目標的優(yōu)勢,、弱點進行明確，并通過分數(shù)評定的方式進行清晰的表述,。

7. 架構(gòu)技能框架

企業(yè)架構(gòu)過程是個非常繁雜的過程,，它的順利進行離不開眾多具有不同角色的人員的通力協(xié)作，而如何保證這些相互合作的人員在各自崗位上能夠勝任就變成一切活動的根本問題,。為了應(yīng)對這一問題,，TOGAF提出了架構(gòu)技能框架（Architecture Skills Framework），它為進行企業(yè)架構(gòu)建設(shè)的組織提供了一份關(guān)于企業(yè)架構(gòu)工作中各種角色及其能力的視圖,，從而為擔負企業(yè)架構(gòu)工作任務(wù)的團隊的建立提供了導(dǎo)則,。簡單來講，架構(gòu)技能框架的內(nèi)容包含如下三個方面：

• 定義了架構(gòu)工作各領(lǐng)域所涉及到的角色,。

• 定義了每個角色所應(yīng)具備的技能,。

• 定義了每個角色為了順利承擔其責任而對各種技能所應(yīng)掌握的水平。

在實踐中,，每個企業(yè)對于項目人員的選擇應(yīng)該都有著自己的一套方法和流程,，基本上來講，都是通過項目本身的特質(zhì)來制定所需人員的技能標準,，并通過簡單的面試來從組織內(nèi)外的候選者中選擇合適之人,，但這對于企業(yè)架構(gòu)的建設(shè)來講卻過于簡單了。雖然企業(yè)架構(gòu)的建設(shè)從本質(zhì)上來講也是一個項目,，但是由于其本身的復(fù)雜度之高,、牽涉性之廣,，如果把它當作一個普通實現(xiàn)項目來對待的話，組織往往會面臨如下風險：

• 由于牽涉太廣,，從而缺乏統(tǒng)一術(shù)語,、溝通和表述方式,，所以招募組織,、資訊團體和雇傭部門之間的溝通會非常困難。

• 候選者往往具有很好的意向,，但卻可能缺乏組織所需要的必要技能和經(jīng)驗,，而這往往會導(dǎo)致時間的浪費。

• 由于沒有明確的標準,，招募宣傳中的要求往往會由于被誤解而使那些具有足夠能力的人員被忽視,。

• 雇傭不合適人員的風險將會加大，而這又會導(dǎo)致：

• 由于可能會出現(xiàn)人員的再次招募或重新分配,，因而會導(dǎo)致人員成本的增加,。

• 對運營的IT系統(tǒng)以及對其進行交付的項目的時間、成本和質(zhì)量將產(chǎn)生巨大影響,。

為了盡量避免這些風險,，各個組織應(yīng)該采用更為正式的認證機制來對企業(yè)架構(gòu)工作人員進行定義和選擇，而這一機制的目的應(yīng)該在于如下兩點：

• 作為建立和維護一個專業(yè)架構(gòu)組織的任務(wù)的一部分,，對架構(gòu)人員所需的技能進行正式認可,。

• 確保人員的技能和經(jīng)驗與其所擔當?shù)娜蝿?wù)相匹配。

7.1 角色分類

TOGAF將通常用來承擔企業(yè)架構(gòu)開發(fā)工作的架構(gòu)團隊中的角色分為如下幾類：

• 架構(gòu)委員會成員（Architecture Board Members）

• 架構(gòu)贊助者（Architecture Sponsor）

• 架構(gòu)經(jīng)理（Architecture Manager）

• 架構(gòu)師（Architects）,。包括如下幾個領(lǐng)域中的架構(gòu)師：

• 企業(yè)架構(gòu)（Enterprise Architecture）：此種類型的架構(gòu)可以看作是下面幾個領(lǐng)域（業(yè)務(wù),、數(shù)據(jù)、應(yīng)用和技術(shù)）中的架構(gòu)的超集,。

• 業(yè)務(wù)架構(gòu)（Business Architecture）

• 數(shù)據(jù)架構(gòu)（Data Architecture）

• 應(yīng)用架構(gòu)（Application Architecture）

• 技術(shù)架構(gòu)（Technology Architecture）

• 方案和/或項目經(jīng)理（Program and/or Project Managers）

• IT設(shè)計師（IT Designer）

• 其他角色...

7.2 技能分類

架構(gòu)技能框架將架構(gòu)團隊所需要技能歸納為如下幾類：

• 通用技能（Generic Skills）：通常包括領(lǐng)導(dǎo)力,、團隊協(xié)作能力和人際交流技能等。

• 業(yè)務(wù)技能和方法（Business Skills & Methods）：通常包括業(yè)務(wù)案例,、業(yè)務(wù)流程和戰(zhàn)略規(guī)劃等,。

• 企業(yè)架構(gòu)技能（Enterprise Architecture Skills）：通常包括建模、構(gòu)建塊設(shè)計,、應(yīng)用和角色設(shè)計,、系統(tǒng)集成等。

• 方案或項目管理技能（Program or Project Management Skills）：通常包括管理業(yè)務(wù)變更,、項目管理方法和工具等,。

• 通用IT知識技能（IT General Knowledge Skills）：通常包括代理應(yīng)用（brokering applications）、資產(chǎn)管理,、遷移規(guī)劃以及SLAs等,。

• IT技術(shù)技能（Technical IT Skills）：通常包括軟件工程,、安全、數(shù)據(jù)交換以及數(shù)據(jù)管理等,。

• 法律環(huán)境（Legal Environment）：通常包括數(shù)據(jù)保護法,、合同法等。

7.3 熟練度水平定義

7.4 各角色及其技能熟練度水平

7.5 企業(yè)架構(gòu)師角色詳解

在前面提到過的各種角色之中,，最經(jīng)常被提到的恐怕要數(shù)“企業(yè)架構(gòu)師”這一角色了,，而這也正是因為這一角色是整個企業(yè)架構(gòu)建設(shè)的核心。雖然非常重要且常被掛在嘴角,，但其在各行業(yè)中正式的定義卻鮮有所聞,，而僅僅被當作一個跨越多個架構(gòu)領(lǐng)域具有廣泛實踐經(jīng)驗和技能的角色。TOGAF對于企業(yè)架構(gòu)師的工作描述總結(jié)為如下幾點：

• 負責保證架構(gòu)的全面性,，即架構(gòu)應(yīng)照顧到所有相關(guān)干系人的關(guān)注點,。

• 負責保證架構(gòu)的完整性，即所有種類不同的視圖關(guān)聯(lián)在一起,，圓滿調(diào)和不同干系人之間的沖突點,，并展示出此種調(diào)和所帶來的利益權(quán)衡。

• 企業(yè)架構(gòu)師所要做的重要決策之一就是針對各種干系人關(guān)注點來選擇開發(fā)特定的視圖,。這一選擇需要注意其可實踐性,，并要在符合適用目標（fitness-for-purpose）的原則下進行。

架構(gòu)師的職責范圍貫穿了企業(yè)架構(gòu)的整個生命周期,，它開始于與客戶一起理解其真正的需求,，并在其后的過程中負責將這些需求轉(zhuǎn)化為能夠?qū)ζ溥M行實現(xiàn)的各項能力。此外,，架構(gòu)師還需要通過不同模型的展示來與客戶就其需求是如何被滿足的進行溝通,。由此可見，架構(gòu)師與負責建設(shè)的團隊是不同的,，他的主要目標在于理解如何才能滿足客戶的需要,，并就此為負責建設(shè)的應(yīng)用開發(fā)團隊或產(chǎn)品實現(xiàn)團隊提供設(shè)計決策文檔。與建設(shè)者相比,，架構(gòu)師需要保持一定水平的抽象性,，并且通常其所使用的技能應(yīng)該是歸納性的，而建設(shè)者則更加注重于實現(xiàn)方面,，其所采用的技能也往往是推斷性的,。綜上所述，架構(gòu)師的角色職能可以總結(jié)如下：

• 理解并解釋需求：探索信息,、傾聽信息,、影響他人、促進共識、將各種觀點綜合轉(zhuǎn)換為可行的需求,、并將這些觀點解釋給他人,。此外，還包括明確用途或目標,、約束以及風險等因素,。架構(gòu)師將參與到針對各種客戶業(yè)務(wù)情景的發(fā)掘之中，并對其進行文檔記錄,。架構(gòu)師還負責針對需求進行理解,，并將這些理解融入到架構(gòu)說明規(guī)范之中。

• 創(chuàng)建有用的模型：根據(jù)需求來開發(fā)各種經(jīng)過精心定制的模型,，并在必要的情況下對這些模型進行充實,，使其能夠適應(yīng)所有的環(huán)境,。架構(gòu)師還將以這些模型為基礎(chǔ)來展示出各種視圖,，從而提升與干系人之間所進行溝通的有效性。架構(gòu)師為整體架構(gòu)的完整性進行負責,，并負責從架構(gòu)的視角來對所提供的愿景進行維護,。此外，架構(gòu)師還要確保對各種明確的機會進行利用,、采用各種構(gòu)建塊,，并充當各個功能組織之間的聯(lián)絡(luò)員。為了理解開發(fā)工作的各個領(lǐng)域,，并對組織內(nèi)外所應(yīng)采取的行為進行指導(dǎo),，架構(gòu)師需要以框架的方式對這些模型進行提供和維護，此外架構(gòu)師還必須通過對所有必須的業(yè)務(wù)組件的理解來表現(xiàn)架構(gòu)的組織視圖,。

• 驗證,、修繕并擴展模型：對各種假設(shè)進行驗證，并將其輸入給主題專家,。為了改善模型并對其進行進一步的定義,，架構(gòu)師需要為模型加入必須的新觀點，從而使得模型更加靈活,，并能夠與當前及期望的需求聯(lián)系得更加緊密,。除此之外，架構(gòu)師還應(yīng)該對產(chǎn)生于現(xiàn)場工作用于對解決方案進行增強的開發(fā)的價值進行評估,，并將這些內(nèi)容適當?shù)厝谌氲郊軜?gòu)模型之中,。

• 管理架構(gòu)：對模型進行持續(xù)監(jiān)督，并在必要時對其進行更新,，從而展示出了各種變化,、新增和調(diào)整。在項目的開發(fā)和決策點對各種架構(gòu)和問題進行表現(xiàn)。在整個開發(fā)周期中,，架構(gòu)師需要持續(xù)地促進組織間對于客戶,、架構(gòu)和技術(shù)信息的共享。

在前面有關(guān)企業(yè)連續(xù)體的部分中我們已經(jīng)了解到,，對于構(gòu)建塊的實現(xiàn)可能會受其復(fù)雜性所限而需要對其解決方案的實施進行進一步劃分,，而在這種情況下就需要多種架構(gòu)師的通力協(xié)作。從企業(yè)連續(xù)體的角度來說,，架構(gòu)師這一角色可以分為如下幾種,，并且其中的每一種都具備著各自的關(guān)注點：

• 企業(yè)架構(gòu)師（Enterprise Architect）：從全景和技術(shù)參考模型的層次來為架構(gòu)設(shè)計和文檔進行負責。企業(yè)架構(gòu)師通常領(lǐng)導(dǎo)一組與某一給定方案相關(guān)的片段架構(gòu)師和/或解決方案架構(gòu)師,，并且其關(guān)注點在于所需要的企業(yè)級業(yè)務(wù)功能,。

• 片段架構(gòu)師（Segment Architect）：負責特定業(yè)務(wù)問題或組織領(lǐng)域內(nèi)的架構(gòu)設(shè)計和文檔。一個片段架構(gòu)師將會對其他架構(gòu)師的輸出進行重用,，并將詳細的技術(shù)解決方案加入到整體架構(gòu)全景之中,。片段架構(gòu)師的關(guān)注點在于一個給定領(lǐng)域（例如財務(wù)、人力資源以及銷售等）中的企業(yè)級業(yè)務(wù)解決方案,。

• 解決方案架構(gòu)師（Solution Architect）：在系統(tǒng)或子系統(tǒng)級別對架構(gòu)設(shè)計和文檔進行負責,。一個解決方案架構(gòu)師可以為企業(yè)或片段架構(gòu)師屏蔽不必要的系統(tǒng)、產(chǎn)品和/或技術(shù)方面的細節(jié),，并且其關(guān)注點在于系統(tǒng)技術(shù)解決方案方面,，例如諸如企業(yè)數(shù)據(jù)倉庫之類的解決方案組件。

在本節(jié)的最后一部分,，我們來探討一下TOGAF對于企業(yè)架構(gòu)師各方面特質(zhì)的歸納總結(jié)：

• 熟悉創(chuàng)建設(shè)計的技能和經(jīng)驗：企業(yè)架構(gòu)師必須熟練掌握創(chuàng)建復(fù)雜系統(tǒng)設(shè)計的各項技術(shù),，這包括需求發(fā)現(xiàn)和分析、解決方案上下文的制定,、對各種可能的解決方案進行識別和評定,、技術(shù)選型以及設(shè)計配置。

• 具備寬泛的技術(shù)廣度,，并在一個或幾個領(lǐng)域中具備一定技術(shù)深度：企業(yè)架構(gòu)師應(yīng)該對IT行業(yè)有著寬泛的技術(shù)廣度,，并且這一廣度應(yīng)該涵蓋應(yīng)用開發(fā)和部署，以及針對用于支持復(fù)雜應(yīng)用環(huán)境的基礎(chǔ)設(shè)施的創(chuàng)建和維護方面,。當前的IT環(huán)境包羅萬象,，而為了應(yīng)對各種情況，有經(jīng)驗的企業(yè)架構(gòu)師將具備跨越多個平臺的技能,，這包括了分布式系統(tǒng)以及傳統(tǒng)的大型機環(huán)境,。此外，企業(yè)架構(gòu)師還應(yīng)至少在一個領(lǐng)域中具備專家級的水平,。

• 以方法驅(qū)動（Method-Driven）的方式來進行工作：企業(yè)架構(gòu)師應(yīng)該使用已被確認的方法（例如TOGAF）來進行工作,。企業(yè)架構(gòu)師應(yīng)會使用一種以上的設(shè)計方法,，并會根據(jù)工作狀態(tài)自如地選擇合適的方法或方法的一部分，亦即架構(gòu)師應(yīng)該了解在某給定情況下何種方法或方法部分可以被采用,，而何種則不可以,。

• 具備全項目范圍的經(jīng)驗：當企業(yè)架構(gòu)師對用于實現(xiàn)的項目的設(shè)計和執(zhí)行進行負責時，他們對項目所有的方面具備經(jīng)驗是非常重要的,。這些項目方面包括了開發(fā),、測試、實現(xiàn)和生產(chǎn),。企業(yè)架構(gòu)師所掌握的項目經(jīng)驗的范圍有助于其立于“適合目標（fitness-for-purpose）”以及系統(tǒng)實現(xiàn)的現(xiàn)實性的基礎(chǔ)之上,，而且全項目范圍經(jīng)驗所帶來的影響將會引導(dǎo)企業(yè)架構(gòu)師制定出更好的設(shè)計決策，并在這些決策之間獲得更好的平衡,。

• 具備領(lǐng)導(dǎo)力：溝通和團隊協(xié)作對于企業(yè)架構(gòu)師這一角色的成功實現(xiàn)來講是關(guān)鍵,，并且良好的技術(shù)技能和領(lǐng)導(dǎo)能力的結(jié)合對其來講也是至關(guān)重要的。企業(yè)架構(gòu)師應(yīng)被IT組織,、其所服務(wù)的客戶以及管理層看作企業(yè)中的一個領(lǐng)導(dǎo)者,。

• 具備人際關(guān)系和專業(yè)方面的技能：由于企業(yè)架構(gòu)師的主要任務(wù)之一就是與所有干系人（包括沒有技術(shù)背景的干系人）就復(fù)雜的技術(shù)信息進行溝通，所以企業(yè)架構(gòu)師必須具備很強的溝通和人際關(guān)系技能,。此外,，企業(yè)架構(gòu)師還需要具備很強的談判及解決問題的能力,，因為企業(yè)架構(gòu)師還必須與項目管理團隊一起工作來及時地制定決策,，從而保證項目運行在正確軌道之上。

• 具備一個或多個行業(yè)中的技能和經(jīng)驗：行業(yè)技能和經(jīng)驗將會使得收集需求及關(guān)于優(yōu)先級的決策任務(wù)更加簡單和有效,。企業(yè)架構(gòu)師必須理解企業(yè)的業(yè)務(wù)流程,，以及這些流程是如何與行業(yè)中的其他企業(yè)協(xié)同工作的。企業(yè)架構(gòu)師還應(yīng)能發(fā)現(xiàn)主要的趨勢,，并對有缺陷的流程進行修正,，從而給予IT組織對企業(yè)進行引導(dǎo)的能力，而不僅僅是對需求進行回應(yīng)而已,。企業(yè)架構(gòu)師的任務(wù)是進行戰(zhàn)略技術(shù)領(lǐng)導(dǎo),。