TOGAF是在過去二十年間出現(xiàn)的企業(yè)架構(gòu)框架，其目標(biāo)是成為 EA 開發(fā)的標(biāo)準(zhǔn)。TOGAF 是由 Open Group consortium 成員創(chuàng)建的， TOGAF 不是一開始就體現(xiàn)整體的 EA 焦點(diǎn)。最初，TOGAF 只包括技術(shù)架構(gòu)(版本 1 到 7)，然而，最近該框架中加入了業(yè)務(wù)架構(gòu)領(lǐng)域(版本 9，Enterprise Edition)，這快速地將 TOGAF 推向當(dāng)今 EA 框架選擇的第一把交椅。

到添加了業(yè)務(wù)架構(gòu)領(lǐng)域?yàn)橹?，TOGAF 已經(jīng)利用應(yīng)用、數(shù)據(jù)和技術(shù)架構(gòu)領(lǐng)域構(gòu)建了堅(jiān)固的技術(shù)基礎(chǔ)。業(yè)務(wù)架構(gòu)領(lǐng)域的加入進(jìn)一步推動(dòng)了 TOGAF 不斷增長的名望，而其他從技術(shù)架構(gòu)開始的框架在它周圍度過困難的時(shí)期。舉例來說，EUP 不得不利用 RUP 的方法、技術(shù)和標(biāo)記符(UML)，而 Zachman、Spewak，和一些其他的框架有意地使它們的指導(dǎo)在高抽象層上，這負(fù)面地影響了人們對它們的接受，因?yàn)樗鼈儧]有贏得技術(shù)團(tuán)隊(duì)的支持。

TOGAF 架構(gòu)開發(fā)方法為實(shí)現(xiàn)和執(zhí)行組織的企業(yè)架構(gòu)提供完整的指導(dǎo)。該過程包括閉合循環(huán)中的多個(gè)，連續(xù)的階段。

圖 1：TOGAF 架構(gòu)開發(fā)方法(Architecture Development Method，ADM)

初期的目標(biāo)是確定實(shí)現(xiàn)過程涉眾，并且讓它們面對企業(yè)架構(gòu)工作的內(nèi)容。該階段交付基于組織業(yè)務(wù)法則的架構(gòu)指導(dǎo)方針(Architecture Guiding Principles)，并且描述用于監(jiān)控 EA 實(shí)現(xiàn)進(jìn)展的過程和標(biāo)準(zhǔn)。

過程的階段 A 用于明確 EA 遠(yuǎn)景。架構(gòu)遠(yuǎn)景(Architecture Vision )工件利用業(yè)務(wù)推動(dòng)者明確企業(yè)架構(gòu)工作的目的，并且創(chuàng)建基線和目標(biāo)環(huán)境的粗略描述。如果業(yè)務(wù)目標(biāo)不清楚，那么該階段中的一部分工作是來幫助業(yè)務(wù)人員確定其關(guān)鍵的目標(biāo)和相應(yīng)的過程，這些企業(yè)架構(gòu)都必須支持。同樣是該階段中生成的架構(gòu)工作描述(Statement of Architectural Work)，勾勒出 EA 的范圍及約束，并且表示出架構(gòu)工作的計(jì)劃。

階段 B 用于詳述關(guān)于業(yè)務(wù)領(lǐng)域架構(gòu)的工作。架構(gòu)遠(yuǎn)景(Architecture Vision) 中概括的基線和目標(biāo)架構(gòu)在此被詳細(xì)說明，從而使它們作為技術(shù)分析的有用輸入。業(yè)務(wù)過程建模、業(yè)務(wù)目標(biāo)建模和用例建模是用于生成業(yè)務(wù)架構(gòu)的一些技術(shù)，這又包含了所期望狀態(tài)的間隙分析。

階段 C 涉及應(yīng)用和數(shù)據(jù)(信息)架構(gòu)的交付。該階段利用基線和階段 A(Architecture Vision)中開始的目標(biāo)架構(gòu)，以及業(yè)務(wù)間隙分析(業(yè)務(wù)架構(gòu)的一部分)的結(jié)果，在范圍內(nèi)，并根據(jù)架構(gòu)工作描述(Statement of Architectural Work )中所概括的計(jì)劃，為目前和展望的環(huán)境交付應(yīng)用及數(shù)據(jù)架構(gòu)。

階段 D 利用技術(shù)架構(gòu)的交付完成了 TOGAF ADM 循環(huán)的詳細(xì)架構(gòu)工作。如前面的階段里，間隙分析和草案架構(gòu)用作基線，由于初期對架構(gòu)指導(dǎo)原則達(dá)成一致。建模標(biāo)記，例如 UML，在此階段中被積極地使用，從而生成各種觀點(diǎn)。

階段 E 的目的是闡明目標(biāo)架構(gòu)所表現(xiàn)出的機(jī)會(huì)，并概述可能的解決方案。此階段中的工作圍繞著實(shí)現(xiàn)方案的可行性和實(shí)用性。此處生成的工件包括實(shí)現(xiàn)與移植策略(Implementation and Migration Strategy)、高層次實(shí)現(xiàn)計(jì)劃(High-level Implementation Plan)，以及項(xiàng)目列表(Project List)，還有作為實(shí)現(xiàn)項(xiàng)目所使用的藍(lán)圖的已更新的應(yīng)用架構(gòu)。

階段 F 將所提議的實(shí)現(xiàn)項(xiàng)目劃分優(yōu)先級(jí)，并且執(zhí)行移植過程的詳細(xì)計(jì)劃和間隙分析。該工作包括評(píng)估項(xiàng)目之間的依賴性，并且最小化它們對企業(yè)運(yùn)作的整個(gè)影響。在此階段中，更新了項(xiàng)目列表(Project List)，詳述了實(shí)現(xiàn)計(jì)劃(Implementation Plan)，并且將藍(lán)圖傳遞給了實(shí)現(xiàn)團(tuán)隊(duì)。

隨著項(xiàng)目列表的穩(wěn)定，重點(diǎn)就移動(dòng)到為每個(gè)實(shí)現(xiàn)項(xiàng)目明確更具體的目標(biāo)和推薦。在階段 G 中，建立起了治理架構(gòu)(TOGAF)和開發(fā)組織之間的關(guān)系(例如，可能由 RUP 和項(xiàng)目管理知識(shí)體系((Project Management Body of Knowledge，PMBOK) 的組合，或其他項(xiàng)目管理方法所規(guī)定)，并且在正式的架構(gòu)治理下實(shí)現(xiàn)所選的項(xiàng)目。階段的交付內(nèi)容是開發(fā)組織所接受的架構(gòu)契約(Architecture Contracts)。階段 G 最終的輸出是符合架構(gòu)的解決方案。

階段 H 中的重點(diǎn)轉(zhuǎn)移到實(shí)現(xiàn)的解決方案的交付所達(dá)到的架構(gòu)基線的變更管理。該階段可能會(huì)生成為企業(yè)架構(gòu)工作的后繼循環(huán)設(shè)置目標(biāo)的 架構(gòu)工作請求(Request for Architecture Work)。