企業架構研究總結（39）——TOGAF架構能力框架之架構委員會和架構合規性

3. 架構委員會

      正如前面所說，一個用來對架構治理策略的實現進行監督的跨組織的架構委員會是架構治理策略成功的主要要素之一。架構委員會應該可以表明全部主要干係人的需求，而且一般還須要對整個架構的審查及維護活動負有高級行政職責。一般來說，架構委員會須要對以下目標的達成進行負責：

• 子架構之間的一致性。
• 肯定可重用組件。
• 保證企業架構的靈活性：
• 知足不斷變化的業務需求。
• 儘量的利用不斷出現的新技術。
• 嚴格確保架構合規性。
• 改善組織中架構規程的成熟度水平。
• 確保採用以架構爲基礎的開發規程。
• 爲全部關於架構變動的決策提供基礎。
• 爲超出範圍的決策提供升級的能力。

      若是從執行的角度來看，架構委員會還須要承擔以下責任：

• 有關架構合同的監督和控制的全部方面。
• 按期舉行會議。
• 確保針對架構進行有效而且一致地管理和實現。
• 解析不清楚的地方，並對各類問題以及已經升級了的衝突進行解決。
• 提供各類建議、指導以及信息。
• 確保各類架構的合規性，並在確保與技術戰略及目標一致的基礎上授予豁免。
• 當類似的豁免被申請並被經過時，架構委員會須要考慮進行策略變動。
• 確保全部與架構合同的實現相關的信息在可控的條件下被髮布，並可被通過受權的團體所得到。
• 對彙報的服務水平、成本節約等方面進行驗證。

      若是從治理的角度來看，架構委員會還須要承擔以下責任：

• 產生各類可用的治理材料和活動。
• 經過共識和被受權的發佈來爲架構的正式接受和批准提供一種機制。
• 爲確保架構的有效實現而提供一個基本控制機制。
• 在架構的實現、包含在企業架構中的架構戰略和目標，以及業務的戰略目標之間創建關聯，並對其進行維護。
• 爲了經過豁免或策略更新來進行調整，架構委員會須要明確架構與計劃開展的活動之間的差別。

3.1 架構委員會的創建

      一個架構委員會的創建每每受以下事件的觸發：

• 新CIO的任命。
• 兼併或收購。
• 考慮採用一個新的計算形式。
• 認識到IT與業務的契合度不好。
• 渴望經過技術來達成競爭優點。
• 一個企業架構方案的建立。
• 重大的業務變動或業務的快速發展。
• 須要複雜且跨越諸多功能的解決方案。

      在不少公司中，最初的領導級架構贊助者一般都是CIO，然而爲了在企業中得到廣闊的支持，一個贊助組織的影響力每每超過某個我的，這樣一個贊助組織在這裏被稱爲一個架構委員會。架構委員會是一個高級領導層組織，用來爲戰略架構及其子架構的審查和維護進行負責。雖然架構委員會是企業中架構的贊助者，企業架構委員會本身自己也須要得到企業高層的贊助和支持，而且這一支持須要貫徹整個規劃過程，延伸到針對架構項目的維護之中。

      架構委員會的常駐人員規模不宜過大，按照TOGAF的建議，一個架構委員會的常駐人員規模應包含四至五人，或不超過十人。爲了使架構委員會隨着事件的推移而一直保持合理的規模，並同時確保其在企業範圍內的表明性，架構委員會的成員須要採用輪換制，從而給予各個高級經理決策權和相關責任。除此以外，因爲現實中的各類緣由這一輪換機制還有其存在的必要性，例如當有些架構委員會成員受時間所限而不能長期承擔其職責時。雖然採用了輪換制，但爲了確保架構委員會的決策不會變化無常，企業須要主動的採用某種機制來確保其核心理念的穩定，例如爲成員設置任期，並將不一樣成員的離退時間交錯開來。

3.2 架構委員會的運行

      架構委員會的運行的核心以及在形式上的表現就是按照清晰的日程安排所進行的架構委員會會議，而且這些日程安排鬚要具備明確的目標、所涵蓋的內容和通過定義的行爲。架構委員會會議須要爲以下幾個方面提供指導：

