https://blog.csdn.net/watermelonbig/article/details/77620847

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

ADM方法被迭代式的應用在架構開發的整個過程中、階段之間和每個階段內部。在ADM的全生命周期中，每個階段都需要根據原始業務需求對設計結果進行確認，這也包括業務流程中特有的一些階段。確認工作需要對企業的覆蓋范圍、時間范圍、詳細程度、計劃和里程碑進行重新審議。每個階段都應該考慮到架構資產的重用（以往ADM迭代成果、其它框架、系統模型、行業模型等）。
因此，ADM便形成了3個級別的迭代概念：基于ADM整體的迭代，用一種環形的方式來應用ADM方法，表明了在一個架構開發工作階段完成后會直接進入隨后的下一個階段。多個開發階段間的迭代，例如在完成了技術架構階段的開發工作后又重新回到業務架構開發階段。在一個階段內部的迭代，TOGAF支持基于一個階段內部的多個開發活動，對復雜的架構內容進行迭代開發。2、ADM方法各階段中的活動

ADM階段	ADM階段內的活動
準備階段	為實施成功的企業架構項目做好準備，包括定義組織機構特定的架構框架、架構原則和工具。
需求管理	完成需求的識別、保管和交付，相關聯的ADM階段則按優先級順序對需求進行處理。 TOGAF項目的每個階段，都是建立在業務需求之上并且需要對需求進行確認。
階段A：架構愿景	設置TOGAF項目的范圍、約束和期望； 創建架構愿景； 定義利益相關者； 確認業務上下文環境； 創建架構工作說明書； 取得上層批準。
階段B：業務架構 階段C：信息系統架構（應用&數據） 階段D：技術架構	從業務、信息系統和技術三個層面進行架構開發，在每一個層面分別完成以下活動： 開發基線架構描述；開發目標架構描述；執行差距分析。
階段E：機會和解決方案	進行初步實施規劃，并確認在前面階段中確定的各種構建塊的交付物形式； 確定主要實施項目； 對項目分組并納入過渡架構； 決定途徑（制造/購買/重用、外包、商用、開源）； 評估優先順序； 識別相依性。
階段F：遷移規劃	對階段E確定的項目進行績效分析和風險評估； 制訂一個詳細的實施和遷移計劃。
階段G：實施治理	定義實施項目的架構限制； 提供實施項目的架構監督； 發布實施項目的架構合同； 監測實施項目以確保符合架構要求。
階段H：架構變更管理	提供持續監測和變更管理的流程，以確保架構可以響應企業的需求并且將架構對于業務的價值最大化。

3、ADM方法的詳細說明在以下的表格中從目標、步驟、輸入和輸出幾個方面對ADM環中的每個階段進行了分析和描述。3.1 準備階段

目標	步驟
對進行企業架構活動的組織的背景和環境進行審查；確認利益相關者、他們的需求、優先級和需要承擔的義務；確定并審視企業機構中受到影響的部分，并對其范圍進行界定，定義約束條件和假設條件，這一點在使用聯邦式體系結構環境的大型機構中特別重要；定義組織的“架構足跡”，包括確定執行架構開發工作的人是誰、他們在哪里以及他們的責任是什么；定義用于進行企業架構建設的框架和詳細方法，這里通常是對ADM進行適應性的改變；確定一個治理和支持框架，用來在整個ADM過程中為架構治理提供業務流程和資源方面的支持，此種框架將會確保目標架構的適用性（fitness-for-purpose），并對其在進行過程中的效能進行評測；選擇和落實用于支持架構活動的各種工具和基礎設施；定義架構原則，而這些原則將會成為約束架構工作的一個部分。	界定將要受到影響的企業組織的范圍；確定治理和支持框架；建立企業架構團隊；定義架構原則；選擇架構框架并剪裁定制；落實相關架構工具。
輸入	輸出
TOGAF架構框架資料；其它的架構框架資料；業務原則、業務目標和驅動力；架構治理策略；IT戰略；當前企業架構組織模型；當前企業架構框架；當前企業架構原則；當前企業架構資源庫。	企業架構的組織模型；定制的企業架構框架，包括架構原則；企業架構資源庫的雛形；針對業務目標、原則和驅動力的聲明或引用；治理框架；架構工作要求書。

