運用TOGAF ADM 的實施治理

在本文我們將會介紹如何訂製與進行架構合規審查(Architecture Compliance Review)，架構合約(Architecture Contracts)的內容是甚麼。還有此階段與架構治理的關係，與風險監控在這個階段的角色。

目標

1. 確保"符合"目標架構
2. 為解決方案和任何實施驅動的架構變更請求執行建立一個適當的架構治理職能

這一階段產生的架構合約在架構治理領域具有顯著的特點。 它經常被用作推動變革的手段。 為確保架構合約的效能和效率，在Phase G應導入以下方面的治理框架：

• 簡單的流程
• 以人為本的決策
• 健全的溝通
• 及時的回應和有效的升級流程
• 支援組織結構

輸入

• 架構框架: TOGAF Library與其他相關的架構框架
• 治理與法律框架: 包含架構治理策略
• 其他框架: 任何已存在企業中其他框架
• 企業的內部文件: 董事會的策略、業務原則/目標/驅動因素
• 現有的架構儲存庫: 框架、企業架構的組織模型
• 架構合約
• 實施與遷移計畫

步驟

步驟1:針對開發管理的部署確認範圍與優先順序

• 啟動開發專案
• 確定架構優先順序
• 確定部署問題

此步驟採用"遷移規劃的產出並由此產生的部署建議"。 這包括確定開發團隊的優先順序、確定部署問題和建議，以及確定替換和更新的建構區塊(Building Block)。 應在企業架構和解決方案框架之間執行差距分析。 解決方案架構師應該考量是否可以在多個專案中重複使用某些 SBB。

步驟2: 確認佈署資源與技能

• 就企業架構的期望教育架構開發團隊
• 確保將設計反饋送回給企業架構師

步驟3:指導解決方案佈署的開發

• 紀錄架構合約(取得所有架構團隊的簽署)
• 更新企業連續體與架構儲存庫
• 指導開發
• 制定實施計畫

通過記錄單一專案的範圍、策略要求(從架構的角度)、任何變更請求(例如對標準介面的支援)、一致性規則和時間表要求，從架構路線圖為每個單獨的"實施和部署專案(implementation and deployment project)"給出專案建議。

架構合約已記錄在案，並從所有開發團隊和贊助單位獲得簽署。 企業連續體與架構儲存庫應該會有解決方案素材的存在。 然後使用架構合約來指導為已確認服務的"開發業務和 IT 運營模型(development of the business and IT operating models)"。 這一個指導基於從企業架構衍生的業務和 IT 運營需求，通過對解決方案架構和當前運營之間的差距進行分析，以確定缺失的元素。 這可以用來制定實施計劃(Implementation Plan)。

步驟4:進行企業架構合規性審查

• 確保正在開發的內容符合需求
• 指導開發後的審查
• 關閉部署專案的開發部分

一旦定義了架構，就需要通過實施來管理該架構，以確保實現最初的架構願景，並將任何實施經驗反饋到架構流程中。 Phase G 實施專案的定期合規審查提供了一種審查專案進度並確保設計和實施按照策略和架構目標進行的機制。

合規審查的時機點

應在專案生命週期中的適當專案里程碑或檢查點進行合規審查。 應包括特定檢查點：

• 架構本身的開發(ADM的合規)
• 架構的實施(架構的合規)

針對評估的架構專案時機點應該包括專案啟動、初始設計、主要設計變更和任何需要的臨時性評估。

架構合規性審查通常針對業務需求和企業架構相當穩固並且專案架構在完成之前就已經成型的時間點。 目的是在有時間造成任何重大錯誤或缺點的階段盡快進行審查以進行修正。

審查的場景

在所有情況下，架構合規性審查過程都需要高階管理層的支持，並且應該作為公司架構治理政策的一部分被強制執行。 通常，企業 CIO 或企業架構委員會將要求對所有主要專案進行架構審查，包括隨後的年度審查。 TOGAF 標準為可能的審查場景提供了以下指導：