• 對高質量的治理材料和活動的產生進行支持。
• 經過共識和被受權的發佈來爲架構的正式接受提供一個機制。
• 爲確保有效的架構實現提供一個基本控制機制。
• 在架構的實現、包含在企業架構中的架構戰略和目標以及業務的戰略目標之間創建關聯，並對其進行維護。
• 爲經過豁免或策略更新來與合同進行從新校準而對合同和規劃活動之間的差別進行明確。

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

      因而可知，會議的日程描述是有關整個會議內容的核心，TOGAF對於其內容項目作了以下建議：

• 前期會議紀要：之前的架構委員會會議的詳細紀要。
• 變動請求：此條目之下的內容一般包含了針對架構、原則等內容進行修訂的變動請求，此外也能夠包含對於架構合同的業務控制（例如，確保針對某一付費號碼的語音流量（例如天氣預報）被禁止，以及對於某一特定網站進行訪問的數據流量須要被控制）。任何一個變動請求的設置須要在制定者的受權範圍以內，並採用在架構合同中已經定義好的參數。
• 豁免：豁免被用來做爲一個對現存架構、合同和原則等方面內容進行更改的申請。豁免只會在必定的時間區間中以及定義明確的在整個豁免期間須要被貫徹的服務和運營條件下被承認。
• 合規性評估：合規性的評估是針對服務水平協議、運營水平協議、成本目標等方面而進行的。根據在架構治理框架中定義的條件標準，經過審查後，這些評估結果或者被接受亦或者被拒絕，而且架構合規性評估報告還應包含所描述的各個細節。
• 爭議解決：通過架構合規性審查和豁免過程而依然未被解決的爭議須要在這裏被明確，從而爲下一步的行動提供目標，而且這些內容須要被記錄到架構合規性評估和豁免文檔之中。
• 架構戰略和方向文檔：這裏所描述的內容僅被全局架構委員會所制定，它包含了架構的戰略、方向及其優先級順序。
• 行動分配：這是一個關於前期架構委員會會議所分配行動狀況的報告。在此報告中，一個行動跟蹤記錄被用來記錄和保持全部在架構委員會會議中被分配的行動的狀態，其內容至少應該包含以下幾個方面：
• 參考材料
• 優先級
• 行動概述
• 行動所屬者
• 行動詳細描述
• 開始日
• 到期日
• 狀態
• 類型
• 決議經過之日
• 合同文檔管理：這是爲架構文檔的後續發佈而對其進行的有關更新和改變的正式承認。
• 其餘事項（AOB：Any Other Business）：關於上述內容所沒有覆蓋的問題的描述。這些內容也許不會被描述在會議日程之中，但應該在會議開始時被提出。
• 會議安排：全部會議的時間和內容安排應被詳細描述，並公之於衆。

4. 架構合規性

      針對架構合規性的審查是架構治理戰略的核心環節，也是決定其可否成功的重要因素。架構合規性審查是針對各個具體項目與已經創建的架構標準、精神以及業務目標的相符合狀況所進行的審議，而一個關於這些審議的正規流程正是企業的架構合規性策略的核心內容。經過架構合規性審查，企業能夠達成以下幾點（或部分）目標：

• 首先且最重要的目標是企業得以儘早在項目架構中發現錯誤，從而減小在整個生命週期的後期進行更改的風險和成本，而這也意味着總體的項目時間得以縮減，而且各項業務也可以儘早地得到架構所帶來的底線收益（bottom-line benefit）。
• 確保將各類最佳實踐應用到架構工做當中。
• 提供一份關於架構與強制性企業標準的符合度的概略。
• 明確標準自己須要進行修改的地方。
• 明確可以做爲企業基礎設施的組成部分，卻在當前只爲特定應用提供支持的各個服務。
• 將關於團隊合做、資源共享以及其餘可以跨越多個架構團隊的協同增效方面的戰略進行文檔化。
• 充分利用技術所帶來的先進性。
• 對項目的技術準備狀態進行溝通。
• 肯定採購活動的關鍵標準。
• 明確重大的架構性差距，並就此與產品和服務供應商進行溝通。

      除了上面這些與質量保證有關的目標以外，架構合規性審查的進行還在特定狀況下具備着傾向於以政治爲導向的動機：