3.2 階段A——架構愿景在架構愿景階段，將啟動一次架構開發過程的迭代，設置迭代工作的范圍、約束和期望，創建架構愿景、驗證業務上下文，創建架構工作說明書并取得大家的一致認可。愿景表達了我們對架構的期望結果，闡明重要涉眾關注的問題和目標，可幫助團隊關注架構的核心領域。

目標	步驟
獲取管理層對這次特定的ADM循環的相關承諾；制訂一個架構開發周期；確認業務原則、業務目標、驅動力和KPI（key performance indicators）定義基線架構的范圍，明確其所包含的組件以及組件的優先級；確認相關干系人、他們的關注點和目標；定義架構工作所要解決的關鍵業務需求，以及必須應對的各項約束；闡明架構愿景，并定制價值主張，這些價值主張被用來闡述對于那些需求和約束的回應；創建一個符合企業項目管理框架要求的綜合計劃；取得繼續下一個步驟工作的正式批準；理解與其他并行的企業架構開發循環之間的相互影響。	成立架構項目；識別干系人、關注點和業務需求；確定并闡述業務目標、驅動力和約束；評估業務能力；評估業務轉型的準備情況；定義范圍；確認并闡述架構原則，包括業務原則；開發架構愿景；定義目標架構的價值主張和KPI；識別業務轉型風險和應對措施；開發企業架構計劃和架構工作說明書，并確保被批準。
輸入	輸出
架構工作要求書；業務原則、業務目標和驅動力；企業架構的組織模型，包括受影響的組織范圍、成熟度評測、差距及解決辦法、架構團隊所擔當的角色和職責；定制的架構框架，包括定制的架構方法、架構內容、架構原則和配置部署工具；初具內容的架構資源庫（包含初始的框架說明、架構描述和基線描述內容）	得到批準的架構工作說明書：范圍和約束架構工作計劃角色和職責風險與應對措施工作產品效能評測業務案例與KPI指標改善的業務原則、業務目標和驅動力說明；架構原則；能力評估；定制的架構框架（方法、內容、工具）；架構愿景：改善的關鍵高層次干系人的需求基線業務架構0.1版基線數據架構0.1版基線應用架構0.1版基線技術架構0.1版目標業務架構0.1版目標應用架構0.1版目標數據架構0.1版目標技術架構0.1版溝通計劃納入到架構資源庫中的新增內容

3.3 階段B——業務架構在業務架構階段，將開發一個支持架構愿景的業務架構。架構愿景中概括的基線和目標業務架構將在此被細化，從而使它們可以作為技術分析的有用輸入。業務過程建模、業務目標建模和用例建模是用于生成業務架構的一些技術，這又包含了所期望狀態的差距分析。本階段的核心內容包括組織如何滿足業務目標；企業靜態特征（業務目標、業務組織結構、業務角色）；企業動態特征（流程、功能、服務）。

