2. 程式人生 > >系統架構設計方法論——TOGAF

系統架構設計方法論——TOGAF

阿新 • • 發佈：2019-01-14 
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

https://blog.csdn.net/watermelonbig/article/details/776208471、ADM的架構開發階段ADM方法是由一組按照架構領域的架構開發順序而排列成一個環的多個階段所構成。通過這些開發階段的工作，設計師可以確認是否已經對複雜的業

系統架構設計方法論——Zachman

Zachman框架模型分兩個維度：橫向維度採用6W（what、how、where、who、when、why）進行組織，縱向維度反映了IT架構層次，從上到下（Top-Down），分別為範圍模型、企業模型、系統模型、技術模型、詳細模型、功能模型。 橫向結合6W，Zachman框

系統架構設計方法論——IBM架構解決方案設計

IBM內部有一套自成體系的架構設計方法論，且是和TOGAF所互相承認效力的。相比較而言，IBM的架構設計理論，在實際上的可操作性會更強，也可以說是功利性更強些。當然，也會更容易落地使用。 該理論包括5個架構設計的步驟： 1、理解客戶的業務和需要（Understand Cli

全民養豬系統架構設計開發平臺

全民養豬 全民養豬系統開發，(李小姐177-8870-6412微/電)全民養豬系統源碼搭建，全民養豬系統全網模式開發，全民養豬 app系統軟件開發，全民養豬系統專業開發，全民養豬系統app開發平臺，全民養豬系統設計運作、非平臺客服，玩家勿擾!!! 全民養豬每個帳戶每天可以購買100元到20

淺談秒殺系統架構設計

秒殺http://mp.weixin.qq.com/s?__biz=MjM5NDM4MDIwNw%3D%3D&mid=2448834705&idx=1&sn=25cf3d4f6d6826e564a634901189eb8f&chksm=b28a405185fdc9478b6bd

高性能、高可用、高擴展ERP系統架構設計

sqlserve 學習 業務邏輯層 表設計 應用程序 log cnblogs 便在 tab ERP之痛 曾幾何時，我混跡於電商、珠寶行業4年多，為這兩個行業開發過兩套大型業務系統（ERP）。作為一個ERP系統，系統主要功能模塊無非是訂單管理、商品管理、生產采

SaaS 系統架構設計經驗總結

計費 攔截 好處 abc www. ring 需求 分系統 數據庫 2B SaaS系統最近幾年都很火。很多創業公司都在嘗試創建企業級別的應用 cRM, HR,銷售, Desk SaaS系統。很多SaaS創業公司也拿了大額風投。畢竟SaaS相對傳統軟件的優勢非常明顯。 最近一

分布式、服務化的ERP系統架構設計

你會 實現 strong 感覺 項目 更新失敗 統一 都在 優點 每天學習一點點 編程PDF電子書、視頻教程免費下載：http://www.shitanlife.com/code ERP之痛 曾幾何時，我混跡於電商、珠寶行業4年多，為這兩個行業開發

DKhadoop大數據系統架構設計方案

深度 穩定性 alt 自己 系統架構 穩定 得到 國產 style 大數據作為當下最為熱門的事件之一，其實已經不算是很新鮮的事情了。如果是三五年前在討論大數據，那可能會給人一種很新鮮的感覺。大數據作為當下最為重要的一項戰略資源，已經是越來越得到國家和企業的高度重視，我們從大

0. 視頻監控系統架構設計

無線 oot nfs服務 實現 圖1 In inux ubun 設計 0、視頻監控系統架構設計 0.1、功能指標 (1)搭建共享文件夾 (2)實現Ubuntu的NAT上網和橋接上網 (3)搭建局域網 (4)搭建nfs服務器、tftp服務器 (5)將uboot、kernel、

學生信息管理系統架構設計

系統 text 接受 目的 shadow 情況 sha 機房 數據庫 近期學習架構設計，首先從最基本的學生信息管理系統進行分析。 目的：學生信息管理系統架構設計 思考第一步：識別系統復雜度 ??架構設計的真正目的是為了解決軟件復雜度帶來的問題，故應首先識別本系統復雜度在何

高級系統架構設計官方教材(帶目錄),免費拿走

圖片 地址 高級 name mil family 下載 chm wid 高級系統架構設計官方教材(帶目錄)下載地址：點此下載以下為目錄截圖： 高級系統架構設計官方教材(帶目錄),免費拿走高級系統架構設計官方教材(帶目錄),免費拿走

分布式存儲系統架構設計，應該遵循什麽樣的原則？

不可 功能 故障恢復 硬盤 獨立 實現 存儲系統 技術 本質 分布式存儲系統架構設計，應該遵循什麽樣的原則？ 分布式存儲系統，本質是將數據分散存儲在多臺獨立的x86設備上。傳統的網絡存儲系統通常采用集中的存儲服務器存放數據，存儲服務器很容易成為系統性能的瓶頸，也容易成為可

機票實時搜索系統架構設計

family 之間 width call 作用 化運維 mage margin 1-1 機票實時搜索系統架構設計? 不同的業務場景，不同的特征 ? 結合特征去進?設計和優化 ? 通?!=最優 ? 量體裁?分布式系統的CAP理論 首先把分布式系統中的三個特性進行了

網購秒殺系統架構設計案例分析——《大型網站技術架構》筆記

一、核心思想： 網站秒殺時的併發比正常運營時多的多，所以網站的秒殺業務不能使用正常的網站業務流程，也不能和正常的網站交易業務共用伺服器（否則造成巨大浪費），必須設計部署專門的秒殺系統，進行專門應對   二、技術挑戰： 1.對現有網站業務造成衝擊：秒殺活動只是網站營銷的一個附加活動，具有時間短

雲南農墾交易系統架構設計

                                  雲南農墾交易系統架構設計 前言：   針對雲南農墾

【阿里雲ACE成長記第5期】分散式鏈路追蹤系統架構設計的經驗分享

【引言】本期由阿里雲ACE（阿里雲開發者社群）&成都檸檬雲網絡技術有限公司資深架構師 曾昌強 為大家分享個人成長經歷與個人專業技術之分散式鏈路追蹤系統架構設計。視訊：https://yq.aliyun.com/live/581 Part 1：成長經歷講述一個不知道什麼叫程式設計的門外漢，如何穿越幾千

0. 視訊監控系統架構設計

轉載，侵刪 0、視訊監控系統架構設計 0.1、功能指標 (1)搭建共享資料夾(2)實現Ubuntu的NAT上網和橋接上網(3)搭建區域網(4)搭建nfs伺服器、tftp伺服器(5)將uboot、kernel、rootfs映象檔案下載到開發板中(6)移植MPP，ORTP庫和WiFi庫(

美團即時物流的分散式系統架構設計

本文根據美團資深技術專家宋斌在ArchSummit架構師峰會上的演講整理而成。 背景 美團外賣已經發展了五年，即時物流探索也經歷了3年多的時間，業務從零孵化到初具規模，在整個過程中積累了一些分散式高併發系統的建設經驗。最主要的收穫包括兩點： 即時物流業務對故障和高延遲的容忍度極低，在業

高併發訂單系統架構設計

高併發下單主要包括以下幾個方面： 分庫分表 多應用例項全域性唯一訂單號 資料庫連線 買家查詢訂單 賣家查詢訂單 擴容問題 業務拆分 一、分庫分表 隨著訂單量的增長，資料庫的發展主要經歷以下幾個步驟：  - 1主-1從架構  - 雙主-多從架構，讀寫分離  - 表