• 因爲具備決策能力的人一般會參與到審查當中，並可以從對業務最優的角度進行決策指導，而不只僅注重技術的優劣，這使得架構合規性審查成爲了一種在各類架構選擇之間進行選擇的好方法。
• 架構合規性審查的輸出是爲數很少的用來彙報給CIO，並輔助其決策制定的可測性交付物之一。
• 架構審查能夠做爲一條架構組織藉以參與到開發項目之中的途徑，不然各個開發項目的進行將會與企業的架構功能相脫節。
• 架構審查能夠爲企業業務團體給出快速且正面的支持：
• 企業架構以及架構合規性能夠幫助確保各IT項目與業務目標的符合度。
• 架構師有時能夠被視爲深刻到技術基礎設施之中而遠離核心業務以外。
• 因爲架構合規性審查傾向於將主要注意力放到一個系統的關鍵風險區域內，因此此審查常常能夠爲系統全部者凸顯各類主要的風險。

4.1 架構合規性審查發生時點

      架構合規性審查並非一個一次性的活動，它應該在適當的項目里程碑或項目生命週期的各個檢查點進行，而且其具體的審查要點應包括：

• 架構開發自身的合規性，亦即對於架構開發方法的符合度。
• 架構實現的合規性，亦即各個實施項目與架構的符合度。

      針對架構項目審查的時點應包括：

• 項目啓動
• 初步設計
• 主要設計變動時
• 其它特定時刻

4.2 架構合規性審查進行的情景歸納

      就架構合規性審查的進行、治理以及參與的人員來講，TOGAF針對此審查的進行總結出了以下三種情景：

• 對於小規模的項目，這一審查流程能夠只是由項目架構師或項目組長制定一系列問題（能夠經過對後面將要列出的問題清單進行定製而得到），再將答案收錄到某種形式的報告中，並對其進行管理。進行這樣一個流程的需求一般要被包含在整個企業範圍的IT治理策略中。
• 若是處於審查之下的項目並無一個全職的架構師的參與（例如，一個應用級的項目），那麼就須要藉助於企業中具備架構功能的組織的專業性架構能力了。這種狀況下，企業架構功能組織將負責對這一審查進行組織、領導和執行，並保證各業務領域專家的參與。須要注意的是，這樣的審查並非要取代架構師對於項目的參與，而是對架構師參與的一個有效的補充。此外，在這種情景下也許還須要引入一套數據庫系統，從而對在大型系統或系統組的分析中所產生的大量數據進行管理。
• 對於大多數狀況來講，尤爲是對於大型項目來講，組織中具備架構功能的組織可能已經深刻地參與到（或領導）處於合規性審查之下的開發項目之中。在這種狀況下，這一審查應該由主架構師來進行協調。主架構師須要組織一個包含業務和技術領域專家的團隊，並將合規性審查中各個問題的答案編織成某種形式的報告。合規性審查中各個問題的制定須要由各個業務和技術領域專家一塊兒來執行。除了由主架構師領導以外，架構合規性審查也能夠由架構委員會的表明或其餘在全企業範圍內具備類似能力的組織來領導。

      在上面這些情景中，架構合規性審查的進行都須要高級管理層的支持，並一般被做爲企業架構治理策略的一個重要部分來加以強制。通常來說，企業的CIO或企業架構委員會將對全部主要項目進行強制性審查，並在以後造成年度審查的慣例。

4.3 架構合規性審查流程

4.3.1 流程

      TOGAF對於架構合規性審查的流程作了以下圖所示的總結：

 

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

角色	職責	備註
架構委員會	確保IT架構的一致性，並能對全部業務目標進行支持	贊助並監督架構活動
項目組長 （或項目委員會）	爲這個項目負責
架構審查協調人	管理整個架構的開發和審查流程	更傾向於面向業務，而不是技術
首席企業架構師	確保架構在技術上的連貫，而且是面向將來的	一個IT架構專家
架構師	首席企業架構師的技術助理之一
客戶	確保業務需求被清晰地描述和理解	管理組織的一部分，該部分依賴於在架構中所描述的信息技術的成功實現和運用
業務領域專家	確保用於知足業務需求的流程是合理並可以被理解的	瞭解業務領域的運做。能夠經過客戶來擔當這一角色
項目負責人	確保架構師對於客戶部門流程有着足夠詳細的理解，並可以爲業務領域專家或架構師提供各類所需的輸入	可以爲架構所要知足的業務需求提供輸入的客戶組織中的成員

