TOGAF ADM的迭代

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

11 min readMar 1, 2023

企業在運用TOGAF ADM的過程中，迭代(Iteration)是一項會使用到的技術。本文中，我們將介紹如何將迭代應用在ADM週期中，以及將ADM應用在不同的企業層級(企業等級、事業群等級、單位等級等)中，以便起始企業架構。

迭代的概念

ADM 支援許多可以代表是迭代的概念。

迭代描述了基於綁定到架構作業請求範圍的各個行動/作業，通過多個 ADM 週期描述架構面貌的過程。
迭代描述了開發架構的整合過程，其中不同 ADM 階段中描述的作業相互作用以產生整合的架構。為了簡明扼要地描述活動和產出，後面的迭代會按順序進行描述。
迭代描述了管理組織架構能力(Architecture Capability)變更的流程。

以迭代進行架構面貌(Architecture Landscape)的開發

ADM 的每個週期都將受到架構作業請求的約束。架構面貌將會由架構產出所填補上，擴展所描述的架構面貌，或根據需求更改架構面貌。

不同的專案可以同時運作它們自己的 ADM 週期，它們之間是有關連的。

一個專案可能會觸發另一個專案的啟動。通常，當更高等級的架構計劃確定需要更詳細的架構的Phase E: 機會或解決方案時，或者當專案確定架構面貌影響超出其架構作業請求範圍時，就會使用這種方式。

在ADM週期的架構開發迭代

架構專案可以同時運行多個 ADM 階段。這通常用於管理B.D.A.T四大架構領域之間的相互關係。

專案可能在 ADM 階段之間循環，計劃週期涵蓋多個階段。通常，當不存在更高等級的架構來提供整體背景脈絡和約束時，就會開始收斂到詳細的目標架構。

專案可能會返回到先前的階段，以便用新資訊循環並更新工作產品。通常，當"實施細節"和"變更範圍"觸發"變更"或"利害關係人需求"的重新優先排序時，就會產生可執行的架構路線圖或實施和遷移計劃。

架構能力迭代

專案可能需要準備階段的新迭代，以(重新)建立Phase A中確定的架構能力的各個面向，以處理架構作業請求。

作為Phase H中"變更請求"的結果，專案可能需要準備階段的新迭代來調整組織的架構能力，作為識別新的或更改的架構能力需求的結果。

影響迭代使用的因素

1.組織中已有的流程檢查點的形式和性質

我們的組織是否強制要求某些"作業組"在"檢查點"之間進行？組織是否規定某些作業必須先完成才能開展其他活動？

2.過程中預期的利害關係人參與程度

利害關係人是否期望密切參與解決方案的開發，或者他們是否期望看到一套完整的可交付成果以供審查和批准？

3.涉及的團隊數量和不同團隊之間的關係

整個架構是由特定團隊開發的，還是存在團隊之間具有治理關係的層次結構？

4.解決方案領域的成熟度以及達到可接受的解決方案所需的預期重工和優化

解決方案能否一次性完成，還是需要大量的PoC和原型設計作業才能演進成成果？

5.對於風險的態度

組織文化是否對運作中的部分完成的工作產品產生負面反應？組織文化是否要求解決方案先在測試環境中得到驗證，然後才能正式上線？

6.參與的類別

企業架構開發的背景脈絡是什麼？

迭代週期

TOGAF ADM 的建議迭代週期如下圖所示，用於有效地對相關架構活動進行分組以實現特定目的。

Architecture Context Iteration

架構能力(Architecture Capability)迭代支援所需架構能力的建立和演進。這包括通過建立或調整架構的方法、原則、範圍、願景和治理，為特定目的或架構參與類型架構作業的初始調整。

Architecture Definition Iteration

