TOGAF ADM介紹

運用"雲端服務"加速企業的數位轉型願景

11 min readJan 8, 2023

本文將介紹ADM(Architecture Development Method) 週期、組成、還有與 TOGAF 標準其他部分的關係，以及如何調整和確定 ADM 的使用範圍。

本文重點:

ADM週期是甚麼?
ADM與TOGAF其他部分的關係
ADM週期循環的重點
如何讓ADM更符合我們自己的企業
架構治理的必要性
為我們的組織確定架構活動的範圍
整合架構領域

架構發展階段週期

ADM 由多個階段組成，這些階段在一個範圍的架構領域中不斷循環，使企業架構師能夠確保充分滿足企業的複雜需求。ADM的基本架構如下圖:

ADM 在整體過程中的各階段之間以及階段內不斷迭代。 在整個 ADM 週期中，應該經常根據原始需求驗證結果，包括整個 ADM 週期和流程中每個階段的結果。而這類的驗證應重新考量到需求的"範圍、細節、時間表和里程碑(milestones)"。每個階段都考量從之前的流程迭代中的產出和來自外部世界的參考資料，例如其他框架或模型。

ADM 支援三個層次的迭代概念：

ADM的大循環: 架構工作的一個階段完成後直接進入架構工作的下一個階段。
各階段間的迭代: 跨階段迭代（例如，在Phase D後返回Phase B）
單一階段內的循環: 一種單一階段的細化架構內容技術

下表為每一階段的摘要活動:

ADM 雖然為展發整個組織的企業架構所涉及的各個階段和步驟定義了建議的順序，但沒有確定企業架構活動的範圍； 這必須由組織自己決定。

ADM的每個階段還有再更細分的步驟，以下範例為Phase B: Business Architecture階段的各項步驟，而步驟的順序應根據組織實際的情況進行調整。特別是，我們應該確定先進行基線(baseline)業務架構開發還是目標業務架構開發哪一種比較適合。

Phase B : Business Architecture 步驟

選擇與參考各種模型，觀點與工具
進行基本業務架構描述
進行目標業務架構描述
進行差距分析(Gap analysis)
定義待選的路線圖組件
解決整個架構樣貌(Landscape)的影響
進行正式的利害關係人檢閱
業務架構的定案
建立架構定義文件

上述的步驟也用於Phase E: Information System Architecture與Phase D: Technology Architecture。

在使用 ADM 的整個過程中，會有產出。早期階段的產出可能會在後期階段被修改。產出的版本控制通過版號進行管理。ADM 中使用版本編號來說明基本架構和目標架構定義的演變，如下所示：

以上的版號只是TOGAF的範例，實際的版號還是需要由企業架構師根據企業的實際狀況與需求進行調整。

ADM與TOGAF其他部分的關係

與企業連續體和架構儲存庫的關係

企業連續體是一種對架構的來源材料進行分類的方法 — — 包括組織自己的架構存儲庫的內容，以及組織所處產業相關的可用參考模型集。 企業連續體的實際施作通常採用架構存儲庫的形式，其中包括在企業內使用的參考架構、模型和模式，以及以前在企業內完成的實際架構工作產出。

在整個 ADM 的相關位置，如果架構儲存庫有架構資產(就是文件)的話，哪麼企業架構師應該應該考慮使用。在某些情況下 — — 例如，在Phase D : Technology Architecture的開發中。同樣，在Phase B : Business Architecture的開發中，它可能是從整個產業中取得的電子商務參考模型。

在使用 ADM 時，企業架構師正在開發某個時間點的企業決策及其在特定時間點的施作。 ADM 的每次迭代都將補上一個特定於組織的架構樣貌，其中包含通過該流程識別和運用的所有架構資產，包括最終交付的特定於組織的架構。

架構開發是一個連續的、循環的過程，隨著時間的推移反覆執行ADM，企業架構師逐漸向組織的架構中將相關內容加入架構存儲庫。雖然 ADM 的主要重點是開發成適用於每個企業自己的架構，但在這個更廣泛的脈絡下，ADM 也可以被視為使用從轉換過程的“左側(也就是企業連續體更通用的一面)”中取得相關可重複使用建構區塊放入企業自己的架構存儲庫的過程。

事實上，ADM 的第一次施作通常比較困難，因為可重複使用的架構資產相對可能比較少(甚至沒有)。然而，即使在這個開發階段，也將有來自外部資源（例如 TOGAF 標準）以及整個 IT 產業的可用架構資產(例如ITIL)，可以用來支持這項作業。

但是隨著越來越多的架構資產被識別，並可加入組織的架構存儲庫，後續執行將變得更加容易，因為後續可重複使用的材料將會越來越多。

與基礎架構的關係