目標	步驟
描述基線業務架構；開發目標業務架構；執行以上二者間的差距分析；選擇和開發相關的架構視角，通過這些視角架構師可以闡述業務架構是如何對各干系人的關注點進行解答的；確定與架構視角相關的工具和技術。	選擇參考模型、視角和工具；開發基線業務架構描述；開發目標業務架構描述；執行差距分析；定義架構路線圖組件；分析對整個架構的影響；涉眾評審；最終確定業務架構；創建架構定義文檔。
輸入	輸出
架構工作要求書；業務原則、業務目標和驅動力；能力評估；溝通計劃； 企業架構的組織模型；得到批準的架構工作說明書；業務架構原則，包括在此之前已經存在了的業務原則；定制的架構框架；企業連續體：架構資源庫；可重用的構建塊公開且可得的參考模型組織特定的參考模型組織標準架構愿景，包括：經過改善的關鍵高層次干系人的需求基線業務架構0.1版基線數據架構0.1版基線應用架構0.1版基線技術架構0.1版目標業務架構0.1版目標應用架構0.1版目標數據架構0.1版目標技術架構0.1版	架構工作說明書（Update）；經過驗證的業務原則、業務目標和驅動力；詳細的業務架構原則；架構定義文檔草稿：基線業務架構1.0版本，如果有的話；目標業務架構1.0版本組織結構業務目標業務功能業務服務業務流程，包括測評和交付物業務角色，包括相關技能需求的發展與改進業務數據模型組織和功能之間的相互關聯主要涉眾關注的業務架構視圖；架構需求說明書草稿：差距分析的結果；技術需求；更新的業務需求；架構路線圖的業務架構組件。

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

目標	步驟
定義業務運行所需的數據源和數據類型。	選擇參考模型、視角和工具；開發基線數據架構1.0版；開發目標數據架構1.0版；執行差距分析；定義組件；分析對整個架構的影響；涉眾評審；確定最終的數據架構；完善架構定義文檔。
輸入	輸出
架構工作要求書；能力評估；溝通計劃； 企業架構的組織模型；定制的架構框架；數據原則（如果有的話）；架構工作說明書；架構資源庫：可重用的構建塊公開可得的參考模型組織特定的參考模型組織標準架構定義文檔草稿，包括：基線業務架構1.0版；目標業務架構1.0版；基線數據架構0.1版；目標數據架構0.1版；基線應用架構（0.1或1.0版）；目標應用架構（0.1或1.0版）；基線技術架構（0.1版）；目標技術架構（0.1版）；架構需求說明書草稿，包括：差距分析結果；適用于此階段的相關技術需求；在架構路線圖中的業務架構組件。	經過改善或更新的架構愿景階段中的各交付物：架構工作說明（Update）；經過驗證的數據原則或新增的數據原則；更新的架構定義文檔草稿：基線數據架構1.0版；目標數據架構1.0版：業務數據模型邏輯數據模型數據管理流程模型數據實體/業務功能矩陣主要涉眾關注的數據架構視圖；更新的架構需求說明書：差距分析結果；數據集成需求；適用于當前階段的相關技術需求；對于下一步將要設計的技術架構的約束；更新的業務需求；更新的應用需求；架構路線圖中的數據架構組件。

3.4.2 應用架構

目標	步驟
定義處理數據并支撐業務運行所需的各種應用系統。	選擇參考模型、視角和工具；開發基線應用架構1.0版；開發目標應用架構1.0版；執行差距分析；定義組件；分析對整個架構的影響；涉眾評審；最終確定應用架構；完善架構定義文檔。
輸入	輸出
架構工作要求書；能力評估；溝通計劃； 企業架構的組織模型；定制的架構框架；應用原則；架構工作說明書；架構資源庫：可重用的構建塊公開且可得的參考模型組織特定的參考模型組織標準架構定義文檔草稿，包括：基線業務架構1.0版；目標業務架構1.0版；基線數據架構（0.1版或1.0版）；目標數據架構（0.1版或1.0版）；基線應用架構0.1版；目標應用架構0.1版；基線技術架構0.1版；目標技術架構0.1版；架構需求說明書草稿，包括：差距分析結果；適用于此階段的相關技術需求；架構路線圖的業務架構組件和數據架構組件。	經過改善和更新的架構愿景階段中的各交付物：架構工作說明（Update）；經過驗證的應用原則或新增的應用原則；更新的架構定義文檔：基線應用架構1.0版目標應用架構1.0版主要涉眾關注的應用架構視圖更新的架構需求說明書：差距分析結果應用交互需求適用于當前階段的相關技術需求；對于將要設計的技術架構的約束；更新的業務需求；更新的數據需求；架構路線圖的應用架構組件。

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