4.4 架構合規性審查問題參考列表

      架構合規性審查是針對各個項目與架構的符合度而進行的審議活動，而這一活動的具體實施須要圍繞着一份問題清單來進行的。爲了幫助這一份問題清單的制定，TOGAF根據架構的各個方面提出了一系列備選問題，而負責問題清單開發的領域專家能夠根據所審查架構的特性在這些備選問題中進行選擇和定製。須要注意的是，這裏所列出的問題並不適用於針對業務領域架構或跨越多個項目的架構的審查。針對這些架構的審查的流程雖然類似，可是其所使用的問題清單的類別和內容將會有所不一樣。（有些問題並非以提問的形式出現，而是經過簡短的描述來對引起問題的原因，以及答案中所應包含的內容方向進行了闡述，從而使得相關人員能夠按照各自狀況編制出合適的問題）

4.4.1 硬件和操做系統問題清單

• 項目生命週期方法是什麼？
• 項目目前處在生命週期的哪一個階段？
• 已經被明確的或被用做分析的，在項目中用來對網絡、服務器以及終端設備的硬件和操做系統進行評估的關鍵問題是什麼？
• 將要參與到大量和/或高頻率數據傳輸中去的系統能力是什麼？
• 系統設計是如何影響或涉及到終端用戶設備的？
• 所進行的使用、數據存儲和處理的數量及分佈（地區性和全局性）是什麼？
• 經過對比數據、應用服務等方面的類似性，應用與項目的關聯有哪些？而且數據與項目的關聯程度爲什麼？
• 在系統關鍵元素的功能性設計以前就已經作出的關於硬件和操做系統的選擇是什麼？
• 是否關於硬件和操做系統的決策制定超出了項目的控制？
• 項目對於那些決策的理由有什麼樣的認識？
• 當系統設計成型時，項目是如何影響那些決策的？
• 是否選擇了非標準化的內容？
• 不使用公司標準的關鍵業務和技術需求是什麼？
• 是否被業務案例所支持？
• 在業務案例中的假設是否已被審查？
• 用於評估硬件和操做系統的全生命週期成本的流程是什麼？
• 公司財務管理是如何被引入到生命週期成本評估中去的？
• 是否進行了供應商的財務分析？
• 是否對供應商提出了承諾？
• 是否堅信需求僅被一個供應商所知足？

4.4.2 軟件服務和中間件問題清單

• 描述錯誤條件是如何在應用組件之間被定義、產生和傳播的。
• 描述在各個應用模塊中關於方法定義和排列的通用模式。
• 描述在各個應用模塊中關於方法參數定義和排列的通用模式。
• 描述用來最小化服務器和客戶端之間調用次數的方法，這對於在進程間進行具備複雜數據結構的調用尤爲重要。
• 描述在主要系統組件之間進行傳遞的主要數據結構。
• 描述在主要系統組件之間進行通訊所採用的協議。
• 描述在不一樣系統組件之間所使用的編組（marshaling）技術，並針對所使用的特定編組安排進行描述。
• 描述系統在多大程度上設計有狀態（stateful）和無狀態（stateless）組件？
• 針對有狀態和無狀態組件來描述如何以及什麼時候進行狀態保存。
• 相比於對象池中對象的重用，描述在什麼範圍內對對象進行建立、使用和銷燬。
• 描述系統依賴於線程或臨界區代碼的程度。
• 描述在系統內部用來記錄方法、方法參數和方法功能的方式和內部文檔。
• 描述代碼審查流程。
• 描述用來測試系統組件的單元測試。
• 描述包含在各類系統模塊中的前置和後置條件測試。
• 描述包含在系統中的斷言測試。
• 各個組件是否具有了它須要支持的全部接口？亦或某些關於何種類型組件採用語言綁定或其它形式的編組（marshaling）方式來調用其它組件的假設是否被制定？
• 描述在何種程度上對跨平臺的大字節或小字節數據格式問題進行了處理。
• 描述在不一樣平臺上是否對數字和字符串的處理採用不一樣的方式。
• 描述是否軟件須要對浮點舍入偏差進行檢查。
• 描述時間和數據是如何應對千年蟲問題的。
• 描述何種工具和流程被用來就內存泄漏、可達性（reachability）或通常魯棒性（general robustness）來對系統進行測試的。
• 描述系統服務軟件的分層狀況。描述主要系統組件之間的鏈接的通常數量。是否系統大量採用點對點方式進行聯繫，仍是主要經過消息路由的方式？
• 描述系統組件鬆耦合或緊耦合的程度。
• 就共享庫、通訊協議支持、負載平衡、事務處理、系統監控、命名服務或其它基礎服務來說，系統對於底層基礎設施的需求是什麼？
• 描述系統和系統組件是如何經過設計來達成重構性的？
• 描述相對於採用點對點的通訊結構，系統或系統組件是如何依賴於通用消息基礎設施的？

