TOGAF ADM：它是什麼，為什麼它如此重要？ - IT 觀察者隨筆

Table of Contents hide

TOGAF 是一個開放的組織框架。該框架本身是一個有據可查的知識體系，包括用於開發企業架構的詳細方法和一組支持工具。TOGAF 9.2 是該框架的最新版本。

TOGAF 由 The Open Group 的成員開發和維護，他們在一個名為 Architecture Forum 的團隊中工作。TOGAF 第 1 版的初步開發是在 1995 年完成的，隨後的 TOGAF 版本擴展和改進了這一知識體系。
TOGAF 是由代表一些世界領先公司和組織的 300 多名架構論壇成員共同努力開發的，因此它是對一般企業架構實踐的極好總結。
開發和維護企業架構是一個複雜的過程，涉及許多利益相關者和決策過程。TOGAF 通過記錄企業架構規範、流程和工作產品來提供幫助。
通過使用 TOGAF，組織可以開發一致的企業架構，以反映利益相關者的需求，採用最佳實踐，並適當考慮當前需求和未來感知的業務需求。

什麼是 ADM？

架構開發方法（通常稱為 ADM 的首字母縮寫詞）是開發或更改企業架構的詳細分步過程。

TOGAF ADM 迭代周期

ADM 描述了涵蓋架構開發週期的 10 個階段。

這些步驟是：

初步階段
A 階段：架構願景
B階段：業務架構
階段 C：信息系統架構
D階段：技術架構
E 階段：機會和解決方案
階段 F：遷移計劃
階段 G：實施治理
階段 H：架構變更管理
ADM 架構需求管理

預備階段：

初步階段的主要目標是識別和建立組織所需的架構能力。

其中一個關鍵部分是確定需要做什麼以及如何實施。 例如，主要輸出是一個架構工作請求 ，它概述了需求並決定需要什麼範圍、結構、工具或架構框架來支持這項工作。

在這個階段，TOGAF 是為滿足即將到來的 ADM 迭代的需求而量身定制的。我們定義基本原則，評估企業架構和業務進行所需更改的能力，並將 TOGAF 與其他管理框架集成。此階段有一些步驟來限制受提議變更影響的企業組織，確定正確的治理和支持框架，定義和建立 EA 團隊和組織，確定和建立架構原則，定制 TOGAF 和任何其他框架，以及實施工具. 在這個階段結束時，EA 團隊應該準備好遵循 ADM 週期的迭代。這部分是因為初級階段顯示在 ADM 圖表的頂部，位於階段 A 到 H 的主循環之外。

A 階段：架構願景：

階段 A 提供了清晰的架構工作聲明，將在 ADM 的迭代中提供。它還提供了提議的企業架構的願景。這種方向感對於在整個迭代過程中指導 ADM 的工作至關重要。這份 建築工作聲明 定義了開發和部署架構願景中概述的架構的工作程序。正是這種願景為提議的企業架構將提供的功能和業務價值提供了高層次的願望。從建築工作申請開始，階段 A 提供了一個工具（此願景），將提議的能力的好處推銷給企業內的利益相關者和決策者。業務場景用於理解業務需求並幫助闡明所需功能所隱含的架構需求。這記錄在架構工作聲明中，用於建立共識以支持最終架構。當贊助組織簽署文件時，就會達成共識。

階段 A 的步驟都是關於將建設工作請求轉化為清晰的架構工作聲明，並確保業務能夠、準備好、願意並致力於進行必要的架構更改。這涉及建立架構項目，包括定義其範圍，以及識別和詳細說明架構和業務原則。階段 A 識別利益相關者及其關注點和要求，並在初步階段識別業務目標、驅動因素和約束。為確保成功，它還評估業務能力、評估業務轉型準備情況並解決任何轉型風險。

B階段：業務架構：

TOGAF 將企業架構視為提高業務能力的一種方式——這就是為什麼第一個架構開發階段涉及 業務架構的原因。

ADM 從業務角度出發——初步階段的 架構工作請求 中確定了強大的業務需求，並進一步細化為階段 A的架構工作和 架構願景 聲明。

