運用TOGAF ADM 的架構願景

先有願景，才能邁向卓越。

運用"雲端服務"加速企業的數位轉型願景

15 min readFeb 15, 2023

架構願景階段的目標

根據提議的企業架構，制定要交付的能力和業務價值的高階願景(high-level aspirational vision)
取得架構作業聲明(Statement of Architecture Work)的批准

這個階段我們也會同時理解在架構儲存庫(Architecture Repository)的典型內容有甚麼。

架構願景階段的輸入

準備階段的產出 — 如架構作業要求、業務原則、業務目標、業務驅動
在架構儲存庫的既有文件 —企業架構的組織模型(Organizational Model)、客製的企業架構(包含架構原則)、既有的架構文件(可能是框架與架構描述等)。

架構願景的步驟

架構願景讓我們理解如何確認利害關係人，他們的關注點與其業務需求。為什麼要使用業務轉型就緒評估(Business Transformation Readiness Assessment)，還有在這個階段採取的風險評估方法。

步驟1: 建立架構專案

與企業中的其他專案一樣進行規劃和管理(可能需要與PMO合作，如果有的話)
確保這個專案經過大老闆與業務單位的認可、背書和支持
架構專案如何遵循現有的管理框架？

步驟2: 確認利害關係人，他們的關注點與業務需求

利害關係人的參與是成功的關鍵之一
確定候選架構願景組件(Architecture Vision Components)
確定利害關係人的關注點、問題和文化因素
產出利害關係人地圖(Stakeholder Map)

利害關係人地圖是用來支援在Phase A的多個產出。關於這個架構專案的利害關係人的關注點(concerns)與觀點(viewpoints)在此階段應該要被記錄在案。參與架構專案的利害關係人及其立場應該被用來製作溝通計劃的起始點。架構專案中的主要角色和職責應包含在架構作業聲明(Statement of Architecture Work)中。

利害關係人管理(Stakeholder Management)是一門重要的學科，一個成功的企業架構師可以使用它來贏得利害關係人的支持。這門學科在Phase A是被用來辨認誰是主要參與者，並且在之後的每個階段都要更新。更多的利害關係人管理內容可參閱Open Group-Stakeholder Management。

TOGAF標準將利害關係人分為五大類22種型態(如下圖)，每一個架構專案都可能會比TOGAF提供的參考或多或少，一切取決於專案的需求。

哪我們如何每個利害關係人不同立場分析呢?下面的範例表格可以做為參考。

根據分析完成的利害關係人立場表，我們就可以確認在這個架構專案中，那些是支持的，那些是反對或批評的。

我們要計算出各個利害關係人的權力、影響力和利益，以便將企業架構參與重點放在主要個別參與者身上。這些可以對應到權力(Power)與利益(Interest)矩陣上(如下參考圖)，這也會呈現了與利害關係人互動所採用的策略。

確定架構要產生的可交付成果(catalog/matrices/diagrams)，並與個別利害關係人群體一起驗證所交付的架構模型的有效性。這使架構內容能夠傳達給所有利害關係人並被他們所理解，並使他們能夠驗證企業架構計劃將解決他們的問題。而這個架構模型的有效性就需要產生架構視圖(Architecture View)。

架構視圖是對利害關係人有意義的架構呈現，使它更容易理解。它們使利害關係人能夠驗證產生的架構是否會解決他們的問題。通過參考現有的架構視圖庫(Viewpoints Library)並從中選擇，通常可以為特定架構建立所需的視圖。這種方法帶來一些效益，例如企業架構師的工作量會減少，因為已經定義了架構觀點，提高了利害關係人的可理解性，因為觀點對利害關係人是熟悉的，並且對架構視圖的有效性更具信心，因為它們以前被使用過 .

最後根據立場分析與權力/利益矩陣表，會產生出利害關係人地圖(如下範例表)。

步驟3: 確認並詳細說明業務目標、業務驅動因素和約束條件

確保業務目的與策略驅動因素是正確跟最新的
定義專案的制約因素(各項資源的限制: 人力/時間/預算等)

此步驟我們必須確定組織的業務目標和策略驅動因素。如果這些已在組織其他地方有定義了，請確保現有定義是最新的，並澄清任何含糊不清的地方。不然，我們就要回到架構作業聲明的發起者那裡，重新定義這些項目，並獲得高階管理層的認可。

步驟4: 評估能力

企業開發和使用架構的能力
企業本身的現行和目標能力的水準

此步驟我們要認知到企業的能力到哪裡?這是指企業開發和使用架構的能力，也是企業的現行和目標能力水準。此活動的結果會記錄在能力評估(Capability Assessment)中。架構能力中確定的任何差距都需要在架構願景和準備階段之間進行迭代，以確保架構能力能夠解決架構專案所覆蓋的範圍。

