為了確保架構(gòu)功能在企業(yè)中能夠被成功地運(yùn)用，企業(yè)需要通過建立適當(dāng)?shù)慕M織結(jié)構(gòu)、流程、角色、責(zé)任和技能來實(shí)現(xiàn)其自身的企業(yè)架構(gòu)能力，而這也正是TOGAF的架構(gòu)能力框架（Architecture Capability Framework）的關(guān)注點(diǎn)所在。架構(gòu)能力框架為企業(yè)如何建立這樣一種架構(gòu)能力提供了一系列參考材料，從而為各企業(yè)架構(gòu)能力的創(chuàng)建提供了幫助，不過TOGAF的架構(gòu)能力框架在當(dāng)前還不是一套全面的關(guān)于如何運(yùn)用架構(gòu)能力的模板，它只是為企業(yè)架構(gòu)能力建設(shè)和運(yùn)用過程中的各項(xiàng)關(guān)鍵活動(dòng)提供了一系列導(dǎo)則和指南。
如圖所示，企業(yè)的架構(gòu)能力一定是運(yùn)行在某一成熟度水平之上，并且在此背景之下，治理組織（Governance Bodies）將對(duì)企業(yè)中各架構(gòu)功能的運(yùn)作進(jìn)行監(jiān)管、評(píng)測(cè)和指導(dǎo)。圖中間部分所表述的就是架構(gòu)功能得以被成功運(yùn)用所需的各種元素，包括了：
用于管理架構(gòu)功能的實(shí)現(xiàn)和維護(hù)所必需的各種角色、責(zé)任以及其所需技能的技能資源池（Skilled Resource Pool）。
架構(gòu)功能的實(shí)現(xiàn)和維護(hù)最終需要落實(shí)到一個(gè)個(gè)的實(shí)施項(xiàng)目（Project/Portfolios）之上，而這些項(xiàng)目在其整個(gè)生命周期內(nèi)都需要處在一定的架構(gòu)治理（Project/Portfolios Governance）之下，從而使其能夠與架構(gòu)的定義始終保持一致，而為了在明確和標(biāo)準(zhǔn)化的前提下達(dá)成這一目標(biāo)，這些實(shí)施項(xiàng)目與相應(yīng)的項(xiàng)目治理之間需要通過合同（Contract）來進(jìn)行溝通和約束。
技能資源池為各實(shí)施項(xiàng)目以及項(xiàng)目治理設(shè)定了相應(yīng)的參與角色和責(zé)任，并對(duì)能夠勝任這些角色和責(zé)任的專業(yè)人員其所需的各種技能進(jìn)行了定義和組織，同時(shí)通過培訓(xùn)的建設(shè)來建立或提高專業(yè)人員所需的各種技能。對(duì)于處于架構(gòu)能力框架主導(dǎo)地位的治理組織來說，它除了對(duì)技能資源池的建設(shè)提供指導(dǎo)之外，還需要為各實(shí)施項(xiàng)目的治理設(shè)定優(yōu)先級(jí)和關(guān)注點(diǎn)，并對(duì)項(xiàng)目治理的成效進(jìn)行評(píng)測(cè)。由于企業(yè)的內(nèi)部以及其所處的外部環(huán)境是不斷變化的，因而企業(yè)本身也需要適應(yīng)這些內(nèi)外的變化，而企業(yè)日常的業(yè)務(wù)運(yùn)營(yíng)（Business Operation）狀況對(duì)于架構(gòu)來說正是這種內(nèi)外變化的最佳反映，它為針對(duì)各架構(gòu)實(shí)現(xiàn)項(xiàng)目所進(jìn)行的治理的優(yōu)先級(jí)排序以及關(guān)注點(diǎn)的設(shè)定提供了參照，同時(shí)各架構(gòu)實(shí)現(xiàn)項(xiàng)目也為企業(yè)的業(yè)務(wù)運(yùn)營(yíng)提供了合適的解決方案。
在之前的各部分中已經(jīng)提到過，企業(yè)架構(gòu)的各項(xiàng)內(nèi)容最終要存放到架構(gòu)資源庫(kù)（Architecture Repository）之中，因而在架構(gòu)能力框架中也將這一元素包括了進(jìn)來，用于對(duì)在各項(xiàng)目中所產(chǎn)生的架構(gòu)工作產(chǎn)品進(jìn)行保存和維護(hù)，并通過引入企業(yè)連續(xù)體（Enterprise Continuum）來對(duì)這些工作產(chǎn)品進(jìn)行分類歸納。
綜上所述，架構(gòu)能力框架為企業(yè)中架構(gòu)能力的建設(shè)提供了指南。這里所說的架構(gòu)能力簡(jiǎn)單來說就是企業(yè)能夠成功建設(shè)和運(yùn)用架構(gòu)的能力，而其實(shí)現(xiàn)方式是在企業(yè)中建立相應(yīng)的組織結(jié)構(gòu)和流程，并對(duì)所需的角色、責(zé)任和技能進(jìn)行定義和分配，從而為企業(yè)中的各架構(gòu)的交付和治理提供環(huán)境和資源。TOGAF針對(duì)上面這些內(nèi)容從如下方面分別給出了導(dǎo)則和指南：
架構(gòu)能力建設(shè)：用于指導(dǎo)企業(yè)如何通過架構(gòu)開發(fā)方法的引入來對(duì)架構(gòu)能力進(jìn)行建設(shè)。
架構(gòu)治理（Architecture Governance）：架構(gòu)能力的目標(biāo)就是通過對(duì)企業(yè)中各個(gè)架構(gòu)的合理治理來保障整個(gè)企業(yè)架構(gòu)建設(shè)和運(yùn)作的順利，并且此部分對(duì)于架構(gòu)治理以及與此過程相關(guān)的組織結(jié)構(gòu)的建立、架構(gòu)合同（Architecture Contracts）和架構(gòu)合規(guī)性（Architecture Compliance）都進(jìn)行了較為詳盡的描述。
架構(gòu)成熟度模型（Architecture Maturity Models）：不論企業(yè)清楚與否，其企業(yè)架構(gòu)的建設(shè)和運(yùn)作一定處于某種成熟度水平之上，而為了讓企業(yè)能夠了解自己企業(yè)架構(gòu)的成熟度水平，并借此針對(duì)薄弱環(huán)節(jié)進(jìn)行識(shí)別和改善，都需要成熟度模型的引入。
架構(gòu)技能框架（Architecture Skills Framework）：架構(gòu)能力的實(shí)現(xiàn)需要為參與架構(gòu)實(shí)現(xiàn)項(xiàng)目和架構(gòu)治理的各種角色、其所需的技能和技能掌握水平進(jìn)行定義，從而明確企業(yè)架構(gòu)過程中相關(guān)角色的職責(zé)和要求，并借此遴選合適的專業(yè)人員。TOGAF的架構(gòu)技能框架便為這一目標(biāo)的實(shí)現(xiàn)提供了參考和指南
1. 架構(gòu)能力的建設(shè)
在前面的敘述中我們應(yīng)該已經(jīng)了解到，企業(yè)可以通過應(yīng)用企業(yè)架構(gòu)開發(fā)方法（ADM）來為其建設(shè)各種業(yè)務(wù)能力，而如果把視界放開一點(diǎn)，我們會(huì)發(fā)現(xiàn)企業(yè)架構(gòu)開發(fā)方法可以應(yīng)用到企業(yè)中任何能力的建設(shè)方面，這當(dāng)然也包括架構(gòu)能力。在架構(gòu)能力的建設(shè)中，對(duì)于架構(gòu)開發(fā)方法的成功運(yùn)用可以使企業(yè)獲得一個(gè)可持續(xù)并以客戶為中心的增值型架構(gòu)實(shí)踐，從而幫助企業(yè)達(dá)成其各項(xiàng)業(yè)務(wù)目標(biāo)、最大化投資價(jià)值，并能夠明確各種獲得業(yè)務(wù)利益和管理風(fēng)險(xiǎn)的機(jī)會(huì)。不過這一架構(gòu)實(shí)踐的建設(shè)并不是一個(gè)一次性的項(xiàng)目，而應(yīng)該是一種持續(xù)性的實(shí)踐過程，從而為組織中其他架構(gòu)的交付提供環(huán)境和資源。
在TOGAF的眼中，任何一種企業(yè)能力的建設(shè)都需要對(duì)如下四種領(lǐng)域進(jìn)行設(shè)計(jì)，這當(dāng)然也包括針對(duì)這一可持續(xù)性架構(gòu)實(shí)踐建設(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)資源庫(kù)的結(jié)構(gòu)。
應(yīng)用架構(gòu)：此領(lǐng)域中的內(nèi)容描述了用于支持此可持續(xù)架構(gòu)實(shí)踐的功能和/或應(yīng)用服務(wù)。
技術(shù)架構(gòu)：此領(lǐng)域中的內(nèi)容描述了此架構(gòu)實(shí)踐中用于支持各架構(gòu)應(yīng)用和企業(yè)連續(xù)體的基礎(chǔ)設(shè)施需求和部署方式。
TOGAF對(duì)于這一可持續(xù)性架構(gòu)實(shí)踐的建設(shè)有著更加詳盡的指南，在本節(jié)的后續(xù)部分中我們將以架構(gòu)開發(fā)方法各階段為基礎(chǔ)來對(duì)企業(yè)架構(gòu)能力的建設(shè)進(jìn)行進(jìn)一步探討。
1.1 架構(gòu)愿景階段
此階段的目的在于定義或?qū)彶檫@一架構(gòu)實(shí)踐的愿景、干系人和原則。TOGAF對(duì)于此過程的具體步驟做了如下建議：
建立項(xiàng)目：此步驟應(yīng)該關(guān)注于定義與此架構(gòu)實(shí)踐有關(guān)的各個(gè)干系人。這些干系人包括了參與到架構(gòu)實(shí)踐活動(dòng)中的角色和組織單元，以及那些會(huì)從架構(gòu)實(shí)踐所產(chǎn)生的交付物中獲益的干系人。
明確干系人和其關(guān)注點(diǎn)、業(yè)務(wù)需求和架構(gòu)愿景：此步驟將會(huì)針對(duì)此架構(gòu)實(shí)踐從業(yè)務(wù)信息系統(tǒng)和技術(shù)的角度產(chǎn)生第一個(gè)關(guān)于基線和目標(biāo)環(huán)境的高度概括定義。
明確業(yè)務(wù)差距和業(yè)務(wù)驅(qū)動(dòng)力：對(duì)業(yè)務(wù)目標(biāo)和驅(qū)動(dòng)力的了解對(duì)于促成此架構(gòu)實(shí)踐和業(yè)務(wù)之間的協(xié)調(diào)是非常重要的。
定義范圍：針對(duì)此架構(gòu)實(shí)踐范圍的定義將會(huì)產(chǎn)生一份高度概括的項(xiàng)目規(guī)劃，用以概括在接下來的一個(gè)時(shí)間區(qū)間內(nèi)需要被解決的問題。
定義約束：此步驟的關(guān)注點(diǎn)在于企業(yè)范圍內(nèi)會(huì)對(duì)所有架構(gòu)項(xiàng)目產(chǎn)生影響的各種約束。
審查架構(gòu)原則（包括業(yè)務(wù)原則）：此步驟的意圖在于定義用于治理和指導(dǎo)這一架構(gòu)實(shí)踐運(yùn)行的各種原則。與通常的架構(gòu)原則用來治理架構(gòu)交付物所不同，架構(gòu)實(shí)踐原則將被用來明確架構(gòu)實(shí)踐的組織、內(nèi)容、工具和相關(guān)流程。
開發(fā)架構(gòu)工作說明書和安全認(rèn)證。
另外一個(gè)需要在此階段被考慮進(jìn)來的步驟是進(jìn)行架構(gòu)成熟度評(píng)估（請(qǐng)參閱2.4.4.6架構(gòu)成熟度模型部分的描述）。
1.2 業(yè)務(wù)架構(gòu)階段
此階段的目標(biāo)在于建立或提煉架構(gòu)實(shí)踐的業(yè)務(wù)架構(gòu)，而這需要關(guān)注如下幾個(gè)關(guān)鍵領(lǐng)域：
架構(gòu)本體論（Architecture Ontology）：定義了各種架構(gòu)的術(shù)語和定義，用于在組織中建立起關(guān)于這些內(nèi)容的共識(shí)。
架構(gòu)流程（Architecture Process）：以架構(gòu)開發(fā)方法為基礎(chǔ)并按照組織的需要和架構(gòu)實(shí)踐的愿景來對(duì)架構(gòu)開發(fā)方法所進(jìn)行的定制，并且所需的架構(gòu)治理流程也應(yīng)該被包含到整個(gè)架構(gòu)流程之中。
架構(gòu)視角和視圖（Architecture Viewpoints and Views）：列舉出所有架構(gòu)實(shí)踐所涉及到的視角和視圖，而針對(duì)這些內(nèi)容的定義工作應(yīng)由此前被識(shí)別出來的架構(gòu)實(shí)踐干系人來進(jìn)行指導(dǎo)。
架構(gòu)框架（Architecture Framework）：描述了將會(huì)由架構(gòu)實(shí)踐所產(chǎn)生的各種架構(gòu)交付物以及他們之間的交互、依賴關(guān)系，此外還包括了種種用于管理這些交付物的設(shè)計(jì)的規(guī)則和指南。那些在之前被定義的架構(gòu)視角和視圖也應(yīng)該被用來指導(dǎo)架構(gòu)框架的定義
架構(gòu)問責(zé)矩陣（Architecture Accountability Matrix）：定義了架構(gòu)實(shí)踐所涉及到的各種角色，以及為這些角色所分配的關(guān)于架構(gòu)交付物和流程的責(zé)任。
架構(gòu)性能指標(biāo)（Architecture Performance Metrics）：明確和描述了用于與架構(gòu)實(shí)踐愿景和目標(biāo)進(jìn)行比對(duì)和監(jiān)督的各項(xiàng)架構(gòu)實(shí)踐性能指標(biāo)。
架構(gòu)治理框架（Architecture Governance Framework）：是一個(gè)與之前定義的架構(gòu)流程和架構(gòu)責(zé)任矩陣相關(guān)的特定視圖。
1.3 信息系統(tǒng)架構(gòu)階段（數(shù)據(jù)）
架構(gòu)實(shí)踐的數(shù)據(jù)架構(gòu)對(duì)組織的企業(yè)連續(xù)體和架構(gòu)資源庫(kù)進(jìn)行了描述和治理。數(shù)據(jù)架構(gòu)的定義應(yīng)該基于組織所選擇的架構(gòu)框架，并且有時(shí)也被引用為架構(gòu)實(shí)踐的元模型。
1.4 信息系統(tǒng)架構(gòu)階段（應(yīng)用）
架構(gòu)實(shí)踐的應(yīng)用架構(gòu)定義了用于產(chǎn)生、維護(hù)、發(fā)布、分發(fā)以及治理架構(gòu)交付物的各種功能，而這其中一個(gè)關(guān)鍵點(diǎn)在于用來建模的各種建模工具組。
1.5 技術(shù)架構(gòu)階段
架構(gòu)實(shí)踐的技術(shù)架構(gòu)應(yīng)該對(duì)用于支持架構(gòu)實(shí)踐的技術(shù)基礎(chǔ)設(shè)施進(jìn)行定義。
1.6 機(jī)會(huì)與解決方案階段
在這樣一個(gè)與架構(gòu)實(shí)踐建設(shè)規(guī)劃相關(guān)的階段中，組織需要審慎考慮的重要一點(diǎn)是所需的組織變更，以及達(dá)成這一變更的方法。
1.7 遷移規(guī)劃階段
此階段的關(guān)注點(diǎn)不僅要放到信息系統(tǒng)架構(gòu)組件之上，還需要將業(yè)務(wù)架構(gòu)包括在內(nèi)，而對(duì)于架構(gòu)流程和框架的采用將會(huì)對(duì)組織中架構(gòu)實(shí)踐的整體建設(shè)產(chǎn)生主要的影響。
1.8 實(shí)施治理階段
針對(duì)架構(gòu)實(shí)踐的業(yè)務(wù)架構(gòu)的實(shí)現(xiàn)應(yīng)該是此階段的關(guān)注重點(diǎn)。將組織中的實(shí)踐活動(dòng)改變?yōu)橐环N更加結(jié)構(gòu)化和有紀(jì)律的方法非常具有挑戰(zhàn)性，因而需要通過適當(dāng)?shù)慕M織變更技術(shù)來達(dá)成。
1.9 架構(gòu)變更管理階段
此階段需要對(duì)架構(gòu)實(shí)踐中各種架構(gòu)的變更進(jìn)行管理，而這些變更通常是在各個(gè)架構(gòu)項(xiàng)目的執(zhí)行過程中被觸發(fā)的。一個(gè)典型的變更往往會(huì)成為對(duì)于新架構(gòu)交付物的需求，并會(huì)對(duì)架構(gòu)實(shí)踐中的所有架構(gòu)領(lǐng)域產(chǎn)生影響。
1.10 需求管理
了解和管理架構(gòu)實(shí)踐的需求是非常關(guān)鍵的，并且這些需求需要被清晰地描述出來，并與架構(gòu)實(shí)踐愿景相一致。
2. 架構(gòu)治理
簡(jiǎn)單來講，企業(yè)架構(gòu)能力是指企業(yè)對(duì)于其內(nèi)各種架構(gòu)的建設(shè)能力，而這里所說的建設(shè)能力不僅指的是企業(yè)中各架構(gòu)的實(shí)現(xiàn)，而且還需要保證架構(gòu)的實(shí)現(xiàn)是處在一個(gè)透明且受控的環(huán)境之中，從而使架構(gòu)的建設(shè)得以正確進(jìn)行。架構(gòu)能力中有關(guān)這種保障架構(gòu)建設(shè)和交付的內(nèi)容就是架構(gòu)治理（Architecture Governance），而這也是架構(gòu)能力中最為核心的部分。
無論何種企業(yè)總有其需要進(jìn)行管理的地方，因而即便是沒有涉及到任何架構(gòu)的企業(yè)也總會(huì)有著針對(duì)其他方面的治理體系，這也注定了架構(gòu)治理必定不會(huì)獨(dú)立并隔絕地存在著，而應(yīng)該存在于一個(gè)層次化的治理結(jié)構(gòu)之中，這對(duì)于大型企業(yè)來講尤其重要。按照所處領(lǐng)域的不同，TOGAF將這一層次化的治理結(jié)構(gòu)劃分為如下四種，其中的每一種都具有其各自的規(guī)則和流程，并且可以存在于多個(gè)地理區(qū)域?qū)哟沃希òㄈ颉⒌貐^(qū)和本地這三種地理區(qū)域種類）：
公司治理（Corporate governance）
技術(shù)治理（Technology governance）
IT治理（IT governance）
架構(gòu)治理（Architecture governance）
以上這幾種治理體系之間并不是絕對(duì)隔離的，不同的治理體系所包含的活動(dòng)和行為多少都會(huì)有所交疊，但由于其所面對(duì)的領(lǐng)域各不相同，其管理的范疇以及所具備的規(guī)則、流程和活動(dòng)具有很大的差異性。由于公司治理、技術(shù)治理和IT治理的內(nèi)容范疇超過了一個(gè)企業(yè)架構(gòu)框架理論內(nèi)容范圍，TOGAF中相關(guān)部分的描述重點(diǎn)還是放在了架構(gòu)治理這一方面，不過它對(duì)治理的共性以及技術(shù)治理和IT治理還是做出了簡(jiǎn)要的描述。
2.1 治理的共性
在進(jìn)一步介紹架構(gòu)治理之前，我們需要對(duì)“治理”這一概念有一個(gè)清晰的認(rèn)識(shí)。這里所說的治理并不像其字面上那樣，僅僅代表顯式的管控和對(duì)于規(guī)則的嚴(yán)格遵守，而是更加傾向于為有效且公平的使用各種資源提供指南，從而確保組織的戰(zhàn)略目標(biāo)的可持續(xù)發(fā)展。根據(jù)所處領(lǐng)域不同，在前面提到過治理可以被細(xì)分為若干治理層次，但無論其種類為何，“治理”的最終目標(biāo)在于確保業(yè)務(wù)得以順利進(jìn)行，并且在這些種類不同的治理都遵循著相同的原則。經(jīng)合組織（OECD：Organization for Economic Co-operation and Development）曾經(jīng)針對(duì)這些基礎(chǔ)共通原則做出了如下概括：
關(guān)注于各種干系人的權(quán)力、角色以及針對(duì)他們的公平處置。
信息披露、透明度和委員會(huì)的責(zé)任。
確保組織中良好的戰(zhàn)略指南。
確保委員會(huì)進(jìn)行有效管理監(jiān)督。
確保委員會(huì)對(duì)于公司與相關(guān)干系人之間的問責(zé)。
委員會(huì)的責(zé)任包括：
審查和指導(dǎo)戰(zhàn)略。
設(shè)置并監(jiān)督管理績(jī)效目標(biāo)的進(jìn)展。
除了這些共同原則之外，TOGAF還概括出了治理的各種共同特性，用以突顯治理作為一個(gè)被組織在其內(nèi)以及與其他有關(guān)團(tuán)體之間所采用的方法的價(jià)值和必要性：
紀(jì)律性（Discipline）：所有牽涉的團(tuán)體需要承諾遵循由組織建立的各種程序、流程和權(quán)利結(jié)構(gòu)。
透明性（Transparency）：被授權(quán)的組織和各供應(yīng)商應(yīng)該可以對(duì)所有實(shí)施行動(dòng)和他們的決策支持進(jìn)行檢查。
獨(dú)立性（Independence）：所有流程、決策制定以及所采用機(jī)制的建立應(yīng)最小化或避免潛在的利益沖突。
問責(zé)性（Accountability）：所有在組織中被確定的團(tuán)隊(duì)需要被授權(quán)，并且需要為他們的行為負(fù)責(zé)。
責(zé)任性（Responsibility）：每個(gè)簽訂契約的團(tuán)體需要對(duì)組織以及他們的干系人采取負(fù)責(zé)任的行為。
公平性（Fairness）：所有的決策、使用的流程以及針對(duì)他們的實(shí)現(xiàn)不應(yīng)對(duì)任何團(tuán)體產(chǎn)生不公平的利益。
2.2 不同治理領(lǐng)域的特性
在前面提到過的四種領(lǐng)域中的治理除了具備上一節(jié)所述的共同原則和特性之外還分別具備各自的特點(diǎn)。由于公司治理的內(nèi)容范疇超過了一個(gè)企業(yè)架構(gòu)框架所應(yīng)覆蓋的范圍，所以在這里并不會(huì)進(jìn)行專門的描述，而接下來我們將針對(duì)其余的三種治理體系，亦即技術(shù)治理、IT治理和架構(gòu)治理，分別進(jìn)行描述。
2.2.1 技術(shù)治理
技術(shù)治理控制了一個(gè)組織如何將技術(shù)應(yīng)用于針對(duì)其產(chǎn)品和服務(wù)的研究、開發(fā)和生產(chǎn)之中。技術(shù)治理與IT治理關(guān)系非常緊密，而且技術(shù)治理往往會(huì)涵蓋IT治理中的各種活動(dòng)，但技術(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)系也越來越緊密，因而針對(duì)IT的治理（亦即IT治理）也成為技術(shù)治理的一個(gè)重要組成部分。這一針對(duì)無形資產(chǎn)逐漸重視的趨勢(shì)同時(shí)也突顯了企業(yè)的業(yè)務(wù)不僅僅依賴于信息本身，還依賴于用于產(chǎn)生、交付和使用這些信息的各種流程、系統(tǒng)和結(jié)構(gòu)。此外，隨著無形資產(chǎn)價(jià)值比重在各個(gè)行業(yè)中的不斷攀升，風(fēng)險(xiǎn)管理也需要作為一個(gè)重點(diǎn)而加以考慮，從而使得新的挑戰(zhàn)、威脅和機(jī)會(huì)能夠得以被理解和緩和。
需要注意的是，不僅僅是組織的運(yùn)營(yíng)和盈利越來越依賴于IT，組織的聲譽(yù)、品牌以及最終他們的價(jià)值也都依賴于這些信息和支持技術(shù)。
2.2.2 IT治理
IT治理為IT資源和信息與企業(yè)目標(biāo)和戰(zhàn)略之間的聯(lián)系提供了框架和結(jié)構(gòu)，并且IT治理為規(guī)劃、采購(gòu)、實(shí)現(xiàn)和監(jiān)督IT績(jī)效指定了各種最佳實(shí)踐，從而確保企業(yè)的IT資產(chǎn)對(duì)其業(yè)務(wù)目標(biāo)的支持。
2.2.3 架構(gòu)治理
架構(gòu)治理是為了在全企業(yè)范圍內(nèi)對(duì)企業(yè)架構(gòu)以及其他各種架構(gòu)進(jìn)行管理和控制而需要借助的各種實(shí)踐和方向，它具有如下幾個(gè)方面的特性：
實(shí)現(xiàn)一個(gè)系統(tǒng)來控制所有架構(gòu)組件和活動(dòng)的創(chuàng)建，并對(duì)它們進(jìn)行監(jiān)督，從而確保在組織內(nèi)有效地引入、實(shí)現(xiàn)各種架構(gòu)，并保障這些架構(gòu)的順利演進(jìn)。
實(shí)現(xiàn)一個(gè)系統(tǒng)用于確保各種架構(gòu)對(duì)于企業(yè)內(nèi)外的標(biāo)準(zhǔn)和法律法規(guī)的遵守。
建立各種流程，用于在已達(dá)成共識(shí)的各因素的約束之下，對(duì)上述流程的有效管理進(jìn)行支持
開發(fā)各種實(shí)踐，用于在組織內(nèi)外確保對(duì)于一個(gè)經(jīng)過清晰定義的干系人團(tuán)體的問責(zé)性。
在前面有關(guān)企業(yè)架構(gòu)開發(fā)方法的介紹中，我們已經(jīng)在“實(shí)施治理”階段見過了“治理”一詞。這個(gè)階段所關(guān)注的是通過各個(gè)變更項(xiàng)目來對(duì)架構(gòu)進(jìn)行實(shí)現(xiàn)，因而此階段的治理僅僅是關(guān)于架構(gòu)實(shí)現(xiàn)這一方面，不過對(duì)于架構(gòu)治理來說，這一實(shí)施治理只是一個(gè)非常重要的方面，架構(gòu)治理的范疇要更為廣闊，它涵蓋了針對(duì)企業(yè)架構(gòu)以及其他各種架構(gòu)在其開發(fā)和演進(jìn)過程中所有方面的管理和控制。作為一個(gè)企業(yè)架構(gòu)框架，TOGAF為支持架構(gòu)治理的實(shí)現(xiàn)提供了一個(gè)架構(gòu)治理框架（Architecture Goverance Framework），用于幫助企業(yè)明確各種有效的治理流程，從而使得與架構(gòu)治理相關(guān)聯(lián)的各種業(yè)務(wù)職責(zé)得以被鑒別出來，并能夠?qū)ζ溥M(jìn)行有效地管理和溝通。
2.3 架構(gòu)治理框架
架構(gòu)治理框架包括兩個(gè)部分的內(nèi)容，其一是用來概括架構(gòu)治理各流程以及相關(guān)內(nèi)容的概念結(jié)構(gòu)，另外一個(gè)是TOGAF對(duì)于架構(gòu)治理所建議的組織結(jié)構(gòu)。在接下來的內(nèi)容中我們將分別對(duì)這兩個(gè)方面進(jìn)行探討。
2.3.1 概念結(jié)構(gòu)
架構(gòu)治理框架的概念結(jié)構(gòu)包含了架構(gòu)治理中的種種概念，這其中最為重要的是對(duì)一個(gè)有效的架構(gòu)治理所應(yīng)具有的各種流程以及與它們相關(guān)的內(nèi)容所進(jìn)行的定義。這一架構(gòu)治理的概念結(jié)構(gòu)采用了一種內(nèi)容無關(guān)的方式，將流程、流程所涉及的內(nèi)容以及背景元素進(jìn)行了分離，從而使得新的治理材料的引入不會(huì)過度地影響到各個(gè)治理流程，同時(shí)也保證了這一治理框架的靈活性。
上圖展示了架構(gòu)治理框架的概念結(jié)構(gòu)，其中涵蓋了這一框架中的各種概念，而這其中最關(guān)鍵的是與治理流程有關(guān)的各種概念。治理流程被用來識(shí)別、管理、審計(jì)和傳播所有與架構(gòu)管理、合同和實(shí)現(xiàn)相關(guān)的信息，從而確保對(duì)所有架構(gòu)制品、合同、原則以及運(yùn)營(yíng)級(jí)別協(xié)議（operational-level agreements）進(jìn)行持續(xù)地監(jiān)督，并且所做的各項(xiàng)決策也具有了清晰的可審計(jì)性。這些治理流程相關(guān)的概念總結(jié)如下：
策略管理與內(nèi)容引入（Policy Management and Take-On）：為了注冊(cè)、驗(yàn)證、批準(zhǔn)、管理和發(fā)布新的或經(jīng)過更新的內(nèi)容，所有針對(duì)架構(gòu)修訂、合同和支持性信息的引入都需要處在一個(gè)正規(guī)流程的治理之下。這些流程將確保與現(xiàn)存治理內(nèi)容的有序整合，從而使得所有相關(guān)的團(tuán)體、文檔、合同和支持信息得以被管理和審計(jì)。
合規(guī)（Compliance）：針對(duì)服務(wù)水平協(xié)議（SLAs：Service Level Agreements）、運(yùn)營(yíng)水平協(xié)議（OLAs：Operational Level Agreements）、現(xiàn)行各項(xiàng)標(biāo)準(zhǔn)和法規(guī)需求的合規(guī)性評(píng)估需要在一個(gè)持續(xù)的基礎(chǔ)上進(jìn)行，從而確保針對(duì)穩(wěn)定性、一致性和性能的監(jiān)督。這些評(píng)估的進(jìn)行需要以在治理框架中所定義的各項(xiàng)標(biāo)準(zhǔn)為準(zhǔn)繩。
豁免（Dispensation）：當(dāng)主題域（設(shè)計(jì)、運(yùn)營(yíng)、服務(wù)水平或技術(shù)）的內(nèi)容在合規(guī)性評(píng)估中被判為不合規(guī)時(shí)，該部分內(nèi)容將可能會(huì)被否定，而此時(shí)將會(huì)存在如下幾種處理方式：
對(duì)這些不合規(guī)內(nèi)容進(jìn)行調(diào)整，從而使其滿足合規(guī)性需求。
申請(qǐng)一份豁免。當(dāng)合規(guī)評(píng)估未能通過時(shí)，豁免就成為了一條用來達(dá)成臨時(shí)性一致的備選路線?；砻庵粫?huì)存在于一段時(shí)間區(qū)間內(nèi)，并在其整個(gè)生命周期內(nèi)被強(qiáng)制設(shè)置明確的服務(wù)和運(yùn)行條件?；砻獠⒉粫?huì)永久有效，它只是被用來作為一種在確保服務(wù)水平和運(yùn)營(yíng)水平得以滿足的同時(shí)附加一定水平的靈活性的機(jī)制?；砻獾臅r(shí)限性特征確保了它們是合規(guī)性評(píng)估循環(huán)的一個(gè)主要觸發(fā)因素。
監(jiān)督和匯報(bào)（Monitoring and Reporting）：性能管理被用來確保運(yùn)營(yíng)和服務(wù)元素的管理是基于一系列經(jīng)過協(xié)定的標(biāo)準(zhǔn)之上，這包括了監(jiān)督服務(wù)水平和運(yùn)營(yíng)水平協(xié)議、對(duì)于調(diào)整的反饋以及針對(duì)這些結(jié)果的匯報(bào)。
業(yè)務(wù)控制（Business Control）：業(yè)務(wù)控制與各個(gè)流程相關(guān)，這些流程的引發(fā)被用來確保與組織的業(yè)務(wù)策略相符合。
環(huán)境管理（Environment Management）：明確了各種服務(wù)，這些服務(wù)確保了以資源存儲(chǔ)庫(kù)為基礎(chǔ)的環(huán)境對(duì)治理框架進(jìn)行支持是有效且高效。這包括了針對(duì)所有用戶的物理和邏輯資源存儲(chǔ)庫(kù)的管理、訪問、溝通、培訓(xùn)和評(píng)審。為了形成一個(gè)受管的服務(wù)和流程環(huán)境，治理環(huán)境中將會(huì)定義一些管理流程，這些流程包括了用戶管理、內(nèi)部服務(wù)水平協(xié)議（為了控制這些管理流程本身而定義）以及針對(duì)管理信息的匯報(bào)
2.3.2 組織結(jié)構(gòu)
在架構(gòu)治理框架的概念結(jié)構(gòu)中，TOGAF以一種內(nèi)容無關(guān)的方式明確了一個(gè)有效的治理所涉及的各種概念，并借此概括了各種架構(gòu)治理流程以及與這些流程相關(guān)聯(lián)的各種內(nèi)容，但如果要確保一個(gè)架構(gòu)治理的順利進(jìn)行，還需要在企業(yè)中設(shè)立專門負(fù)責(zé)治理舉措施行的組織結(jié)構(gòu)。在實(shí)踐中憑空創(chuàng)建這些用于架構(gòu)治理的組織結(jié)構(gòu)其實(shí)是不現(xiàn)實(shí)的，企業(yè)應(yīng)該組合現(xiàn)有的各種IT治理流程、組織結(jié)構(gòu)和能力來對(duì)其進(jìn)行創(chuàng)建。通常來講，企業(yè)中的治理組織結(jié)構(gòu)可被分為如下幾個(gè)層次：
全局治理委員會(huì)
本地治理委員會(huì)
設(shè)計(jì)部門
工作組
TOGAF提出了如下圖所示的治理組織結(jié)構(gòu)，各個(gè)企業(yè)可以按照各自的需求以此圖所示的組織結(jié)構(gòu)為基礎(chǔ)而進(jìn)行改造：
如圖所示，架構(gòu)治理框架的組織結(jié)構(gòu)可以被分為三個(gè)重點(diǎn)區(qū)域，他們分別是：開發(fā)（Develop）、實(shí)現(xiàn)（Implement）和部署（Deploy），它們中的每一個(gè)都代表了在架構(gòu)生命周期的每一個(gè)階段中各個(gè)相關(guān)小組所應(yīng)盡的責(zé)任。尤其是對(duì)于開發(fā)區(qū)域來講，這里的開發(fā)責(zé)任、流程和組織結(jié)構(gòu)都與架構(gòu)開發(fā)方法過程有著緊密的關(guān)聯(lián)，而對(duì)于實(shí)現(xiàn)區(qū)域來講，其所包含的實(shí)施責(zé)任、流程和組織結(jié)構(gòu)與架構(gòu)開發(fā)方法的實(shí)施治理階段也是密不可分的：
在開發(fā)區(qū)域中，架構(gòu)委員會(huì)（Architecture Board）對(duì)主架構(gòu)師進(jìn)行任命，并且通過兩者的合作來對(duì)企業(yè)架構(gòu)的設(shè)計(jì)和落實(shí)進(jìn)行指導(dǎo)，并最終將企業(yè)架構(gòu)細(xì)化成為各個(gè)面向具體問題的領(lǐng)域架構(gòu)。
在實(shí)現(xiàn)區(qū)域中，受架構(gòu)委員會(huì)授權(quán)和委派的項(xiàng)目管理辦公室（Program Management Office）對(duì)用于實(shí)現(xiàn)各個(gè)領(lǐng)域架構(gòu)的實(shí)施項(xiàng)目進(jìn)行管控，從而保障其順利施行。
在部署區(qū)域中，由于各個(gè)架構(gòu)實(shí)現(xiàn)項(xiàng)目的實(shí)現(xiàn)和部署改變了企業(yè)當(dāng)前的運(yùn)營(yíng)狀態(tài)，因而受管理辦公室委派的服務(wù)管理組織（Service Management Organisation）需要對(duì)企業(yè)的各運(yùn)營(yíng)系統(tǒng)進(jìn)行監(jiān)督，從而發(fā)現(xiàn)新的問題和需求，并借此啟動(dòng)新的一輪架構(gòu)開發(fā)循環(huán)。
除了以上這三個(gè)核心區(qū)域之外，我們還應(yīng)注意到企業(yè)連續(xù)體的再次出現(xiàn)。企業(yè)連續(xù)體之所以會(huì)在這里出現(xiàn)是因?yàn)樗羌軜?gòu)治理的一個(gè)不可或缺的部分，因?yàn)樗粌H承載了與架構(gòu)相關(guān)的各種內(nèi)容，也同時(shí)存儲(chǔ)了與架構(gòu)治理過程相關(guān)的種種材料。
2.4 架構(gòu)治理實(shí)踐導(dǎo)則
在實(shí)踐中，為了實(shí)現(xiàn)一個(gè)成功的架構(gòu)治理方法，并對(duì)架構(gòu)合同進(jìn)行有效的管理，企業(yè)需要考慮如下幾個(gè)關(guān)鍵因素：
與架構(gòu)策略、程序、角色、技能、組織結(jié)構(gòu)和支持服務(wù)的提交、采用、重用、回報(bào)和廢止相關(guān)的各種最佳實(shí)踐。
用于支持架構(gòu)治理的流程以及達(dá)成匯報(bào)需求的組織結(jié)構(gòu)及其責(zé)任。
對(duì)各種工具和流程進(jìn)行整合，從而便于在程序上和文化上執(zhí)行各個(gè)流程。
與架構(gòu)治理流程、豁免、合規(guī)性審查、SLAs和OLAs的控制相關(guān)的各種指標(biāo)。
組織內(nèi)外對(duì)于所有架構(gòu)治理相關(guān)信息、服務(wù)和流程在有效性、效率、保密性、完整性、可得性、合規(guī)性和可靠性這些方面的需求。
除了上面幾項(xiàng)對(duì)于架構(gòu)治理成功因素的描述，TOGAF還指出了一個(gè)在企業(yè)中獲得接受和成功的架構(gòu)所應(yīng)具備的三個(gè)主要的架構(gòu)治理戰(zhàn)略元素：
需要在最高管理層的支持下建立一個(gè)跨組織的架構(gòu)委員會(huì)（Architecture Board，見2.4.4.3架構(gòu)委員會(huì)）來對(duì)IT治理策略的實(shí)現(xiàn)提供監(jiān)督。
需要建立一套全面的架構(gòu)原則，從而對(duì)組織如何通過使用信息技術(shù)來完成自身的任務(wù)而進(jìn)行指導(dǎo)和支持。
需要采用一種架構(gòu)合規(guī)性策略（見2.4.4.4架構(gòu)合規(guī)性），從而通過具體的措施來保證架構(gòu)的合規(guī)性，這包括了項(xiàng)目影響評(píng)估、正式的架構(gòu)合規(guī)性審查流程，同時(shí)也可能包括在產(chǎn)品采購(gòu)過程中架構(gòu)團(tuán)體所進(jìn)行參與。
3. 架構(gòu)委員會(huì)
正如前面所說，一個(gè)用來對(duì)架構(gòu)治理策略的實(shí)現(xiàn)進(jìn)行監(jiān)督的跨組織的架構(gòu)委員會(huì)是架構(gòu)治理策略成功的主要要素之一。架構(gòu)委員會(huì)應(yīng)該能夠代表所有主要干系人的需求，并且通常還需要對(duì)整個(gè)架構(gòu)的審查及維護(hù)活動(dòng)負(fù)有高級(jí)行政職責(zé)。通常來講，架構(gòu)委員會(huì)需要對(duì)如下目標(biāo)的達(dá)成進(jìn)行負(fù)責(zé)：
子架構(gòu)之間的一致性。
確定可重用組件。
保證企業(yè)架構(gòu)的靈活性：
滿足不斷變化的業(yè)務(wù)需求。
盡可能的利用不斷出現(xiàn)的新技術(shù)。
嚴(yán)格確保架構(gòu)合規(guī)性。
改善組織中架構(gòu)規(guī)程的成熟度水平。
確保采用以架構(gòu)為基礎(chǔ)的開發(fā)規(guī)程。
為所有關(guān)于架構(gòu)變更的決策提供基礎(chǔ)。
為超出范圍的決策提供升級(jí)的能力。
如果從執(zhí)行的角度來看，架構(gòu)委員會(huì)還需要承擔(dān)如下責(zé)任：
有關(guān)架構(gòu)合同的監(jiān)督和控制的所有方面。
定期舉行會(huì)議。
確保針對(duì)架構(gòu)進(jìn)行有效并且一致地管理和實(shí)現(xiàn)。
解析不清楚的地方，并對(duì)各種問題以及已經(jīng)升級(jí)了的沖突進(jìn)行解決。
提供各種建議、指導(dǎo)以及信息。
確保各種架構(gòu)的合規(guī)性，并在確保與技術(shù)戰(zhàn)略及目標(biāo)一致的基礎(chǔ)上授予豁免。
當(dāng)相似的豁免被申請(qǐng)并被通過時(shí)，架構(gòu)委員會(huì)需要考慮進(jìn)行策略變更。
確保所有與架構(gòu)合同的實(shí)現(xiàn)相關(guān)的信息在可控的條件下被發(fā)布，并可被經(jīng)過授權(quán)的團(tuán)體所獲得。
對(duì)匯報(bào)的服務(wù)水平、成本節(jié)約等方面進(jìn)行驗(yàn)證。
如果從治理的角度來看，架構(gòu)委員會(huì)還需要承擔(dān)如下責(zé)任：
產(chǎn)生各種可用的治理材料和活動(dòng)。
通過共識(shí)和被授權(quán)的發(fā)布來為架構(gòu)的正式接受和批準(zhǔn)提供一種機(jī)制。
為確保架構(gòu)的有效實(shí)現(xiàn)而提供一個(gè)基本控制機(jī)制。
在架構(gòu)的實(shí)現(xiàn)、包含在企業(yè)架構(gòu)中的架構(gòu)戰(zhàn)略和目標(biāo)，以及業(yè)務(wù)的戰(zhàn)略目標(biāo)之間建立關(guān)聯(lián)，并對(duì)其進(jìn)行維護(hù)。
為了通過豁免或策略更新來進(jìn)行調(diào)整，架構(gòu)委員會(huì)需要明確架構(gòu)與計(jì)劃開展的活動(dòng)之間的差異。
3.1 架構(gòu)委員會(huì)的建立
一個(gè)架構(gòu)委員會(huì)的建立往往受如下事件的觸發(fā)：
新CIO的任命。
兼并或收購(gòu)。
考慮采用一個(gè)新的計(jì)算形式。
認(rèn)識(shí)到IT與業(yè)務(wù)的契合度很差。
渴望通過技術(shù)來達(dá)成競(jìng)爭(zhēng)優(yōu)勢(shì)。
一個(gè)企業(yè)架構(gòu)方案的創(chuàng)建。
重大的業(yè)務(wù)變更或業(yè)務(wù)的快速發(fā)展。
需要復(fù)雜且跨越諸多功能的解決方案。
在很多公司中，最初的領(lǐng)導(dǎo)級(jí)架構(gòu)贊助者通常都是CIO，然而為了在企業(yè)中獲得廣闊的支持，一個(gè)贊助組織的影響力往往超過某個(gè)個(gè)人，這樣一個(gè)贊助組織在這里被稱為一個(gè)架構(gòu)委員會(huì)。架構(gòu)委員會(huì)是一個(gè)高級(jí)領(lǐng)導(dǎo)層組織，用來為戰(zhàn)略架構(gòu)及其子架構(gòu)的審查和維護(hù)進(jìn)行負(fù)責(zé)。雖然架構(gòu)委員會(huì)是企業(yè)中架構(gòu)的贊助者，企業(yè)架構(gòu)委員會(huì)自己本身也需要獲得企業(yè)高層的贊助和支持，并且這一支持需要貫徹整個(gè)規(guī)劃過程，延伸到針對(duì)架構(gòu)項(xiàng)目的維護(hù)之中。
架構(gòu)委員會(huì)的常駐人員規(guī)模不宜過大，按照TOGAF的建議，一個(gè)架構(gòu)委員會(huì)的常駐人員規(guī)模應(yīng)包含四至五人，或不超過十人。為了使架構(gòu)委員會(huì)隨著事件的推移而一直保持合理的規(guī)模，并同時(shí)確保其在企業(yè)范圍內(nèi)的代表性，架構(gòu)委員會(huì)的成員需要采用輪換制，從而給予各個(gè)高級(jí)經(jīng)理決策權(quán)和相關(guān)責(zé)任。除此之外，由于現(xiàn)實(shí)中的各種原因這一輪換機(jī)制還有其存在的必要性，例如當(dāng)有些架構(gòu)委員會(huì)成員受時(shí)間所限而不能長(zhǎng)期承擔(dān)其職責(zé)時(shí)。雖然采用了輪換制，但為了確保架構(gòu)委員會(huì)的決策不會(huì)變化無常，企業(yè)需要主動(dòng)的采用某種機(jī)制來確保其核心理念的穩(wěn)定，例如為成員設(shè)置任期，并將不同成員的離退時(shí)間交錯(cuò)開來。
3.2 架構(gòu)委員會(huì)的運(yùn)行
架構(gòu)委員會(huì)的運(yùn)行的核心以及在形式上的表現(xiàn)就是按照清晰的日程安排所進(jìn)行的架構(gòu)委員會(huì)會(huì)議，并且這些日程安排需要具有明確的目標(biāo)、所涵蓋的內(nèi)容和經(jīng)過定義的行為。架構(gòu)委員會(huì)會(huì)議需要為如下幾個(gè)方面提供指導(dǎo)：
對(duì)高質(zhì)量的治理材料和活動(dòng)的產(chǎn)生進(jìn)行支持。
通過共識(shí)和被授權(quán)的發(fā)布來為架構(gòu)的正式接受提供一個(gè)機(jī)制。
為確保有效的架構(gòu)實(shí)現(xiàn)提供一個(gè)基本控制機(jī)制。
在架構(gòu)的實(shí)現(xiàn)、包含在企業(yè)架構(gòu)中的架構(gòu)戰(zhàn)略和目標(biāo)以及業(yè)務(wù)的戰(zhàn)略目標(biāo)之間建立關(guān)聯(lián)，并對(duì)其進(jìn)行維護(hù)。
為通過豁免或策略更新來與合同進(jìn)行重新校準(zhǔn)而對(duì)合同和規(guī)劃活動(dòng)之間的差異進(jìn)行明確。
每個(gè)會(huì)議的參與者在開會(huì)前會(huì)收到一份日程描述和相關(guān)支持文檔，他們需要在開會(huì)前對(duì)這些內(nèi)容進(jìn)行熟悉，并且被分配進(jìn)行某項(xiàng)活動(dòng)的與會(huì)人員還需要報(bào)告其執(zhí)行進(jìn)度。此外，每個(gè)與會(huì)人員還必須確認(rèn)其是否參加架構(gòu)委員會(huì)會(huì)議。
由此可見，會(huì)議的日程描述是有關(guān)整個(gè)會(huì)議內(nèi)容的核心，TOGAF對(duì)于其內(nèi)容項(xiàng)目做了如下建議：
前期會(huì)議紀(jì)要：以前的架構(gòu)委員會(huì)會(huì)議的詳細(xì)紀(jì)要。
變更請(qǐng)求：此條目之下的內(nèi)容通常包含了針對(duì)架構(gòu)、原則等內(nèi)容進(jìn)行修訂的變更請(qǐng)求，此外也可以包含對(duì)于架構(gòu)合同的業(yè)務(wù)控制（例如，確保針對(duì)某一付費(fèi)號(hào)碼的語音流量（例如天氣預(yù)報(bào)）被禁止，以及對(duì)于某一特定網(wǎng)站進(jìn)行訪問的數(shù)據(jù)流量需要被控制）。任何一個(gè)變更請(qǐng)求的設(shè)置需要在制定者的授權(quán)范圍之內(nèi)，并采用在架構(gòu)合同中已經(jīng)定義好的參數(shù)。
豁免：豁免被用來作為一個(gè)對(duì)現(xiàn)存架構(gòu)、合同和原則等方面內(nèi)容進(jìn)行更改的申請(qǐng)?；砻庵粫?huì)在一定的時(shí)間區(qū)間中以及定義明確的在整個(gè)豁免期間需要被貫徹的服務(wù)和運(yùn)營(yíng)條件下被認(rèn)可。
合規(guī)性評(píng)估：合規(guī)性的評(píng)估是針對(duì)服務(wù)水平協(xié)議、運(yùn)營(yíng)水平協(xié)議、成本目標(biāo)等方面而進(jìn)行的。根據(jù)在架構(gòu)治理框架中定義的條件標(biāo)準(zhǔn)，通過審查后，這些評(píng)估結(jié)果或者被接受亦或者被拒絕，并且架構(gòu)合規(guī)性評(píng)估報(bào)告還應(yīng)包含所描述的各個(gè)細(xì)節(jié)。
爭(zhēng)議解決：經(jīng)過架構(gòu)合規(guī)性審查和豁免過程而依然未被解決的爭(zhēng)議需要在這里被明確，從而為下一步的行動(dòng)提供目標(biāo)，并且這些內(nèi)容需要被記錄到架構(gòu)合規(guī)性評(píng)估和豁免文檔之中。
架構(gòu)戰(zhàn)略和方向文檔：這里所描述的內(nèi)容僅被全局架構(gòu)委員會(huì)所制定，它包含了架構(gòu)的戰(zhàn)略、方向及其優(yōu)先級(jí)順序。
行動(dòng)分配：這是一個(gè)關(guān)于前期架構(gòu)委員會(huì)會(huì)議所分配行動(dòng)情況的報(bào)告。在此報(bào)告中，一個(gè)行動(dòng)跟蹤記錄被用來記錄和保持所有在架構(gòu)委員會(huì)會(huì)議中被分配的行動(dòng)的狀態(tài)，其內(nèi)容至少應(yīng)該包含如下幾個(gè)方面：
參考材料
優(yōu)先級(jí)
行動(dòng)概述
行動(dòng)所屬者
行動(dòng)詳細(xì)描述
開始日
到期日
狀態(tài)
類型
決議通過之日
合同文檔管理：這是為架構(gòu)文檔的后續(xù)發(fā)布而對(duì)其進(jìn)行的有關(guān)更新和改變的正式認(rèn)可。
其他事項(xiàng)（AOB：Any Other Business）：關(guān)于上述內(nèi)容所沒有覆蓋的問題的描述。這些內(nèi)容也許不會(huì)被描述在會(huì)議日程之中，但應(yīng)該在會(huì)議開始時(shí)被提出。
會(huì)議安排：所有會(huì)議的時(shí)間和內(nèi)容安排應(yīng)被詳細(xì)描述，并公之于眾。
4. 架構(gòu)合規(guī)性
針對(duì)架構(gòu)合規(guī)性的審查是架構(gòu)治理戰(zhàn)略的核心環(huán)節(jié)，也是決定其能否成功的重要因素。架構(gòu)合規(guī)性審查是針對(duì)各個(gè)具體項(xiàng)目與已經(jīng)建立的架構(gòu)標(biāo)準(zhǔn)、精神以及業(yè)務(wù)目標(biāo)的相符合情況所進(jìn)行的審議，而一個(gè)關(guān)于這些審議的正規(guī)流程正是企業(yè)的架構(gòu)合規(guī)性策略的核心內(nèi)容。通過架構(gòu)合規(guī)性審查，企業(yè)可以達(dá)成如下幾點(diǎn)（或部分）目標(biāo)：
首先且最重要的目標(biāo)是企業(yè)得以盡早在項(xiàng)目架構(gòu)中發(fā)現(xiàn)錯(cuò)誤，從而減少在整個(gè)生命周期的后期進(jìn)行更改的風(fēng)險(xiǎn)和成本，而這也意味著整體的項(xiàng)目時(shí)間得以縮減，并且各項(xiàng)業(yè)務(wù)也能夠盡早地獲得架構(gòu)所帶來的底線收益（bottom-line benefit）。
確保將各種最佳實(shí)踐應(yīng)用到架構(gòu)工作當(dāng)中。
提供一份關(guān)于架構(gòu)與強(qiáng)制性企業(yè)標(biāo)準(zhǔn)的符合度的概略。
明確標(biāo)準(zhǔn)本身需要進(jìn)行修改的地方。
明確能夠作為企業(yè)基礎(chǔ)設(shè)施的組成部分，卻在當(dāng)前只為特定應(yīng)用提供支持的各個(gè)服務(wù)。
將關(guān)于團(tuán)隊(duì)合作、資源共享以及其他能夠跨越多個(gè)架構(gòu)團(tuán)隊(duì)的協(xié)同增效方面的戰(zhàn)略進(jìn)行文檔化。
充分利用技術(shù)所帶來的先進(jìn)性。
對(duì)項(xiàng)目的技術(shù)準(zhǔn)備狀態(tài)進(jìn)行溝通。
確定采購(gòu)活動(dòng)的關(guān)鍵標(biāo)準(zhǔn)。
明確重大的架構(gòu)性差距，并就此與產(chǎn)品和服務(wù)供應(yīng)商進(jìn)行溝通。
除了上面這些與質(zhì)量保證有關(guān)的目標(biāo)之外，架構(gòu)合規(guī)性審查的進(jìn)行還在特定情況下具有著傾向于以政治為導(dǎo)向的動(dòng)機(jī)：
由于具有決策能力的人通常會(huì)參與到審查當(dāng)中，并能夠從對(duì)業(yè)務(wù)最優(yōu)的角度進(jìn)行決策指導(dǎo)，而不僅僅注重技術(shù)的優(yōu)劣，這使得架構(gòu)合規(guī)性審查成為了一種在各種架構(gòu)選擇之間進(jìn)行選擇的好方法。
架構(gòu)合規(guī)性審查的輸出是為數(shù)不多的用來匯報(bào)給CIO，并輔助其決策制定的可測(cè)性交付物之一。
架構(gòu)審查可以作為一條架構(gòu)組織借以參與到開發(fā)項(xiàng)目之中的途徑，否則各個(gè)開發(fā)項(xiàng)目的進(jìn)行將會(huì)與企業(yè)的架構(gòu)功能相脫節(jié)。
架構(gòu)審查可以為企業(yè)業(yè)務(wù)團(tuán)體給出快速且正面的支持：
企業(yè)架構(gòu)以及架構(gòu)合規(guī)性可以幫助確保各IT項(xiàng)目與業(yè)務(wù)目標(biāo)的符合度。
架構(gòu)師有時(shí)可以被視為深入到技術(shù)基礎(chǔ)設(shè)施之中而遠(yuǎn)離核心業(yè)務(wù)之外。
由于架構(gòu)合規(guī)性審查傾向于將主要注意力放到一個(gè)系統(tǒng)的關(guān)鍵風(fēng)險(xiǎn)區(qū)域內(nèi)，所以此審查經(jīng)?？梢詾橄到y(tǒng)所有者凸顯各種主要的風(fēng)險(xiǎn)。
4.1 架構(gòu)合規(guī)性審查發(fā)生時(shí)點(diǎn)
架構(gòu)合規(guī)性審查并不是一個(gè)一次性的活動(dòng)，它應(yīng)該在適當(dāng)?shù)捻?xiàng)目里程碑或項(xiàng)目生命周期的各個(gè)檢查點(diǎn)進(jìn)行，并且其具體的審查要點(diǎn)應(yīng)包括：
架構(gòu)開發(fā)自身的合規(guī)性，亦即對(duì)于架構(gòu)開發(fā)方法的符合度。
架構(gòu)實(shí)現(xiàn)的合規(guī)性，亦即各個(gè)實(shí)施項(xiàng)目與架構(gòu)的符合度。
針對(duì)架構(gòu)項(xiàng)目審查的時(shí)點(diǎn)應(yīng)包括：
項(xiàng)目啟動(dòng)
初步設(shè)計(jì)
主要設(shè)計(jì)變更時(shí)
其它特定時(shí)刻
4.2 架構(gòu)合規(guī)性審查進(jìn)行的情景概括
就架構(gòu)合規(guī)性審查的進(jìn)行、治理以及參與的人員來說，TOGAF針對(duì)此審查的進(jìn)行總結(jié)出了如下三種情景：
對(duì)于小規(guī)模的項(xiàng)目，這一審查流程可以只是由項(xiàng)目架構(gòu)師或項(xiàng)目組長(zhǎng)制定一系列問題（可以通過對(duì)后面將要列出的問題清單進(jìn)行定制而獲得），再將答案收錄到某種形式的報(bào)告中，并對(duì)其進(jìn)行管理。進(jìn)行這樣一個(gè)流程的需求通常要被包含在整個(gè)企業(yè)范圍的IT治理策略中。
如果處于審查之下的項(xiàng)目并沒有一個(gè)全職的架構(gòu)師的參與（例如，一個(gè)應(yīng)用級(jí)的項(xiàng)目），那么就需要借助于企業(yè)中具有架構(gòu)功能的組織的專業(yè)性架構(gòu)能力了。這種情況下，企業(yè)架構(gòu)功能組織將負(fù)責(zé)對(duì)這一審查進(jìn)行組織、領(lǐng)導(dǎo)和執(zhí)行，并保證各業(yè)務(wù)領(lǐng)域?qū)＜业膮⑴c。需要注意的是，這樣的審查并不是要取代架構(gòu)師對(duì)于項(xiàng)目的參與，而是對(duì)架構(gòu)師參與的一個(gè)有效的補(bǔ)充。此外，在這種情景下也許還需要引入一套數(shù)據(jù)庫(kù)系統(tǒng)，從而對(duì)在大型系統(tǒng)或系統(tǒng)組的分析中所產(chǎn)生的大量數(shù)據(jù)進(jìn)行管理。
對(duì)于大多數(shù)情況來說，尤其是對(duì)于大型項(xiàng)目來說，組織中具有架構(gòu)功能的組織可能已經(jīng)深入地參與到（或領(lǐng)導(dǎo)）處于合規(guī)性審查之下的開發(fā)項(xiàng)目之中。在這種情況下，這一審查應(yīng)該由主架構(gòu)師來進(jìn)行協(xié)調(diào)。主架構(gòu)師需要組織一個(gè)包含業(yè)務(wù)和技術(shù)領(lǐng)域?qū)＜业膱F(tuán)隊(duì)，并將合規(guī)性審查中各個(gè)問題的答案編織成某種形式的報(bào)告。合規(guī)性審查中各個(gè)問題的制定需要由各個(gè)業(yè)務(wù)和技術(shù)領(lǐng)域?qū)＜乙黄饋韴?zhí)行。除了由主架構(gòu)師領(lǐng)導(dǎo)之外，架構(gòu)合規(guī)性審查也可以由架構(gòu)委員會(huì)的代表或其他在全企業(yè)范圍內(nèi)具有相似能力的組織來領(lǐng)導(dǎo)。
在上面這些情景中，架構(gòu)合規(guī)性審查的進(jìn)行都需要高級(jí)管理層的支持，并通常被作為企業(yè)架構(gòu)治理策略的一個(gè)重要部分來加以強(qiáng)制。一般來講，企業(yè)的CIO或企業(yè)架構(gòu)委員會(huì)將對(duì)所有主要項(xiàng)目進(jìn)行強(qiáng)制性審查，并在之后形成年度審查的慣例。
4.3 架構(gòu)合規(guī)性審查流程
4.3.1 流程
TOGAF對(duì)于架構(gòu)合規(guī)性審查的流程做了如下圖所示的總結(jié)：
4.3.2 參與流程的各角色及職責(zé)
角色
職責(zé)
備注
架構(gòu)委員會(huì)
確保IT架構(gòu)的一致性，并能對(duì)所有業(yè)務(wù)目標(biāo)進(jìn)行支持
贊助并監(jiān)督架構(gòu)活動(dòng)
項(xiàng)目組長(zhǎng)
（或項(xiàng)目委員會(huì)）
為這個(gè)項(xiàng)目負(fù)責(zé)
架構(gòu)審查協(xié)調(diào)人
管理整個(gè)架構(gòu)的開發(fā)和審查流程
更傾向于面向業(yè)務(wù)，而不是技術(shù)
首席企業(yè)架構(gòu)師
確保架構(gòu)在技術(shù)上的連貫，并且是面向未來的
一個(gè)IT架構(gòu)專家
架構(gòu)師
首席企業(yè)架構(gòu)師的技術(shù)助理之一
客戶
確保業(yè)務(wù)需求被清晰地描述和理解
管理組織的一部分，該部分依賴于在架構(gòu)中所描述的信息技術(shù)的成功實(shí)現(xiàn)和運(yùn)用
業(yè)務(wù)領(lǐng)域?qū)＜?div style="height:15px;">
確保用于滿足業(yè)務(wù)需求的流程是合理并能夠被理解的
了解業(yè)務(wù)領(lǐng)域的運(yùn)作?？梢酝ㄟ^客戶來?yè)?dān)當(dāng)這一角色
項(xiàng)目負(fù)責(zé)人
確保架構(gòu)師對(duì)于客戶部門流程有著足夠詳細(xì)的理解，并能夠?yàn)闃I(yè)務(wù)領(lǐng)域?qū)＜一蚣軜?gòu)師提供各種所需的輸入
能夠?yàn)榧軜?gòu)所要滿足的業(yè)務(wù)需求提供輸入的客戶組織中的成員
4.4 架構(gòu)合規(guī)性審查問題參考列表
架構(gòu)合規(guī)性審查是針對(duì)各個(gè)項(xiàng)目與架構(gòu)的符合度而進(jìn)行的審議活動(dòng)，而這一活動(dòng)的具體實(shí)施需要圍繞著一份問題清單來進(jìn)行的。為了幫助這一份問題清單的制定，TOGAF根據(jù)架構(gòu)的各個(gè)方面提出了一系列備選問題，而負(fù)責(zé)問題清單開發(fā)的領(lǐng)域?qū)＜铱梢愿鶕?jù)所審查架構(gòu)的特性在這些備選問題中進(jìn)行選擇和定制。需要注意的是，這里所列出的問題并不適用于針對(duì)業(yè)務(wù)領(lǐng)域架構(gòu)或跨越多個(gè)項(xiàng)目的架構(gòu)的審查。針對(duì)這些架構(gòu)的審查的流程雖然相似，但是其所使用的問題清單的類別和內(nèi)容將會(huì)有所不同。（有些問題并不是以提問的形式出現(xiàn)，而是通過簡(jiǎn)短的描述來對(duì)引發(fā)問題的緣由，以及答案中所應(yīng)包含的內(nèi)容方向進(jìn)行了闡述，從而使得相關(guān)人員可以按照各自情況編制出合適的問題）
4.4.1 硬件和操作系統(tǒng)問題清單
項(xiàng)目生命周期方法是什么？
項(xiàng)目目前處在生命周期的哪個(gè)階段？
已經(jīng)被明確的或被用作分析的，在項(xiàng)目中用來對(duì)網(wǎng)絡(luò)、服務(wù)器以及終端設(shè)備的硬件和操作系統(tǒng)進(jìn)行評(píng)估的關(guān)鍵問題是什么？
將要參與到大量和/或高頻率數(shù)據(jù)傳輸中去的系統(tǒng)能力是什么？
系統(tǒng)設(shè)計(jì)是如何影響或涉及到終端用戶設(shè)備的？
所進(jìn)行的使用、數(shù)據(jù)存儲(chǔ)和處理的數(shù)量及分布（地區(qū)性和全局性）是什么？
通過對(duì)比數(shù)據(jù)、應(yīng)用服務(wù)等方面的相似性，應(yīng)用與項(xiàng)目的關(guān)聯(lián)有哪些？并且數(shù)據(jù)與項(xiàng)目的關(guān)聯(lián)程度為何？
在系統(tǒng)關(guān)鍵元素的功能性設(shè)計(jì)之前就已經(jīng)做出的關(guān)于硬件和操作系統(tǒng)的選擇是什么？
是否關(guān)于硬件和操作系統(tǒng)的決策制定超出了項(xiàng)目的控制？
項(xiàng)目對(duì)于那些決策的理由有什么樣的認(rèn)識(shí)？
當(dāng)系統(tǒng)設(shè)計(jì)成型時(shí)，項(xiàng)目是如何影響那些決策的？
是否選擇了非標(biāo)準(zhǔn)化的內(nèi)容？
不使用公司標(biāo)準(zhǔn)的關(guān)鍵業(yè)務(wù)和技術(shù)需求是什么？
是否被業(yè)務(wù)案例所支持？
在業(yè)務(wù)案例中的假設(shè)是否已被審查？
用于評(píng)估硬件和操作系統(tǒng)的全生命周期成本的流程是什么？
公司財(cái)務(wù)管理是如何被引入到生命周期成本評(píng)估中去的？
是否進(jìn)行了供應(yīng)商的財(cái)務(wù)分析？
是否對(duì)供應(yīng)商提出了承諾？
是否堅(jiān)信需求僅被一個(gè)供應(yīng)商所滿足？
4.4.2 軟件服務(wù)和中間件問題清單
描述錯(cuò)誤條件是如何在應(yīng)用組件之間被定義、產(chǎn)生和傳播的。
描述在各個(gè)應(yīng)用模塊中關(guān)于方法定義和排列的通用模式。
描述在各個(gè)應(yīng)用模塊中關(guān)于方法參數(shù)定義和排列的通用模式。
描述用來最小化服務(wù)器和客戶端之間調(diào)用次數(shù)的方法，這對(duì)于在進(jìn)程間進(jìn)行具有復(fù)雜數(shù)據(jù)結(jié)構(gòu)的調(diào)用尤其重要。
描述在主要系統(tǒng)組件之間進(jìn)行傳遞的主要數(shù)據(jù)結(jié)構(gòu)。
描述在主要系統(tǒng)組件之間進(jìn)行通信所采用的協(xié)議。
描述在不同系統(tǒng)組件之間所使用的編組（marshaling）技術(shù)，并針對(duì)所使用的特定編組安排進(jìn)行描述。
描述系統(tǒng)在多大程度上設(shè)計(jì)有狀態(tài)（stateful）和無狀態(tài)（stateless）組件？
針對(duì)有狀態(tài)和無狀態(tài)組件來描述如何以及何時(shí)進(jìn)行狀態(tài)保存。
相比于對(duì)象池中對(duì)象的重用，描述在什么范圍內(nèi)對(duì)對(duì)象進(jìn)行創(chuàng)建、使用和銷毀。
描述系統(tǒng)依賴于線程或臨界區(qū)代碼的程度。
描述在系統(tǒng)內(nèi)部用來記錄方法、方法參數(shù)和方法功能的方式和內(nèi)部文檔。
描述代碼審查流程。
描述用來測(cè)試系統(tǒng)組件的單元測(cè)試。
描述包含在各種系統(tǒng)模塊中的前置和后置條件測(cè)試。
描述包含在系統(tǒng)中的斷言測(cè)試。
各個(gè)組件是否具備了它需要支持的所有接口？亦或某些關(guān)于何種類型組件采用語言綁定或其它形式的編組（marshaling）方式來調(diào)用其它組件的假設(shè)是否被制定？
描述在何種程度上對(duì)跨平臺(tái)的大字節(jié)或小字節(jié)數(shù)據(jù)格式問題進(jìn)行了處理。
描述在不同平臺(tái)上是否對(duì)數(shù)字和字符串的處理采用不同的方式。
描述是否軟件需要對(duì)浮點(diǎn)舍入誤差進(jìn)行檢查。
描述時(shí)間和數(shù)據(jù)是如何應(yīng)對(duì)千年蟲問題的。
描述何種工具和流程被用來就內(nèi)存泄漏、可達(dá)性（reachability）或一般魯棒性（general robustness）來對(duì)系統(tǒng)進(jìn)行測(cè)試的。
描述系統(tǒng)服務(wù)軟件的分層情況。描述主要系統(tǒng)組件之間的連接的一般數(shù)量。是否系統(tǒng)大量采用點(diǎn)對(duì)點(diǎn)方式進(jìn)行聯(lián)系，還是主要通過消息路由的方式？
描述系統(tǒng)組件松耦合或緊耦合的程度。
就共享庫(kù)、通信協(xié)議支持、負(fù)載平衡、事務(wù)處理、系統(tǒng)監(jiān)控、命名服務(wù)或其它基礎(chǔ)服務(wù)來講，系統(tǒng)對(duì)于底層基礎(chǔ)設(shè)施的需求是什么？
描述系統(tǒng)和系統(tǒng)組件是如何通過設(shè)計(jì)來達(dá)成重構(gòu)性的？
描述相對(duì)于采用點(diǎn)對(duì)點(diǎn)的通信結(jié)構(gòu)，系統(tǒng)或系統(tǒng)組件是如何依賴于通用消息基礎(chǔ)設(shè)施的？
4.4.3 應(yīng)用問題清單
基礎(chǔ)設(shè)施應(yīng)用
是否需要一些企業(yè)標(biāo)準(zhǔn)基礎(chǔ)設(shè)施應(yīng)用產(chǎn)品并沒有提供的能力？例如：
團(tuán)隊(duì)協(xié)作方面：
應(yīng)用共享
視頻會(huì)議
日程安排
電子郵件
工作流管理
出版/文字處理應(yīng)用
HTML
SGML和XML
可移植的文檔格式
文檔處理（專有格式）
桌面發(fā)布系統(tǒng)（Desktop publishing）
電子表格應(yīng)用
展示應(yīng)用
業(yè)務(wù)展示
圖片
動(dòng)畫
視頻
音響
基于計(jì)算機(jī)的培訓(xùn)系統(tǒng)（CBT：Computer-Based Trainning）
Web瀏覽器
數(shù)據(jù)管理應(yīng)用
數(shù)據(jù)庫(kù)接口
文檔管理
產(chǎn)品數(shù)據(jù)管理
數(shù)據(jù)倉(cāng)庫(kù)/集市
項(xiàng)目管理應(yīng)用
項(xiàng)目管理
項(xiàng)目可見度（Program visibility）管理
描述標(biāo)準(zhǔn)產(chǎn)品所不能滿足的對(duì)于企業(yè)基礎(chǔ)設(shè)施應(yīng)用能力的業(yè)務(wù)需求。
業(yè)務(wù)應(yīng)用
是否用于支持一條或多條業(yè)務(wù)線應(yīng)用的標(biāo)準(zhǔn)產(chǎn)品提供了所需要的能力？例如：
業(yè)務(wù)采購(gòu)應(yīng)用：
銷售和市場(chǎng)
工程應(yīng)用
計(jì)算機(jī)輔助設(shè)計(jì)
計(jì)算機(jī)輔助工程
數(shù)學(xué)和統(tǒng)計(jì)分析
供應(yīng)管理應(yīng)用
供應(yīng)鏈管理
客戶關(guān)系管理
生產(chǎn)應(yīng)用
企業(yè)資源規(guī)劃（ERP）應(yīng)用
制造執(zhí)行系統(tǒng)
制造質(zhì)量
制造工藝工程
機(jī)器和自適應(yīng)控制
客戶支持應(yīng)用
航空物流支持
維護(hù)工程
財(cái)務(wù)應(yīng)用
人員應(yīng)用
設(shè)施應(yīng)用
信息系統(tǒng)應(yīng)用
系統(tǒng)工程
軟件工程
Web開發(fā)工具
集成式開發(fā)環(huán)境
生命周期類別
功能類別
專業(yè)類別
計(jì)算機(jī)輔助生產(chǎn)
電子商務(wù)支持
業(yè)務(wù)流程工程
統(tǒng)計(jì)質(zhì)量控制
描述標(biāo)準(zhǔn)產(chǎn)品所不能滿足的對(duì)于業(yè)務(wù)應(yīng)用能力的流程需求。
應(yīng)用集成方法
架構(gòu)的目標(biāo)集成點(diǎn)（業(yè)務(wù)流程/活動(dòng)、應(yīng)用、數(shù)據(jù)、計(jì)算環(huán)境）是什么？
所采用的應(yīng)用集成技術(shù)是什么（通用數(shù)據(jù)對(duì)象、標(biāo)準(zhǔn)數(shù)據(jù)定義（STEP、XML等）、通用用戶界面展示）？
4.4.4 信息管理問題清單
數(shù)據(jù)價(jià)值方面
用于對(duì)數(shù)據(jù)的管理和使用進(jìn)行標(biāo)準(zhǔn)化的流程是什么？
用于支持?jǐn)?shù)據(jù)錄入和驗(yàn)證的業(yè)務(wù)流程是什么？數(shù)據(jù)的用處為何？
與數(shù)據(jù)的創(chuàng)建和修改相關(guān)的業(yè)務(wù)行為是什么？
與數(shù)據(jù)的刪除相關(guān)的業(yè)務(wù)行為是什么？是否這些數(shù)據(jù)被認(rèn)為是業(yè)務(wù)記錄的一部分？
業(yè)務(wù)用戶對(duì)于數(shù)據(jù)質(zhì)量的需求是什么？
當(dāng)前用于支持?jǐn)?shù)據(jù)引用完整性和/或規(guī)范化的流程是什么？
數(shù)據(jù)定義方面
所購(gòu)買的應(yīng)用的數(shù)據(jù)模型、數(shù)據(jù)定義、結(jié)構(gòu)以及主機(jī)選項(xiàng)（hosting options）都是什么？
用于定義和維護(hù)數(shù)據(jù)需求規(guī)則以及對(duì)信息系統(tǒng)中所有組件所進(jìn)行的設(shè)計(jì)是什么？
何種共享資源庫(kù)被用來保存數(shù)據(jù)模型內(nèi)容和數(shù)據(jù)的支持性信息？
用于設(shè)計(jì)數(shù)據(jù)庫(kù)的物理數(shù)據(jù)模型定義是什么？
所選擇的軟件開發(fā)和數(shù)據(jù)管理工具是什么？
已明確的對(duì)如下事項(xiàng)進(jìn)行負(fù)責(zé)的數(shù)據(jù)擁有者都有哪些？：
通用數(shù)據(jù)定義
計(jì)劃外冗余的消除
穩(wěn)定可靠性的提供
信息的及時(shí)性和準(zhǔn)確性
防止數(shù)據(jù)被濫用和破壞
安全/保護(hù)方面
為了防止數(shù)據(jù)被無意及未授權(quán)的更改、泄露和散布，對(duì)于數(shù)據(jù)實(shí)體及其屬性的訪問應(yīng)該制定什么樣的規(guī)則？
用于保護(hù)數(shù)據(jù)免于被外界進(jìn)行未授權(quán)訪問的數(shù)據(jù)保護(hù)機(jī)制是什么？
采用何種機(jī)制來控制企業(yè)內(nèi)部臨時(shí)駐留性外部資源對(duì)于數(shù)據(jù)的訪問？
托管、數(shù)據(jù)類型和共享方面
用于將單一授權(quán)數(shù)據(jù)作為一個(gè)邏輯數(shù)據(jù)源進(jìn)行管理的規(guī)程為何？這一邏輯數(shù)據(jù)源為貯存在不同平臺(tái)上的物理數(shù)據(jù)定義了更新規(guī)則。
用于對(duì)復(fù)制數(shù)據(jù)進(jìn)行管理的規(guī)程為何？這些復(fù)制數(shù)據(jù)來源于運(yùn)行中的單一授權(quán)數(shù)據(jù)。
已經(jīng)明確的用于儲(chǔ)存高級(jí)或中級(jí)重要度的運(yùn)行數(shù)據(jù)的層級(jí)數(shù)據(jù)服務(wù)器為何？
已經(jīng)明確的用于儲(chǔ)存C類型運(yùn)行數(shù)據(jù)的層級(jí)數(shù)據(jù)服務(wù)器為何？
已經(jīng)明確的用于儲(chǔ)存包含在一個(gè)數(shù)據(jù)倉(cāng)庫(kù)中的決策支持?jǐn)?shù)據(jù)的層級(jí)數(shù)據(jù)服務(wù)器為何？
所實(shí)現(xiàn)的數(shù)據(jù)庫(kù)管理系統(tǒng)為何？
通用服務(wù)
標(biāo)準(zhǔn)化的分布式數(shù)據(jù)管理服務(wù)（例如，數(shù)據(jù)驗(yàn)證、一致性檢查、數(shù)據(jù)編輯、加密以及事務(wù)管理）為何？這些服務(wù)存在于何處？
訪問方法
對(duì)于標(biāo)準(zhǔn)文件、消息和數(shù)據(jù)管理的數(shù)據(jù)訪問需求為何？
對(duì)于決策支持?jǐn)?shù)據(jù)的訪問需求為何？
數(shù)據(jù)存儲(chǔ)庫(kù)和應(yīng)用邏輯位置為何？
采用何種查詢語言？
4.4.5 安全方面問題清單
安全意識(shí)：
是否已確保正在使用的公司安全策略和導(dǎo)則是最新的版本？
是否已經(jīng)閱讀了最新版本的公司安全策略和導(dǎo)則？
是否了解所有相關(guān)的計(jì)算安全合規(guī)性和風(fēng)險(xiǎn)接受流程？
識(shí)別/認(rèn)證：對(duì)于一個(gè)用戶是如何被應(yīng)用所識(shí)別，以及此應(yīng)用是如何驗(yàn)證該用戶確為其所聲稱那個(gè)人的過程流進(jìn)行圖形表述。對(duì)這一圖形表述提供支持性文檔，從而對(duì)用戶界面和應(yīng)用/數(shù)據(jù)庫(kù)服務(wù)器之間的交互流程進(jìn)行解釋。是否符合公司關(guān)于賬戶、密碼等方面的策略？
授權(quán)：提供一個(gè)流程來展示一個(gè)用戶如何申請(qǐng)?jiān)L問某個(gè)應(yīng)用，從而指明了相關(guān)的安全控制以及責(zé)任的劃分。這一流程應(yīng)該包括：
申請(qǐng)是如何被適當(dāng)?shù)臄?shù)據(jù)擁有者所批準(zhǔn)？
用戶是如何被歸入到適當(dāng)?shù)脑L問級(jí)別分類設(shè)定檔中的？
用戶賬號(hào)、密碼和訪問是如何建立的，并如何提供給用戶的？
如何通知用戶對(duì)于應(yīng)用的使用責(zé)任？
如何變更密碼？
應(yīng)向誰請(qǐng)求幫助？
其他。
訪問控制：記錄用戶的賬戶、密碼和訪問配置是如何被增加、更改、刪除和記錄的？這一文檔還應(yīng)該包括對(duì)這些流程進(jìn)行負(fù)責(zé)的人員。
敏感信息保護(hù)：提供確定了需要額外保護(hù)的敏感數(shù)據(jù)的文檔。明確對(duì)這些數(shù)據(jù)進(jìn)行負(fù)責(zé)的數(shù)據(jù)擁有者，以及用來保護(hù)數(shù)據(jù)存儲(chǔ)、傳輸、打印和分發(fā)的流程。這包括：
如何對(duì)密碼文件或字段進(jìn)行保護(hù)？
如何防止用戶查看他人的敏感信息？
與外部團(tuán)體之間是否具有著信息保護(hù)的協(xié)議？如果是，具體責(zé)任和義務(wù)為何？
審計(jì)跟蹤和審計(jì)日志：
明確并記錄被多個(gè)用戶或應(yīng)用支持所需要的組賬戶。
明確并記錄個(gè)人賬戶和/或具有超級(jí)用戶權(quán)限的角色。
這些權(quán)限為何？
何人可以訪問這些賬戶？
如何對(duì)這些賬戶的訪問進(jìn)行控制和跟蹤，以及如何對(duì)其進(jìn)行日志記錄？
如何處理密碼的變更和分發(fā)？
明確審計(jì)日志：
何人可以讀取審計(jì)日志？
何人可以修改審計(jì)日志？
何人可以刪除審計(jì)日志？
如何保護(hù)和存儲(chǔ)審計(jì)日志？
用戶賬戶在審計(jì)日志中是否記錄不清？
外部訪問注意事項(xiàng)：
是否應(yīng)用只是內(nèi)部使用？
如果不是內(nèi)部使用，那么是否符合公司的外部訪問需求？
4.4.6 系統(tǒng)管理問題清單
必須被分發(fā)出去的軟件更新的頻率為何？
采用何種工具進(jìn)行軟件分發(fā)？
是否在產(chǎn)品中允許使用多個(gè)軟件和/或數(shù)據(jù)版本？
用戶數(shù)據(jù)的備份頻率以及期望的回復(fù)時(shí)間為何？
如何對(duì)用戶的賬戶進(jìn)行創(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ā)生之后）的審計(jì)日志的格式。
描述系統(tǒng)將其錯(cuò)誤消息發(fā)送給服務(wù)人員的能力。
4.4.7 系統(tǒng)工程/整體架構(gòu)問題清單
一般性問題
需要整合進(jìn)來的其他應(yīng)用和/或系統(tǒng)為何？
描述集成度水平和戰(zhàn)略。
用戶群的地理分布為何？
系統(tǒng)對(duì)于其他企業(yè)內(nèi)外用戶團(tuán)體的戰(zhàn)略重要性為何？
需要什么樣的計(jì)算資源來為企業(yè)內(nèi)的用戶、處于企業(yè)外并使用企業(yè)計(jì)算資產(chǎn)的用戶，以及處于企業(yè)外并使用他們自有資產(chǎn)的用戶提供系統(tǒng)服務(wù)？
處于本地交付環(huán)境之外的用戶如何訪問企業(yè)的應(yīng)用和數(shù)據(jù)？
當(dāng)前應(yīng)用的平均壽命為何？
描述用于適應(yīng)來源于用戶群、存儲(chǔ)的數(shù)據(jù)以及交付系統(tǒng)技術(shù)的變化的設(shè)計(jì)。
用戶群的規(guī)模以及他們的期望性能水平為何？
采用何種性能和壓力測(cè)試技術(shù)？
軟件和數(shù)據(jù)組件的整體組織方式為何？
整體的服務(wù)和系統(tǒng)配置為何？
軟件與數(shù)據(jù)是如何被配置和映射到服務(wù)及系統(tǒng)配置之上的？
此系統(tǒng)需要何種專門的軟硬件技術(shù)？
描述每個(gè)版本的軟件是如何隨著時(shí)間的推移而被重制和重新部署的？
描述當(dāng)前的用戶群，以及在之后的三到五年中對(duì)其變化的預(yù)期。
描述當(dāng)前的用戶群地理分布，以及在之后的三到五年中對(duì)其變化的預(yù)期。
描述在當(dāng)前或未來需要通過移動(dòng)或離線方式來對(duì)應(yīng)用進(jìn)行使用的用戶數(shù)量。
描述應(yīng)用的通常行為、其主要組件以及主要的數(shù)據(jù)流。
描述包含在應(yīng)用中并用于監(jiān)督其健康和性能狀況的儀器。
描述系統(tǒng)的業(yè)務(wù)緣由。
從初始開發(fā)成本對(duì)比長(zhǎng)期維護(hù)成本的角度出發(fā)，描述選擇系統(tǒng)開發(fā)語言的理由。
描述用于產(chǎn)生系統(tǒng)架構(gòu)及其產(chǎn)品選擇階段的系統(tǒng)分析流程。
除了原來的客戶之外還有誰會(huì)通過對(duì)此系統(tǒng)的使用而獲益？
通過瀏覽模式和更新模式來使用此系統(tǒng)的用戶比例為何？
事務(wù)性的申請(qǐng)數(shù)量通常為多少？
是否需要嚴(yán)格保障的數(shù)據(jù)傳輸或更新？系統(tǒng)是否容錯(cuò)？
系統(tǒng)的正常工作時(shí)間需求為何？
描述系統(tǒng)架構(gòu)符合或不符合標(biāo)準(zhǔn)的地方。
描述運(yùn)用在項(xiàng)目中的項(xiàng)目規(guī)劃和分析方法。
處理器/服務(wù)器/客戶端方面
描述客戶/服務(wù)器應(yīng)用架構(gòu)。
通過標(biāo)注圖示來闡述執(zhí)行應(yīng)用功能的地方。
客戶端方面
除了展示之外用戶設(shè)備是否還具有其他功能？
描繪數(shù)據(jù)和流程所提供的幫助功能。
描述“從屏到屏”的導(dǎo)航技術(shù)。
描述用戶如何在此應(yīng)用與其他應(yīng)用之間進(jìn)行導(dǎo)航。
如何從用戶設(shè)備上對(duì)此應(yīng)用以及其他應(yīng)用進(jìn)行啟動(dòng)？
是否具有應(yīng)用之間的數(shù)據(jù)和流程共享能力？如果是，描繪所共享的內(nèi)容，以及采用何種技術(shù)來實(shí)現(xiàn)共享。
描述傳輸?shù)娇蛻舳松系臄?shù)據(jù)量。
對(duì)于支持應(yīng)用的本地緩存數(shù)據(jù)的額外需求是什么？
對(duì)于支持應(yīng)用的本地軟件存儲(chǔ)/內(nèi)存的額外需求是什么？
是否存在由其他應(yīng)用需求或會(huì)對(duì)用戶產(chǎn)生影響的情況而導(dǎo)致的軟硬件沖突或容量限制？
描述當(dāng)前應(yīng)用與其他現(xiàn)存應(yīng)用之間展示層的感觀效果的對(duì)比情況。
描述客戶端在多大程度上支持異步和/或同步通信。
描述系統(tǒng)的展示層是如何與其他計(jì)算或數(shù)據(jù)傳輸層相分離的。
應(yīng)用服務(wù)器方面
展示層和應(yīng)用層是否可以運(yùn)行在不同的處理器之上？
應(yīng)用層和數(shù)據(jù)訪問層是否可以運(yùn)行在不同的處理器之上？
是否此應(yīng)用可以被放置到一個(gè)應(yīng)用服務(wù)器之上，并獨(dú)立于其他所有應(yīng)用？如不可以，則需要解釋這些應(yīng)用之間的依賴關(guān)系。
是否可以比較容易地添加額外的平行應(yīng)用服務(wù)器？如果可以，負(fù)載平衡機(jī)制為何？
是否應(yīng)用的資源需求被測(cè)量過了，且其值為何？如果已被測(cè)量，那么是否規(guī)劃的服務(wù)器容量已在應(yīng)用和總體級(jí)別上被確認(rèn)了？
數(shù)據(jù)服務(wù)器方面
是否存在其他應(yīng)用必須與當(dāng)前應(yīng)用共享數(shù)據(jù)服務(wù)器？如果是，則需要對(duì)這些應(yīng)用進(jìn)行明確，并描述其數(shù)據(jù)和數(shù)據(jù)訪問需求。
是否應(yīng)用的資源需求被測(cè)量過了，且其值為何？如果已被測(cè)量，那么是否規(guī)劃的服務(wù)器容量已在應(yīng)用和總體級(jí)別上被確認(rèn)了？
商用現(xiàn)成品（COTS）方面
廠商是否穩(wěn)定？
當(dāng)廠商消亡時(shí)企業(yè)是否會(huì)收到產(chǎn)品源代碼？
是否軟件按照企業(yè)的用途而進(jìn)行了配置？
是否存在特有的架構(gòu)和設(shè)計(jì)方面的數(shù)據(jù)或流程，從而阻礙了針對(duì)軟件的使用？
是否此軟件在當(dāng)前是可得的？
是否廠商使用或闡明的規(guī)模/可用性/服務(wù)水平與企業(yè)的需求相類似？
描述廠商過往的財(cái)務(wù)和市場(chǎng)份額歷史。
4.4.8 系統(tǒng)工程/方法與工具問題清單
是否具有對(duì)當(dāng)前業(yè)務(wù)操作方法的評(píng)定指標(biāo)？
系統(tǒng)擁有者是否已經(jīng)創(chuàng)建了用于指導(dǎo)當(dāng)前項(xiàng)目的評(píng)估標(biāo)準(zhǔn)？如果有，則對(duì)如何使用這些評(píng)估標(biāo)準(zhǔn)進(jìn)行描述。
是否對(duì)于現(xiàn)存架構(gòu)的研究已經(jīng)完成，從而使得當(dāng)前的工作成果能夠得以被充分利用？描述在這一研究中所使用的發(fā)現(xiàn)和認(rèn)識(shí)方法。是否現(xiàn)存的這些架構(gòu)需要被整合？如果是，解釋將會(huì)采用的方法。
描述將會(huì)應(yīng)用到項(xiàng)目中的方法：
用于定義業(yè)務(wù)戰(zhàn)略的方法。
用于定義需要改善的領(lǐng)域的方法。
用于定義基線和目標(biāo)業(yè)務(wù)流程的方法。
用于定義過渡流程的方法。
用于管理項(xiàng)目的方法。
用于團(tuán)隊(duì)溝通的方法。
用于知識(shí)管理、變更管理和配置管理的方法。
用于軟件開發(fā)的方法。
用于引用標(biāo)準(zhǔn)和方向說明的方法。
用于交付物的質(zhì)量保證的方法。
用于設(shè)計(jì)審查和交付驗(yàn)收的方法。
用于達(dá)成指標(biāo)的方法。
是否各個(gè)方法已被記錄，并被分發(fā)給了每個(gè)團(tuán)隊(duì)成員？
團(tuán)隊(duì)成員在多大程度上熟悉這些方法？
采用何種流程來確保方法執(zhí)行的符合性？
描繪當(dāng)前所采用的用于支持方法使用的基礎(chǔ)設(shè)施。
如何提供咨詢和故障排除？
如何協(xié)調(diào)安排培訓(xùn)？
如何合并和關(guān)聯(lián)各種變更和改進(jìn)？
如何獲取經(jīng)驗(yàn)教訓(xùn)，并對(duì)其進(jìn)行溝通？
關(guān)于項(xiàng)目所采用的工具為何？（指定版本和平臺(tái)）。團(tuán)隊(duì)成員對(duì)這些工具的熟悉度為何？
描繪當(dāng)前所采用的用于支持此工具使用的基礎(chǔ)設(shè)施。
如何提供咨詢和故障排除？
如何協(xié)調(diào)安排培訓(xùn)？
如何合并和關(guān)聯(lián)各種變更和改進(jìn)？
如何獲取經(jīng)驗(yàn)教訓(xùn)，并對(duì)其進(jìn)行溝通？
描述項(xiàng)目如何促進(jìn)對(duì)其交付物及所交付內(nèi)容的重用。
在項(xiàng)目實(shí)現(xiàn)后此架構(gòu)設(shè)計(jì)是否還會(huì)存續(xù)？描述用來將變更合并入此架構(gòu)設(shè)計(jì)的方法。
當(dāng)前流程是否被定義？
是否各種問題已經(jīng)被記錄和評(píng)定，并與當(dāng)前流程關(guān)聯(lián)起來？如果沒有，那又如何得知已經(jīng)出現(xiàn)問題的地方正在被修正？
是否現(xiàn)存或規(guī)劃的流程改善活動(dòng)已被明確，并與當(dāng)前流程關(guān)聯(lián)起來？如果沒有，那又如何知道此活動(dòng)與其他工作說明書中的內(nèi)容不會(huì)發(fā)生沖突或相互冗余？
當(dāng)前是否存在各種評(píng)估指標(biāo)？當(dāng)前是否存在預(yù)測(cè)指標(biāo)？如果沒有，那又如何得知獲得了改善？
采用何種流程來收集、評(píng)估和匯報(bào)各種指標(biāo)？
新的設(shè)計(jì)對(duì)于現(xiàn)存業(yè)務(wù)流程、組織結(jié)構(gòu)和信息系統(tǒng)有什么樣的影響？是否這些影響已經(jīng)被記錄到文檔之中，并與其他干系人進(jìn)行共享？
4.5 架構(gòu)合規(guī)性審查實(shí)踐導(dǎo)則
4.5.1 裁剪和定制問題清單導(dǎo)則
關(guān)注于：
高風(fēng)險(xiǎn)區(qū)域。
預(yù)期的（突發(fā)的）差異。
對(duì)于清單中的每條問題，需要理解：
問題本身的含義。
問題背后的原則。
在回應(yīng)中需要尋找什么樣的內(nèi)容。
尋求領(lǐng)域?qū)＜业囊庖姟?div style="height:15px;">
理解審查的目標(biāo)，并始終保持在正確的軌道之上對(duì)提出的問題提供適合的交付物。例如，人們通常希望了解正在架構(gòu)的系統(tǒng)的對(duì)錯(cuò)之處，而不是希望了解諸如所采用的開發(fā)方法是否正確、管理組織結(jié)構(gòu)是否合理等這些方面，因而在審查中就會(huì)經(jīng)常偏離主題。
隨著審查討論的進(jìn)行，其他一些需要被解決的問題將會(huì)逐漸顯現(xiàn)，而且這些問題還常常會(huì)超出當(dāng)前審查的范圍。在這種情況下，我們需要在此次審查會(huì)后對(duì)其進(jìn)行處理，并依照這些問題的重要性來制定一份用于解決這些問題的計(jì)劃。
保持科學(xué)的態(tài)度。與其說“我們期望看到大型數(shù)據(jù)庫(kù)放置在ABC之上而不放在XYZ”，我們更應(yīng)該說“XYZ數(shù)據(jù)庫(kù)環(huán)境之下的停機(jī)時(shí)間遠(yuǎn)遠(yuǎn)超過在ABC數(shù)據(jù)庫(kù)環(huán)境之中的狀況。因此我們不推薦將M和N系統(tǒng)放置到XYZ環(huán)境中”。
在審查的征詢過程中經(jīng)常會(huì)存在隱藏的日程或有爭(zhēng)議的問題，而這些內(nèi)容在前期是無法預(yù)知的，因而采用一個(gè)非個(gè)性化的方法來進(jìn)行討論將會(huì)彌合這些差距而不是加劇他們。
尊重面談的對(duì)象。他們可能不會(huì)采用合適的方法來構(gòu)建系統(tǒng)，但是他們可能在其所處的環(huán)境中已經(jīng)盡了最大的努力。
審查應(yīng)該包括針對(duì)架構(gòu)的詳細(xì)評(píng)估活動(dòng)，并確保其結(jié)果被存儲(chǔ)到企業(yè)連續(xù)體之中。
架構(gòu)合同是在開發(fā)團(tuán)體和贊助者之間關(guān)于架構(gòu)的交付物、質(zhì)量以及適用目標(biāo)的聯(lián)合協(xié)議，并且通過有效的架構(gòu)治理將會(huì)促使這些協(xié)議的成功施行。通過對(duì)合同的管理施行一個(gè)治理方法，如下幾點(diǎn)將會(huì)得到保障：
一個(gè)連續(xù)監(jiān)測(cè)系統(tǒng)，用于檢查完整性、變更、決策，并對(duì)組織內(nèi)所有架構(gòu)相關(guān)活動(dòng)進(jìn)行審計(jì)。
對(duì)于為合同進(jìn)行負(fù)責(zé)的治理組織、其權(quán)威等級(jí)以及它所負(fù)責(zé)的架構(gòu)范圍產(chǎn)生一個(gè)正式的理解。
在企業(yè)架構(gòu)開發(fā)方法的各階段中經(jīng)常會(huì)見到架構(gòu)合同的身影，例如架構(gòu)愿景階段中的架構(gòu)工作說明書等。但無論是何種架構(gòu)協(xié)議，我們都要牢記企業(yè)架構(gòu)開發(fā)的終極目標(biāo)是創(chuàng)建一個(gè)動(dòng)態(tài)的企業(yè)架構(gòu)，亦即該架構(gòu)可以適應(yīng)外界技術(shù)和業(yè)務(wù)環(huán)境的變化而靈活地演進(jìn)，而架構(gòu)合同對(duì)于促成這一動(dòng)態(tài)企業(yè)架構(gòu)的實(shí)現(xiàn)，以及針對(duì)此實(shí)現(xiàn)的治理是非常重要的。
架構(gòu)工作說明書產(chǎn)生于架構(gòu)開發(fā)方法的架構(gòu)愿景階段，它是架構(gòu)組織和企業(yè)架構(gòu)贊助者之間的所簽訂的協(xié)議，其具體內(nèi)容請(qǐng)參見之前架構(gòu)內(nèi)容框架中的相關(guān)內(nèi)容。
此合同是一份為設(shè)計(jì)和開發(fā)企業(yè)架構(gòu)而簽署的意向說明，亦或是其中一個(gè)重要部分。此合同所涉及到的團(tuán)隊(duì)組織包括系統(tǒng)集成者、應(yīng)用提供者和服務(wù)提供者。隨著合作分工的逐漸細(xì)化，針對(duì)一個(gè)或多個(gè)架構(gòu)領(lǐng)域（業(yè)務(wù)、數(shù)據(jù)、應(yīng)用和技術(shù)）的開發(fā)已經(jīng)越來越多的被外包出去，而企業(yè)架構(gòu)組織則主要負(fù)責(zé)在整體上進(jìn)行監(jiān)督和協(xié)調(diào)，并且在有些情況下，這一監(jiān)督性角色的任務(wù)也被外包到企業(yè)之外。但無論怎樣安排這些外包任務(wù)，這些安排都需要在架構(gòu)合同的治理之下來進(jìn)行。這些架構(gòu)合同定義了所開發(fā)架構(gòu)的交付物、質(zhì)量、適用目標(biāo)以及架構(gòu)開發(fā)團(tuán)隊(duì)之間進(jìn)行合作的各種流程。通常來講，這些架構(gòu)的內(nèi)容包括如下幾點(diǎn)：
當(dāng)企業(yè)架構(gòu)被實(shí)現(xiàn)之后，在架構(gòu)功能組織（或整合了架構(gòu)功能的IT治理組織）和業(yè)務(wù)用戶（他們將會(huì)在所設(shè)計(jì)的架構(gòu)環(huán)境中創(chuàng)建和部署各個(gè)應(yīng)用系統(tǒng)）之間就需要達(dá)成一份架構(gòu)合同（此合同還可以被用來在架構(gòu)變更階段中對(duì)企業(yè)架構(gòu)變更進(jìn)行管理），而這份業(yè)務(wù)用戶架構(gòu)合同（Business Users’ Architecture Contract）的內(nèi)容通常包括如下幾點(diǎn)：
在企業(yè)架構(gòu)開發(fā)方法過程的實(shí)施治理階段中所產(chǎn)生的各種架構(gòu)合同文檔主要處于架構(gòu)治理領(lǐng)域之中。在架構(gòu)治理的背景之下，這些架構(gòu)合同經(jīng)常被用來作為驅(qū)動(dòng)架構(gòu)變更的一種手段。為了確保這些架構(gòu)合同的效能，如下幾個(gè)治理框架的方面需要被引入到實(shí)施治理階段之中：
由于各個(gè)組織所處的環(huán)境并不是一成不變的，因而能夠?qū)@些變化進(jìn)行快速反應(yīng)并與之相適應(yīng)的組織將會(huì)比那些缺乏應(yīng)變能力的組織獲得更大的優(yōu)勢(shì)。隨著IT技術(shù)的日益發(fā)展以及與組織業(yè)務(wù)聯(lián)系的日趨緊密，每個(gè)組織都知道為了管理所有可能出現(xiàn)的變化需要不斷地改其與IT相關(guān)的開發(fā)流程，但對(duì)于很多組織來說，在哪些方面進(jìn)行改進(jìn)以及如何改進(jìn)的確是個(gè)讓人頭疼的問題。所以在實(shí)踐過程中，有的組織要么由于不知如何下手而投入過少，要么進(jìn)行漫無目標(biāo)的投入而導(dǎo)致投資回報(bào)率過低。那么各個(gè)組織如何才能解決這一問題，從而使得其所做的改進(jìn)努力更加有目的性，并得到足夠好的回報(bào)呢？其實(shí)這一問題的答案就是在組織中建立和運(yùn)用能力成熟度模型（CMMs：Capability Maturity Models）。通過使用這些模型，組織可以得到如下效益：
能力成熟度模型并不是專為企業(yè)架構(gòu)而生，其實(shí)它最初目標(biāo)是為了改善軟件和系統(tǒng)工程的過程，只是隨著企業(yè)架構(gòu)理論的發(fā)展以及業(yè)界針對(duì)這一領(lǐng)域的關(guān)注逐漸加強(qiáng)，人們才開始考慮將這一模型應(yīng)用到企業(yè)架構(gòu)的領(lǐng)域之中，從而為評(píng)測(cè)和改進(jìn)企業(yè)架構(gòu)的過程提供導(dǎo)向。在TOGAF 9中并沒有為企業(yè)架構(gòu)專門設(shè)計(jì)一套成熟度模型，它只是通過例舉兩種成熟度模型來介紹當(dāng)前企業(yè)架構(gòu)是如何與能力成熟度模型相結(jié)合的，以供讀者借鑒。
在前面已經(jīng)提到過，美國(guó)政府可以說是施行企業(yè)架構(gòu)的先行者之一，因而所有的美國(guó)聯(lián)邦政府部門都被要求提供成熟度模型以及相應(yīng)的打分機(jī)制來作為他們的IT投資管理和審計(jì)需求的一部分。以美國(guó)商務(wù)部（US Department of Commerce（DoC））為例，他就已經(jīng)開發(fā)出了一套企業(yè)架構(gòu)能力成熟度模型（ACMM：Architecture Capability Maturity Model）來幫助其內(nèi)部的企業(yè)架構(gòu)成熟度評(píng)測(cè)。這一成熟度模型在2007年12月時(shí)發(fā)布了1.2版本。ACMM提供了一套框架，其中包含了一個(gè)富有成效的企業(yè)架構(gòu)過程所應(yīng)具備的各種關(guān)鍵組件，其目標(biāo)在于通過明確企業(yè)架構(gòu)的薄弱環(huán)節(jié)并提供一條定義良好的演進(jìn)改善路線來提升企業(yè)架構(gòu)的成功幾率。ACMM包含如下三部分內(nèi)容：
在上述三個(gè)部分的內(nèi)容中，前兩部份描述了架構(gòu)能力成熟度水平、相應(yīng)的企業(yè)架構(gòu)元素，以及用在成熟度評(píng)測(cè)中的每個(gè)成熟度水平的特性；最后一個(gè)部分被用來獲取用于向商務(wù)部首席信息官（CIO）進(jìn)行匯報(bào)的架構(gòu)能力成熟度水平。
截至到目前，成熟度模型已經(jīng)在很多行業(yè)中得到了接受和施行，而且每個(gè)行業(yè)幾乎都具有符合其自身特點(diǎn)的成熟度模型，但是正是由于這種廣泛的接受性導(dǎo)致了成熟度模型過于繁雜。為了管理這一由于過多成熟度模型所帶來復(fù)雜性，SEI（Software Engineering Institute）開發(fā)了一個(gè)名為能力成熟度模型集成（CMMI：Capability Maturity Model Integration）的框架。該框架綜合了各領(lǐng)域成熟度模型的最佳實(shí)踐，它使得組織可以：
由于CMMI并不是隸屬于某個(gè)特定行業(yè)的綜合性成熟度模型，因而在企業(yè)架構(gòu)的成熟度方面也可以對(duì)其進(jìn)行借鑒，而這其中最為重要的就是標(biāo)準(zhǔn)過程改進(jìn)評(píng)估方法（SCAMPI ：Standard CMMI Appraisal Method for Process Improvement）。此方法是與CMMI相關(guān)連的評(píng)估方法，被用來與CMMI參考模型進(jìn)行比對(duì)，從而對(duì)目標(biāo)的優(yōu)勢(shì)、弱點(diǎn)進(jìn)行明確，并通過分?jǐn)?shù)評(píng)定的方式進(jìn)行清晰的表述。
企業(yè)架構(gòu)過程是個(gè)非常繁雜的過程，它的順利進(jìn)行離不開眾多具有不同角色的人員的通力協(xié)作，而如何保證這些相互合作的人員在各自崗位上能夠勝任就變成一切活動(dòng)的根本問題。為了應(yīng)對(duì)這一問題，TOGAF提出了架構(gòu)技能框架（Architecture Skills Framework），它為進(jìn)行企業(yè)架構(gòu)建設(shè)的組織提供了一份關(guān)于企業(yè)架構(gòu)工作中各種角色及其能力的視圖，從而為擔(dān)負(fù)企業(yè)架構(gòu)工作任務(wù)的團(tuán)隊(duì)的建立提供了導(dǎo)則。簡(jiǎn)單來講，架構(gòu)技能框架的內(nèi)容包含如下三個(gè)方面：
在實(shí)踐中，每個(gè)企業(yè)對(duì)于項(xiàng)目人員的選擇應(yīng)該都有著自己的一套方法和流程，基本上來講，都是通過項(xiàng)目本身的特質(zhì)來制定所需人員的技能標(biāo)準(zhǔn)，并通過簡(jiǎn)單的面試來從組織內(nèi)外的候選者中選擇合適之人，但這對(duì)于企業(yè)架構(gòu)的建設(shè)來講卻過于簡(jiǎn)單了。雖然企業(yè)架構(gòu)的建設(shè)從本質(zhì)上來講也是一個(gè)項(xiàng)目，但是由于其本身的復(fù)雜度之高、牽涉性之廣，如果把它當(dāng)作一個(gè)普通實(shí)現(xiàn)項(xiàng)目來對(duì)待的話，組織往往會(huì)面臨如下風(fēng)險(xiǎn)：
對(duì)運(yùn)營(yíng)的IT系統(tǒng)以及對(duì)其進(jìn)行交付的項(xiàng)目的時(shí)間、成本和質(zhì)量將產(chǎn)生巨大影響。
為了盡量避免這些風(fēng)險(xiǎn)，各個(gè)組織應(yīng)該采用更為正式的認(rèn)證機(jī)制來對(duì)企業(yè)架構(gòu)工作人員進(jìn)行定義和選擇，而這一機(jī)制的目的應(yīng)該在于如下兩點(diǎn)：
作為建立和維護(hù)一個(gè)專業(yè)架構(gòu)組織的任務(wù)的一部分，對(duì)架構(gòu)人員所需的技能進(jìn)行正式認(rèn)可。
企業(yè)架構(gòu)（Enterprise Architecture）：此種類型的架構(gòu)可以看作是下面幾個(gè)領(lǐng)域（業(yè)務(wù)、數(shù)據(jù)、應(yīng)用和技術(shù)）中的架構(gòu)的超集。
其他角色...
業(yè)務(wù)技能和方法（Business Skills & Methods）：通常包括業(yè)務(wù)案例、業(yè)務(wù)流程和戰(zhàn)略規(guī)劃等。
企業(yè)架構(gòu)技能（Enterprise Architecture Skills）：通常包括建模、構(gòu)建塊設(shè)計(jì)、應(yīng)用和角色設(shè)計(jì)、系統(tǒng)集成等。
方案或項(xiàng)目管理技能（Program or Project Management Skills）：通常包括管理業(yè)務(wù)變更、項(xiàng)目管理方法和工具等。
通用IT知識(shí)技能（IT General Knowledge Skills）：通常包括代理應(yīng)用（brokering applications）、資產(chǎn)管理、遷移規(guī)劃以及SLAs等。
在前面提到過的各種角色之中，最經(jīng)常被提到的恐怕要數(shù)“企業(yè)架構(gòu)師”這一角色了，而這也正是因?yàn)檫@一角色是整個(gè)企業(yè)架構(gòu)建設(shè)的核心。雖然非常重要且常被掛在嘴角，但其在各行業(yè)中正式的定義卻鮮有所聞，而僅僅被當(dāng)作一個(gè)跨越多個(gè)架構(gòu)領(lǐng)域具有廣泛實(shí)踐經(jīng)驗(yàn)和技能的角色。TOGAF對(duì)于企業(yè)架構(gòu)師的工作描述總結(jié)為如下幾點(diǎn)：
負(fù)責(zé)保證架構(gòu)的完整性，即所有種類不同的視圖關(guān)聯(lián)在一起，圓滿調(diào)和不同干系人之間的沖突點(diǎn)，并展示出此種調(diào)和所帶來的利益權(quán)衡。
企業(yè)架構(gòu)師所要做的重要決策之一就是針對(duì)各種干系人關(guān)注點(diǎn)來選擇開發(fā)特定的視圖。這一選擇需要注意其可實(shí)踐性，并要在符合適用目標(biāo)（fitness-for-purpose）的原則下進(jìn)行。
架構(gòu)師的職責(zé)范圍貫穿了企業(yè)架構(gòu)的整個(gè)生命周期，它開始于與客戶一起理解其真正的需求，并在其后的過程中負(fù)責(zé)將這些需求轉(zhuǎn)化為能夠?qū)ζ溥M(jìn)行實(shí)現(xiàn)的各項(xiàng)能力。此外，架構(gòu)師還需要通過不同模型的展示來與客戶就其需求是如何被滿足的進(jìn)行溝通。由此可見，架構(gòu)師與負(fù)責(zé)建設(shè)的團(tuán)隊(duì)是不同的，他的主要目標(biāo)在于理解如何才能滿足客戶的需要，并就此為負(fù)責(zé)建設(shè)的應(yīng)用開發(fā)團(tuán)隊(duì)或產(chǎn)品實(shí)現(xiàn)團(tuán)隊(duì)提供設(shè)計(jì)決策文檔。與建設(shè)者相比，架構(gòu)師需要保持一定水平的抽象性，并且通常其所使用的技能應(yīng)該是歸納性的，而建設(shè)者則更加注重于實(shí)現(xiàn)方面，其所采用的技能也往往是推斷性的。綜上所述，架構(gòu)師的角色職能可以總結(jié)如下：
理解并解釋需求：探索信息、傾聽信息、影響他人、促進(jìn)共識(shí)、將各種觀點(diǎn)綜合轉(zhuǎn)換為可行的需求、并將這些觀點(diǎn)解釋給他人。此外，還包括明確用途或目標(biāo)、約束以及風(fēng)險(xiǎn)等因素。架構(gòu)師將參與到針對(duì)各種客戶業(yè)務(wù)情景的發(fā)掘之中，并對(duì)其進(jìn)行文檔記錄。架構(gòu)師還負(fù)責(zé)針對(duì)需求進(jìn)行理解，并將這些理解融入到架構(gòu)說明規(guī)范之中。
創(chuàng)建有用的模型：根據(jù)需求來開發(fā)各種經(jīng)過精心定制的模型，并在必要的情況下對(duì)這些模型進(jìn)行充實(shí)，使其能夠適應(yīng)所有的環(huán)境。架構(gòu)師還將以這些模型為基礎(chǔ)來展示出各種視圖，從而提升與干系人之間所進(jìn)行溝通的有效性。架構(gòu)師為整體架構(gòu)的完整性進(jìn)行負(fù)責(zé)，并負(fù)責(zé)從架構(gòu)的視角來對(duì)所提供的愿景進(jìn)行維護(hù)。此外，架構(gòu)師還要確保對(duì)各種明確的機(jī)會(huì)進(jìn)行利用、采用各種構(gòu)建塊，并充當(dāng)各個(gè)功能組織之間的聯(lián)絡(luò)員。為了理解開發(fā)工作的各個(gè)領(lǐng)域，并對(duì)組織內(nèi)外所應(yīng)采取的行為進(jìn)行指導(dǎo)，架構(gòu)師需要以框架的方式對(duì)這些模型進(jìn)行提供和維護(hù)，此外架構(gòu)師還必須通過對(duì)所有必須的業(yè)務(wù)組件的理解來表現(xiàn)架構(gòu)的組織視圖。
驗(yàn)證、修繕并擴(kuò)展模型：對(duì)各種假設(shè)進(jìn)行驗(yàn)證，并將其輸入給主題專家。為了改善模型并對(duì)其進(jìn)行進(jìn)一步的定義，架構(gòu)師需要為模型加入必須的新觀點(diǎn)，從而使得模型更加靈活，并能夠與當(dāng)前及期望的需求聯(lián)系得更加緊密。除此之外，架構(gòu)師還應(yīng)該對(duì)產(chǎn)生于現(xiàn)場(chǎng)工作用于對(duì)解決方案進(jìn)行增強(qiáng)的開發(fā)的價(jià)值進(jìn)行評(píng)估，并將這些內(nèi)容適當(dāng)?shù)厝谌氲郊軜?gòu)模型之中。
管理架構(gòu)：對(duì)模型進(jìn)行持續(xù)監(jiān)督，并在必要時(shí)對(duì)其進(jìn)行更新，從而展示出了各種變化、新增和調(diào)整。在項(xiàng)目的開發(fā)和決策點(diǎn)對(duì)各種架構(gòu)和問題進(jìn)行表現(xiàn)。在整個(gè)開發(fā)周期中，架構(gòu)師需要持續(xù)地促進(jìn)組織間對(duì)于客戶、架構(gòu)和技術(shù)信息的共享。
在前面有關(guān)企業(yè)連續(xù)體的部分中我們已經(jīng)了解到，對(duì)于構(gòu)建塊的實(shí)現(xiàn)可能會(huì)受其復(fù)雜性所限而需要對(duì)其解決方案的實(shí)施進(jìn)行進(jìn)一步劃分，而在這種情況下就需要多種架構(gòu)師的通力協(xié)作。從企業(yè)連續(xù)體的角度來說，架構(gòu)師這一角色可以分為如下幾種，并且其中的每一種都具備著各自的關(guān)注點(diǎn)：
企業(yè)架構(gòu)師（Enterprise Architect）：從全景和技術(shù)參考模型的層次來為架構(gòu)設(shè)計(jì)和文檔進(jìn)行負(fù)責(zé)。企業(yè)架構(gòu)師通常領(lǐng)導(dǎo)一組與某一給定方案相關(guān)的片段架構(gòu)師和/或解決方案架構(gòu)師，并且其關(guān)注點(diǎn)在于所需要的企業(yè)級(jí)業(yè)務(wù)功能。
片段架構(gòu)師（Segment Architect）：負(fù)責(zé)特定業(yè)務(wù)問題或組織領(lǐng)域內(nèi)的架構(gòu)設(shè)計(jì)和文檔。一個(gè)片段架構(gòu)師將會(huì)對(duì)其他架構(gòu)師的輸出進(jìn)行重用，并將詳細(xì)的技術(shù)解決方案加入到整體架構(gòu)全景之中。片段架構(gòu)師的關(guān)注點(diǎn)在于一個(gè)給定領(lǐng)域（例如財(cái)務(wù)、人力資源以及銷售等）中的企業(yè)級(jí)業(yè)務(wù)解決方案。
解決方案架構(gòu)師（Solution Architect）：在系統(tǒng)或子系統(tǒng)級(jí)別對(duì)架構(gòu)設(shè)計(jì)和文檔進(jìn)行負(fù)責(zé)。一個(gè)解決方案架構(gòu)師可以為企業(yè)或片段架構(gòu)師屏蔽不必要的系統(tǒng)、產(chǎn)品和/或技術(shù)方面的細(xì)節(jié)，并且其關(guān)注點(diǎn)在于系統(tǒng)技術(shù)解決方案方面，例如諸如企業(yè)數(shù)據(jù)倉(cāng)庫(kù)之類的解決方案組件。
熟悉創(chuàng)建設(shè)計(jì)的技能和經(jīng)驗(yàn)：企業(yè)架構(gòu)師必須熟練掌握創(chuàng)建復(fù)雜系統(tǒng)設(shè)計(jì)的各項(xiàng)技術(shù)，這包括需求發(fā)現(xiàn)和分析、解決方案上下文的制定、對(duì)各種可能的解決方案進(jìn)行識(shí)別和評(píng)定、技術(shù)選型以及設(shè)計(jì)配置。
具備寬泛的技術(shù)廣度，并在一個(gè)或幾個(gè)領(lǐng)域中具備一定技術(shù)深度：企業(yè)架構(gòu)師應(yīng)該對(duì)IT行業(yè)有著寬泛的技術(shù)廣度，并且這一廣度應(yīng)該涵蓋應(yīng)用開發(fā)和部署，以及針對(duì)用于支持復(fù)雜應(yīng)用環(huán)境的基礎(chǔ)設(shè)施的創(chuàng)建和維護(hù)方面。當(dāng)前的IT環(huán)境包羅萬象，而為了應(yīng)對(duì)各種情況，有經(jīng)驗(yàn)的企業(yè)架構(gòu)師將具備跨越多個(gè)平臺(tái)的技能，這包括了分布式系統(tǒng)以及傳統(tǒng)的大型機(jī)環(huán)境。此外，企業(yè)架構(gòu)師還應(yīng)至少在一個(gè)領(lǐng)域中具備專家級(jí)的水平。
以方法驅(qū)動(dòng)（Method-Driven）的方式來進(jìn)行工作：企業(yè)架構(gòu)師應(yīng)該使用已被確認(rèn)的方法（例如TOGAF）來進(jìn)行工作。企業(yè)架構(gòu)師應(yīng)會(huì)使用一種以上的設(shè)計(jì)方法，并會(huì)根據(jù)工作狀態(tài)自如地選擇合適的方法或方法的一部分，亦即架構(gòu)師應(yīng)該了解在某給定情況下何種方法或方法部分可以被采用，而何種則不可以。
具備全項(xiàng)目范圍的經(jīng)驗(yàn)：當(dāng)企業(yè)架構(gòu)師對(duì)用于實(shí)現(xiàn)的項(xiàng)目的設(shè)計(jì)和執(zhí)行進(jìn)行負(fù)責(zé)時(shí)，他們對(duì)項(xiàng)目所有的方面具備經(jīng)驗(yàn)是非常重要的。這些項(xiàng)目方面包括了開發(fā)、測(cè)試、實(shí)現(xiàn)和生產(chǎn)。企業(yè)架構(gòu)師所掌握的項(xiàng)目經(jīng)驗(yàn)的范圍有助于其立于“適合目標(biāo)（fitness-for-purpose）”以及系統(tǒng)實(shí)現(xiàn)的現(xiàn)實(shí)性的基礎(chǔ)之上，而且全項(xiàng)目范圍經(jīng)驗(yàn)所帶來的影響將會(huì)引導(dǎo)企業(yè)架構(gòu)師制定出更好的設(shè)計(jì)決策，并在這些決策之間獲得更好的平衡。
具備領(lǐng)導(dǎo)力：溝通和團(tuán)隊(duì)協(xié)作對(duì)于企業(yè)架構(gòu)師這一角色的成功實(shí)現(xiàn)來講是關(guān)鍵，并且良好的技術(shù)技能和領(lǐng)導(dǎo)能力的結(jié)合對(duì)其來講也是至關(guān)重要的。企業(yè)架構(gòu)師應(yīng)被IT組織、其所服務(wù)的客戶以及管理層看作企業(yè)中的一個(gè)領(lǐng)導(dǎo)者。
具備人際關(guān)系和專業(yè)方面的技能：由于企業(yè)架構(gòu)師的主要任務(wù)之一就是與所有干系人（包括沒有技術(shù)背景的干系人）就復(fù)雜的技術(shù)信息進(jìn)行溝通，所以企業(yè)架構(gòu)師必須具備很強(qiáng)的溝通和人際關(guān)系技能。此外，企業(yè)架構(gòu)師還需要具備很強(qiáng)的談判及解決問題的能力，因?yàn)槠髽I(yè)架構(gòu)師還必須與項(xiàng)目管理團(tuán)隊(duì)一起工作來及時(shí)地制定決策，從而保證項(xiàng)目運(yùn)行在正確軌道之上。
具備一個(gè)或多個(gè)行業(yè)中的技能和經(jīng)驗(yàn)：行業(yè)技能和經(jīng)驗(yàn)將會(huì)使得收集需求及關(guān)于優(yōu)先級(jí)的決策任務(wù)更加簡(jiǎn)單和有效。企業(yè)架構(gòu)師必須理解企業(yè)的業(yè)務(wù)流程，以及這些流程是如何與行業(yè)中的其他企業(yè)協(xié)同工作的。企業(yè)架構(gòu)師還應(yīng)能發(fā)現(xiàn)主要的趨勢(shì)，并對(duì)有缺陷的流程進(jìn)行修正，從而給予IT組織對(duì)企業(yè)進(jìn)行引導(dǎo)的能力，而不僅僅是對(duì)需求進(jìn)行回應(yīng)而已。企業(yè)架構(gòu)師的任務(wù)是進(jìn)行戰(zhàn)略技術(shù)領(lǐng)導(dǎo)。