目標	步驟
開發一個目標技術架構，并以此作為后續的實施和遷移計劃的基礎。 將應用架構中定義的各種應用組件映射為相應的技術組件， 這些技術組件代表了各種可以從市場或組織內部獲得的軟件和硬件組件。	選擇參考模型、視角和工具；開發基線技術架構1.0版；開發目標技術架構1.0版；執行差距分析；定義組件；分析對整個架構的影響；涉眾評審；技術架構定稿；完善架構定義文檔。
輸入	輸出
架構工作要求書；能力評估；溝通計劃； 企業架構的組織模型；定制的架構框架；技術原則；架構工作說明書；架構資源庫（4方面）；架構定義文檔草稿，包括：基線業務架構1.0版目標業務架構1.0版基線數據架構1.0版目標數據架構1.0版基線應用架構1.0版目標應用架構1.0版基線技術架構0.1版目標技術架構0.1版架構需求說明書草稿，包括：差距分析結果來自于之前各階段的相關技術需求架構路線圖的業務、數據和應用架構組件。	經過改善和更新的架構愿景階段中的各交付物：架構工作說明（Update）經過驗證的或新增的技術原則；更新的架構定義文檔：基線技術架構1.0版目標技術架構10.版各技術組件以及他們與信息系統之間的關系各技術平臺以及它的結構組成環境和位置期望的處理負荷以及技術組件間的負荷分布物理（網絡）通信硬件及網絡說明主要涉眾關注的技術架構視圖更新的架構需求說明書：差距分析結果從業務架構和信息系統架構階段輸出的需求更新后的技術需求架構路線圖的技術架構組件。

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

目標	步驟
重新審查業務目標和業務能力，合并從階段B到階段D的差距分析，確定主要工作包并分組；重新審查并確認企業承受變化的能力；獲得一系列過渡架構，它們可以通過對各種機會的開發利用，來為各構建塊的實現提供持續的業務價值；產生概要性的實施與遷移策略，并取得共識。	確定關鍵的公司變更屬性；確定項目實施的業務約束；審查并合并從階段B到階段D的差距分析結果；從功能的角度審查IT需求；確定并加強交互需求；改善并驗證依賴關系；確認業務轉型的準備情況和風險；制訂高層次的實施和遷移策略；識別主要的工作包并進行分組；確定過渡架構；創建項目投資組合和項目章程，同時對架構進行更新。
輸入	輸出
產品信息； 架構工作要求書；能力評估；溝通計劃；規劃方法； 企業架構的組織模型；定制的架構框架；架構工作說明書；架構愿景；架構資源庫；架構定義文檔草稿（v1.0版的4個基線架構和4個目標架構）；架構需求說明書草稿：差距分析結果（業務、數據、應用和技術架構）架構需求IT服務管理一體化要求現存業務程序或項目的變更請求。	經過改善和更新的架構愿景、業務架構、信息系統架構和技術架構階段中的各交付物：架構工作說明（Update）；架構愿景（Update）；架構定義文檔草稿：識別出的增量內容交互和共存需求實現和移植策略項目清單和項目章程架構需求說明書草稿（Update）；能力評估：企業架構成熟度概況轉型準備工作報告過渡架構1.0版：確定的關于差距、解決方案和依賴性的評估風險注冊表1.0版本影響分析（項目列表）依賴性分析報告實施因素的評估和推導矩陣(Deduction Matrix)實施和遷移計劃0.1版本（概述）

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