4.4.3 應用問題清單

• 基礎設施應用
• 是否須要一些企業標準基礎設施應用產品並無提供的能力？例如：
• 團隊協做方面：
• 應用共享
• 視頻會議
• 日程安排
• 電子郵件
• 工做流管理
• 出版/文字處理應用
• HTML
• SGML和XML
• 可移植的文檔格式
• 文檔處理（專有格式）
• 桌面發佈系統（Desktop publishing）
• 電子表格應用
• 展現應用
• 業務展現
• 圖片
• 動畫
• 視頻
• 音響
• 基於計算機的培訓系統（CBT：Computer-Based Trainning）
• Web瀏覽器
• 數據管理應用
• 數據庫接口
• 文檔管理
• 產品數據管理
• 數據倉庫/集市
• 項目管理應用
• 項目管理
• 項目可見度（Program visibility）管理
• 描述標準產品所不能知足的對於企業基礎設施應用能力的業務需求。
• 業務應用
• 是否用於支持一條或多條業務線應用的標準產品提供了所須要的能力？例如：
• 業務採購應用：
• 銷售和市場
• 工程應用
• 計算機輔助設計
• 計算機輔助工程
• 數學和統計分析
• 供應管理應用
• 供應鏈管理
• 客戶關係管理
• 生產應用
• 企業資源規劃（ERP）應用
• 製造執行系統
• 製造質量
• 製造工藝工程
• 機器和自適應控制
• 客戶支持應用
• 航空物流支持
• 維護工程
• 財務應用
• 人員應用
• 設施應用
• 信息系統應用
• 系統工程
• 軟件工程
• Web開發工具
• 集成式開發環境
• 生命週期類別
• 功能類別
• 專業類別
• 計算機輔助生產
• 電子商務支持
• 業務流程工程
• 統計質量控制
• 描述標準產品所不能知足的對於業務應用能力的流程需求。
• 應用集成方法
• 架構的目標集成點（業務流程/活動、應用、數據、計算環境）是什麼？
• 所採用的應用集成技術是什麼（通用數據對象、標準數據定義（STEP、XML等）、通用用戶界面展現）？

4.4.4 信息管理問題清單

• 數據價值方面
• 用於對數據的管理和使用進行標準化的流程是什麼？
• 用於支持數據錄入和驗證的業務流程是什麼？數據的用處爲什麼？
• 與數據的建立和修改相關的業務行爲是什麼？
• 與數據的刪除相關的業務行爲是什麼？是否這些數據被認爲是業務記錄的一部分？
• 業務用戶對於數據質量的需求是什麼？
• 當前用於支持數據引用完整性和/或規範化的流程是什麼？
• 數據定義方面
• 所購買的應用的數據模型、數據定義、結構以及主機選項（hosting options）都是什麼？
• 用於定義和維護數據需求規則以及對信息系統中全部組件所進行的設計是什麼？
• 何種共享資源庫被用來保存數據模型內容和數據的支持性信息？
• 用於設計數據庫的物理數據模型定義是什麼？
• 所選擇的軟件開發和數據管理工具是什麼？
• 已明確的對以下事項進行負責的數據擁有者都有哪些？：
• 通用數據定義
• 計劃外冗餘的消除
• 穩定可靠性的提供
• 信息的及時性和準確性
• 防止數據被濫用和破壞
• 安全/保護方面
• 爲了防止數據被無心及未受權的更改、泄露和散佈，對於數據實體及其屬性的訪問應該制定什麼樣的規則？
• 用於保護數據免於被外界進行未受權訪問的數據保護機制是什麼？
• 採用何種機制來控制企業內部臨時駐留性外部資源對於數據的訪問？
• 託管、數據類型和共享方面
• 用於將單一受權數據做爲一個邏輯數據源進行管理的規程爲什麼？這一邏輯數據源爲貯存在不一樣平臺上的物理數據定義了更新規則。
• 用於對複製數據進行管理的規程爲什麼？這些複製數據來源於運行中的單一受權數據。
• 已經明確的用於儲存高級或中級重要度的運行數據的層級數據服務器爲什麼？
• 已經明確的用於儲存C類型運行數據的層級數據服務器爲什麼？
• 已經明確的用於儲存包含在一個數據倉庫中的決策支持數據的層級數據服務器爲什麼？
• 所實現的數據庫管理系統爲什麼？
• 通用服務
• 標準化的分佈式數據管理服務（例如，數據驗證、一致性檢查、數據編輯、加密以及事務管理）爲什麼？這些服務存在於何處？
• 訪問方法
• 對於標準文件、消息和數據管理的數據訪問需求爲什麼？
• 對於決策支持數據的訪問需求爲什麼？
• 數據存儲庫和應用邏輯位置爲什麼？
• 採用何種查詢語言？

