企業架構（EA）依賴結構化方法來引導組織變革。此領域中兩個最突出的標準是TOGAF架構開發方法（ADM）和ArchiMate建模語言。當有效運用時，這些框架相輔相成，為設計、規劃和治理企業變革提供穩固的結構。然而，將ArchiMate模型的細節與TOGAF ADM的程序階段整合，需要明確的對齊。本指南探討如何將ArchiMate概念映射到特定的ADM階段，以確保架構生命周期中的一致性和清晰性。
許多組織在架構成果物彼此脫節方面面臨困難。若缺乏明確的映射策略，模型可能保持靜態，或無法反映ADM週期中定義的不斷演變的業務需求。正確的對齊確保ADM的每個階段都有對應的架構輸出，這些輸出具有標準化、可重用且易於理解的特點。此過程彌補了高階策略與詳細實施規格之間的差距。
理解框架 🔍
在深入探討映射之前，理解每個框架的獨特角色至關重要。TOGAF ADM是一個包含多個階段的循環過程，提供開發企業架構的流程、步驟和治理機制。它回答了「如何」建立架構的問題。如何來建立架構。
相反地，ArchiMate是一種建模語言，提供表示架構本身的符號、詞彙和結構。它回答了「正在建立什麼」的問題。正在建立什麼正在被建立的內容。ArchiMate採用分層方法，將業務、應用與技術領域分離，同時還包含策略與實施層。這種分離使架構師能夠在組織的不同層級之間視覺化依賴關係與影響。
將這兩者對齊，意味著將ADM的程序步驟填入特定的ArchiMate視圖與觀點。這確保了每個階段產生的文件不僅僅是報告，更是一個可分析、可查詢和可追蹤的結構化模型。
ADM週期概覽 🔄
TOGAF ADM包含八個階段，通常稱為核心週期。此外還有一個預備階段和一個需求管理階段，與週期並行運作。為達成此對齊目的，我們將專注於核心階段A至H，因為這些階段代表了主要的架構開發工作。
- 階段A：架構願景
- 階段B：業務架構
- 階段C：資訊系統架構（資料與應用）
- 階段D：技術架構
- 階段E：機會與解決方案
- 階段F：遷移規劃
- 階段G：實施治理
- 階段H：架構變更管理
每個階段都會產生特定的交付成果。透過將ArchiMate概念映射到這些交付成果，架構師可以建立一個一致的資料庫。以下各節將詳細說明每個階段的具體ArchiMate建模活動。
階段 A：架構願景 👁️
階段 A 聚焦於定義架構專案的範圍、限制條件與利害關係人。主要輸出為架構願景文件。在此階段，ArchiMate 模型的使用雖有限但至關重要。目標在於建立背景脈絡。
模型建立活動
- 利害關係人建模：利用 ArchiMate 的利害關係人與角色概念識別關鍵利害關係人。這能明確指出變更所影響的對象。
- 業務能力概覽：建立現有能力與未來能力的高階對照視圖。這能突顯架構必須解決的缺口。
- 價值流：定義架構將支援的高階價值流。確保從一開始就具備商業脈絡。
- 驅動因素對應：利用 ArchiMate 的驅動因素來表示在願景規劃過程中識別出的商業驅動因素與風險。
在階段 A 中，模型應保持高階層次。目前尚不需要詳細的流程圖或應用介面。重點在於與商業策略的一致性，以及架構範圍的定義。
階段 B：業務架構 🏢
階段 B 通常是 ArchiMate 使用最密集的階段。它定義了商業策略、治理、組織架構與關鍵業務流程。這正是 ArchiMate 核心業務架構層發揮作用的時刻。
關鍵模型元件
- 業務流程模型：活動、功能與業務流程的詳細對應。應包含資訊與控制的流動。
- 組織結構：呈現業務角色、職位與組織單位。這能明確責任與權責關係。
- 業務互動：定義業務角色與其所執行流程之間的互動。
- 業務服務：識別提供給客戶或其他業務單位的服務。這能將內部流程與外部價值交付連結起來。
- 價值流：深入說明階段 A 所識別的端對端價值創造流程。
在此階段，架構師應建立現行狀態（現況）與目標狀態（未來）的模型。這兩者之間的差距分析，將驅動後續資訊系統與技術架構的需求。
階段 C：資訊系統架構 🗃️
階段 C 分為兩個子階段：資料架構與應用架構。此階段將商業需求轉譯為資訊與軟體支援。
資料架構
- 業務物件： 定義與業務流程相關的資料實體（例如：客戶、訂單、產品）。
- 資料物件：建立邏輯與實體資料結構模型，以儲存這些業務物件。
- 關係：繪製資料物件之間的關聯，以確保資料的完整性與流動性。
應用架構
- 應用組件：識別支援業務服務與業務流程的軟體應用程式。
- 應用服務：定義應用程式提供給業務層的服務。
- 應用互動：繪製應用程式之間的介面與資料流。
- 使用關係：指定哪些應用程式使用資料物件或其他應用服務。
此項對齊確保每個業務流程都有對應的應用支援，且每個業務物件都有對應的資料儲存機制。這可避免產生無明確業務目的的孤兒系統。
階段 D：技術架構 💻
階段 D 聚焦於支援應用架構所需的基礎設施與技術平台，包括硬體、網路與雲端服務。
模型元素
- 技術服務：定義技術層所提供的服務（例如：資料庫服務、運算服務）。
- 技術組件：建立實體或邏輯技術節點的模型（例如：伺服器、路由器、雲端實例）。
- 裝置：代表與架構互動的終端使用者裝置或物聯網裝置。
- 網路：繪製技術組件之間的通訊路徑與通訊協定。
- 基礎設施：定義環境限制與實體位置。
將技術架構與應用架構連結至關重要。每個應用組件都必須部署至至少一個技術組件。這可確保在進入實作階段前，解決方案的技術可行性已獲得驗證。
階段 E：機會與解決方案 🚀
階段E涉及識別從當前狀態移動到目標狀態所需的關鍵工作包和專案。這正是架構從設計轉向規劃的階段。
對齊活動
- 差距分析：使用ArchiMate明確地視覺化所有層級中「現狀」與「目標」模型之間的差異。
- 工作包：將相關的架構變更歸類為邏輯上的工作包。這些工作包可表示為特定的專案或行動。
- 解決方案定義：定義將用來彌補差距的具體解決方案（軟體、服務或流程）。
- 依賴關係映射：建立工作包之間的依賴關係，以確保實施順序的邏輯性。
此階段對於預算編列與資源配置至關重要。透過使用結構化模型，組織能更準確地估算每個工作包所需的投入。同時也有助於識別與特定技術轉換或業務流程變更相關的風險。
階段F：遷移規劃 📅
階段F建立詳細的實施與遷移計畫。它將階段E中識別的工作包分解為一條路徑圖。
以模型進行規劃
- 遷移路徑圖：視覺化架構變更的時間軸。可透過ArchiMate圖表與專案時程的組合來呈現。
- 影響分析：評估每次遷移步驟對現有架構的影響。這有助於在轉移期間最小化中斷。
- 資源配置：將架構元件與實施所需的資源連結起來。這確保計畫具備現實可行性。
- 先決條件：定義在特定工作包開始前必須達成的架構先決條件。
遷移計畫應具備迭代性。隨著架構在實施過程中演進，計畫必須持續更新。ArchiMate模型支援版本控制，有利於此迭代方法。
階段G：實施治理 ⚖️
階段G確保實施專案與既定架構保持一致。這包括監督與控制機制。
治理模型
- 合規性檢查：使用ArchiMate定義合規規則。例如，確保所有客戶資料都儲存在特定的技術節點內。
- 架構合規性：將實際實施的解決方案與目標架構進行比較。偏差應被記錄並分析。
- 變更請求： 如果專案需要對架構進行變更，則必須將其記錄為模型的修改。這能維持架構的完整性。
- 交付成果驗證： 確保所有必要的架構交付成果在專案生命週期內產生並經過審查。
此階段往往是架構治理失敗的地方。若缺乏明確的模型，很難驗證合規性。透過使用ArchiMate作為唯一真實來源，架構師可以自動檢查已部署系統中的偏差。
階段 H：架構變更管理 🔄
階段 H 處理實施後對架構的變更管理。企業環境是動態的，架構必須持續演進以支援新的業務需求。
變更管理
- 變更請求： 捕捉影響架構的新需求或變更。這些項目被建模為驅動因素或需求。
- 影響評估： 分析所提出變更在業務、應用與技術層級之間產生的連鎖效應。
- 版本控制： 維護ArchiMate模型的版本歷史。這使架構師能夠追蹤架構隨時間的演變過程。
- 反饋迴路： 將來自運營與維護的資訊回饋至架構資料庫中。這將為ADM循環的未來迭代提供資訊。
架構變更管理確保架構不會過時。它建立了一個反饋迴路，使TOGAF ADM循環能以更新的資訊重複執行。
對應表摘要 📊
下表總結了與每個TOGAF ADM階段相關的關鍵ArchiMate元素，以供快速參考。
| ADM階段 | 主要重點 | 關鍵ArchiMate元素 |
|---|---|---|
| 階段 A | 願景與範圍 | 利害關係人、驅動因素、業務能力、價值流 |
| 階段 B | 業務 | 業務流程、組織、業務服務、業務角色 |
| 階段 C | 資料與應用 | 業務物件、應用元件、應用服務、資料物件 |
| 階段 D | 技術 | 技術服務、技術元件、裝置、網路 |
| 階段 E | 解決方案 | 差距分析、工作包、實施事件 |
| 階段 F | 遷移 | 遷移路徑圖、先決條件、影響分析 |
| 階段 G | 治理 | 合規性、實施事件、交付成果 |
| 階段 H | 變更 | 變更請求、需求、版本控制 |
對齊的最佳實務 🛠️
成功的對齊不僅僅需要映射元素，還需要對建模與治理採取紀律嚴明的方法。以下最佳實務有助於維持一致性。
- 一致的命名慣例： 確保所有架構師對概念、流程與服務使用相同的術語。這可避免模型中的歧義。
- 層級分離： 保持業務、應用與技術層級的區分。除非有明確定義的介面，否則不要跨層級混合概念。
- 觀點定義： 為不同利害關係人定義特定的觀點。高階主管可能需要高階能力地圖，而開發人員則需要詳細的介面規格。
- 儲存庫管理： 維護一個中央架構儲存庫。所有模型應儲存在單一位置，以確保版本控制與存取權限。
- 可追溯性： 維持需求、業務能力與技術元件之間的可追溯性連結。這確保每一行程式碼或流程變更都有明確的商業理由。
常見挑戰與陷阱 ⚠️
儘管這些框架的優勢顯而易見，但對齊它們仍存在挑戰。了解這些陷阱有助於避免常見錯誤。
1. 模型過度細化
一個常見的問題是過早建立過於詳細的模型。在A階段和B階段，應專注於高階概念。詳細的流程建模可稍後進行。過度細化會拖慢初始設計進程，並帶來維護負擔。
2. 忽視利益相關者參與
如果利益相關者無法理解模型，那麼這些模型就毫無用處。請確保圖示清晰明瞭，且術語對業務使用者而言易於理解，而不僅僅是技術架構師。
3. 忽視迭代特性
架構並非一次性事件。ADM循環具有迭代性質。模型必須定期更新，以反映業務環境的變化。將架構視為靜態文件，將導致其迅速過時。
4. 孤島式模型
業務架構師經常與應用架構師分開工作。這導致業務需求與技術能力之間出現脫節。必須定期進行跨功能審查，以確保整合。
整合的價值 📈
當ArchiMate與TOGAF ADM相契合時，組織將獲得多項戰略優勢。
- 改善溝通：標準化的模型為業務與IT利益相關者提供了一種共通語言。
- 更佳的決策制定：對影響與依賴關係的清晰可見性，有助於做出明智的投資決策。
- 降低風險：治理與合規檢查可降低實施失敗的風險。
- 敏捷性：維護良好的架構資料庫，可加快對市場變化的反應速度。
- 成本效率：消除重複的系統與流程，長期而言可節省成本。
關於對齊的最後思考 💡
將ArchiMate模型與TOGAF ADM階段對齊，是成熟企業架構實踐的基礎活動。它能將抽象的戰略轉化為具體且可執行的計畫。透過遵循本指南所提出的結構化方法，組織可確保其架構不僅僅是一組圖表，更是一個能推動業務價值的活躍資產。
關鍵在於一致性。無論是業務能力的命名，還是技術組件的版本控制，都需要嚴謹的紀律。然而，其回報是建立一個易於理解、可維護且與企業戰略目標一致的架構。隨著技術的演進，這些框架仍保持相關性，因為它們關注的是組織的底層結構，而非特定工具或產品。
從明確的範圍開始。定義價值流。繪製能力圖。建立層級結構。治理實施過程。並管理變更。這個循環確保企業架構始終是戰略資產，而非文書負擔。