TOGAF — ADM的指南與技術

12 min readJan 18, 2023

本文將幫助我們理解TOGAF的指南與技術文件如何支援ADM的發展，特別是TOGAF標準的第三部分內容。也會了解如何在特定架構風格的整體脈絡中使用 TOGAF ADM。並且理解什麼是架構原則，為何需要它以及在ADM過程中的哪一個部分使用它。甚麼是業務場景?甚麼是差距分析(gap analysis)技術?TOAGF標準中的互操作性(interoperability)的意思是甚麼?什麼是業務轉型就緒(Business Transformation Readiness)？風險管理的主要特徵是什麼？什麼是基於能力(capability)的規劃？

ADM指南與技術的概述

TOGAF標準的第三部分：ADM 指南和技術包含一系列用於調整和應用 TOGAF ADM。 TOGAF 文件庫中還包含其他指南和技術。這些指南記錄了如何調整 ADM 流程，而這些技術則在應用 ADM 流程時會使用到。

調整 ADM 流程的指南包含了：

將迭代應用於 ADM 的方法
在企業的不同層級應用 ADM
如何使用TOGAF框架中不同的架構風格

在特定架構風格的整體脈絡中使用 TOGAF ADM

TOGAF 框架設計是靈活的，可以很容易地調整成不同的架構風格。
當使用 TOGAF 標準來支援特定的架構風格時，我們必須考量到執行或表達架構的獨特特徵的組合。第一步，必須確定該架構的明顯特徵。

例如，The Open Group 針對SOA明確定義了以下明顯特徵：

它基於服務的設計 — — 反映真實世界的業務活動 — — 包括企業（或企業間）業務流程
服務呈現利用”業務描述”來提供企業的整體脈絡（即業務流程、目標、規則、策略、服務介面和服務組件）並使用服務編排(Service orchestration)實現服務
它對基礎設施提出了獨特的要求 — — 建議實施使用開放標準以實現互操作性(interoperability)和位置透明性
SOA的實現是特定於環境的 — — 它們受整體脈絡的約束或啟用，並且必須在該脈絡中進行描述

在 Phase B-D，我們應選擇相關的架構資源，包括模型、觀點和工具，以正確描述架構領域(BDAT)並證明利害關係人關注的問題得到解決。根據不同的特徵，不同的架構風格加上必須描述的新元素，突顯現有元素，調整用於描述架構的符號，並使企業架構師聚焦在一些利害關係人跟他們所關注的問題。

找出明顯的特徵通常包括對架構內容元模型(Metamodel)的延伸和特定符號或建模技術的使用以及觀點的識別。 風格是否占主導地位將決定是否有必要重新檢查ADM的準備階段並修改架構能力( Architecture Capability) 或是否可以在單一個 ADM 週期內預期的選擇範圍內支援這個獨特的功能。

架構原則

架構原則是一組用於正在開發的架構通用規則和指南。而這組通用規則和指南基本上很少修改，並為組織著手完成其企業使命的方式提供資訊和支援。它們通常是一組結構化想法的一個元素，這些想法共同定義和指導組織，從價值觀到行動和結果。

原則是準備階段的初始產出，並在整個 ADM 中運用到，用來指導企業內部決策制定的框架。根據組織的不同，可以在不同領域和不同層級建立原則。兩個關鍵領域為架構的開發和使用提供資訊：

企業原則為整個企業決策提供了基礎，並規定了組織如何完成其使命。這些原則通常用作協調決策的手段。它們是成功的架構治理策略的關鍵要素。
架構原則是一組與架構作業相關的原則。它們反映了整個企業的共識，體現了企業架構的精神。 架構原則治理著架構流程，影響企業架構的開發、維護和使用。

用於定義架構原則的 TOGAF 模板

TOGAF 標準定義了一種描述原則的建議方式，如下表所示。除了定義聲明外，每個原則還應具有相關的基本原理和含義聲明，以促進對原則本身的理解和接受，並支持使用原則來解釋和證明為什麼做出特定決策。

以下是一個簡單原則範例

什麼會促成好的架構原則

下表呈現有五個標準可以區分一套好的原則

業務場景

業務場景技術在TOGAF Series Guide: Business Scenarios中有描述到。

什麼是業務場景

任何其他重大專案成功的關鍵因素是它與業務需求相關聯的程度，且明顯地支援並使企業能夠實現其業務目標。業務場景是一種用於幫助識別和理解架構必須滿足的業務需求的技術。

一個業務場景會描述:

一個業務流程，一個或一組的應用程序
業務與技術環境
會在這一個場景中執行作業的人員與電腦組件，也就是行動者
正確執行之後的產出