目標	步驟
確保實施和遷移規劃與企業中正在使用的各種管理框架相協調；通過分配業務價值和執行業務成本分析，劃分所有工作包、項目和構建塊的優先級；最終確定架構愿景和架構定義文檔，使其與共同商定的實施方法一致；與相關干系人一起確認在機會和解決方案階段中定義的過渡架構；創建、演進并監控詳細的實施和遷移規劃，提供實現過渡架構所需的各種資源。	確定管理框架與實施和遷移規劃之間的相互作用；為每個項目指定業務價值；估算資源需求、項目時間和交付工具；通過績效評估和風險驗證，確定遷移項目的優先級；確定過渡架構的增量內容并更新架構定義文檔；生成架構實現路線圖（有時間標識）和遷移計劃；創建架構演進循環并記錄收到的經驗教訓。
輸入	輸出
架構工作要求書；能力評估（企業架構成熟度概況和轉型準備報告）；溝通計劃； 企業架構的組織模型；治理模型和框架：企業架構管理框架能力管理框架投資組合管理框架項目管理框架運營管理框架定制的架構框架；架構工作說明；架構愿景；架構資源庫；架構定義文檔草稿：遷移規劃策略影響分析（項目列表和章程）架構需求說明書草稿：差距分析結果（業務、數據、應用和技術架構）架構需求IT服務管理一體化要求現存業務程序和項目的變更請求；經過確認和驗證的架構路線圖；過渡架構1.0版：確定的關于差距、解決方案和依賴性的評估風險注冊表1.0版本影響分析（項目列表）依賴性分析報告實施因素評估和推導矩陣實現和遷移計劃0.1版。	實施和遷移計劃1.0版；定稿的架構定義文檔；定稿的架構需求說明書；定稿的架構路線圖；定稿的過渡架構；可重用的架構構建塊；架構工作要求書（各實施項目，如果有的話）；架構契約（關于各實施項目）；實施治理模型；從經驗教訓中產生的變更請求。

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

目標	步驟
為每個實施項目給予建議；對涵蓋整個實施和部署過程的架構契約進行治理；在解決方案正在實施和部署時，行使恰當的治理職責；確保各實施項目符合于規定的架構；確保按工作計劃成功部署了解決方案的相關程序；確保已經部署的解決方案與目標架構一致；組織各種支持性行動，確保被部署的解決方案長期有效。	通過開發管理工作，確認部署的范圍和優先級；明確用于部署的資源和技能；指導部署解決方案的開發工作；執行企業架構合規審查；實施業務和IT運營；執行實施后審查并結束實施工作。
輸入	輸出
架構工作要求書；能力評估； 企業架構的組織模型：受影響的組織范圍成熟度評測、差距及解決方法架構團隊所擔當的角色和職責架構工作的約束預算需求治理和支持策略定制的架構框架：定制的架構方法定制的架構內容（交付物和制品）配置和部署工具架構工作說明書；架構愿景；架構資源庫：可重用的構建塊公開且可得的參考模型組織特定的參考模型組織標準架構定義文檔；架構需求說明書：架構需求差距分析結果（業務、數據、應用和技術）架構路線圖；過渡架構；實施治理模型；架構契約；架構工作要求書（經過機會與解決方案和遷移規劃階段明確的）；實施和遷移計劃。	架構契約（簽字）；變更請求；影響分析（實施）；建議；可部署的符合架構要求的解決方案：實現的符合架構要求的系統填充了相關資料的架構資源庫架構合規性建議與特許對服務交付需求的建議關于效能指標的建議服務水平協議（SLAs）在實施后經過更新的架構愿景在實施后經過更新的架構定義文檔在實施后經過更新的過渡架構已實施解決方案的業務和IT運營模型

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

