運用TOGAF ADM 的機會與解決方案

在本文我們將會講述:

1. 主要利害關係人會參與此階段的作業
2. 使用遷移計劃技術(migration planning techniques)來審查和綜合之前階段的差距分析結果
3. 建立第一版"實施和遷移策略"的步驟
4. 三種基本”實施(implementation)”方法
5. 如何辨識與組合作業包
6. 過渡架構的建立與紀錄
7. 實施因子評估和演譯矩陣(Factor Assessment and Deduction matrix)來記錄影響架構實施和遷移計劃的因素
8. 合併差距，解決方案和依賴項矩陣

目標

1. 根據從Phase B/C/D的"差距分析"與"待選架構路線圖組件"來發展第一版的完整架構路線圖
2. 決定是否採用增量方法，也就是會有過渡架構。過渡架構也需要有業務價值
3. 基於決定好的ABB來定義整體的SBB

在這個階段，我們需要業務單位和IT單位的利害關係人一起合作。 也應該包括實施/運營基礎架構與戰略規劃的成員，特別是在有需要的情況下建立過渡架構。

輸入

• 上一個階段的產出架構作業聲明、架構作業要求、能力評估、溝通計畫、規劃方法、架構願景
• 架構儲存庫現有的文件 — 企業架構的組織模型、量身訂做的架構框架、治理模型與框架、
• 架構定義文件 1.0版本
• 架構需求規範的草稿
• 架構路線圖 0.1版本
• 產品資訊
• 針對現有的規劃與專案的變更要求
• 從Phase B/C/D產生的待選架構路線圖組件

步驟

步驟1:確定關鍵的企業變革屬性

• 進行企業的業務文化變革的最佳方式是什麼
• 因子和演繹矩陣(Factor and Deduction matrix)

此步驟決定如何透過企業的業務文化來實施企業架構。 這應該包括建立一個因子和演繹矩陣，以作為架構"實施和遷移"決策的存儲庫。 還包括評估企業(包括文化和能力)的過渡能力，以及對企業(包括文化和技能)的評估。 評估的結果因素應記錄在因子和演繹矩陣中。 對於建立企業架構的組織，此步驟可以很簡單，但是必須建立矩陣，以便它可以用作做出的決策的存檔和記錄。

什麼是"因子和演繹矩陣"?

因子和演繹矩陣記錄了會影響"實施和遷移"計劃的因素。 矩陣應包括一個因子清單，因子和演繹矩陣會對基本原理的描述以及指示在製定計劃時必須考慮的行動或約束的演繹(也就是結論)。 生產和運用此工件可以被視為風險管理作業。 下表為一個範例矩陣。

步驟2:確認在實施中的業務制約因素

• 有任何事是會制約企業架構專案的實施嗎?

為了辨識任何的制約事項，我們應該包括對整體企業與業務單位等級的業務和戰略計劃進行查核，以及對企業架構成熟度評估的審查。

步驟3:檢視和合併Phase B/C/D的差距分析

• 合併所有已確定的差距
• 已合併的差距、解決方案和依賴關係矩陣
• 確定解決差距的SBB
• 重組和分組

合併並整合了從Phase B到D的差距分析結果，並評估其對潛在解決方案和相互依存的影響。 這可以建立一個合併的”差距，解決方案和依賴項矩陣(Gaps, Solutions, and Dependencies matrix)”來完成，如下表一所示，該矩陣將使能夠識別SBB，這些SBB或許有可能解決一個或多個差距及其相關的ABB。

回顧Phase B到D的差距分析結果，並將其合併在單一清單中。 差距應與"差距和依賴關係"的潛在解決方案合併。 確定依賴關係的推薦技術是使用一組視圖(view)，例如業務交互矩陣，資料實體/業務功能矩陣以及應用程式/功能矩陣，以完全關聯來自不同架領域(B.D.A.T)的元素。

