TOGAF的架構治理

Mar 3, 2023

本文將介紹如何將架構治理(Architecture Governance)應用於企業架構的開發。重點有：

架構治理如何融入 ADM週期
將架構治理付諸實踐的關鍵成功因素
成立架構委員會(Architecture Board)時應考量的因素
如何運作架構委員會

架構治理與ADM

在準備階段(Preliminary Phase)，是決定如何治理”架構框架(architecture framework)”，以及如何將其與組織的現有治理和支援模型進行整合。還決定了所需的治理存儲庫(governance repository)特徵的類型。

在Phase F中，產生的實施治理模型(Implementation Governance Model)確保實施中的專案能順利轉移到Phase G的架構治理。

Phase G 包括架構合約的產生，該合約在架構治理中具有明顯的特點，作為確保合規性和推動變革的一種手段。定期對專案進行合規審查，並確保設計和實施符合策略和架構目標。 風險監控也應該發生在這個階段。

Phase H 管理架構的治理流程和框架。這包括安排和召開架構委員會會議。這些會議的目的是決定如何處理架構變更請求。這些可能來自原始架構定義和需求中發現的問題，也可能來自外部因素，例如業務策略變化和新技術機會。架構委員會還應確保正確應用 ADM，以確保做出所有考量並產生所有必需的可交付成果。

關鍵成功因素

以下為確保架構治理的成功方法和架構合約的有效管理：

建立和運行架構政策、程序、角色、技能、組織結構和支援服務的提交、採用、重複使用、回報和淘汰的最佳實踐
建立正確的組織職責和結構以支援架構治理流程和回報要求
整合工具和流程以促進流程的進行(包括程序和文化)
管理架構治理流程、分配、合規性評估、SLA 和 OLA(Operational Level Agreements) 的控制標準
滿足架構治理相關資訊、服務和流程的效能、效率、機密性、完整性、可用性、合規性和可靠性的內部和外部要求

成立架構委員會

需要考慮的因素包括執行發起人的身份(夠不夠大咖)、委員會的規模、委員會的結構及其與其他企業內單位和職責的關係。

在許多公司中，初始架構工作的執行發起人是 CIO(或其他C-Level)。然而，為了獲得企業大部分人的支持，發起機構可以發揮更大的影響力。這個發起機構稱為架構委員會。架構委員會是企業內部的發起人，但架構委員會本身需要來自公司C-Level人員。架構委員會的承諾必須橫跨規劃流程並持續到架構專案的維護階段。在許多架構規劃工作失敗的公司中，明顯缺乏對專案的執行參與和激勵。

架構委員會的建議規模為四到五名永久成員，上限為十名。管理委員會規模的一項技術是輪替成員。這可能是必需的，因為一些架構委員會成員發現時間限制阻礙了長期的積極參與。然而，架構委員會必須存在一些連續性，以防止公司架構從一組想法換到到另一組想法(一朝天子一朝臣的狀況發生)。確保連續輪換的一種技術是為成員設定任期，並讓任期在不同時間到期(像美國參議員的選舉作法)。

TOGAF 架構治理框架提供了一個通用的組織框架，將架構委員會置於更廣泛的企業治理結構的背景下。該結構確定了主要的組織和職責，以及每個組織之間的關係。這是最佳實踐結構，可能會根據組織的形式和現有結構進行更改。

架構委員會的結構應該反映組織的形式。所需的架構治理結構可能遠遠超出 TOGAF 架構治理框架中概述的通用結構。 組織可能需要定義 IT 治理流程與現有組織結構和能力的組合，通常可能包括最高治理委員會、本地治理委員會、設計機構和工作小組。

運作架構委員會

TOGAF 標準為架構委員會的運作提供指導，特別是從治理的角度。這主要著重於如何準備和召開會議，總結如下。

一般性

架構委員會會議應根據明確的議程進行，議程應具有明確的目標、內容範圍和明確的行動。這些會議將在以下方面提供關鍵方向：

支援品質治理素材和活動的生產
提供一個正式認可的機制，而該機制是通過共識和授權發布的
提供基本控制機制以確保架構的有效實施
建立和維護架構實施與組織(業務和 IT)既定戰略和目標之間的聯繫
識別與合約和計劃活動的差異，以通過豁免或政策更新重新調整合約

準備

會議之前，每個參與者都應收到議程和任何相關或補充文件（例如，豁免請求、績效管理報告等）。每個參與者都應該熟悉每一個內容。如果該項作業已分配給個人，則每個人有責任報告這些行動的進展情況。每個參與者都必須確認他們是否有空並出席架構委員會會議。

架構委員會的議程

TOGAF 標準為架構委員會會議議程提供了一組內容大綱。每個議程項目僅根據其內容進行描述。

1.上次會議記錄

根據組織協議，會議記錄包含上一次架構委員會會議的詳細資訊。

2.變更請求

通常是對架構、原則等的修改的變更請求，但也可能包括與架構合約相關的業務控制；例如，確保禁止向特別email帳號(例如全公司)發送mail，並控制向某些網站傳送資料。任何變更請求均在架構合約定義的商定的權限等級和參數內提出。

3.豁免(也可以稱特許)

豁免被用作請求在正常操作參數之外更改現有架構、合約、原則等的機制；例如，排除向子公司提供服務、出於特定業務原因要求不尋常的服務等級、部署非標準技術或產品以支援特定業務計劃。

豁免是在特定的時間區段內授予的，並且必須在特許的生命週期內執行一組已確定的服務和操作標準。 豁免不是無限期授予的，而是用作確保滿足服務等級和運作等級的機制，同時在其實施和時間安排方面提供一定程度的靈活性。分配的時間限制性質確保它們是架構合規性活動的觸發因素。

4.合規評估

根據 SLA、OLA、成本目標和所需的架構更新評估合規性。這些評估將根據架構治理框架中定義的標準進行審查來決定是接受或拒絕。架構合規性評估報告將包括所描述的詳細資訊。

5.解決爭議

未通過架構合規性和豁免流程解決的爭議在此處確定以採取進一步行動，並通過架構合規性評估和豁免文件進行記錄。

6.架構策略與方向的文件

這描述了架構策略、方向和優先順序，並且將僅由最高架構委員會制定。它應該採用標準架構文件的形式。

7.行動分配

這是一份關於在之前的架構委員會會議上行動分配的報告。行動追蹤器用於記錄和保存架構委員會會議期間分配的所有動作的狀態，並且應至少包含以下資訊：

參考
優先順序
行動說明
行動所有者
行動細節
起始日期
終止日期
狀態
類型
決議日期

8. 合約文件管理

這是對架構文件的更新和變更的正式認可，以供後續發布。

9.臨時動議

對上述任何一項未直接涵蓋的問題的描述。這些可能不會在議程中說明，但應在會議開始時提出。任何補充文建都必須按照所有架構治理文件進行管理。

10.會議日程

所有會議日期都應詳細說明並公佈。

總結

架構治理是在企業範圍內管理和管控企業架構和其他架構的實踐和方向。 TOGAF 標準提供了架構能力框架中架構治理方面的指導。