運用TOGAF ADM 的遷移計畫

在本文中我們將介紹在這個階段協調各項作業包的管理框架,並且對每個作業包給予業務價值。接著是在遷移專案中各項作業包的優先順序確認架構路線圖。最重要的是此階段的產出

  • 實施和遷移計劃
  • 過渡架構
  • 架構定義文件

另外我們也會介紹業務價值評估技術(Business Value Assessment technique)如何用於架構開發,以及過渡架構狀態進程表(Transition Architecture State Evolution Table)如何與企業所定義的分類法(如 TOGAF TRM)結合使用。

目標

  1. 架構路線圖與遷移計畫的定稿
  2. 確保遷移計劃與企業整體的變革組合相互協調
  3. 確保業務價值與作業包的成本可以被利害關係人理解

輸入

  • 架構作業請求
  • 溝通計畫
  • 企業架構組織模型
  • 治理模型與框架
  • 量身訂製的架構框架
  • 架構作業聲明
  • 架構願景
  • 架構儲存庫
  • 架構定義文件的草稿,包含過渡架構(如果有的話)
  • 架構需求規範的草稿
  • 針對現有的方案與專案的變更請求
  • 架構路線圖,包含作業包及過渡架構的確認以及因子評估與演譯矩陣
  • 能力評估
  • 實施與遷移計畫的大綱

步驟

步驟1: 針對實施與遷移計畫確認管理框架交互

  • 針對架構專案我們要使用甚麼類型的框架
  • 這是企業架構流程涉及專案管理流程的地方
  • SCRUM、Lean、PRINCE、Waterfall等框架使用,或其他的框架,如ITIL

此步驟是關於協調"實施和遷移計劃"與組織內的"管理框架"。 通常有四個管理框架必須緊密合作才能成功:

  1. 為實現具體業務目標/成果所需的所有活動構思、方向和提供資源的業務規劃
  2. 為所有企業活動構建並提供背景脈絡的企業架構主要具體的業務成果,該成果應該含IT領域之外的
  3. 協調、設計和建立業務系統以交付具體業務成果的專案組合/專案管理
  4. 整合、運營和維護交付具體業務成果的運營管理

實施和遷移計劃將影響了企業正在使用的每一種框架,因此必須反映在它們中。 在此步驟的過程中,了解組織內的框架並確保這些計劃得到協調並插入(以摘要格式)在每個框架的計劃中。 此步驟的成果很可能是實施和遷移計劃可能是在企業架構使用的其他框架的不同計劃的一部分。

步驟2: 針對每個作業包給予業務價值

  • 如作業包1有1千萬業務價值,作業包2有2千萬業務價值等
  • 對架構專案評估並分配風險
  • 業務價值評估技術(Business Value Assessment Technique)

為每個作業包分配業務價值。 目的是首先確定什麼構成了組織內的業務價值,如何衡量價值,然後將其應用於每個專案和專案增量。

如果已使用基於能力的規劃(Capability-Based Planning),則應使用與能力相關的業務價值和相關的能力增量(Capability increments)來分配可交付成果的業務價值。

這個步驟中有幾個問題需要解決:

  1. ”組合和能力”管理者運用績效評估標準來批准和監控架構轉換的進度
  2. 必須詳細說明"投資回報標準",並由各執行作業的利害關係人簽署
  3. 必須定義業務價值以及技術,例如價值鏈(例如 NASCIO),這些技術將用於說明在實現有形業務成果中的作用。業務價值將由組合和能力管理者用於分配資源和 ,在存在資源/預算削減的情況下,業務價值與ROI可用於確定一項作業是否繼續、延遲或取消。
  4. 應建立關鍵成功因素(Critical Success Factors) 來定義專案和(或)專案增量的成功; 這些將為管理人員和實施者提供衡量成功實施的標準
  5. 有效性衡量標準(Measures of Effectiveness)通常是績效標準,許多公司將其包含在關鍵成功因素中; 在分別處理這些標準的地方,應該清楚如何對這些標準進行分組
  6. 基於整體企業架構(所有層級)的戰略契合度將是批准任何新專案或計劃以及確定任何可交付成果價值的關鍵因素

