TOGAF ®，由The Open Group的標準，是一個成熟的企業架構方法和框架由世界領先的組織使用，以提高業務效率。它是最突出和最可靠的企業架構標準，確保企業架構專業人員之間的標準，方法和通信一致。精通TOGAF標準的企業架構專業人員享有更高的行業信譽，工作效率和職業機會。TOGAF幫助從業者避免陷入專有方法，更有效地利用資源，實現更高的投資回報。

ADM方法是由一組按照架構領域的架構開發順序而排列成一個環的多個階段所構成。通過這些開發階段的工作，設計師可以確認是否已經對複雜的業務需求進行了足夠全面的討論。TOGAF中最為著名的一個ADM基礎結構圖如下所示：

ADM方法被迭代式的應用在架構開發的整個過程中、階段之間和每個階段內部。在ADM的全生命週期中，每個階段都需要根據原始業務需求對設計結果進行確認，這也包括業務流程中特有的一些階段。確認工作需要對企業的覆蓋範圍、時間範圍、詳細程度、計劃和里程碑進行重新審議。每個階段都應該考慮到架構資產的重用（以往ADM迭代成果、其它框架、系統模型、行業模型等）。

因此，ADM便形成了3個級別的迭代概念：

• 基於ADM整體的迭代，用一種環形的方式來應用ADM方法，表明了在一個架構開發工作階段完成後會直接進入隨後的下一個階段。
• 多個開發階段間的迭代，例如在完成了技術架構階段的開發工作後又重新回到業務架構開發階段。
• 在一個階段內部的迭代，TOGAF支持基於一個階段內部的多個開發活動，對複雜的架構內容進行迭代開發。

 

TOGAF和ArchiMate

ArchiMate是Open Group引入的建模標準。它提供了豐富的建模符號和概念，支持在域內和域之間一致地建模企業架構。

由於TOGAF和ArchiMate都是由Open Group維護的標準，它們都用於企業架構開發，很多人在它們之間感到困惑，提出諸如“TOGAF和ArchiMate之間有什麼區別？”，“TOGAF vs ArchiMate？”之類的問題， TOGAF框架和ArchiMate建模語言均由The Open Group維護。TOGAF 9.1和ArchiMate 2.1或更高版本協同工作，是EA開發的兼容和補充。雖然TOGAF ADM是一個可用於開發和實施企業系統，流程和結構的EA框架，但ArchiMate可用作可視建模語言，可用於創建EA描述。

重申ArchiMate標準是建模語言而非框架是很重要的。ArchiMate語言廣泛用於開發可視化EA模型，通常與TOGAF ADM一起使用。此外，TOGAF和ArchiMate標準可以組合在一起，提供一組可用於對不同體系結構進行建模的視點。

ArchiMate語言由ArchiMate核心語言組成，其中包括業務，應用程序和技術層，以及構建體系結構的策略和動機以及實現和遷移的元素。

下圖顯示了ArchiMate語言如何與TOGAF架構開發方法（ADM）階段相關的簡化映射。

 

ArchiMate核心

代碼ArchiMate層可以對TOGAF定義的體系結構域進行建模。

該業務，應用和技術層支持業務，信息系統和技術架構領域由TOGAF框架中定義的描述，以及它們的相互關係。

戰略與動機延伸

戰略和動機擴展可以實現利益相關者的建模，變革的驅動因素，業務目標，原則和要求。

ArchiMate語言中的策略和激勵元素可用於支持TOGAF ADM 的需求管理，初步和架構願景階段，這些階段建立了高級業務目標，架構原則和初始業務需求。它們也與TOGAF ADM的架構變更管理階段相關，因為該階段涉及不斷變化的需求。

實施和遷移擴展

實施和遷移擴展支持項目組合管理，差距分析以及過渡和遷移規劃的建模。

ArchiMate語言的實現和遷移元素通過TOGAF ADM的機會和解決方案，遷移規劃和實施治理階段支持體系結構的實施和遷移。