說明合併的"差距，解決方案和依賴關係矩陣"。 一旦記錄了所有差距，我們要重新組織差距清單(gap list)，然後將類似的項目放在一起。 在分組差距時，需要參閱因子和演繹矩陣並查核因子。 任何其他因子都應添加到因子和演繹矩陣中。

什麼是”差距，解決方案和依賴關係矩陣”?

建立"合併的差距，解決方案和依賴關係矩陣"的技術使企業架構師可以在個領域架構的差距分析結果中分組差距(gap)，並評估一個或多個差距的潛在解決方案和依賴項。 下表是一個範例。在建立作業包時，該矩陣可以用作規劃工具。 依賴項驅動了Phase E與F的專案和遷移計劃的建立。

表一

步驟4: 檢視相關業務職能的綜合需求

• 嘗試通過分組相關解決方案來最小化需求
• 從業務角度出發，審查需求、差距、解決方案和因素
• 也許一個解決方案可以滿足多個業務部門的需求

步驟5: 整合和協調互操作性需求

• 解決互操作性衝突，或至少最小化它們。例如企業的ERP有著雲端運算的相關管銷費用，哪這一類的資料如何進到客戶看到的計費系統?
• 要嘛：開發一個處理互操作性的新建構區塊
• 或者：更改造成衝突的建構區塊規範

此步驟合併了先前階段中互操作性要求。 應"綜合並審查"1)架構願景和目標架構以及2)實施因子評估和演譯矩陣以及3)差距，解決方案和依賴關係矩陣，以確定潛在解決方案集所需的互操作性的任何約束。 一個關鍵的結果是最大程度地減少互操作性衝突。 可重複使用的SBB，商業現成（COTS）產品和第三方服務提供商通常會強化的互操作性要求(也就是產品之間的無法整合)。 任何此類衝突都必須在架構中解決。

互操作性要求與解決方案

要解決的最重要問題是業務互操作性(business interoperability)。 大多數SBB或COTS都會有自己的內建業務流程。 更改內建的業務流程通常需要花費很大的代價，以至於重複使用解決方案的優勢將會不復存在，更新版本的成本高昂，可能需要會有重工(rework)。 此外，必須考慮多個系統之間的工作流程方面。 買COTS軟體必須被視為可能需要領域架構進行重工的業務決策。 企業架構師將必須確保在修訂的架構作業聲明中，商業架構師和架構贊助人簽署了業務互操作性要求的任何變更。

步驟6: 優化和驗證依賴關係

• 這個新目標架構中的依賴項是什麼？
• 能否先交付一個，或者交付邏輯增量？
• 這是進入遷移計劃的關鍵部分

優化依賴項，確保對實施和遷移計劃的任何限制。 應考慮幾個關鍵依賴項，例如對業務服務和資訊系統服務的現有實施或對其進行變更的依賴項。 依賴項應用於確定實施順序並確定所需的協調。 依賴項還將有助於識別何時可以交付確定的增量。 完成後，這些依賴項應作為架構路線圖和任何必要的過渡架構的一部分進行記錄。 加入依賴項是大多數遷移計劃的基礎。

基於能力的規劃(Capability-Based Planning)與ADM

所謂的"特定能力"是能夠構思架構的重點（Phase B/C/D）和Phase E的作業包。 能力增量(capability increments)是將建立專案增量(project increments)的過渡架構(Phase E)的驅動力量。 實際交付將通過實施和遷移計劃(Phase F)協調。

步驟7: 確定業務轉型的就緒情況和風險

• ADM 週期中反覆出現的主題是確定企業處理變革的能力
• 在綜合差距、解決方案和依賴關係矩陣中定義風險
• 我們可以做些什麼來減輕風險並提高企業接受變革的準備程度？

步驟8: 制定實施和遷移策略

• 此階段的主要輸出是實施和遷移策略(implementation and migration strategy)並建立過渡架構
• 三種總體戰略方法：新建(greenfield)、革命式(revolutionary，根本性的變化)或漸進式(evolutionary)
• 三種常見的實施方法：快速取得、可實現的目標、價值鏈方法(如NASCIO企業架構成熟度模型)