基於能力的規劃(Capability-Based Planning)確保企業策略計劃自上而下的(top-down)方法推動企業發展。它注重的是交付業務成果與業務價值而不是技術交付成果；例如，企業架構專案將交付電商服務，而不是交付Web-based的業務解決方案。所以是IT配合組織的業務，而不是組織業務配合IT。在Phase A階段，它是被企業戰略方向所驅動的。在接下來的Phase B/C/D就著重在個別能力。到了Phase E，作業包(Work Packages)和專案則會被確定能夠提供所需的能力。

TOGAF標準建議我們將能力分解成能力增量(Capability increments)，因為新能力可能需要很長時間才能發展完成，並且可能涉及許多交付大量"能力增量"的專案。這具有潛在的優勢，是離散、可見和可量化的結果形式為利害關係人提供真正的商業價值，這些結果可以為過渡架構(Transition Architecture)提供聚焦。

Phase E驅動過渡架構的能力增量導致專案增量(Project Increment)的識別，其實際交付通過 Phase E完成的實施和遷移計劃(Implementation and Migration Plan)進行協調。

步驟5: 評估業務轉型的就緒情況

業務轉型就緒評估(Business Transformation Readiness Assessment)
結合能力評估(Capability assessment)
專案成功的風險

業務轉型就緒評估可用於"評估和量化"組織對變革的準備情況。該評估基於一系列就緒因素評分的確認。

理解組織準備好接受變革、確定問題然後處理它們是成功進行架構轉換的關鍵部分。 TOGAF標準建議此評估由業務單位和 IT 規劃人員共同完成。為此，必須使用成熟度模型確定和呈現將影響組織的就緒因素。應對每個就緒因素的風險進行評估，並採取改進措施來減緩已識別的風險。 TOGAF 標準建議建立一個總表(如下範例)以整合因素並提供管理層概覽。然後將調查結果記錄到能力評估中，然後將其納入Phase F: 實施和遷移計劃。

以下是從現行架構遷移到目標架構時可能影響業務轉型的就緒因素範例清單。這些是從加拿大的BTEP(Government Business Transformation Enablement Program) 中擷取的。

Vision
Desire, Willingness, and Resolve
Need
Business Case Exists
Funding
Sponsorship and Leadership
Governance
Accountability
Workable Approach and Execution Model
IT Capability to Execute
Enterprise Capability to Execute
Enterprise Ability to Implement and Operate

步驟6: 定義範圍

架構的範圍要到甚麼程度(Breath of coverage)
架構細節要到甚麼程度才足夠
架構分區的要求
涵蓋的架構領域(B.D.A.T)
架構要看到未來多遠
如何利用現有架構資產(ABB and SBB)

步驟7: 確認架構原則

回頭參考之前建立的架構原則
我們有在跟隨這些原則嗎？原則夠清楚嗎？

步驟8: 發展架構願景

這是我們總結企業架構未來計劃的地方，並且探討如何將一切(基於利害關係人的關注點、業務能力要求、範圍、約束和原則)組合在一起。然後向利害關係人推銷這一願景如何改善他們的業務，不過這一階段還處於高階概念，就是有點非正式。這個階段不必知道所有的答案。使用的技術是業務場景(Business scenarios)，一個好的業務場景具備S.M.A.R.T(Specific/Measurable/Actionable/Realistic/Time-bound)特徵。這個步驟將從業務、資訊系統和技術角度產生現行環境和目標環境的第一個非常高階的定義。

步驟9: 定義價值主張與KPIs

為所需的架構和變更發展商業案例
為每個利害關係人群體制定價值主張
評估和定義採購需求
與相關發起人和利害關係人一起審查並同意價值主張
定義要放入到企業架構中以滿足業務需求的績效指標和措施
評估業務風險

我們製作一個商業案例。這個案例中要說明組織花費了多少代價，並且獲得了多少價值回報。這個商業案例顧及每個利害關係人群體都並且從他們的關店來看這個架構願景的價值。接下來我們要衡量這個架構怎樣才算成功?並評估業務風險。

步驟10: 辨識風險並有相對緩解風險的作業

在此步驟中，確定與架構願景相關的風險並評估風險的初始級別（例如，catastrophic/critical/marginal/negligible）以及與之相關的潛在頻率。為每個風險分配緩解策略。可參考如下範例表格

而組織應考慮兩個等級的風險：

初始風險(Initial Level of Risk):在確定和實施緩解措施之前進行風險分類
剩餘風險(Residual Level of Risk):實施緩解措施後的風險分類（如果有的話）