該技術可以在業務架構的每一層分解(hierarchical decomposition)中的不同層級上迭代使用。一般性的業務場景流程如下：

識別、記錄和排序驅動著專案的問題是甚麼
將出現問題的業務環境和技術環境記錄為高等架構模型
確定並記錄期望的目標；成功處理問題的結果
識別參與者及其在商業模型中的位置、參與者及其角色
識別電腦及其在技術模型中的位置、電腦元素及其角色
確定並記錄每個參與者(包含電腦)的角色、職責和成功衡量標準、每個參與者所需的腳本以及正確處理情況的預期結果
檢查是否適合啟發後續架構工作的目的，並僅在必要時進行改進

我們可以把上述流程簡化成如下流程圖:

好的業務場景代表重要的業務需求或問題，並使供應商能夠了解解決方案對客戶的價值。一個好的業務場景也是“SMART”的：

Specific(具體的) — 定義需要做什麼
Measurable(可量測的) — 有明確的成功指標
Actionable(可行動的) — 清楚地劃分問題並提供解決方案
Realistic(實際的) — 因為問題可以在現實世界、時間和成本約束的範圍內解決
Time-bound(有時限的) — 明確說明機會何時到期

ADM中業務場景的使用

業務場景在 ADM 週期的Phase A: Architecture Vision 中最為明顯，此時它們用於定義相關業務需求，並與業務管理層和其他利害關係人建立共識。

它們也可以用於其他階段，特別是在Phase B: Business Architecture期間，以直接從業務的高階需求中導出架構的特徵。由於業務需求在 ADM 週期的所有階段都很重要，因此業務場景技術在 TOGAF ADM 中發揮重要作用，確保業務需求本身是完整和正確的。

Gap Analysis(差距分析)

差距分析技術在 ADM 中會一直用到，以驗證正在開發的架構。驗證架構的一個關鍵步驟是考量可能被忘掉的事項。該架構必須支援組織的所有基本訊息處理需求。 應該考量的最關鍵差距來源是利害關係人關注的問題，這些關注點在之前的架構工作中沒有得到解決。

基本前提是突顯出基準(baseline)架構和目標架構之間的不足；也就是說，有意省略、意外遺漏或尚未定義的項目。

可能的差距的潛在來源包括:

業務領域的差距:
— 人員差距(如交叉培訓的需求)
— 流程差距(如流程的效率低下)
— 工具差距(如重複或缺少的工具功能)
— 資訊差距
— 量測差距
— 財務差距
— 設施缺口（如建築物、辦公空間等）
資料領域的差距
— 資料不夠流通
— 資料不在需要的地方
— 資料是不需要的
— 資料沒有被建立
— 資料沒有被運用
— 資料關係的差距
受影響、消除或建立的應用程序
受到影響、淘汰或創造的技術

步驟如下:

繪製一個矩陣，縱軸為基準(baseline)架構的所有ABB(Architecture Building Blocks)，橫軸為目標架構的所有 ABB
加到現行架構軸的最後一行標記為“New ABBs”，並加入到目標架構軸的最後一列標記為“Eliminated ABBs”
如果 ABB 在現行和目標架構中均可用，請在交叉方格中用“Included”記錄
如果目標架構中缺少現行架構中的 ABB，則必須對每個 ABB 進行審查。如果它被正確消除，在相應的“已消除”方格中將其標記為正確。如果不是，則我們會發現目標架構中的意外遺漏，必須通過在架構設計的下一次迭代中恢復 ABB 來解決 — — 在適當的“已消除”方格中將其標記為此類。
如果目標架構中的 ABB 無法在現行架構中找到，則在與“新”行的交叉處將其標記為需要通過開發或採購建構區塊來填補的空白

整個步驟完成後，“消除的服務(Eliminated Services)”或“新服務”下的任何內容都是差距，應將其解釋為正確消除，或標記為通過恢復或開發/採購功能來解決。差距分析技術在ADM的Phase B/C/D/E都會用到。

以下的範例表格顯示了現行架構和目標架構之間的差距；這個範例中缺少的元素是“broadcast services”和“shared screen services”。

Interoperability(互操作性)

TOGAF 標準將互操作性定義為“共享資訊和服務的能力”。定義資訊和服務的共享程度非常重要，尤其是在複雜的組織和(或)成長的企業中。

互操作性分類如下：

運營或業務互操作性定義如何共享業務流程
資訊互操作性定義如何共享資訊
技術互操作性定義如何共享或至少共享技術服務