• 對於較小規模的專案，審查過程可以簡單地採用專案經理向自己提出的一系列問題的形式，使用清單(checklist)方式進行專案報告
• 如果審查中的專案迄今為止沒有涉及全職架構師(例如，在軟體架構師中)，審查的目的通常是導入架構專業知識
  在這種情況下，企業架構職能將在SME(Subject Matter Expert)的參與下組織、領導和執行審查。 在這種情況下，審查不能替代企業架構師參與專案，但可以作為他們參與的補充或指南。
• 在大多數情況下，尤其是在大型專案中，架構職能將深入參與並可能領導正在審查的開發專案
  在這種情況下，審查將由首席企業架構師協調，首席企業架構師將召集業務和技術領域專家團隊進行審查，並將審查期間提出的問題的答案彙編成某種形式的報告。 這些問題通常由業務和技術領域專家提出。 或者，審查可能由架構委員會或具有企業範圍責任的類似機構的代表領導。

關於風險監控

風險普遍存在於任何企業架構作業中，並且存在於 ADM 的所有階段。 作為業務轉型就緒評估的一部分，風險最初將在 Phase A確定。 在該階段建立的風險識別和緩解評估工作表將成為治理工件，合規審查流程的一部分應包括風險監控，以確保將接受的任何剩餘風險緩解到可接受的水準。 對於未緩解的關鍵風險，應產生可能需要另一個完整或部分 ADM 週期的變更請求。

步驟5: 業務與IT維運的實施

• 部署
• 訓練
• 技術發展
• 溝通
• 將新的現行架構發佈到架構存儲庫

步驟6: 進行實行後的審查

• 實行後的審查
• 發布審查結果
• 關閉專案

產出

1. 已簽署的架構合約(開發團隊與實施團隊之間)
2. 合規評估
3. 變更請求
4. 衝擊分析 — 實施建議
5. 符合架構的解決方案，包括:
   — 符合架構的實施系統
   — 填充架構存儲庫
   — 架構合規性建議和豁免
   — 關於服務交付要求的建議
   — 關於績效指標的建議
   — 服務水平協議 (SLA)
   — 架構願景、架構定義文檔、過渡架構。這些都在實施後更新
   — 已實施解決方案的業務和 IT 運營模型

關於架構合約

Phase G中產生的架構合約是架構開發團隊和贊助人之間就架構的可交付成果、質量和適用性達成的聯合協議。 這些協議的成功實施將通過有效的架構來實現。 通過對合約管理實施受監管的方法，可以確保以下內容：

• 一個持續監控系統，用於檢查組織內所有與架構相關的活動的完整性、變更、決策制定和稽核
• 遵守現有或正在開發的架構的原則、標準和要求
• 識別架構開發和實施各個方面的風險，包括針對公認標準、政策、技術和產品的內部開發以及架構的運營方面，以便企業是運作在一個具韌性的環境
• 一組流程和實踐，確保所有架構工件的開發和使用方面的問責制、責任和紀律
• 了解負責合約的正式治理組織、他們的權限等級以及該組織治理下的架構範圍

TOGAF 標準有兩個合約範例：1)架構設計和開發合約以及2)業務單位的架構合約。

架構設計和開發合約的一般內容會有：

• 介紹和背景
• 協議的性質
• 架構範圍
• 架構和策略原則和需求
• 一致性要求
• 架構開發和管理流程及角色
• 目標架構措施
• 定義可交付成果的階段
• 聯合作業計劃的優先順序
• 時間區間
• 架構交付和業務指標

業務單位架構合約的一般內容會有:

• 介紹和背景
• 協議的性質
• 範圍
• 策略要求
• 一致性要求
• 架構採用者
• 時間區間
• 架構業務指標
• 服務架構（包括 SLA）

業務單位架構合約還用於管理 Phase H的變更。

合規評估

通常包含了:

• 專案進展及狀態概述
• 架構/設計的專案概述
• 完成的架構清單：
  — 硬體和操作系統檢查表
  — 軟體服務和middleware檢查表
  — 申請檢查表
  — 資訊管理檢查表
  — 安全檢查表
  — 系統管理檢查表
  — 系統工程檢查表
  — 方法和工具檢查表

總結

• 這個階段結束時，目標架構已完全部署
• 這是關於與開發團隊合作完成工作
• 回答問題，解決爭議
• 如果架構的某些部分需要變更，則提出變更請求
• 確保開發團隊執行需要執行的事項