風險緩解作業應包含在架構作業聲明(Statement of Architecture Work)中。

TOGAF標準在第 Part III“風險管理”中提供了風險管理技術指南。這包括風險分類方案和風險評估樣本工作表。 TOGAF 標準裡的風險管理流程是：

Risk classification
Risk identification
Initial risk assessment
Risk mitigation and residual risk assessment
Risk monitor(在Phase G執行)，這可能會導致在Phase H中處理與風險管理相關的變更請求。

更多的資訊可參閱TOGAF的Risk Management一文。

步驟11: 制定架構作業聲明，取得批准

定義願景，製定業務案例(Business Case)
確定需要更改的作業產品
確定該變更對其他作業產品的影響
估算資源，制定路線圖，排程
效能指標
溝通計劃
簽署

架構願景的產出

經過批准的架構作業聲明(專案中的主要里程碑)
架構願景(包含問題描述，目標，總結意見，主要利害關係人的高階需求)
架構文件的初稿(BDAT架構文件的 0.1版本，現行與目標架構)
溝通計畫(怎麼與利害關係人溝通，以甚麼頻率，要甚麼程度的細節，他們是否參與流程)
優化過的業務原則、業務目的與業務驅動因素
優化過的架構原則
能力評估(Capability Assessment)
量身訂做的架構框架

架構作業聲明(Statement of Architecture Work)

架構作業聲明是作為 Phase A的可交付成果，實際上是架構團隊與架構專案發起單位之間的合約。這個文件是回應架構作業要求(Request for Architecture Work)。它應該描述解決作業請求的總體計劃，並提出如何通過架構流程解決問題(已確認的)的解決方案。 TOAGF對這個架構作業聲明的建議內容如下：

標題
架構專案要求與其背景
架構專案的描述與範圍
架構願景的概述
具體範圍變更程序
角色、職責和可交付成果
驗收標準和程序
架構專案計畫和進度表
批准

能力評估(Capability Assessment)

在著手進行詳細的架構定義(Architecture Definition)之前，了解企業的現行與目標能力水準是必須的。這種能力評估首先在Phase A進行，並在Phase E進行更新。它可以在幾個層面上進行評估：

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

以下為典型進行幾種能力評估並產生其結果:

業務能力評估，包含:
 — 業務能力
 — 每項能力的績效水準的現行狀態評估
 — 對每項能力的績效水準的未來狀態期望
 — 對每項能力如何實現的現行狀態評估
 — 對如何實現每項能力的未來狀態期望
 — 評估成功部署目標架構對業務單位可能產生的影響
IT能力評估，包含:
— 現行變革過程和目標變革過程的成熟度水準
— 現行維運流程和目標維運流程的成熟度水準
— 現行能力和能力評估
— 評估成功部署目標架構對 IT 單位可能產生的影響
架構成熟度評估，包含:
— 架構治理流程、組織、角色和職責
— 架構技能評估
— 架構儲存庫(Architecture Repository)中landscape definition/standards definition/reference model definition的廣度(Breath)、深度(depth)和質量(quality)
—交付成果再利用的評估
業務轉型就緒評估，包含:
— 就緒因素
— 每個就緒因素的願景
— 當前和目標的就緒等級
— 就緒風險

架構願景

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

業務場景是在這一階段一定會用到的技術，可用作開發架構願景文件流程的一部分。TOGAF建議內容如下：

問題描述，包含利害關係人及其關注點，以及要解決的問題/場景清單
架構作業聲明的目標
架構作業請求和高階的B.D.A.T架構所需的概要視圖
對照需求
參考架構定義文件的草稿

溝通計畫

企業架構包含大量複雜且互相都是有關係的資訊。 在正確的時間將目標資訊有效地傳達給正確的利害關係人是企業架構的關鍵成功因素 。在這一階段製定溝通計劃可以讓我們與利害關係人的溝通是經過規劃與有一個正規的流程。

通常，溝通計劃包括確定：

按溝通要求來分組利害關係人
溝通要求、與架構願景相關的關鍵資訊、溝通風險和關鍵成功因素
會用在與利害關係人溝通並允許存取架構資訊的方法，例如會議、定期公告、文件庫等。
溝通時間表，顯示將在何時何地與哪些利害關係人進行哪些溝通

總結

Phase A: Architecture Vision的重點是啟動 ADM 的這個特定週期。這個階段從架構作業請求(Request for Architecture Work)開始，最後經過架構委員會簽署架構工作聲明(Statement of Architecture Work)來結束。在這階段要有來自大老闆的支持。還有定義此次ADM週期範圍內和範圍外的內容，所以首先切入高階概念的現行和目標架構。