從 IT 的角度來看，以類似於EAI(Enterprise Application Integration) 的方式考慮互操作性也很有效的；具體來說：

呈現整合/互操作性是一種通過類似入口網站的通用解決方案的通用外觀方法，可將使用者引導至一套系統的基本功能
資訊整合/互操作性是企業資訊在各種企業應用程式之間無縫共享的地方，例如，實現一組通用的客戶資訊。通常，這是基於資訊的結構、質量、存取和安全/隱私的共享服務。
應用程式整合/互操作性是企業功能整合和共享的地方，這樣應用程式就不會重複（例如，地址服務(或組件)的一次更改；不應該是每個應用程式都有一個）並且通過工作流程等功能無縫接軌在一起。這會影響業務和基礎設施應用程式，並且與企業業務流程統一/互操作性密切相關。
技術整合/互操作性包括通信、存儲、處理和存取主要在應用程式平台和通信基礎設施領域中資訊的通用方法和共享服務

這種互操作性的前提是基於標準和(或)通用 IT 平台的企業 IT 基礎設施的合理化程度。例如，多個應用程式共享一個基礎設施或 100 個公司網站使用一個集中的伺服器（而不是遍布全球的數千個伺服器和網站管理員）。

以下是加拿大政府的互操作性模型範例。該模型包括三類互操作性的高階定義以及在每個等級共享的資訊和服務的性質。互操作性是根據電子政府的e化推動因素創造的。互操作性細分如下：

資訊互操作性：
— 知識管理
— 商業智慧
— 資訊管理
— 可信任的身分
業務互操作性
— 傳遞網路
— 電子民主
— 電子商務
— 企業資源管理
— 關係與個案管理
技術互操作性
— IT基礎建設

互操作性與ADM

互操作性會發生在以下的ADM階段中：

Phase A — Architecture Vision:
使用業務場景找到資訊和服務交換的性質和安全考慮
Phase B — Business Architecture:
以業務術語定義資訊和服務交換
Phase C — Information system Architecture — Data Architecture:
使用公司資料和(或)資訊交換模型詳細說明資訊交換的內容
Phase C — Information system Architecture — Application Architecture:指定應用程式共享資訊和服務的方式
Phase D — Technology Architecture:
指定讓資訊和服務交換的適當技術機制
Phase E — Opportunities & Solutions: 選擇實際解決方案
Phase F — Migration Planning:互操作性在邏輯上得以實現

業務轉型就緒(Business Transformation Readiness)評估

企業架構通常涉及相當大的變化。業務轉型就緒評估提供了一種技術，用於了解組織是否準備好接受變更、識別問題並在實施和遷移計劃中處理這些問題。

使用這種技術是在Phase E和 F 中成功進行架構轉換的關鍵。在Phase A 中對業務轉換就緒情況進行初步評估。建議此評估由公司員工、業務部門和 IT 規劃人員共同完成。

建議的活動有：

確定將影響組織的就緒因素
使用成熟度模型來呈現就緒因素
評估就緒因素，並確定就緒因素評級
評估每個就緒因素的風險並確認改進措施以降低風險
將調查結果記錄到能力評估(Capability Assessment)中，然後將這些行動納入 Phase E和F的實施和遷移計劃

風險管理

風險管理是一種用於在實施架構專案時降低風險的技術。要考慮兩種等級的風險：

初始風險等級：確定和實施緩解措施之前的風險分類。
剩餘風險等級：實施緩解措施後的風險分類。

建立的風險管理流程包括以下活動：

風險分類
風險識別
初步風險評估
風險緩解和剩餘風險評估
風險監控

ADM中的風險管理

風險普遍存在於任何企業架構活動中，並存在於 ADM 的所有階段。 業務轉型風險和緩解活動的識別首先在Phase A中確定，作為初始業務轉型就緒評估的一部分。 建議將風險緩解活動包含在架構作業聲明中。

風險識別和緩解評估工作表作為治理工件進行維護，並在進行風險監控的PhaseG: Implementation Goverance中保持最新。實施治理可以識別未被緩解的關鍵風險，並且可能需要另一個完整或部分 ADM 週期。

基於能力(capability)的規劃

基於能力的規劃是一種專注於業務成果的業務規劃技術。它是業務驅動和業務主導的，結合了所有業務部門的必要努力以實現所需的能力。它適用於大多數企業業務模型，並且在需要潛在回應能力（例如，應急應變部門）並且相同資源涉及多種能力的組織中特別有用。通常使用業務場景發現並改進對這些功能的需求。

下圖說明了基於能力的規劃、企業架構和投資組合/專案管理之間的關係。