運用TOGAF ADM的業務架構

12 min readFeb 16, 2023

在Phase B 主要的輸入是從Phase A的產出(業務原則/業務目的/業務驅動因素)。在Phase B的進行步驟中主要會用到業務建模(Business modeling)技術、差距分析(Gap analysis)技術，如何選擇”參考模型、觀點與工具”以及建構區塊(Building Block)是如何在此階段開始發展。

目標

發展"目標"業務架構以達成"業務目的"
解決架構工作聲明(Statement of Architecture Work)和利害關係人的問題回應架構願景中業務策略驅動因素
根據現行與目標架構的差距製作”待選的架構路線圖”

輸入

前一個階段的產出 — 架構作業要求，業務原則/目標/驅動因素，能力評估，溝通計畫
既有的架構儲存庫(Architecture Repository)文件 — 企業架構的組織模型，量身訂製的企業況價，既有的架構文件等
架構願景
0.1版本的架構定義文件草稿

什麼是業務原則

業務原則是架構原則的一部分，它是在準備階段(Preliminary Phase)制定的。下表為一個業務原則範例。下表總結了來自TOGAF Part III 架構原則的業務原則範例。

Phase B的進行步驟

在這個階段中處理的詳細程度將取決於整體架構工作的範圍和目標。此階段中需要詳細定義描述業務需求的新模型。要在目標環境中支援的現有業務工件(Business Artifacts)可能已經在以前的架構工作中充分定義；但是，如果沒有，它們也需要在此階段中定義。

步驟1: 選擇要參考的模型，觀點與工具

如果有現有的參考模型可以在之後對架構進行建模
哪些利害關係人需要對此的觀點
任何用於取得和建模流程的工具

在此步驟中，根據業務驅動因素、利害關係人及其問題，從架構存儲庫中選擇相關的業務架構資源（參考模型、模式等）。此外，選擇相關的業務架構觀點（例如，運營、管理、財務）；也就是說，那些展現出利害關係人關注的問題是如何在業務架構中得到解決的。然後，確定用於擷取、建模和分析所選擇觀點的適當工具和技術。

業務建模(Business Modeling)和策略評估(Strategy assessment)是構建組織業務架構目標狀態的技術。這兩項作業的產出可用於闡明拉近當前狀態和目標狀態之間差距所需的業務能力、組織結構和價值流。

對於每個觀點，針對不同的視圖採用不同的工具或方法來解決。確認所有利害關係人的問題都得到解決。如果不是，就要建立新模型來解決沒有涵蓋到的問題，或擴充現有模型。 業務場景(Business Scenarios)是探索和記錄業務需求的技術。

以下為建議的建模技術:

能力對照圖(Capability Mapping): 識別、分類和分解組織業務想要的業務能力，以便能夠向一個或多個利害關係人交付價值
組織對照圖(Organization Mapping):業務組織結構的呈現(包括第三方)，描述業務單元，將這些單元分解為較低等級的功能，以及組織關係（單元到單元和對照到業務能力、位置和其他屬性）
價值流對照圖(Value Stream Mapping):為創造與利害關係人價值而執行的活動細部分解。價值流對照圖說明了組織如何在一組特定利害關係人的背景下交付價值，並利用業務能力來創造利害關係人價值並與目標業務架構的其他方面保持一致
結構分析(Structured Analysis):識別架構範圍內的主要業務功能，並將這些功能對應到業務中的各單位
案例分析(Use-Case Analysis):跨越參與者和組織的"業務等級功能"細分允許識別"功能"中的參與者(人與電腦)，並讓我們可以細分為支援/交付該功能的服務
流程建模(Process Modeling):通過流程建模分解功能或業務服務讓我們識別流程中的元素，並可以識別較低等級的業務服務或功能

確定架構的哪些組件是功能，哪些是服務。指定所需的服務等級。這應該會產生正式的 SLA。

TOGAF 標準提供了用於開發業務架構的目錄(Catalogs)、矩陣(Matrices)和圖表(Diagrams)的定義。目錄擷取企業核心資產的清單。矩陣呈現模型實體之間的核心關係。圖表從一組不同的角度(觀點)呈現業務架構資訊。

TOGAF 標準建議在此階段中考量下圖的目錄、矩陣和圖表，並在TOGAF Part IV 的內容元模型(Content Metamodel)中提供有關其結構的指導。

有了目錄、矩陣和圖表，就應該形式化(formalizing)目標架構的業務需求來完成建模。企業架構師應該確定架構要滿足的需求類型。這些需求可能與業務領域相關，可能會提供對資料、應用程式和技術架構的需求輸入，或者可能會提供詳細的指導以反映在設計和實施過程中。