4.4.5 安全方面問題清單

• 安全意識：
• 是否已確保正在使用的公司安全策略和導則是最新的版本？
• 是否已經閱讀了最新版本的公司安全策略和導則？
• 是否瞭解全部相關的計算安全合規性和風險接受流程？
• 識別/認證：對於一個用戶是如何被應用所識別，以及此應用是如何驗證該用戶確爲其所聲稱那我的的過程流進行圖形表述。對這一圖形表述提供支持性文檔，從而對用戶界面和應用/數據庫服務器之間的交互流程進行解釋。是否符合公司關於帳戶、密碼等方面的策略？
• 受權：提供一個流程來展現一個用戶如何申請訪問某個應用，從而指明瞭相關的安全控制以及責任的劃分。這一流程應該包括：
• 申請是如何被適當的數據擁有者所批准？
• 用戶是如何被納入到適當的訪問級別分類設定檔中的？
• 用戶帳號、密碼和訪問是如何創建的，並如何提供給用戶的？
• 如何通知用戶對於應用的使用責任？
• 如何變動密碼？
• 應向誰請求幫助？
• 其餘。
• 訪問控制：記錄用戶的帳戶、密碼和訪問配置是如何被增長、更改、刪除和記錄的？這一文檔還應該包括對這些流程進行負責的人員。
• 敏感信息保護：提供肯定了須要額外保護的敏感數據的文檔。明確對這些數據進行負責的數據擁有者，以及用來保護數據存儲、傳輸、打印和分發的流程。這包括：
• 如何對密碼文件或字段進行保護？
• 如何防止用戶查看他人的敏感信息？
• 與外部團體之間是否具備着信息保護的協議？若是是，具體責任和義務爲什麼？
• 審計跟蹤和審計日誌：
• 明確並記錄被多個用戶或應用支持所須要的組帳戶。
• 明確並記錄我的帳戶和/或具備超級用戶權限的角色。
• 這些權限爲什麼？
• 何人能夠訪問這些帳戶？
• 如何對這些帳戶的訪問進行控制和跟蹤，以及如何對其進行日誌記錄？
• 如何處理密碼的變動和分發？
• 明確審計日誌：
• 何人能夠讀取審計日誌？
• 何人能夠修改審計日誌？
• 何人能夠刪除審計日誌？
• 如何保護和存儲審計日誌？
• 用戶帳戶在審計日誌中是否記錄不清？
• 外部訪問注意事項：
• 是否應用只是內部使用？
• 若是不是內部使用，那麼是否符合公司的外部訪問需求？

4.4.6 系統管理問題清單

• 必須被分發出去的軟件更新的頻率爲什麼？
• 採用何種工具進行軟件分發？
• 是否在產品中容許使用多個軟件和/或數據版本？
• 用戶數據的備份頻率以及指望的回覆時間爲什麼？
• 如何對用戶的帳戶進行建立和管理？
• 系統受權的管理策略爲什麼？
• 須要採用何種通用系統管理工具？
• 須要採用何種特定的服務管理工具？
• 如何接受和發送服務調用？
• 描述如何卸載系統。
• 描述用於檢查系統是否被正確安裝的流程或工具。
• 描述用於監督系統健康情況和性能的工具或儀器。
• 描述用來肯定系統被安裝在何處的工具或流程。
• 描述用於捕捉系統歷史（特別是在一次意外發生以後）的審計日誌的格式。
• 描述系統將其錯誤消息發送給服務人員的能力。

4.4.7 系統工程/總體架構問題清單