作業包是實施和遷移計劃中的專案基礎。 確定的專案將在Phase F的其他步驟中得到充分發展。專案和專案增量可能需要調整架構路線圖和架構定義文件。

然後應通過"匯總的差距、解決方案和依賴關係矩陣(Phase E)”中確定的風險,將風險分配給專案和專案增量。使用業務價值評估技術評估每個專案的業務價值

關於業務價值評估技術評估

評估業務價值的一種技術是根據價值指標維度和風險指標維度(value index dimension and a risk index dimension)來繪製矩陣。 下圖為一個範例。價值指數應包括諸如遵守原則、財務貢獻、戰略一致性和競爭地位等標準。 風險指數應包括規模和複雜性、技術、組織能力和故障影響等標準。 每個標準都應分配一個獨立的權重。 該指數及其標準和權重應由高階管理層制定和批准。 在知道選項之前建立決策標準很重要

取自Open Group官網

步驟3: 預估資源、專案時程與

  • 那些團隊會參與專案?
  • 要花多少錢?
  • 何時可以被交付?

步驟4:優先項目

  • 成本/效益評估與風險驗證(Cost/Benefit Assessment and Risk Validation)
  • 讓利害關係人就項目的優先順序達成一致

通過確定專案的業務價值與交付成本來確定專案的優先順序。 該方法首先盡可能清楚地確定專案交付的所有 SBB 的淨收益,然後驗證風險是否已得到有效緩解和考量。其意圖是獲得必要的共識,以創建一個優先專案清單,為資源分配提供依據。

重要的是要發現所有成本,並確保決策者了解隨著時間推移的淨收益。審查風險以確保盡可能降低專案可交付成果的風險。 然後用風險相關評論(risk-related comments)更新專案清單。

讓利害關係人就專案的優先順序達成一致。 優先等級標準將使用在Phase E中建立的架構路線圖草稿時所確定的元素以及與各個利害關係人議程相關的元素。

正式審查風險評估並在必要時對其進行修改,以確保充分了解與優先順序和預計資金額度相關的剩餘風險。

步驟5:確認架構路線圖與更新版的架構定義文件

  • 更新架構路線圖,包含任何的過渡架構(如果有的話)
  • 過渡架構狀態進程表
  • 更新架構定義文件

審查迄今為止的作業以評估過渡架構之間的時間跨度應該是多少,同時考量業務價值和能力的增量以及其他因素,例如風險。 一旦確定了能力增量,就按每個過渡架構的專案增量整合可交付成果。 這將會修改架構路線圖。

這是為了協調不同架構的多個進行中的作業所必需的。 過渡架構狀態進程表可用於在各個詳細等級上顯示領域架構的建議狀態。

如果由於確認實施增量而導致實施方法發生變化,我們需要更新架構定義文件。 這可能包括分配專案目標並使專案及其可交付成果與過渡架構保持一致,以建立架構定義增量表(Architecture Definition Increments Table)。

關於架構定義增量表

創建架構定義增量表的技術允許企業架構師規劃一系列過渡架構,概述特定時間的企業架構狀態。 所以應該會有一個表格(如下範例),列出專案,然後在過渡架構中分配它們的增量可交付成果(incremental deliverables)。

取自Open Group官網

步驟6: 完成實施和遷移計劃

  • 完成實施和遷移計劃的定稿
  • 包含所有的外部依賴項
  • 專案計畫(也許有)

此步驟會產生完整的實施和遷移計劃。 而且已經有了計劃的大部分細節,這一步使用公認的計劃和管理技術將所有細節整合在一起。

這應該包括將所有專案、專案增量和活動以及依賴項整合到專案計劃中。 任何過渡架構都將作為專案組合的里程碑。

應擷取並包括所有外部依賴項,並評估資源的總體可用性。 專案計劃可能包含在實施和遷移計劃中。