步驟2: 發展現行架構描述

要有一個適當的詳細程度，現行的架構是什麼?

要定義的範圍和詳細程度將取決於現有業務元素可能被轉移到目標業務架構中的程度，以及架構描述是否存在。在需要開發新架構模型以滿足利害關係人的關注點，使用步驟 1 中所決定的模型作為建立新架構內容以描述現行架構的指南。

步驟3: 發展目標架構描述

要有一個適當的詳細程度，未來的架構是什麼?

在架構願景的範圍內，為業務架構制定目標描述。要定義的範圍和詳細程度將取決於業務元素與實現目標架構願景的相關性，以及是否存在架構描述。在需要開發新架構模型以滿足利害關係人的問題，使用步驟 1 中所決定的模型作為建立新架構內容以描述目標架構的指南。

關於業務建模(Business Modeling)

有許多各種建模技術可以使用，其中包括業務能力圖(Business Capability maps)、價值流圖(Value Stream maps)和組織圖(Organization maps)。

在架構願景階段開發的業務能力圖是獨立於當現行組織結構、業務流程、資訊系統和應用程式以及其餘產品或服務組合的業務的獨立視圖，也就是說它是一個未來的業務能力，是現行組織沒有的。

價值流為組織需要業務能力的原因提供利害關係人背景，而業務能力則提供了組織在特定價值階段取得成功所需的條件。組織圖顯示了構成企業生態系統的主要單位、合作夥伴和利害關係人群體。

步驟4: 進行差距分析(Gap analysis)

驗證架構模型的一致性和準確性
驗證模型是否支持架構願景
驗證模型是否支持原則、目標和約束
對於每個觀點，注意前後的變化
使用差距分析確定現行和目標之間的差距

步驟5: 定義待選的路線圖組件

根據現行，目標與差距分析，定義出要執行的作業
在時間軸(timeline)上確定作業的優先等級
粗略的想法，因為兩個階段專門用於完成此路線圖

這個初步的業務架構路線圖只是原材料，它會在Phase E 中更詳細地定義綜合的跨學科路線圖。

步驟6: 解決整個架構面貌(Architecture Landscape)的影響

業務架構完成後，我們有必要知道有任何更廣泛的影響。在此階段，應檢查整個架構面貌(Architecture Landscape)中的其他架構工件以解決以下問題：

新架構是否會對任何先前存在的架構產生影響？
近期的變更是否影響業務架構
是否有任何影響該架構的外部變化？
新架構是否會對任何計劃中或進行中的專案產生影響？
或者是否有任何計劃中或進行中的專案影響此架構？
是否有機會在組織的其他領域重複使用此業務架構的工作？

步驟7: 進行利害關係人審查

根據我們的溝通計劃以及我們在步驟一中確定的利害關係人觀點，
對利害關係人傳達將進行的計劃。每個領域按順序排列 — Business、 Data/Application、Technology，僅在必要時修改。

步驟8: 確定業務架構

為每個建構區塊(Building Block)選擇標準，盡可能多地重複使用從架構儲存庫中選擇的參考模型。完整記錄每個建構區塊，然後根據業務目標對整體架構進行最終交叉檢查；在架構文件中記錄建構區塊決策的基本原理。記錄最終需求可追溯性報告。在架構存儲庫中記錄架構的最終對映。從選定的建構區塊中，確定可以重複使用的建構區塊(作業實踐、角色、業務關係、職位描述等)並通過架構存儲庫發布。

步驟9: 建立架構定義文件

定義最終將會出現在企業連續體中的建構建塊(Building Block)
每個領域按順序排列 — Business、 Data/Application、Technology

解釋建構區塊

建構區塊在 TOGAF 標準中被廣泛用於建立架構，如果在架構中它們被稱為ABB，在建構解決方案中，它們被稱為SBB。將功能、產品和自行開發組裝成建構區塊的方式在不同的架構之間差異很大。每個企業都必須自行決定哪種建構區塊的安排最適合自己。 好的建構區塊可以加強就有系統的整合、互操作性以及建立新系統和應用程式的靈活性。

在Phase B中，當建立現行和目標架構描述時，企業架構師應該確定相關的業務架構建構區塊，如果可能的話，利用架構存儲庫。它提供了許多目錄以幫助對建構區塊的分解以及跨相關建構區塊的分解進行建模。一旦初始的現行和目標架構完成，就會使用差距分析來確定要轉移到目標的建構區塊；消除建構區塊; 和建立新的、必需的建構區塊。在最終確定業務架構時，為每個建構區塊選擇標準，記錄每個建構區塊，並且將那些看起來可能可重複使用的建構區塊發佈在架構存儲庫中。

