ADM的可交付成果

本文將會講述在ADM週期中的主要交付成果與它們的意圖。我們會提到架構可交付成果在整個 ADM 週期中的作用是什麼？主要交付成果的目的是什麼？

架構可交付成果的作用

TOGAF 標準定義了一組建議的可交付成果，這些交付成果將在 TOGAF ADM 週期中使用和產出。 提供的可交付成果主要在提供架構可交付成果的典型基礎(baseline)，以便更好地定義 ADM 中所需的活動，並作為不同組織內不同客製的起點。

TOGAF 標準確定可交付成果，這些成果作為執行 ADM 週期的輸出而產出，並可能在 ADM 的其他階段作為輸入。 其他可交付成果可能在別處產生並由 ADM 使用。

由於可交付成果通常是架構專案的合約或作業產出，因此這些可交付成果很可能會受到任何總體專案或企業流程管理（例如 CMMI、PRINCE2、PMBOK 或 MSP）的約束或修改。

主要交付成果的目的

本節描述了在 TOGAF ADM 週期中輸出和輸入的可交付成果的目的。

ABB(Architecture Building Blocks)

ABB 是來自企業架構儲存庫的架構文件和模型。

架構合約

架構合約是開發合作夥伴(可能是外部廠商或內部其他團隊)和贊助商之間就架構的可交付成果、質量和適用性達成的協議。 它們在 Phase G: Implementation Governance產生。 這些協議的成功實施將通過有效的架構治理來實現。

通過對合約管理進行受監管的方法，以下內容將會得到保障：

• 一個持續監控系統，用於檢查組織內所有與架構相關的活動的完整性、變更、決策制定和審核
• 遵守現有或正在開發的架構的原則、標準和需求
• 識別架構開發和實作各個方面的風險，包括針對公認標準、政策、技術和產品的內部開發以及架構的運營方面，以便組織的運作環境是具有彈性的
• 一組流程和實踐，確保所有架構工件的開發和使用方面的問責制、責任和紀律
• 理解負責合約的管理單位、他們的權限等級以及該單位治理下的架構範圍

架構定義文件

架構定義文件是專案期間建立的"核心架構工件和重要相關資訊"的可交付事項。 架構定義文件涵蓋所有架構領域（B.D.A.T），還檢查架構的所有相關狀態（baseline、transition和target）。

它首先在Phase A : Architecture Vision中建立，其中放入了為支持架構願景而建立的工件。 它在 Phase B: Business Architecture使用與業務架構相關的素材進行更新，隨後在 Phase C: Information system Architecture使用資訊系統架構素材進行更新，然後在 Phase D: Technology Architecture使用技術架構素材進行更新。實施目標架構的變更範圍需要增量方式 ，架構定義文件將被更新來包含Phase E: Opportunities & Solutions 中的一個或多個過渡架構。

過渡架構顯示企業處於現行(baseline)架構和目標架構之間的架構重要狀態。 過渡架構用於描述有效實現目標架構所必需的過渡目標架構。

架構定義文件跟架構需求規範是相輔相成的，具有互補的目標：架構定義文件提供解決方案的定性視圖(qualitative view)，主要在傳達企業架構師的意圖。 架構需求規範提供了解決方案的定量視圖(quantitative view)，說明了在架構實施期間必須滿足的可衡量標準。

架構原則

這一份文件是ADM的準備階段(Preliminary Phase)的初始產出。 原則是一般規則和指南，所謂原則就是它是持久的並且很少修改，它為組織著手完成其使命的方式提供資訊和支持。

反過來，原則可能只是一組結構化思想中的一個元素，這些思想共同定義和指導組織，從價值觀到行動再到結果。

架構文件庫

架構文件庫是企業內所有與架構相關專案的存放區域。 文件庫允許專案管理的可交付成果、定位可重複使用資產以及將產出發布給利害關係人。

架構需求規範

架構需求規範提供了一組定量(quantitative)陳述，概述了實施專案必須做什麼才能符合架構。 架構需求規範通常會形成已實行的合約或更詳細的架構定義合約的主要組成部分。

架構路線圖

架構路線圖列出了將實現目標架構的各個作業包(work packages)，並將它們排列在時間軸上以顯示從現行架構到目標架構的進展。 架構路線圖標示了各個作業包在每個階段的業務價值。 有效實現目標架構所必需的過渡架構被確定為中間步驟。 架構路線圖在整個Phase E & F中逐步發展，並由PhaseB到D中發展路線圖組件提供資訊。

架構願景

架構願景是在Phase A中建立的，它提供了成功部署目標架構後企業將發生的變化的高階總結。 願景的目的是在一開始就架構的預期結果達成一致，以便企業架構師隨後可以專注於驗證可行性所需的細節。 提供架構願景還通過提供完整架構定義的總結版本來支援我們與利害關係人的溝通。

業務原則、業務目標與業務驅動

業務原則、業務目標和業務驅動因素通過描述企業運用的所需和作業方式為架構工作提供整體脈絡。 這些通常在架構作業之前在企業的其他地方定義。 企業架構這門專業考慮範圍之外的許多因素可能對架構的開發方式產生重大影響。