架構開發(Architecture Development)迭代允許通過循環或整合B.D.A.T四大架構階段來建立架構內容(architecture content)。這些迭代確保架構被視為一個整體。在這種類型的迭代中，利害關係人的審查工作通常更廣泛。隨著迭代集中在一個目標上，PhseE:機會和解決方案以及Phase F:遷移規劃階段的擴展確保在架構最終確定時考慮架構實施的可行性。

Transition Iteration

過渡規劃(Transition Planning)迭代為定義的架構建立正式的變更路線圖。

Architecture Governance Iteration

架構治理(Architecture Governance)迭代支援朝著定義的目標架構前進的變更作業的治理。

架構定義的風格

TOGAF 標準在定義架構時提出了兩種流程風格：

現行架構優先
對現行狀態的評估用於確定問題和改進機會。當現行狀態很複雜、沒有被清楚地理解或達成一致時，這是一種合適的方法。

目標架構優先
詳細闡述目標解決方案，然後對映回現行架構。如果目標架構在高階概念達成一致並且企業希望有效地過渡到目標模型，則這是一種合適的方法。

架構參與的類別

架構功能或服務組織可能會被要求在許多不同的環境中協助企業的架構開發，因為架構的範圍從概略到細節，從廣泛到狹隘的範圍，從當前狀態到未來狀態。在這些背景脈絡中，應該在開發架構時使用迭代的概念。

TOGAF 標準為企業架構師定義了三個典型的參與領域，分為所需變更的識別(Identification)、定義(Definition)或實施(Implementation)。每個分類都有自己的場景或參與類型；例如，支援業務策略、架構面貌的架構組合管理、基礎變更計劃等。這些在下圖中呈現並在以下部分中描述。

所需變更的識別

在任何變更計劃的背景脈絡之外，企業架構可以用作一種技術來提供 IT 能力的可見性，以支持戰略決策制定和執行協調。

所需變更的定義

在企業中確定需要變更的地方，企業架構可以用作一種技術，以結構化方式定義變更的性質和範圍。在大規模變更計劃中，可以開發架構以提供受到方案或專案組合範圍限制的詳細架構計劃。

所需變更的實施

企業所有等級的架構都可以用作一種技術，通過提供整體可見性和結構性限制以及定義評估技術決策的標準來為變更計劃提供設計治理(Design governance)。

在以上三個領域中，TOGAF 標準定義了許多參與類別，下表對其進行了總結。

將 TOGAF 各階段對映到迭代周期

ADM週期之間的迭代

在這種方法中，每次迭代都在架構描述的單一等級完成一個 ADM 週期(也就是說每一個ADM週期都有階層的)，Phase F: Migration Plan用於啟動新的更詳細的架構開發專案。這種類型的迭代強調需要更高層次的架構來指導和約束更詳細的架構，並且是一種在多次迭代中為專案開發完整架構面貌的方法。這種方法如下圖所示。

單一ADM週期內的迭代

TOGAF 標準包括針對現行優先和目標優先架構定義的建議迭代周期。目標優先的範例如下圖所示。

對映到 TOGAF 階段的建議迭代周期的說明如下。

架構開發迭代(現行優先)

迭代1 — 定義現行架構
此迭代包括通過 ADM 的業務架構、資訊系統架構和技術架構階段，重點是現行架構的定義。還要考慮機會、解決方案和遷移計劃以確定變更和測試可行性的重點。

迭代2—定義目標架構與差距
此迭代包括通過 ADM 的業務架構、資訊系統架構和技術架構階段，重點關注目標架構的定義和分析與現行架構的差距。還考慮機會、解決方案和遷移計劃來測試可行性。

迭代n — 優化現行/目標架構與差距
隨後的迭代嘗試糾正和完善現行和目標架構，以實現有效益、切實與可行的成果。

架構開發迭代(目標優先)

迭代1 — 定義目標架構
此迭代包括通過 ADM 的業務架構、資訊系統架構和技術架構階段，重點是目標架構的定義。還要考慮機會、解決方案和遷移計劃以確定變更和測試可行性的重點。

