TOGAF的架構內容框架
在本文中我們將會介紹TOGAF的架構內容框架(Architecture Content Framework)以及內容元模型(Content Metamodel)的高層次概念。重點如下:
- 為什麼要有架構內容框架
- 架構內容框架與ADM之間的關係
- 內容元模型的主要組件
- 核心元模型(Core metamodel)概念
- 為什麼元模型分為核心(Core)與擴展(extensions)
- 與核心元模型實體(core metamodel entities)相關的主要概念
簡介
架構內容框架(以下簡稱ACF)提供了架構作業產品的詳細模型，包括1.)可交付成果、2.)可交付成果中的工件以及3.)工件所代表的ABB。 它有助於通過以一致性和結構化的方式呈現產出來提高 TOGAF 產出的一致性，還有助於對它們進行引用和分類。
使用 ACF的效益包括它提供了一個全面的架構產出清單，它促進了作業產品(work product)的整合，並且它為應該如何描述架構提供了一個詳細的開放標準。
ACF讓 TOGAF 框架用作企業中架構的獨立框架。 但是，如果有其他內容框架的存在，一些企業就可能會選擇將外部框架與 TOGAF ADM 結合使用。 在這些情況下，TOGAF ACF為將 TOGAF 內容對映到其他框架的元模型提供了有用的參考和起點。
ACF與TOGAF ADM
ADM 通過願景、定義、規劃和治理等流程處理業務需求。 在每個階段，ADM 都將資訊作為輸入並製造產出。 內容框架為 ADM 提供了一個結構，它詳細定義了輸入和產出，並將每個可交付成果放入架構的整體脈絡中。 因此，ACF是 ADM的輔助。 ADM 說明了建立架構需要完成的工作，ACF則說明它最終應該是長什麼樣。
為何需要元模型(metamodel)?
模型的使用有助於簡化複雜的主題，例如用在企業上，使它們更易於理解。 內容元模型用於形式化企業架構的定義，以有序的方式建立架構資訊，以便可以對其進行處理以滿足利害關係人的需求，因為有結構所以有助於溝通和理解。
大多數架構中的利害關係人實際上不需要知道架構元模型是什麼，他們只關心特定的問題，例如應用程式的功能，或者將受到專案影響的流程。 為了滿足這些利害關係人的需求，TOGAF使用了建構區塊、目錄、矩陣和圖表的 TOGAF 標準概念。 內容元模型還可以形式化物件之間的關係，從而實現可追溯性。 最重要的是，它可以用作企業架構工具的資料模式對映。
內容元模型的組件
ACF是基於標準的內容元模型，它定義了架構中所有類型的建構區塊，顯示如何說明這些建構區塊以及它們如何相互關聯。 例如，在建立架構時，企業架構師將識別應用程式、應用程式中保存的資料實體以及實現這些應用程式的技術。 這些應用程式將回過頭來支援特定的業務上的使用者或業務單位，並將用於完成業務服務。 內容元模型標識所有這些實體（即應用程式、資料實體、技術、參與者和業務服務），顯示它們之間可能存在的關係（例如，參與者操作業務服務），並標識可用於代表這些的實體。
下圖呈現 TOGAF 內容元模型的抽象概念的最高層次，它與 ADM 密切相關。
元模型具有由上而下有三個層次：
第一層(Layer 1): 架構原則、願景與需求
這一層中的實體(entities)旨在取得正式架構模型的背景脈絡，包括通用架構原則、形成架構建模輸入的策略脈絡以及從架構產生的需求。 架構脈絡通常在準備階段和架構願景階段收集。
第二層(Layer 2):B.D.A.T架構領域
業務架構實體(entities)取得業務運營的架構模型，特別關注激勵企業的因素、企業的組織結構以及企業具有的功能。
資訊系統架構實體取得 IT 系統的架構模型，根據 TOGAF ADM 階段查看應用程式和資料。技術架構實體取得用於實施和實現資訊系統解決方案的技術資產。
第三層(Layer 3):架構實現
這一層中的實體(entities)取得變更路線圖，顯示在"架構狀態"與"架構作業聲明"之間的過渡狀態，而這一個過渡狀態用於指導和管理架構的實現。
下圖顯示了內容元模型的更詳細資訊。 TOGAF Part IV：ACF中提供了包括詳細關係在內的圖表。
核心元模型概念
TOGAF 架構基於在架構目錄中定義 ABB，在架構矩陣中指定這些建構區塊之間的關係，並以精確方式呈現架構是什麼的通訊圖表。
核心內容與擴展內容
為了使 TOGAF 標準可用於許多不同的場景和情況，有必要為內容提供功能齊全的企業架構元模型，並能夠避免執行不必要的作業。 元模型通過劃分為核心內容和擴展內容來支援這一點，如下圖所示，核心內容設計是不可更動的。
核心內容元模型提供了一組最小化的架構內容來支援跨工件的可追溯性。 支援更具體或更深入建模的附加元模型概念包含在一組擴展(a set of extensions)中，這些擴展在邏輯上將擴展目錄、矩陣和圖表在一起的組合。
所有擴展模塊都是選用的，應該在架構開發的準備階段加以選擇來滿足組織的需求。 此外，內容元模型描述的擴展分組只是一個建議，可以根據企業架構師的判斷進一步調整以適應特定需求。
核心內容和擴展概念旨在支持 TOGAF 標準中的形式化方法擴展方法，例如 OMG(Object Management Group) 開發的 SPEM(Software Process Engineering Metamodel) 中的方法插件概念(method plug-in concept)。
核心元模型實體
內容元模型使用下表中列出的核心術語來描述元模型實體。
這些核心元模型實體之間的關係如下：
- 使用過程(process)來描述流程(flow)
過程是功能和服務之間的交互流程，無法進行物理部署。 所有過程都應該描述功能的執行流程，因此過程的部署是通過它支援的功能進行的； 即，應用程式實現具有過程的功能。 - 功能描述了所有細緻度等級的業務能力單元
功能(function)這個術語用於描述各個細緻度等級的業務能力單元，包裝了諸如價值鏈(value chain)、過程區域(Process area)、能力、業務功能等術語。任何有邊界的業務功能單元都應該被描述為一個功能。 - 業務服務支援組織目標，並在與所需治理等級位於一致的細緻度等級上定義
業務服務(business service)作為一個或多個功能的邊界來運作。 業務服務的細緻度取決於業務的焦點和重點（如所反映的驅動因素、目標和目的）。 SOA(Service Oriented Architecture)術語中的服務(即應用程式功能的可部署單元)實際上更接近應用程式服務、應用程式組件或技術組件，它們可以實現或支援業務服務。 - 業務服務部署到應用程式組件上
業務服務可以通過與IT無關的業務活動來實現，也可以通過IT來實現。 通過 IT 實現的業務服務在應用程式組件上實現。 應用程式組件可以分層分解，可以支援一種或多種業務服務。 業務服務可能由多個應用程序組件支援，但從治理的角度來看是有問題的，並且是因業務服務的細緻度太粗略或應用程式組件過於細緻的關係。 - 應用程式組件部署到技術組件上
應用程式組件由一組技術組件實現。 例如，諸如“HR 系統”之類的應用程式通常會在多個技術組件上實現，包括硬體、應用程式伺服器軟體和應用程式服務。
建構區塊、目錄、矩陣與圖表
為了讓大多數利害關係人不用知道什麼是 TOGAF 內容元模型，所以我們需要使用建構區塊、目錄、矩陣和圖表的 TOGAF 概念。
建構區塊是元模型中特定類型的實體（例如，“採購訂單”的業務服務）。 建構區塊根據元模型攜帶的元資料(metadata)，能夠支援查詢和分析。 例如，業務服務具有擁有者的元資料屬性，它允許利害關係人查詢特定組織擁有的所有業務服務。 建構區塊還可以根據架構的背景脈絡包括相關的的實體（例如，稱為“採購訂單”的業務服務可能隱含地包括許多流程、資料實體、應用程式組件等）。
目錄是特定類型或相關類型的建構區塊清單，用於治理或參考目的（例如，組織結構圖，顯示位置和參與者）。 與建構區塊一樣，目錄針對元模型帶有元資料，所以也支援分析與查詢。
矩陣是顯示兩個或多個模型實體之間關係。 矩陣的呈現是基於清單而非圖形的關係（例如，CRUD 矩陣顯示哪些應用程式create、read、update和delete特定類型的資料）。
圖表是以圖形格式呈現的架構內容。 圖表可用作以圖形方式構成架構內容或檢查已收集資訊完整性的技術。 TOGAF標準定義了一組要建立的架構圖（例如，組織結構圖）。 這些圖表中的每一個都可以針對具有不同風格或內容覆蓋範圍的架構進行多次的建立，以滿足利害關係人的問題。
在使用工具對架構建模的環境中，此類工具(建構區塊、目錄、矩陣和圖表)通常支持搜索、過濾和查詢架構存儲庫的機制。 下圖為建構區塊、目錄、矩陣、圖表與利害關係人的相互作用。
總結
架構內容框架以一致性和結構化的方式呈現產出。 它具有三類作業產品：可交付成果、工件和建構區塊。 這三類產出會從架構內容框架對映 TOGAF ADM 階段。
TOGAF 內容元模型用於以特定方式建立架構資訊。 元模型是建立模型所需的構造和規則的精確定義。 TOGAF 元模型有一個核心模塊和一組擴展模塊。