TOGAF ADM生命週期 - 迭代

ADM支持三個級別的迭代概念：

在ADM周圍循環：ADM以循環方式呈現，表明一個架構工作的完成直接進入架構工作的後續階段。

在階段之間進行迭代：TOGAF描述了跨階段迭代的概念（例如，在完成技術架構時返回到業務架構）。

圍繞單個階段循環：TOGAF支持在單個ADM階段中重複執行活動，作為詳細描述建築內容的技術。

TOGAF ADM

在ADM過程的應用過程中，根據ADM提供的相位目標，根據一些輸入和步驟產生許多輸出。

例如：

• 流程
• 建築要求
• 項目計劃
• 項目合規評估
• 等等

為了以一致和結構化的方式整理和展示這些主要的工作產品，TOGAF定義了一個結構模型，在其中放置它們。

ADM輸入和輸出

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

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

交付

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

 

2、ADM方法各階段中的活動

在以下的表格中從目標、步驟、輸入和輸出幾個方面對ADM環中的每個階段進行了分析和描述。

3.1 準備階段

3.2 階段A——架構願景

在架構願景階段，將啟動一次架構開發過程的迭代，設置迭代工作的範圍、約束和期望，創建架構願景、驗證業務上下文，創建架構工作說明書並取得大家的一致認可。

願景表達了我們對架構的期望結果，闡明重要涉眾關注的問題和目標，可幫助團隊關注架構的核心領域。

3.3 階段B——業務架構

在業務架構階段，將開發一個支持架構願景的業務架構。架構願景中概括的基線和目標業務架構將在此被細化，從而使它們可以作為技術分析的有用輸入。業務過程建模、業務目標建模和用例建模是用於生成業務架構的一些技術，這又包含了所期望狀態的差距分析。

本階段的核心內容包括組織如何滿足業務目標；企業靜態特徵（業務目標、業務組織結構、業務角色）；企業動態特徵（流程、功能、服務）。

3.4 階段C——信息系統架構

在信息系統架構設計階段，確定主要的信息類型和處理這些信息的應用系統。在本階段有兩個主要的步驟，數據架構設計和應用架構設計，二者既可以依次開發，也可以並行開發。核心內容為：IT系統如何滿足企業的業務目標；信息以及信息之間的關係；應用以及應用之間的關係。

3.4.1 數據架構

3.4.2 應用架構

3.5 階段D——技術架構

在技​​術架構階段，完成對IT系統基礎服務設施的設計，定義了架構解決方案的物理實現，包括硬件、軟件和通信技術。

3.6 機會及解決方案

這是第一個直接關注實施的階段，該階段主要描述確定目標架構交付物（項目、程序或文件）的過程。

3.7 階段F——遷移規劃

該階段通過制訂一個詳細的實現和遷移計劃完成從基線架構向目標架構的轉變。

3.8 階段G——實施治理

該階段定義了實施項目的架構約束，提供項目構建的架構監督，產生一個架構契約。

3.9 階段H——架構變更管理

該階段確保能夠以一種可控制的方式對架構的改變進行管理。

3.10 需求管理

架構需求管理適用於ADM的所有階段，這是一個動態的過程，完成對企業需求的識別、存儲並把它們插入或取出相應的ADM階段。需求管理是ADM流程的中心。處理需求變化的能力對於ADM過程是非常重要的，架構通過其天然處理不確定性和變化的能力在涉眾訴求之間架起橋樑並交付一個可實踐的解決方案。

3.11 建立架構活動的範圍

ADM方法不能夠確定架構活動的範圍，這必須由企業自己確定。需要限定架構活動範圍的原因與以下因素有關：

選定的架構活動範圍理論上應該地支持企業中的架構師高效地完成治理和整合工作。這需要一套一致的“架構分區”，確保架構師不會從事重複勞動或衝突的活動。這同樣需要定義重用和多個架構分區間的服從關係。下表從四個維度對架構活動範圍的限定進行了說明。