迭代2 — 定義現行架構與差距
此迭代包括通過 ADM 的業務架構、資訊系統架構和技術架構階段，重點關注現行架構的定義和分析與目標架構的差距。還考慮機會、解決方案和遷移計劃來測試可行性。

迭代n — 優化現行/目標架構與差距
隨後的迭代嘗試糾正和完善現行和目標架構，以實現有效益、切實與可行的成果。

過渡規劃(Transition Planning)迭代

迭代1 — 定義並同意一組改良機會
過渡規劃的初始迭代尋求在 ADM 的機會和解決方案階段獲得對解決方案機會組合的支援。此迭代還提供臨時實施和遷移計劃。

迭代n — 優化改良機會
過渡規劃的後續迭代尋求就過渡架構達成一致，並通過將問題反饋到"Phase E:機會和解決方案階段"來完善實施和遷移計劃。

架構治理迭代

迭代1 — 調動架構治理和變更管理流程
最初的架構治理迭代建立了一個變更治理流程，並安排了適當的人員、流程和技術來支援對已定義架構的託管存取和變更。

迭代n — 進行架構治理和變更控制
架構治理週期的後續迭代著重於審查變更計劃以解決問題並確保合規性。變更請求的結果可能會觸發重新存取另一個階段；例如，將新的需求反饋到 P準備階段以提高架構能力，或者將架構的新需求反饋到架構開發階段。

在整個架構面貌中應用 ADM

在一個典型的企業中，在任何時間點，架構面貌中都會存在多種架構。一些架構將解決非常具體的需求；其他架構則是一般性的。有些會解決細節問題；有些會是一個總體全局。為了解決這種複雜性，TOGAF 標準使用等級和企業連續體的概念來提供用於組織架構面貌的概念框架。

架構面貌

等級(Level)提供了一個框架，用於將架構面貌劃分為三個等級，如下圖所示。

戰略架構為運營和變更作業提供了一個組織框架，並允許在執行層面設定方向。
區段架構(Segment Architecture)為運營和變更作業提供了一個組織框架，並允許在方案(Program)或組合(Protfolio)等級設定方向和開發有效的架構路線圖。
能力架構為變更活動和有效架構路線圖的開發提供了一個組織框架，以實現能力增量(capability increments)。

架構連續體

架構連續體提供了一種通過抽象方法來劃分架構面貌的每個等級。它提供了一種一致性的方式來定義和理解架構中的通用規則、呈現和關係，包括可追溯性和衍生關係。架構連續體呈現了從基礎元素到組織特定架構的關係。

架構連續體的分類方法可用於將架構面貌劃分和組織成一組相關的架構：

每個單獨的架構或解決方案的可管理複雜性
分群的定義
定義的層次結構和導航結構
每個分組都有適當的流程、角色和職責

組織"架構面貌"

以下特徵可用於組織"架構面貌"：

廣度(Breath)：廣度(也稱主題subject matter)區域通常是描述架構面貌的主要組織特徵 — — 架構在功能上被分解為特定主題區域或部分的層次結構
深度(Depth)：對於更廣泛的主題領域，需要更少的細節來確保架構具有可管理的規模和復雜性 — — 更具體的主題領域通常會允許（並需要）更詳細的架構
時間(Time)：對於特定的廣度和深度，企業可以建立一個現行架構和一組延伸到未來的目標架構 — — 更廣泛和不太詳細的架構通常會在更長的時間內有效，並且可以為企業提供一個願景延伸到未來
新近度(recency)：最後，每個架構視圖都將經歷一個開發週期，在這個週期中它的準確性會不斷提高，直到最終獲得批准

使用上述標準，架構可以分為策略性、區段性和能力這三種架構等級，如下圖所示。

總結

TOGAF 標準提供了針對迭代而如如何調整ADM的指南。這包括建議的迭代周期以適應不同類別的架構參與。還提供了有關如何在整個架構面貌中使用不同等級來進行架構開發的指南。