這些方法和確定的依賴項應成為建立作業包的基礎。 該作業以企業的"實施和遷移策略(Implementation and Migration Strategy)"達成協議。

步驟9: 識別和分組主要作業包

• 主要利害關係人、規劃者和企業架構師應該評估目前發現還缺少的業務能力
• 將各項作業分組為作業包
• 對於每個差距/作業，確定它是新作業、既有產品還是現成的(off-the-shelf)
• 將每個現行系統分類為Mainstream、Contain或Replace
• 將作業包分組到組合中的專案中，將所有內容都考慮在內，包括依賴性和實施策略

使用”差距，解決方案和依賴關係矩陣”以及"因子評估和演譯矩陣"
，從邏輯上將各種作業分組為作業包(作業包是一組相互依賴的活動和可交付成果，可提供個別不同的企業成果)。

在"差距，解決方案和依賴關係矩陣"中的“解決方案”欄位填入填寫”提議的解決方案”。 指出每個差距/活動是否應針對新開發或基於現有產品和(或)使用可以購買的解決方案。 現有系統可以通過較小的強化需求。 對於新的開發，這是確定應該在內部自行開發還是通過外包的好時機。

分類現行的系統:

• Mainstream:未來資訊系統的一部分
• Contain:預計將在計劃範圍內更換或修改（接下來的三年）
• Replace:要在計劃範圍中替換

應將支援頂層作業包的再分解為增量(increments)以交付"功能增量"。 就其業務轉型問題和戰略實施方法而言，分析和完善這些作業包或增量作業。 最後，考慮到依賴關係和戰略實施方法，將作業包分組為一個組合，然後在組合中開始架構專案。

步驟10: 確認過渡架構

• 可以一次完成所有的作業嗎？
• 或者是否需要使用過渡架構分次完成？
• 每個過渡架構都提供可衡量的業務價值
• 不需要均勻地間隔過渡架構（3 個月、6 個月、9 個月……）
• TOGAF Standard 建議先做簡單有成果的，然後再解決更難的問題

過渡架構的開發必須基於選擇的實施方法，差距，解決方案和依賴項矩陣，專案和組合的清單以及企業建立和吸收變化的能力。

決定困難的作業在哪裡，除非有令人信服的原因，否則在其他作業中最容易因為缺少這種能力而進行後續作業。

步驟11: 建立架構路線圖及"實施與遷移計畫"

• 將作業包和過渡架構整合到架構路線圖中，版本 0.1
• 01.版本描述了從現行架構到目標架構的進展時間表
• 實施和遷移計劃(0.1版) 必須展示實現架構路線圖所需的作業
• 更新架構願景、架構定義文件檔和架構需求規範

時間表為實施和遷移計劃提供了資訊。 架構路線圖將構成Phase F的遷移計劃。確定的過渡架構和作業包應該具有明確的成果。 架構路線圖必須證明過渡架構和作業包的選擇和時間表如何實現目標架構。

架構路線圖的細節(0.1版本)應以類似的細節等級呈現，與Phase B/C/D中開發的架構定義文件相似 。 實施和遷移計劃必須認知到實現架構路線圖所需的作業。 實施和遷移計劃構成了Phase F的遷移計劃的基礎。實施和遷移計劃的詳細資訊(0.1版本)必須與架構路線圖的細節保持一致，並且足以確定必要的專案和資源需求以實現路線圖。

產出

1.架構路線圖(0.1版)

• 作業包組合
  ○ 要交付的每個作業包的詳細資訊、需求、依賴項、業務價值、影響
• 識別過渡架構
• 實施建議

2.實施與遷移計劃(0.1版)

• 包含實施與遷移策略

3. 更新過的現有文件(如果需要)

• 架構願景
• 架構作業聲明
• 架構定義文件1.0版
• 架構需求規範的草稿

總結

• 如何交付架構
• 全面審查所有已確定的差距
• 將更改邏輯分組到工作包中
• 確保在每一步都交付商業價值