業務架構階段的一個關鍵目標是開發一個目標業務架構，展示企業如何實現架構願景並解決架構工作請求。它的第二個目標是首先確定候選架構路線圖組件，以彌合基線和目標業務架構之間的差距。TOGAF 將業務架構知識視為在數據、應用程序和技術等其他領域進行架構工作的先決條件。業務架構還向關鍵利益相關者展示了架構工作的業務價值和投資回報。業務模型，例如活動或流程模型、用例和類模型或節點連接圖，

所有三個架構開發階段（B、C 和 D）都遵循類似的步驟。重用任何可用的參考模型並自定義所有輸出以解決利益相關者的觀點非常重要。然後架構師開發業務架構的基線和目標描述，並執行差距分析以確定如何從一個過渡到另一個。

階段 C：信息系統架構：

TOGAF 將階段 C（信息系統架構）分為兩部分，涵蓋數據和 應用程序 架構的開發。TOGAF 文檔有一個簡短的介紹性章節，涵蓋這兩個領域，然後是數據和應用程序的單獨章節。與其他架構開發階段 (B&D) 一樣，目標是為數據和應用程序開發目標信息系統架構，並根據基線和目標架構之間的差距確定候選架構路線圖組件。

階段 C 始終涉及數據和應用程序架構的組合。提供兩者都包含的順序無關緊要 – 兩種方法都有倡導者。數據和應用程序的步驟非常相似——選擇參考模型、觀點和工具；制定基線，然後定位架構描述，執行差距分析並定義候選路線圖組件；並解決整個架構環境中的任何影響。在正式的利益相關者審查之後，最終確定了架構並創建了架構定義文檔。

數據和應用程序之間的主要區別在於主題，這反映在使用不同的參考模型、技術和架構表示上。例如，數據架構可能使用實體關係圖或類圖，而應用程序架構可能使用應用程序通信圖或軟件工程圖。

D階段：技術架構：

D 階段是 TOGAF 的階段，為架構項目開發技術架構。技術架構描述了平台服務以及邏輯和物理技術組件的結構和交互。階段 D 開發支持數據和應用程序組件（在階段 C 中開發）的目標技術架構，支持業務組件。

在 B、C 和 D 階段開發的架構結合起來實現架構願景——解決利益相關者的關注和對建設工作的要求。與其他架構開發階段一樣，階段 D 確定候選架構路線圖組件，以實現從基線到目標的過渡。D 階段的步驟與 B 和 C 階段的步驟幾乎相同——主要區別在於現在的重點是技術。因此，這包括技術參考模型和技術標准或測量——例如性能、可維護性、位置和延遲或可用性。

確定輸出和可交付成果對於幫助構建真正支持信息系統和業務架構的技術架構非常重要。獲得正確的範圍可以加快回報，而過多的範圍會阻礙成功實施。這不是關於部署技術本身，而是關於開發真正解決架構願景和工作要求的技術架構。

E 階段：機會和解決方案：

E 階段得名——它正在尋找通過實施特定解決方案來交付目標架構的機會。E 階段通過結合建築開發階段（B、C 和 D）的分析和建議，生成第一個完整版本的建築路線圖。

這個階段的重點是如何提供模式。因此，它著眼於創建架構路線圖，在時間線中列出工作包以實現目標架構。當更改如此之大以至於無法直接從基線轉到目標架構時，階段 E 會導致增量方法，包括中間或過渡架構。E 階段將所需的架構更改映射到具有資金和資源的投資計劃和項目，以執行工作包並提供過渡和目標架構。此階段的輸入幾乎是早期階段輸出的所有內容。這些步驟採取了這些輸出；整合它們，分析依賴關係並協調差異；並重申該組織有能力做出改變。階段 E 細化和更新需求、架構文檔和架構路線圖。關鍵輸出是實施和遷移計劃的第一步。

F 階段：遷移計劃：

ADM 的早期階段確定了架構更改的需求，然後開發業務、數據、應用程序和技術架構來支持這一需求。然後，第二階段製定一個高層次的 實施和遷移計劃 ，以利用投資機會並確定具體的解決方案。目標架構。F 階段最終確定了詳細的 實施和遷移計劃 ，以及最終的架構路線圖。

