ADM各階段目標
本文讓我們理解ADM的各階段是如何讓我們的企業架構能更成功。各階段的目標與企業架構開發的每個階段所使用方法的關鍵面向是什麼？
Preliminary Phase(初步階段)
初步階段包含了準備活動與初始活動以便能建立架構能力(Architecture Capability)。主要活動如下:
- 理解企業所處的業務環境
- 得到C-level們的背書
- 就實施範圍達成一致
- 建立架構原則
- 建立治理結構
- TOGAF框架的客製化
目標
確定組織所需的架構能力
- 審查所要進行的企業架構的組織整體脈絡
- 識別並界定受架構能力影響的企業組織元素
- 確認與架構能力有交集的現有框架、方法和流程
- 建立能力成熟度(Capability Maturity)目標
建立架構能力
- 定義和建立企業架構的組織模型
- 定義和建立架構治理的詳細流程和資源
- 選擇並實施能支援架構能力的工具
- 定義架構原則
方法
初步階段是關於從企業(也就是全體員工)這個角度來定義“我們要實作架構的4W1H(where/what/why/who/how)”。 主要有以下幾個方面：
- 定義一個企業
- 確認組織整體脈絡中的關鍵驅動因素和要素
- 定義架構作業的需求
- 定義將為任何架構作業提供資訊的架構原則
- 定義要使用的框架
- 定義管理框架之間的關係
- 評估企業架構的成熟度
定義一個企業
企業架構的主要挑戰之一是企業範圍。 企業的範圍以及它是否是多個組織/單位/部門聯合的，將決定那些將從新的或增強的企業架構中獲得最大利益的利害關係人。 必須在初始階段確定贊助者(也就是哪個高階長官支持或發起的)，以確保由此產生的活動有資源繼續進行(因為高階長官才有辦法給資源)，並得到C-Level們的明確支持。 企業可能包括許多組織，贊助者的職責是確保所有利害關係人都參與了定義、建立和運用架構能力(Architecture Capability)。
確認組織整體脈絡中的關鍵驅動因素和要素
我們(也就是企業架構師)有必要了解架構的整體脈絡。例如下列事項可能都是我們需要考量到的:
- 企業架構的商業模型和預算
- 利害關係人
- 組織的意圖和文化
- 支援企業執行變更和運營的現行流程
- 現行的架構樣貌
- 企業的技能和能力
對組織整體脈絡的查核應該提供關於如何定制架構框架是有價值的需求，特別是正式程度、所需支出以及與其他組織的聯繫。
定義架構作業的需求
業務方向驅動需求和效能指標。 需要說明以下一項或多項需求，以便贊助者可以確認參與定義和建立架構能力的主要決策者和利害關係人：
- 業務需求
- 文化訴求
- 組織意圖
- 戰略意圖
- 預測財務需求
定義將為任何架構作業提供資訊的架構原則
架構原則的定義是企業架構開發的基礎。 架構作業受業務原則和架構原則的影響。 架構原則本身通常也部分基於業務原則。
定義要使用的框架
ADM 是一種通用方法，主要在供各類產業的企業使用。 如果需要，它還可以與各種其他企業架構框架一起使用。 TOGAF 框架必須與組織內使用的其他框架共存並增強其企業營運的能力。可能需要與 TOGAF 框架協調的主要框架有：
- Business Capability Management(業務方向和規劃)，確定需要哪些業務能力
- Portfolio/Project Management Methods — 決定企業如何管理其變革計劃
- Operations Management Methods — 企業如何運作其日常運營
- Solution Development Methods — 正規化的業務系統交付
如下圖所示，這些框架不是離散的，它們與業務能力管理之間有很大的重疊。 因此，我們(企業架構師)必須了解架構對整個企業的影響。
定義管理框架之間的關係
下圖呈現了各種框架和業務規劃活動之間的一組更詳細的依賴關係。 企業架構可用於為所有企業計劃提供結構。
評估企業架構的成熟度
能力成熟度模型 (Capability Maturity Models) 是評估企業行使不同能力的方法。 能力成熟度模型通常識別行使能力所需的特定因素。 一個組織執行特定因素的能力提供了成熟度的衡量標準，可用於一系列連續的步驟來提高能力。 它是一種評估，可以給C-level們一種見解，這種見解是可以提高企業的能力的。
Phase A : Architecture Vision(架構願景)
Phase A 是關於專案建立並啟動架構開發週期的迭代，為迭代設置"範圍、約束和期望"。在每個架構週期開始時都需要從Phase A開始，以建立架構願景、驗證企業的業務整體脈絡與建立得到大老闆批准的架構作業聲明。
目標
- 根據提議的企業架構，制定要交付的能力和業務價值的高階願景
- 取得對架構作業聲明的批准，該聲明定義了開發和部署架構願景中概述的架構工作規劃
方法
Phase A 開始於取得架構組織的架構作業請求。 一個關鍵目標是確保公司管理層(大老闆們的支持)的認可和背書，以及第一線管理層對 ADM 週期演變的支持和承諾。正如該階段的名稱所示，建立架構願景是該階段的一項關鍵活動。 這是一種開發架構願景的業務場景技術。
建立架構願景
架構願景為贊助者提供了一個關鍵工具，用於向企業內的利害關係人和決策者推銷所倡議這個架構能力的效益。 它描述了新的能力將如何滿足組織的業務目的和戰略目標，並在實施時解決利害關係人的憂慮。 架構願景不可或缺的部分是對新興技術(如雲端運算、大數據、區塊鏈等)及其對產業和企業的潛在影響的理解，否則可能會錯失許多商機。
通常，架構願景的關鍵要素（例如企業使命、願景、戰略和目標）已被記錄為更廣泛的業務戰略或企業規劃活動的一部分，這些活動在企業內具有自己的生命週期。 在這種情況下，Phase A的活動涉及驗證和理解記錄在案的業務戰略和目標。 Phase A 還可以將企業戰略和目標與當前架構中隱含的戰略和目標相結合。 業務模型是關鍵的戰略工件，可以展示組織打算如何向其客戶和利害關係人提供價值的這種視角。
大多數的企業可能很少或根本沒有完成業務架構(Business Architecture)作業。 在這種狀況下，架構團隊將需要研究、驗證並取得對該架構要支援的關鍵業務目標和流程。 這可以作為一個獨立的活動來完成，可以在架構開發之前完成，也可以作為 ADM 準備階段(Preliminary Phase)的一部分。 此類活動應檢查和搜索與基本業務架構概念相關的現有素材，例如業務能力、價值流和組織圖。
此外，架構願景應該探索適合企業架構的其他領域； 例如，資訊、安全、數位化等。
業務場景(Business scenarios)是一種適當且有用的技術，用於發現和記錄業務需求，並闡明回應這些需求的架構願景。
架構願景提供了基準和目標架構的初步、高階描述，涵蓋BDAT(Business/Data/Applications/Technology)這些領域。 這些領域的大綱描述是在後續階段製定的。
一旦架構願景被定義並記錄在架構作業聲明(Statement of Architecture Work)中，使用它來建立共識是至關重要的。 沒有這種共識，最終架構不太可能被整個組織接受。 共識由簽署架構作業聲明的贊助組織(某個單位)代表。
業務場景
業務場景技術可用於識別和闡明隱含的業務需求和隱含的架構需求。 這個技術我們會在其他的文章中提到。該技術可以在業務架構的階層式分解的不同詳細等級上迭代使用。
Phase B: Business Architecture(業務架構)
Phase B是關於開發業務架構以支援組織接受的架構願景。 這描述了企業的基本組織體現在：
- 業務流程與人員
- 他(它)們之間的相互關係(流程與人員)
- 管理其設計和演變的原則
並展示組織如何達到它的業務目的。
目標
- 發展出描述企業需要如何運作來實現業務目標的業務架構，並以解決"架構作業聲明和利害關係人"所關注的議題來回應架構願景中定義的戰略驅動因素
- 根據基準業務架構和目標業務架構之間的差距確定所要選擇的架構路線圖組件
方法
業務架構是對能力、端到端(end-to-end)價值交付、資訊和組織結構的整體、多維業務視圖的呈現； 以及這些業務觀點和戰略、產品、政策、舉措和利害關係人之間的關係。 簡單來說，業務架構將業務元素與其他領域的業務目標和元素相關聯。
一般性
了解業務架構是任何其他領域（Data、Applications、Technology）架構工作的先決條件，因此是需要進行的第一項架構活動。
實際上，業務架構通常是必要的，它可以作為向主要利害關係人展示後續架構工作的商業價值的手段，以及這些利害關係人支持和參與後續工作的投資回報。
Phase A : Architecture Vision主要決定 Phase B : Business Architecture的工作範圍。業務戰略所定義"成功的目標、驅動因素和指標"，但不一定需要走到哪裡。 這就是業務架構的作用。
進行基準(baseline)架構描述
如果企業已有現行的架構描述，則應將其作為基本描述的基礎。 一些輸入可能已經在Phase A: Architecture Vision中使用，並且可能足以滿足這個基本描述。 如果不存在此類描述，則必須收集資訊並開發架構描述。
應用業務能力
在Phase A 中開發的業務能力圖提供了獨立於現行的組織結構、業務流程、資訊系統和應用程式以及其餘產品或服務組合的業務視圖(view)。 這些業務能力應該映射回企業架構專案範圍內的組織單位、價值流、資訊系統和戰略計劃。
應用價值流(Value Streams)
價值流提供了最有價值的利害關係人背景，以了解組織為何需要業務能力，而業務能力則提供了組織在特定價值階段取得成功所需的條件。 可以通過熱圖(heat mapping)（按價值流階段）或圍繞價值流的完整定義來發展使用案例（可參考TOGAF Series Guide：Value Streams中的Baseline Example）在專案範圍內分析價值流。 一個專案可能會關注特定的利害關係人、業務價值的一個元素，或者強調某些階段而不是其他階段，以便在以後的階段為解決方案開發更好的需求。 推薦的技術是將價值流中各階段之間的關係對映到業務能力，然後在價值流中為特定的利害關係人實現的業務價值的脈絡背景中對能力進行差距分析。
應用組織圖
組織圖是業務架構的關鍵元素，因為它為整個企業架構作業提供了組織環境。 雖然能力對映揭示了企業在做什麼，價值流對映揭示了它如何為特定的利害關係人提供價值，但組織圖標識了使用這些能力並參與價值流的業務單位或第三方。 將能力圖(capability maps)和價值流結合起來，組織圖提供了對哪些業務單位參與架構工作、誰與何時討論特定需求以及如何衡量各種決策的影響的理解。
應用業務建模
除了上述技術（能力圖、價值流和組織圖）之外，還可以使用各種其他建模技術。 例如，活動模型（也稱為Business Process Models）、Use-Case Models和Class Models。 這三個種類型的模型都可以用UML(Unified Modeling Language) 呈現，並且存在用於產生此類模型的各種工具。
運用架構儲存庫
架構團隊需要考量從架構儲存庫中可以取得哪些相關的業務架構資源，特別是：
- 與組織的產業相關的產業參考模型（在企業連續體方面）
- 企業的業務架構視圖（能力圖、價值流圖、組織圖等）
- 企業的建構區塊（流程組件、業務規則、工作描述等）
- 適用標準
Phase C: Information Systems Architectures(資訊系統架構)
Phase C 是關於記錄架構專案的資訊系統架構，包括資料和應用程式架構的開發。 這描述了主要的資訊類型和處理資訊的應用系統，以及它們之間的關係以及它們與環境的關係。它涉及資料和應用程式架構的某種組合，可以依序或同時開發：
- Data Architecture
- Application Architecture
目標
- 開發目標資訊系統（Data和Application）架構，描述企業的資訊系統架構將如何實現Phase B : Business Architecture和Phase A : Architecture Vision，以解決架構作業聲明和利害關係人關注的議題
- 根據基準(baseline)和目標資訊系統（Data和Application）架構之間的差距確定要選擇的架構路線圖組件
方法
Phase C 涉及資料和應用程式架構的某種組合(順序不限)。 TOGAF 標準將其組合順序留給使用的人(也就是我們 — 企業架構師)來決定。
資料架構(Data Architecture)的主要考量
主要考量包括:
資料管理(Data Management)
當企業進行大規模架構轉型時，理解和解決資料管理問題非常重要。 結構化和全面的資料管理方法可以有效地利用資料以利用其競爭優勢。考量點有:
- 定義將用作企業主要資料的記錄或參考系統的應用程式組件
- 定義所有應用程式組件需要採用的企業範圍標準
- 理解業務功能、流程和服務如何利用資料
- 理解企業資料的建立、存儲、傳輸和報告的方式和位置
- 理解支援應用程式之間的資訊交換需求所需的資料轉換的等級和複雜性
- 定義支援與企業的客戶和供應商的資料整合的需求（例如，在資料遷移期間使用 ETL工具，評估資料質量的數據分析工具等）
資料遷移(Data Migration)
替換現有應用程式時，迫切需要將資料（主要資料、交易資料和參考數據）遷移到新的應用程式。 資料架構應確定資料遷移要求，並提供有關以滿足目標應用程式的要求和約束的格式所呈現資料所需的資料轉換、資料清除和清理等級的指標。 目的是確保在開始使用目標應用程式具有高質量資料。 另一個關鍵考慮因素是確保建立企業範圍內的通用資料定義以支援其轉型。
資料治理(Data Governance)
資料治理的注意事項應確保企業具有實現轉型以下所需的維度：
- 結構 :企業是否有必要的組織結構和標準機構來管理轉換的資料實體面？
- 管理系統:企業是否有必要的管理系統和資料相關程序來管理資料在其整個生命週期的治理面？
- 人員: 企業轉型需要哪些與資料相關技能和角色？ 如果企業缺乏這些資源和技能，企業應該考慮要嘛招募有這些關鍵技能的人，要嘛通過明確的學習計劃培訓現有的人以滿足需求。
運用架構儲存庫
作為Phase C: Information System Architecture階段的一部分，架構團隊應考量組織的架構存儲庫中可用的相關資料架構和應用程式架構資源； 特別是與組織的產業“具垂直性”部門相關的通用模型。 例如：
Data Architecture models:
- ARTS 為零售業定義的資料模型
- Energistics 為石油產業定義的資料模型
Application Architecture models:
- TM 論壇 — www.tmforum.org — 與電信產業相關的應用模型
- The Open Group 為組織的 IT 部門開發了應用程式架構參考模型（IT4IT 參考架構）
- OMG( Object Management Group www.omg.org) — 擁有許多垂直領域任務組，負責開發與特定垂直領域相關的軟體模型，例如醫療保健、交通運輸、金融等。
- high-level業務功能相關的應用模型，例如電商、供應鏈管理等。
Open Group 有一個III-RM(Reference Model for Integrated Information Infrastructure) — — 重點關注的應用程式等級組件和服務所需以便提供一個整合式的資訊基礎設施。
Phase D: Technology Architecture(技術架構)
Phase D 是關於以 IT 系統的基本組織形式記錄架構專案的技術架構：
- 體現在軟硬體和通訊技術上
- 它們之間的關係和環境
- 管理其設計和演變的原則
目標
- 開發目標技術架構，使架構願景、目標業務、資料和應用程式建構區塊能夠通過技術組件和技術服務來交付，以解決架構作業聲明和利害關係人所關注的議題
- 根據基準(baseline)和目標技術架構之間的差距確定要選擇的架構路線圖組件
方法
新興技術 — — 變革的驅動力
新技術的發展是企業尋求新的創新運營方式和改良業務的變革的主要驅動力。 技術架構需要通過運用新技術來擷取企業的轉型機會。
雖然企業架構是由業務關注點主導的，但變革的驅動因素通常存在於不斷發展的技術能力中。 隨著越來越多的數位創新進入市場，利害關係人需要預測並接受技術驅動的變革。 部分數位轉型的興起是由於電信和電腦功能的融合，這開闢了實施基礎設施的新途徑。
TOGAF ADM 的靈活性使技術變革成為驅動力和戰略資源，而不是變革的接受者。 因此，技術架構可以同時驅動業務能力和回應資訊系統需求。
運用架構儲存庫
作為Phase D 的一部分，架構團隊必須考量架構存儲庫中可用的相關技術架構資源。 特別是：
- 現有的IT服務
- 採用的技術參考模型（如果適用的話）
- 與組織的產業“垂直”部門相關的通用技術模型； 例如，在電信產業
- 與通用系統架構(Common Systems Architectures)相關的技術模型； 例如，III-RM
Phase E: Opportunities and Solutions(機遇與解決方案)
Phase E是直接施作的第一階段。 它描述了識別主要實施專案並將它們分組的過程，這些群組作業交付在先前階段(Phase B,C,D)中識別的目標架構。
主要的活動如下:
- 進行初始施作的規劃
- 辨識主要實施的專案
- 將變更作業進行分群
- 決定方法
— 自己做 vs. 用買的 vs. 重複使用的
— 外包
— COTS(Commercial off the Shelf)
— 開源的 - 評估優先事項
- 辨認依賴關係
目標
- 根據Phase B、C 、D 的差距分析和要選擇的架構路線圖組件，產生架構路線圖的第一版完整版
- 確定是否需要增量方式，如果需要，確定在過渡架構的時期中持續提供業務價值
- 定義基於ABB(Architecture Building Blocks)產生的SBB(Solution Building Blocks) 所確定最終目標架構
方法
Phase E 專注於如何交付架構。 它考量了所有架構領域中的目標架構和基準架構之間的差距，並在邏輯上將執行作業分組到企業作業組合中的作業包中。 這是根據利害關係人的需求、企業的業務轉型準備情況、已確定的機會和解決方案以及已確定的施作限制來構建最合適的路線圖的努力。 關鍵是在實現增量業務價值(incremental business value)的同時關注最終目標。
Phase E是建立經過深思熟慮的實施和遷移計劃的第一步，該計劃將整合到 Phase F: Migration Plan的企業作業組合中。
從開發目標架構到交付目標架構的過程中有四個關鍵概念：
- 架構路線圖
- 作業包
- 過渡架構
- 實行與遷移計畫
架構路線圖在時間軸中列出了實現目標架構的各個作業包。 每個作業包都標識了實現目標架構所需的一組邏輯異動。 過渡架構描述了處於現行架構和目標架構之間的架構重要狀態。 過渡架構提供組織可以涵蓋的臨時目標架構。 實施和遷移計劃提供了將實現目標架構的專案時間表。
Phase F: Migration Planning(遷移規劃)
Phase F就是詳細的實際遷移計畫，也就是如何從現行架構轉移到目標架構。主要的活動如下:
- 對於確定的作業包和專案，執行成本效益分析和風險評估
- 完成詳細的實施和遷移計劃
目標
- 完成架構路線圖和配套的實施和遷移計劃
- 確保實施和遷移計劃與企業的整體變更組合中管理和實施變更的方法相互協調
- 確保主要利害關係人理解作業包和過渡架構的業務價值和成本
方法
Phase F: Migration Palnning的重點是與作業組合經理和專案經理(portfolio and project managers)合作建立實施和遷移計劃。 Phase E 提供了一個不完整的架構路線圖和實施和遷移計劃，用於解決架構作業聲明。 在 Phase F，該路線圖和實施和遷移計劃與企業的其他變革活動相結合。 活動包括評估各種遷移專案的依賴關係、成本和效益。 Phase E的架構路線圖以及實施和遷移計劃將構成詳細的實施和遷移計劃的基礎，其中將包括作業組合和專案等級的資訊。 然後完成架構開發週期，並記錄所吸取的經驗教訓，以實現持續的流程改進。
Phase G: Implementation Governance(實施治理)
Phase G 定義"架構"如何約束我們所要實施的專案，在構建過程中對其進行監控，並產生已被簽署的架構合約。主要活動有:
- 為實施作業提供架構監督
- 定義實施專案的架構約束
- 治理和管理架構合約
- 監控實施作業的一致性
目標
- 通過實施專案確保符合目標架構
- 為解決方案和任何實施作業中的架構變更請求執行架構治理功能
方法
在Phase G，匯集了管理各種實施專案的所有資訊。 實際開發中的各項作業在Phase G中是並行的。方法如下:
- 建立一個實施計劃，以實現過渡架構的交付
- 採用反映架構路線圖中的業務優先等級的分階段部署計劃
- 遵循組織內IT 和架構治理標準
- 使用組織已建立的portfolio/program管理方法
- 定義運作框架以確保已部署的解決方案的有效時期
Phase G 的一個關鍵是確保遵守已定義的架構，不僅是已完成的專案，還有其他正在進行的專案。
Phase H: Architecture Change Management(架構變更管理)
Phase H 確保架構變更是在一種受控的管理方式。主要活動有:
- 提供持續監控和變更管理流程
- 確保以連貫和架構化的方式管理對架構變更
- 提供具靈活性的快速演化以回應技術或業務環境的變化
- 監控業務和容量管理
目標
- 確保架構生命週期有被維護
- 確保架構治理框架得到執行
- 確保企業的架構能力滿足當前需求
方法
架構變更管理流程的目標是確保架構實現其最初的目標業務價值。 監控業務的成長和下降是這一階段的一個關鍵。價值和變更管理流程一旦建立，將決定：
- 在部署企業架構後允許更改或更改其中一部分，以及當發生這種情況時需要的流程
- 啟動架構開發週期以開發新架構
變革的驅動力
可以通過以下三種方式變更已經整合完成的基準基礎架構：
- 戰略性的、自上而下(top-down)的變革，以增強或建立企業新的能力(資本性的)
- 自下而上(Bottom-up)的變革以糾正或增強運營管理基礎設施能力(運營和維護性的)
- 在運營管理方面，之前已交付的專案學習經驗，但仍在由正在進行的專案交付
企業架構變更管理流程
企業架構變更管理流程需要確定如何管理變更、應用哪些技術以及使用哪些方法。TOGAF 標準根據將所需的架構變更分為以下三種方法：
- 架構簡化變更：簡化變更通常可以通過變更管理技術來處理
- 架構增量變更：增量變更也許能夠通過變更管理技術處理，或者可能需要部分的架構修改，具體取決於變更的性質
- 架構重新變更：意思是整個企業架構需要再重跑一次架構開發週期
以上三種的變更會發生的狀況通常是:
- 對架構的簡化變更通常是由減少投資的需求驅動的
- 增量變更是由從現有投資中獲得額外價值的需求驅動的
- 重新架構的變化是由增加投資以創造新的開發價值的要求驅動的
要確定變更是簡化的、增量的還是重新架構的，需要進行以下活動：
- 列出所有可能影響架構的事件
- 架構任務的資源分配和管理
- 負責架構資源的流程或角色必須評估應該做什麼
- 衝擊評估
維護與架構重新設計的指導方針
建議的指導方針如下:
- 如果變更影響兩個或以上的利害關係人，則可能需要重新設計架構並重跑 ADM
- 如果變更只影響一個利害關係人，那麼它更有可能成為變更管理的候選人
- 如果可以在豁免下允許變更，那麼它更有可能成為變更管理的候選人
例如:
- 如果對業務戰略的影響很大，那麼可能需要重新構建整個企業架構 — — 因此需要一種重新架構的方法
- 如果出現新技術或標準，則可能需要更新技術架構，而不是整個企業架構 — — 因此是增量變更
- 如果變化是在基礎設施層面 — — 例如，五個系統減少或改為一個系統 — — 這可能不會改變物理層以上的架構，但會改變技術架構的現行描述； 這將是通過變更管理技術處理的簡化變更
特別是，如果出現以下情況，可能需要刷新整個ADM循環（部分架構或完全重新架構）：
- 基礎架構需要重新與業務戰略保持一致
- 需要對用於架構部署的組件和指南進行實質性修改
- 產品架構中使用的重要標準發生變化，對最終用戶產生重大影響； 例如，法規法令的變動
如果需要刷新ADM周期，則必須發布新的架構工作請求（移動到另一個週期）
Requirements Management(需求管理)
管理架構需求的流程適用於 ADM 週期的所有階段。 需求管理流程是一個動態過程，它處理企業需求的識別、存儲它們，然後將它們輸入和輸出相關的 ADM 階段。正如本文一開始的 ADM 循環圖中的中心位置所示，此過程是驅動 ADM 流程的核心。
目標
- 確保需求管理流程在所有相關的 ADM 階段持續運作
- 管理在 ADM 週期或階段的任何執行過程中確定的架構需求
- 確保在執行階段時相關架構需求可供每個階段使用
方法
ADM 不斷地由需求管理流程驅動。 處理需求變化的能力是至關重要的，因為架構的本質是處理"不確定性和變動"，是彌合利害關係人的期望與可以作為實際解決方案交付成果之間的鴻溝。但需求管理流程本身不處理、解決或優先考慮任何需求； 這是在 ADM 的相關階段完成的。
我們應該使用架構需求存儲庫來記錄和管理所有架構需求。 TOGAF 標準不強制或推薦任何特定的需求管理流程或工具； 它只是說明有效的需求管理流程應該實現什麼，可以將其視為“需求中的需求”。
TOGAF 標準建議了該領域的一些資源可以參考：
業務場景
業務場景是發現和記錄業務需求以及描述影響這些需求的Phase A : Architecture Vision的適當且有用的技術。 TOGAF Series Guide: Business Scenarios中詳細描述了業務場景。
其他需求工具
有大量且越來越多的COTS(Commercial Off-The-Shelf)工具可用於支援需求管理。 Volere 網站有一個有用的需求工具清單。