• 通常性問題
• 須要整合進來的其餘應用和/或系統爲什麼？
• 描述集成度水平和戰略。
• 用戶羣的地理分佈爲什麼？
• 系統對於其餘企業內外用戶團體的戰略重要性爲什麼？
• 須要什麼樣的計算資源來爲企業內的用戶、處於企業外並使用企業計算資產的用戶，以及處於企業外並使用他們自有資產的用戶提供系統服務？
• 處於本地交付環境以外的用戶如何訪問企業的應用和數據？
• 當前應用的平均壽命爲什麼？
• 描述用於適應來源於用戶羣、存儲的數據以及交付系統技術的變化的設計。
• 用戶羣的規模以及他們的指望性能水平爲什麼？
• 採用何種性能和壓力測試技術？
• 軟件和數據組件的總體組織方式爲什麼？
• 總體的服務和系統配置爲什麼？
• 軟件與數據是如何被配置和映射到服務及系統配置之上的？
• 此係統須要何種專門的軟硬件技術？
• 描述每一個版本的軟件是如何隨着時間的推移而被重製和從新部署的？
• 描述當前的用戶羣，以及在以後的三到五年中對其變化的預期。
• 描述當前的用戶羣地理分佈，以及在以後的三到五年中對其變化的預期。
• 描述在當前或將來須要經過移動或離線方式來對應用進行使用的用戶數量。
• 描述應用的一般行爲、其主要組件以及主要的數據流。
• 描述包含在應用中並用於監督其健康和性能情況的儀器。
• 描述系統的業務原因。
• 從初始開發成本對比長期維護成本的角度出發，描述選擇系統開發語言的理由。
• 描述用於產生系統架構及其產品選擇階段的系統分析流程。
• 除了原來的客戶以外還有誰會經過對此係統的使用而獲益？
• 經過瀏覽模式和更新模式來使用此係統的用戶比例爲什麼？
• 事務性的申請數量一般爲多少？
• 是否須要嚴格保障的數據傳輸或更新？系統是否容錯？
• 系統的正常工做時間需求爲什麼？
• 描述系統架構符合或不符合標準的地方。
• 描述運用在項目中的項目規劃和分析方法。
• 處理器/服務器/客戶端方面
• 描述客戶/服務器應用架構。
• 經過標註圖示來闡述執行應用功能的地方。
• 客戶端方面
• 除了展現以外用戶設備是否還具備其餘功能？
• 描繪數據和流程所提供的幫助功能。
• 描述「從屏到屏」的導航技術。
• 描述用戶如何在此應用與其餘應用之間進行導航。
• 如何從用戶設備上對此應用以及其餘應用進行啓動？
• 是否具備應用之間的數據和流程共享能力？若是是，描繪所共享的內容，以及採用何種技術來實現共享。
• 描述傳輸到客戶端上的數據量。
• 對於支持應用的本地緩存數據的額外需求是什麼？
• 對於支持應用的本地軟件存儲/內存的額外需求是什麼？
• 是否存在由其餘應用需求或會對用戶產生影響的狀況而致使的軟硬件衝突或容量限制？
• 描述當前應用與其餘現存應用之間展現層的感觀效果的對比狀況。
• 描述客戶端在多大程度上支持異步和/或同步通訊。
• 描述系統的展現層是如何與其餘計算或數據傳輸層相分離的。
• 應用服務器方面
• 展現層和應用層是否能夠運行在不一樣的處理器之上？
• 應用層和數據訪問層是否能夠運行在不一樣的處理器之上？
• 是否此應用能夠被放置到一個應用服務器之上，並獨立於其餘全部應用？如不能夠，則須要解釋這些應用之間的依賴關係。
• 是否能夠比較容易地添加額外的平行應用服務器？若是能夠，負載平衡機制爲什麼？
• 是否應用的資源需求被測量過了，且其值爲什麼？若是已被測量，那麼是否規劃的服務器容量已在應用和整體級別上被確認了？
• 數據服務器方面
• 是否存在其餘應用必須與當前應用共享數據服務器？若是是，則須要對這些應用進行明確，並描述其數據和數據訪問需求。
• 是否應用的資源需求被測量過了，且其值爲什麼？若是已被測量，那麼是否規劃的服務器容量已在應用和整體級別上被確認了？
• 商用現成品（COTS）方面
• 廠商是否穩定？
• 當廠商消亡時企業是否會收到產品源代碼？
• 是否軟件按照企業的用途而進行了配置？
• 是否存在特有的架構和設計方面的數據或流程，從而阻礙了針對軟件的使用？
• 是否此軟件在當前是可得的？
• 是否廠商使用或闡明的規模/可用性/服務水平與企業的需求相相似？
• 描述廠商過往的財務和市場份額歷史。

4.4.8 系統工程/方法與工具問題清單

