es_ES Españolja 日本語pt_PT Portuguesezh_CN 简体中文zh_TW 繁體中文

TOGAF架構開發方法（ADM）介紹

Table of Contents hide
1 TOGAF 從何而來？
2 為什麼選擇 TOGAF？
3 什麼是 ADM？
4 ADM 輸入和輸出
5 可交付成果
6 初期：
7 A 階段：架構願景：
8 B階段：業務架構：
9 階段 C：信息系統架構：
10 D階段：技術架構：
11 E 階段：機會和解決方案：
12 階段 F：遷移計劃：
13 階段 G：實施治理：
14 H 階段：結構變更管理：
15 架構需求管理：
16 ADM 初步階段
16.1 輸出成果：
17 ADM 階段 A：架構願景
17.1 輸出成果：
18 ADM 階段 B：業務架構
18.1 輸出成果：
19 ADM 階段 C：信息系統架構
20 ADM 階段 D：技術架構
20.1 輸出成果：
21 ADM E 階段：機會與解決方案
21.1 輸出成果：
22 ADM 階段 F：遷移計劃
23 ADM 階段 G：實施治理
23.1 輸出成果：
24 ADM 階段 H：架構變更管理
25 概括
25.1 TOGAF 介紹性參考資料
25.2 ArchiMate 3

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

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

TOGAF 從何而來？

TOGAF 起源於美國國防部的信息管理技術架構框架（TAFIM）。TOGAF 1.0 經過多年探索，終於在 1995 年發布，得到了美國國防部的許可，並得到了美國政府的大量投資。迄今為止，TOGAF 已經發布了第九個版本，TOGAF 9（最新版本是 TOGAF 9.2）

為什麼選擇 TOGAF？

IT 架構需要密切反映組織的業務目標。實際上，應該使用特定技術（業務場景）來確保 IT 架構師正確理解業務目標，並在使用 TOGAF 開發的 IT 架構中得到反映。

以下是我們應該採用 TOGAF ADM 進行架構開發的原因：

  • 綜合通用方法
  • 與其他框架互補而非競爭
  • 被市場廣泛採用
  • 量身定制，以滿足組織和行業的需求
  • 在免費的永久許可下可用
  • 供應商、工具和技術中立的開放標準
  • 避免重新發明輪子
  • 業務 IT 對齊
  • 基於最佳實踐
  • 可能參與框架的演變

什麼是 ADM？

架構開發方法 (ADM) 用於開發滿足組織的業務和信息技術需求的企業架構。TOGAF ADM 是大量架構從業者為以下目的不斷貢獻的結果：

  • 它描述了一種開發和管理企業架構生命週期的方法，並構成了 TOGAF 的核心。
  • 它可以根據組織的需要進行定制，然後用於管理架構規劃活動的執行。

架構開發方法——通常稱為 ADM 的縮寫——是一個詳細的分步過程，用於開發或更改企業的架構。

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

這些階段是：

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

ADM 輸入和輸出

TOGAF 提供了每個階段的許多輸入和輸出可交付成果：

  • 這些是建議，不需要完全遵循
  • 生成的每個可交付成果都應進行版本控制，以指示何時發生更改
  • 顯示的版本編號也是一個建議，無需遵循

可交付成果

合同規定的工作產品，然後由利益相關者正式審查、同意和簽署。它通常會在項目完成時存檔，或者作為參考模型轉換為架構存儲庫

初期：

初始階段的主要目標是確定和建立組織所需的架構能力。

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

在這個階段，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將Phase C-Information System Architecture-分為兩部分，涵蓋 數據開發 和 應用 架構。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階段特別需要四個管理框架之間的密切合作，以使實施和安置計劃取得成功。

這四個領域是：

  1. 商業計劃
  2. 企業架構
  3. 投資組合管理
  4. 項目管理

通過合作，這四個領域必須優先考慮工作，使用績效評估、投資回報、商業價值、關鍵成功因素、有效性衡量和戰略匹配等標準。

階段 G：實施治理：

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

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