關於過渡架構狀態進程表

建立過渡架構狀態進程表的技術讓企業架構師使用有定義的分類法(例如 TOGAF TRM)在不同等級顯示架構的建議狀態。 所以會有一個表格表,列出企業中使用的分類法中的服務、過渡架構和建議的轉換,如下表示。

應描述所有 SBB 的交付及其對這些服務的影響。 它們還應該被標記以顯示企業架構的進展。 在上面範例中,已達到目標能力的地方顯示為“New”或“retain”; 將能力轉移到新解決方案的地方,標記為“transition”; 如果要替換功能,則標記為“replace”。

步驟7:完成架構開發週期並記錄經驗教訓(lessons learned)

  • 從架構設計到實現的過渡
  • 專案期間的經驗教訓

此步驟將治理從架構的開發過渡到架構的實現。 如果架構能力的成熟度是有保證的,哪就可以產生一個"實施治理模型(Implementation Governance Model)"。 吸取的經驗教訓也應記錄在案,並由Phase H中的適當治理流程中取得,作為管理"架構能力"的輸入。

架構路線圖和"實施和遷移計劃"的細節應該以與Phase B/C/D中開發的架構定義文件類似的詳細程度來呈現。如果下一階段需要重要的額外細節,架構可能是 過渡到不同的水準。 根據目標架構、實施和遷移計劃的等級,可能需要在較低的詳細等級上迭代另一個 ADM 週期。

輸出

  1. 實施與遷移計畫1.0版,包含
    1.1實施和遷移策略
    1.2分解專案和組合(portfolio)
    1.3 專案章程(project charters)
  2. 定稿架構定義文件
  3. 定稿架構需求規範
  4. 定稿架構路線圖
  5. 可重複使用的ABB
  6. 根據經驗教訓更改架構能力的請求

關於實施與遷移計畫

實施和遷移計劃在Phase E 與F 中製定,並提供目標架構實施專案的時間表。 實施和遷移計劃包括可執行專案,這些專案被分組為受到管理的專案組合和專案方案中。 確定變更方法的實施和遷移策略是實施和遷移計劃的關鍵要素。而要素內容通常包含:

  • 實施與遷移計畫策略
    — 策略性的實施方向
    — 實施順序的方法
  • 實施的專案與專案組合的分解
    — 將作業包分配給專案和專案組合
    — 專案所交付的能力
    — 里程碑和時機
    — 工作分解結構

可能還要包含:

  • 專案章程(project charters)
    — 作業包
    — 業務價值
    — 風險、問題、假設與依賴項
    — 資源需求與成本
    — 確定遷移的效益(包括對映到業務需求)
    — 遷移選項的估計成本

關於架構定義文件與過渡架構

架構定義文件在此階段定稿。 如果實施目標架構的變更範圍需要增量方法,則在Phase E的架構定義文件產出中定義一個或多個過渡架構。過渡架構顯示企業處於現行架構和目標架構之間的架構重要狀態。 過渡架構用於描述有效實現目標架構所必需的過渡目標架構。 這些提供了沿著實現目標架構的路線圖識別明確目標的能力。

以下過渡架構中的通常會有的:

  • 過渡狀態的定義
  • 每個過渡狀態的B.D.A.T架構

關於實施治理模型

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

作為Phase F 產出的實施治理模型可確保過渡到實施的專案也順利過渡到適當的架構治理(Phase G)。

以下實施治理模型中的通常會有的:

  • 治理流程
  • 治理組織的結構
  • 治理的R&R(roles and responsibilities)
  • 治理的檢查點與成功/失敗的標準

總結

  • 專案移交給實施團隊
  • 架構文件已完成,所有最終狀態,都已簽署
  • 架構團隊轉向治理模式

--

--

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

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

我們協助您駕馭名為"雲端運算"的怪獸,馴服它為您所用。諮詢請來信jason.kao@suros.com.tw. https://facebook.com/jason.kao.for.cloud

No responses yet