產出

架構定義文件的草稿(現行與目標的1.0版本，解決從主要利害關係人的觀點在乎的關注點)
架構需求規範的草稿(差距分析的結果，技術需求，按BDAT領個別產出)
架構路線圖(作業單位，按優先次序排列)
更新的架構願景原則(這些階段的作業可能會修改原始計畫，更新的架構作業聲明，經過驗證的架構原則)
驗證過的業務原則、業務目的與業務驅動因素

這些產出會以部分或全部用目錄、矩陣與圖表的方式呈現。

產出: 架構定義文件

架構定義文件是架構專案期間建立的核心架構工件和重要相關資訊的可交付容器(Deliverable container)。 架構定義文件涵蓋所有四個架構領域(BDAT)，還檢查架構的所有相關狀態(現行、過渡和目標)。它首先在Phase A中建立工件。它在 Phase B中使用與業務架構相關的素材進行更新，隨後在 Phase C使用資訊系統架構素材進行更新，然後在 Phase E使用技術架構素材再次更新。實施目標架構的變更範圍需要用"增量法" ，架構定義文檔會在Phase E 中變成一個包含一個或多個過渡架構。

架構定義文檔是架構需求規範的姊妹篇，其目標是提供解決方案的定性視圖(qualitative view)。目的是傳達企業架構師的意圖。另一方面，架構需求規範提供了解決方案的定量視圖(quantitative view)，說明了在架構實施過程中必須滿足的可衡量標準。

以下為架構定義文件通常會有的內容:

範圍
目的，目標與制約因素
架構原則
現行架構
架構模型(針對每個要建模的狀態)；例如針對BDAT四個架構的模型
架構方法的基本原理和理由
對映到架構存儲庫，包括對映到架構景觀、參考模型、標準以及重複使用評估
差距分析
衝擊評估
過渡架構

產出: 架構定義規範(Architecture Requirements Specification)

架構需求規範提供了一組定量陳述，概述了進行專案必須做什麼才能符合架構。 架構需求規範通常會構成實施合約或更詳細的架構定義合約的主要組成部分。如之前所述，架構需求規範是架構定義文件的補充，並提供了一個定量視圖(quantitative view)。

通常架構需求規範會有以下內容:

成功措施
架構要求
業務服務合約
應用程式服務合約
實施指南
實施規範
執行標準
互操作性要求
IT服務管理要求
約束條件
假設

在此階段中會讓架構需求規範逐步產生的業務架構需求包括：

差距分析結果
技術要求：應產生一組初始技術需求作為Phase B 的產出。這些是隨後的Phase D: 技術架構工作的驅動因素，應該識別、分類和優先考慮對其餘架構領域工作的影響；例如，通過dependency/priority matrix(如，指導交易處理速度和安全性之間的權衡)；預期產生的特定模型列表（例如，規定主要使用Zachman 框架）。
更新的業務需求，通過使用業務場景技術確定

產出:架構路線圖(Architecture Roadmap)

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

通常架構路線圖會含有以下內容:

作業包的組合
— 作業包的描述（名稱、敘述、目標、可交付成果）
— 功能要求
— 依賴關係
— 與商機的關係
— 與架構定義文件和架構需求需求規範的關係
— 商業價值
實施因素評估和推導矩陣(Factor Assessment and Deduction matrix)，包括：
— 風險
— 議題
— 假設
— 依賴關係
— 行動
— 衝擊
綜合"差距、解決方案和依賴關係"矩陣，包括：
— 架構領域
— 差距
— 潛在的解決方案
— 依賴關係
過渡架構(如果有的話)
— 專案有效性的標準/措施
— 風險與問題
— SBB

總結

Phase B是關於業務架構的開發；業務能力、點對點的價值交付、資訊和組織結構的整體呈現，以及與策略、產品、政策、計劃和利害關係人的關係。它應該顯示組織如何實現其業務目標。

所以這是很大量的作業，因為要將架構願景轉化為定義，需求和路線圖。
如果這是組織第一次使用 ADM，組織可能沒有很多現有文件可以從中著手。但只要進行一次 ADM 週期，哪後續運行則更容易 — 因為架構和業務能力的強化，簡化的流程，以及許多已經存在的架構工件/建構區塊。