ADM 在補充企業的基礎架構時也是有用的。企業的業務需求可用於識別基礎架構(Foundation Architecture)中必要的定義和選擇。這可以是一組可重複使用的通用模型、政策和治理定義，甚至可以忽視一切的技術選擇（例如，法規法令的要求）。基礎架構的強化遵循與企業架構類似的原則，不同之處在於對整體企業的要求僅限於一般企業的整體，因此不如對特定企業(如特定於我們自己的公司)的要求完整。

與支援的指南技術的關係

ADM 的應用有一組資源可以使用 — — 指南、模板、清單和其他素材。單獨描述各個指南和技術，以便在必要時從 ADM 中的相關點(relevant points)引用它們，而不是讓這些資源的素材混淆 ADM 本身的描述。

為支援 TOGAF 標準而提供的指南描述了如何調整 ADM 流程以處理許多不同的使用場景，包括不同的流程風格（例如，迭代的使用）和特定的專業架構（例如資安）。所描述的技術支援 ADM 中的特定任務（例如，差距分析技術、原則、業務場景等）。

ADM週期循環的重點

由於ADM是迭代式的，所以在每一次的迭代之後都會產生以下的決策:

企業的所包括的業務範圍
詳細的程度
時間區段
架構資產的重複使用，包含 1)上一個ADM迭代 2)其他的框架、系統模型、產業模型等等

做出的決策應基於企業的能力和(或)資源可用性，以及為企業帶來的價值。 ADM 不會建議企業在使用ADM時的活動範圍；這必須由組織自己決定。

活動範圍的選擇對於架構設計工作的成功至關重要。主要指導方針是關注為企業創造價值的內容，並相應地選擇橫向(跨出組織)和縱向(組織內部)的活動範圍以及專案進度表。不斷重複此活動，這樣未來的迭代將建立在現行工作中所建立內容的基礎上，增加更大的寬度和深度。在必要時，應客製成專屬於我們的 ADM 以滿足組織的需求。 這意味著可以省略、修改ADM的某些階段，甚至可以添加額外的程序。

如何讓ADM更符合我們自己的企業

ADM 是架構開發的通用方法，旨在處理大多數系統和組織需求。但是，通常需要修改或擴展 ADM 以滿足組織特定需求。應用 ADM 之前的任務之一是審查企業的流程及其產出的適用性，然後根據個別企業的情況對其進行適當調整。此活動很可能會產生用於“特定個別企業”的 ADM。

出於多種原因，需要根據單一企業的情況調整 ADM。部分原因概述如下：

一個重要的考慮因素是 ADM 中的階段順序在某種程度上取決於企業內架構規章的成熟度。例如，如果做架構的業務案例沒有得到很好的識別，那麼Phase A : Architecture Vision是不可少的；接下來需要詳細的Phase B: Business Architecture來定義其餘架構工作的業務案例，並確保利害關係人積極參與該項階段的作業。
階段的順序也可以由企業的業務和架構原則來定義。例如，業務原則可能要求企業準備調整其業務流程以滿足固定的解決方案的需求，以便快速實施以實現對市場變化的快速回應（例如使用雲端運算）。在這種情況下，業務架構（或至少它的完成）很可能會在資訊系統架構完成之後才會進行。
企業可能希望將 ADM 與另一個企業架構框架一起使用，這個其他框架具有針產業的一組定義的可交付成果：政府單位、金融、電信這些高度監管的產業等。
ADM 是構成企業公司治理模型的眾多流程之一。 ADM 是對其他標準專案管理流程的補充和支援。企業將客製後的 ADM 會反映與其他管理流程的關係和依賴性。
ADM可以讓外包商來使用於客戶（也就是發包企業），並且需要進行客製在承包商的現有實作和發包企業的要求之間實現適當的妥協。
ADM可以簡化成適用於成中小企業的簡易版，該版本更適合沒有大型企業的大量資源和系統複雜性這類環境的運作。
企業通常非常龐大和複雜，在一個整體協作的業務框架內包含許多獨立但相互連結的“企業”，而我們使用的架構方法需要適應這一點。這樣的企業通常不能被成完整的視為一個單一的實體，而是需要多種方法一起使用。

架構治理的必要性

無論是被組織客製化還是按照 TOGAF 標準中的標準方式使用，ADM都是需要管理和治理的關鍵流程。 遵守 ADM 是架構治理的基礎，以確保做出所有考量並產生所有必需的可交付成果。

所有架構工件、治理和相關流程的管理都應該在一個受控環境。通常這將基於一個或多個支援有著＂版本化的物件和流程控制和狀態＂的存儲庫。

一個受到治理存儲庫的主要資訊區域應包含以下類型的資訊：

Reference Data: （來自組織自己的存儲庫/企業連續體的附屬品，包含外部資料；例如 COBIT，IT4IT 的參考架構）：用於專案實施期間的指導和指南
Process Status:有關任何治理流程狀態的所有資訊的記錄；這方面的例子包括未完成的合規請求、豁免請求和合規評估調查
Audit Information: 所有已完成的治理流程運作的記錄。

而這一類的Audit Information使用是為了：