能力評估(Capability Assessment)

在著手進行詳細的架構定義之前，了解企業的現行和目標能力是有價值的。 該評估首先在 Phase A中進行，並在 Phase E更新。

這種能力評估可以在幾個層面上進行檢查：

• 企業整體能力水平如何？ 企業希望在哪些方面增加或優化能力？ 支持企業預期發展的架構重點領域(BDAT)是什麼？
• 企業內 IT 功能的能力或成熟度水平如何？ 就設計治理、運營治理、技能和組織結構而言，執行架構專案可能會產生什麼影響？ 架構專案適合 IT 組織的文化和能力的適當風格、正式程度和詳細程度是多少？
• 企業內部架構功能的能力和成熟度如何？ 目前存在哪些架構資產？ 它們是否得到維護且準確？ 需要考慮哪些標準和參考模型？ 在架構專案期間是否有機會建立可重複使用的資產？
• 如果存在能力差距，企業準備在多大程度上進行轉型以實現目標能力？ 除了基本能力差距之外，還有哪些轉型風險、文化障礙和其他需要解決的問題？

變更請求

架構變更請求在Phase H:Architecture Change Mangement中會被考量到。
在架構的施行的過程中，隨著越來越多的事實被得知，原始的架構定義和需求可能不適合或不足以完成解決方案的實施。 在這些情況下，施行的專案有必要變動原來的架構方式或請求範圍延伸。 此外，外部因素 — — 例如市場因素、業務戰略的變化和新技術機會 — — 可能會帶來延伸和完善架構的機會。在這些情況下，可以提交變更請求以請求豁免或啟動下一個架構工作週期。

溝通計畫

企業架構包含大量複雜且相互依賴的資訊。 在正確的時間將目標資訊有效地傳達給正確的利害關係人是企業架構的關鍵成功因素 (CSF —Critical Success Factor )。

合規評估

一旦定義了架構，就需要進行施作來管理該架構，以確保適當地實現原來的架構願景，並將任何施作學習反饋到架構過程中。 Phase G :Implementation Governance中施作中專案的定期合規審查提供了一種審查專案進度並確保設計和施作按照戰略和架構目標進行的機制。

施作與遷移計畫

施作和遷移計劃提供了目標架構實行專案的時間表。 施作和遷移計劃包括可執行項目，這些項目被分組為受管理的組合和項目群。 確定變更方式的施作和遷移策略是施作和遷移計劃的關鍵要素。而概要式的施作和遷移計劃在 Phase E: Opportunities & Solutions，然後在Phase F: Migration Plan完成。

實施治理模式

一旦定義了架構，就需要計劃如何通過施作來治理實現該架構的過渡架構。 在已建立架構功能的組織內，可能已經存在治理框架，但可能需要根據專案逐個定義具體流程、組織、角色、職責和措施。

作為Phase F: Migration Plan的產出的實施治理模型可確保過渡到實施的專案順利進入適當的架構治理。

企業架構的組織模型

準備階段(Preliminary Phase)的一個重要交付成果是企業架構的組織模型。
為了成功使用架構框架，它必須得到企業內正確的單位、角色和職責的支援。 特別重要的是不同企業架構實踐者之間的邊界定義以及跨越這些邊界的治理關係。

請求架構作業

這是從發起單位送到架構單位以開始架構開發週期開始的文件。 架構作業請求可以建立為準備階段的產出、已批准的架構變更請求的結果或源自遷移計劃的架構作業的參考條款。一般來說，這個文件中的所有資訊都應該都是高階的。

需求影響評估

在整個 ADM 中，收集與架構相關的新資訊。 隨著這些資訊的收集，可能會發現新的事實，使現行架構是無效的。 需求影響評估會評估當前的架構需求和規範，以確定應該進行的變更以及這些變更的影響。

架構作業的論述

架構作業論述是作為Phase A : Architecture Vision的可交付成果建立的，它定義了將用於完成架構開發週期的範圍和方法。 架構作業論述通常是衡量架構專案成功執行的文件，並且可以構成架構服務的提供者和使用者之間合約協議的基礎。

訂製的架構框架

選擇和訂製框架是架構專案的實際起點。TOGAF 標準為可用於各種組織的架構提供了一個產業標準框架。 然而，在架構專案中有效使用 TOGAF 框架之前，需要在兩個層級上進行裁切(也就是客製)。

首先，需要客製 TOGAF 模型以整合到企業中。 這種裁切將包括與管理框架的整合、術語的定義、呈現風格的發展、架構工具的選擇、配置和部署等。所採用的任何框架的形式和細節也應與企業的其他背景因素保持一致，例如 作為文化、利害關係人、企業架構的商業模型，以及架構能力的現有水平。

一旦為企業量身訂製了框架，就需要進一步裁切以使框架適合特定的架構專案。 此層級的裁切將選擇適當的可交付成果和工件以滿足專案和利害關係人的需求。