它還確保該計劃與企業內使用的變更管理方法以及整個變更組合中的其他計劃保持一致。最後，階段 F 確保關鍵利益相關者充分了解業務價值、工作包的成本以及過渡和未來架構。雖然 ADM 的早期階段在很大程度上由企業架構團隊指導，但從 E 到 H 的階段需要與其他變革推動者協作。F 階段特別要求四個管理框架緊密合作，以使實施和移民計劃取得成功。這四個領域是：

商業計劃
企業架構
投資組合管理
項目管理

這四個領域必須協同工作，使用績效衡量、投資回報、商業價值、關鍵成功因素、有效性衡量和戰略匹配等標準來確定工作的優先級。

階段 G：實施治理：

實際開發和實施與階段 G 並行進行。階段 G 確保實施項目以及其他正在進行的項目符合定義的架構。

通常，目標架構被開發為一系列轉換，以盡快實現業務價值和收益並降低轉型計劃中的風險。每一次轉型都代表著向目標公司邁出的一步，實現了自己的商業利益。

當我們到達階段 G 時，已經開發了架構（在階段 A 到階段 D），已經確定了交付架構的機會和解決方案（在階段 E），並且已經完成了詳細的實施和遷移計劃（在階段F））。因此，階段 G 架構團隊的角色是監督架構的實施。這是通過確認部署的範圍和優先級、指導開發和解決方案部署以及執行合規審查來完成的。架構合同文件用於推動架構變更。在階段 G 開始時生成並由架構功能和負責實施的人員批准，它是評估架構治理合規性的機制。

H 階段：架構變更管理：

一切都沒有完全按計劃進行——總會有新的需求和要求來改變架構。階段 H 描述了變更管理過程，以一種內聚的架構方式來管理架構的變更。通常，這需要持續監控治理請求、新技術或業務環境的變化。

該過程應該支持已實施的企業架構作為一個動態環境，可以靈活地快速發展以響應這些變化。在階段 H，管理機構設置標準以判斷變更請求是否需要簡單的架構更新，或者是否需要啟動架構開發方法 (ADM) 的新周期，這一點至關重要。避免“爬行優雅”很重要，因此更改必須與業務價值直接相關。如何使用企業架構是架構開發週期中最重要的部分，因此在 H 階段監控業務增長和下降至關重要。最終，昨天為組織工作的企業架構不再支持當前或未來的功能。H 階段的變更請求輸出可歸類為簡化——通常由減少投資的要求驅動；增量變化——需要從現有投資中獲取額外價值；或重新設計變革，這是由增加投資和創造新價值的需求驅動的。

架構需求管理：

在 ADM 的每個階段生成、分析和審查需求。需求管理階段描述了在整個 ADM 中管理這些架構需求的過程。需求管理階段是 ADM 的核心——這就是為什麼它顯示在 ADM Clipping Circle 的中心。此階段描述了需求管理的過程以及該過程如何與 ADM 的其他階段聯繫起來。需求不是靜態的——它們隨著我們完成 ADM 的每個階段和 ADM 週期之間而動態變化。企業架構的需求和對這些需求的後續更改將被識別、存儲以及與 ADM 階段相關的輸入和輸出，以及在 ADM 的周期之間。處理需求變化至關重要。架構處理不確定性和變化——利益相關者期望和可能性之間的“灰色地帶”！因此，架構要求總是會發生變化。此外，架構涉及許多業務無法控制的驅動因素和約束——例如不斷變化的市場條件或新的立法——這可能會以不可預見的方式造成需求變化。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。因此，架構要求總是會發生變化。此外，架構涉及許多業務無法控制的驅動因素和約束——例如不斷變化的市場條件或新的立法——這可能會以不可預見的方式產生需求變化。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。因此，架構要求總是會發生變化。此外，架構涉及許多業務無法控制的驅動因素和約束——例如不斷變化的市場條件或新的立法——這些都會以不可預見的方式產生需求變化。TOGAF 強調需求管理過程本身並沒有解決，解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。需求管理階段只是在整個 ADM 中管理需求的過程。TOGAF 強調需求管理過程本身並沒有解決、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段只是在整個 ADM 中管理需求的過程。

（*來源：TOGAF ADM：它是什麼，它為什麼如此重要？）

TOGAF

ArchiMate 3