• 是否具備對當前業務操做方法的評定指標？
• 系統擁有者是否已經建立了用於指導當前項目的評估標準？若是有，則對如何使用這些評估標準進行描述。
• 是否對於現存架構的研究已經完成，從而使得當前的工做成果可以得以被充分利用？描述在這一研究中所使用的發現和認識方法。是否現存的這些架構須要被整合？若是是，解釋將會採用的方法。
• 描述將會應用到項目中的方法：
• 用於定義業務戰略的方法。
• 用於定義須要改善的領域的方法。
• 用於定義基線和目標業務流程的方法。
• 用於定義過渡流程的方法。
• 用於管理項目的方法。
• 用於團隊溝通的方法。
• 用於知識管理、變動管理和配置管理的方法。
• 用於軟件開發的方法。
• 用於引用標準和方向說明的方法。
• 用於交付物的質量保證的方法。
• 用於設計審查和交付驗收的方法。
• 用於達成指標的方法。
• 是否各個方法已被記錄，並被分發給了每一個團隊成員？
• 團隊成員在多大程度上熟悉這些方法？
• 採用何種流程來確保方法執行的符合性？
• 描繪當前所採用的用於支持方法使用的基礎設施。
• 如何提供諮詢和故障排除？
• 如何協調安排培訓？
• 如何合併和關聯各類變動和改進？
• 如何獲取經驗教訓，並對其進行溝通？
• 關於項目所採用的工具爲什麼？（指定版本和平臺）。團隊成員對這些工具的熟悉度爲什麼？
• 描繪當前所採用的用於支持此工具使用的基礎設施。
• 如何提供諮詢和故障排除？
• 如何協調安排培訓？
• 如何合併和關聯各類變動和改進？
• 如何獲取經驗教訓，並對其進行溝通？
• 描述項目如何促進對其交付物及所交付內容的重用。
• 在項目實現後此架構設計是否還會存續？描述用來將變動合併入此架構設計的方法。
• 當前流程是否被定義？
• 是否各類問題已經被記錄和評定，並與當前流程關聯起來？若是沒有，那又如何得知已經出現問題的地方正在被修正？
• 是否現存或規劃的流程改善活動已被明確，並與當前流程關聯起來？若是沒有，那又如何知道此活動與其餘工做說明書中的內容不會發生衝突或相互冗餘？
• 當前是否存在各類評估指標？當前是否存在預測指標？若是沒有，那又如何得知得到了改善？
• 採用何種流程來收集、評估和彙報各類指標？
• 新的設計對於現存業務流程、組織結構和信息系統有什麼樣的影響？是否這些影響已經被記錄到文檔之中，並與其餘干係人進行共享？

4.5 架構合規性審查實踐導則

4.5.1 裁剪和定製問題清單導則

• 關注於：
• 高風險區域。
• 預期的（突發的）差別。
• 對於清單中的每條問題，須要理解：
• 問題自己的含義。
• 問題背後的原則。
• 在迴應中須要尋找什麼樣的內容。
• 尋求領域專家的意見。
• 根據自身須要對清單中的問題進行修補。
• 時刻牢記須要架構委員會的反饋。

4.5.2 架構合規性審查執行導則

• 理解審查的目標，並始終保持在正確的軌道之上對提出的問題提供適合的交付物。例如，人們一般但願瞭解正在架構的系統的對錯之處，而不是但願瞭解諸如所採用的開發方法是否正確、管理組織結構是否合理等這些方面，於是在審查中就會常常偏離主題。
• 隨着審查討論的進行，其餘一些須要被解決的問題將會逐漸顯現，並且這些問題還經常會超出當前審查的範圍。在這種狀況下，咱們須要在這次審查會後對其進行處理，並依照這些問題的重要性來制定一份用於解決這些問題的計劃。
• 保持科學的態度。與其說「咱們指望看到大型數據庫放置在ABC之上而不放在XYZ」，咱們更應該說「XYZ數據庫環境之下的停機時間遠遠超過在ABC數據庫環境之中的情況。所以咱們不推薦將M和N系統放置到XYZ環境中」。
• 詢問開放性問題。
• 在審查的徵詢過程當中常常會存在隱藏的日程或有爭議的問題，而這些內容在前期是沒法預知的，於是採用一個非個性化的方法來進行討論將會彌合這些差距而不是加重他們。
• 尊重面談的對象。他們可能不會採用合適的方法來構建系統，可是他們可能在其所處的環境中已經盡了最大的努力。
• 在練習中增加經驗。
• 審查應該包括針對架構的詳細評估活動，並確保其結果被存儲到企業連續體之中。