目標	步驟
確保基線架構持續符合當前實際情況；評估架構性能并提出改進建議；評估在之前階段中制定的框架和原則的變化；為實施治理階段建立的新的企業架構基線建立一個架構變更管理流程；將架構和運營的業務價值最大化；運用治理框架。	建立價值實現過程；部署監控工具；管理風險；提供架構變更管理分析；開發變更需求以滿足性能目標；管理治理過程；啟動實施變更的流程。
輸入	輸出
在階段E和F中確認的架構工作要求書； 企業架構的組織模型；架構工作說明書；架構愿景；架構資源庫；架構定義文檔；架構需求說明書；架構路線圖；由技術變化產生的變更請求：新技術報告資產管理成本削減措施技術退出報告各標準舉措由業務變化產生的變更請求：業務發展業務異常業務革新業務技術革新戰略變化發展由經驗教訓產生的變更請求；過渡架構；實施治理模型；架構契約（簽字）；合規性的評估；實施和遷移計劃。	架構的各種更新；對架構框架和原則的變更；新的架構工作要求書，用于發起另一次ADM循環；架構工作說明書（Update）；架構契約（Update）；合規性的評估（Update）。

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

目標	步驟
定義一個可以貫穿ADM循環各個階段的管理架構需求的過程；識別和存儲企業需求并與相應的ADM階段進行交互。	通過業務情景或其它模擬技術來識別并記錄需求（ADM各階段）；建立需求基線：確定產生于當前架構開發方法階段的各優先級事項確認干系人認可各個結果優先級事項記錄需求優先級并將其放入需求庫監控需求基線；識別發生變更的需求（ADM各階段）：增、刪、改處理并重新評定優先級識別并解決沖突生成需求影響說明評估變更的需求對現在和之前的ADM階段產生的影響（ADM各階段）；實施架構變更管理階段的需求（ADM架構變更管理階段）；更新需求資源庫；實施當前階段的需求變更（ADM各階段）；評估并修訂先前階段的差距分析（ADM各階段）。
輸入	輸出
各個ADM階段中與需求相關的輸出就是需求管理流程的輸入；最初高層次的需求是作為一部分的架構愿景所產生；每個架構領域都有相應的詳細需求，之后的ADM階段交付物也包含了對新的需求類型的映射（如一致性需求）。	更新的架構需求說明（如有必要）；需求影響的評估，識別出需要回到的ADM階段。最終版本必須包含需求的全部含義（如成本、時間范圍和業務流程）。

3.11 建立架構活動的范圍ADM方法不能夠確定架構活動的范圍，這必須由企業自己確定。需要限定架構活動范圍的原因與以下因素有關：創建架構的團隊所具備的組織權力；需要在架構中實現的目標和干系人的訴求；可利用的人、資金以及其它資源。選定的架構活動范圍理論上應該地支持企業中的架構師高效地完成治理和整合工作。這需要一套一致的“架構分區”，確保架構師不會從事重復勞動或沖突的活動。這同樣需要定義重用和多個架構分區間的服從關系。下表從四個維度對架構活動范圍的限定進行了說明。

維度	考察
企業范圍或焦點	企業最大的業務范圍是什么？其中又有多少是需要架構工作聚焦的？ 許多企業的規模非常大，實際上形成了一個組織單位成員的聯盟，每個成員都有自己獨立的企業權利。 現代企業越來越突破它的傳統界線，包括了一個由供應商、客戶和合作伙伴形成的模糊的傳統行業企業聯盟。
架構領域	一個全面的企業架構描述應該包括全部四個架構領域（業務、數據、應用、技術），但是實際的資源和時間約束經常意味著沒有充分的時間、資金或其它資源去設計一個自頂而下的、包含全部四個架構領域的架構描述。即使在選定的架構活動范圍小于企業整體業務范圍時也是這樣。
詳述垂直范圍或級別	架構工作應該細化到第幾層？怎么樣的架構工作才算充分的？ 架構工作和其它相關工作（系統設計、系統工程以及系統開發）的界線是什么？
時間周期	架構愿景的準確時間周期是什么？它是否意味著要在這個時間期間內用詳細的架構描述填充滿？如果不是，那么需要定義多少個中間級別的目標架構，并且它們的時間周期是多少？

總結

以上是生活随笔為你收集整理的系统架构设计方法论——TOGAF的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。