當我們到達 G 階段時，架構已經開發（在 A 到 D 階段），提供架構的機會和解決方案已經確定（在 E 階段），並且詳細的實施和遷移計劃已經完成（在 F 階段）。因此，階段 G 架構團隊的角色是監督架構實施。這是通過驗證部署的範圍和優先級、指導開發和解決方案部署以及執行合規性審查來完成的。

架構合同文件用於推動架構變更。在階段 G 開始時生成並由架構功能和負責實施的人員批准，它是一種評估架構治理合規性的機制。

H 階段：結構變更管理：

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

該過程應該支持已實現的企業架構作為一個動態環境，可以靈活地響應這些變化并快速發展。在階段 H，治理機構設定標準來確定變更請求是否需要簡單的架構更新，或者是否需要啟動新的架構開發方法 (ADM) 循環非常重要。變更必須與業務價值直接相關。如何使用企業架構是架構開發週期中最重要的部分，因此在 H 階段監控業務增長和下降至關重要。

最後，昨天為組織工作的企業架構不再支持當前或未來的功能。H 階段變更請求的輸出可以歸類為簡化——通常由減少投資的要求驅動；增量變化——需要從現有投資中獲得額外價值；或者重新設計變革，這是一個需要增加投資和創造新價值的驅動。

架構需求管理：

在 ADM 的每個階段，都需要生成、分析和審查的要求。需求管理階段描述了在整個 ADM 中管理這些架構需求的過程。需求管理階段是 ADM 的核心——這就是為什麼它顯示在 ADM 麥田圈的中心。此階段描述了需求管理過程以及該過程如何與 ADM 的其他階段相關聯。需求不是靜態的——它們在我們完成 ADM 的每個階段和 ADM 週期之間動態演變。

企業架構的需求以及對這些需求的後續更改將被識別、存儲以及與 ADM 階段相關的輸入和輸出，以及在 ADM 週期之間。應對需求變化至關重要。架構處理不確定性和變化——利益相關者期望和可能性之間的“灰色地帶”！因此，架構要求總是會發生變化。

此外，該架構涉及許多企業無法控制的驅動因素和約束——例如不斷變化的市場條件或新的立法——它們將以不可預見的方式產生需求變化。

TOGAF 強調需求管理過程本身不會處理、解決或優先考慮需求，因為這是在 ADM 的相關階段完成的。需求管理階段就是對整個 ADM 中的需求進行管理的過程。

ADM 初步階段

創建架構能力所需的準備和啟動活動，包括 TOGAF 的定制和架構的定義

輸出成果：

ADM 階段 A：架構願景

架構開發週期的初始階段。它包括有關定義架構開發計劃範圍、識別利益相關者、創建架構願景以及獲得批准以繼續進行架構開發的信息

輸出成果：

ADM 階段 B：業務架構

業務架構：開發業務架構以支持商定的架構願景

輸出成果：

ADM 階段 C：信息系統架構

信息系統架構：開發信息系統架構以支持商定的架構願景

ADM 階段 D：技術架構

技術架構：開發技術架構以支持商定的架構願景

輸出成果：

ADM E 階段：機會與解決方案

Opportunities & Solutions 為之前階段定義的架構進行初始實施規劃和交付工具的識別

輸出成果：

ADM 階段 F：遷移計劃

遷移計劃通過最終確定詳細的實施和遷移計劃來解決如何從基線遷移到目標架構

ADM 階段 G：實施治理

實施治理提供實施的架構監督

輸出成果：

ADM 階段 H：架構變更管理

架構變更管理建立了管理新架構變更的程序 需求管理檢查整個 ADM 中管理架構需求的過程

概括

ADM 是一種綜合的通用方法

  • 它推薦了開發架構所涉及的各個階段和步驟的順序
  • 這是一種迭代方法
  • 它藉鑑了 TOGAF 的資產和流程的其他部分
  • 它可以與其他框架的其他可交付成果一起使用

以下是每個開發階段的 TOGAF ADM 概述，如下圖所示：

  1. 有關 TOGAF ADM 指南的更多信息
  2. 有關即時 TOGAF 模板的更多信息
  3. 有關 ArchiMate 工具的更多信息
  4. 免費試用 Visual Paradigm

TOGAF 介紹性參考資料

ArchiMate 3

Leave a Reply

發佈留言必須填寫的電子郵件地址不會公開。