4. 架構制品（Architectural Artifacts）
架構制品是針對某個系統或解決方案的模型描述，與架構交付物和構建塊相比，架構制品既不是架構開發方法過程各階段的合約性產物，亦不是企業中客觀存在的各種可重用解決方案，而是針對包括這些構建塊在內的企業客觀現實的描述，並以解答不同干系人的關注點為其最終目標。可以說，架構交付物面向於企業架構的產生，架構構建塊傾向於企業架構的結果，而架構制品則注重於針對企業架構的應用（雖然架構交付物可以包含若干架構制品，但是架構制品在本質上還是被用來為不同的干系人按照其視角提供相應的企業客觀視圖，況且架構交付物對架構制品的包含本身也是架構制品的應用之一，其目的也是為了在架構開發過程中所涉及的不同干系人之間達成共識）。
企業架構並不是一個靜態的過程，並且不能將建設一個包含企業架構內容的信息資源庫當作唯一目標。對於任何企業來說，企業架構的意義都應該在於將其自身的戰略決策、業務和信息技術資源聯系為一個有機整體，並且不同的干系人都可以從企業架構中獲得其所需的關於企業的自上而下（自業務至用於支持各項業務實現的解決方案）的視圖，而這方面的內容屬於針對企業架構內容的使用范疇。在這一范疇之中，所有的企業架構框架理論，哪怕是幾乎不涉及企業架構內容的框架，都會關注於兩個概念：視角與視圖。關於這兩者的概念，在前面的內容已經有所涉及，其中視角是針對不同干系人企業架構內容的需求描述，而視圖是基於某一視角的具體架構內容描述，因而也可以說視角是視圖的元類型定義。在這兩個概念中，視圖比較好理解，亦即根據視角的定義而對企業客觀現狀的某一側面描述，相比之下，用於對視圖進行定義的視角概念則更為關鍵。對於視角的定義來說，僅僅一句“一個視角描述了你站在何處進行觀察”好像只能給人一種朦朦朦朧的感覺，為了更進一步描述這一概念，筆者通過對多個企業架構框架理論進行綜合后，做出了如下的理解：視角是不同干系人對於企業架構內容需求的體現，亦即其采用何種角度對企業客觀存在或計划存在的自頂層戰略、業務至底層解決方案而進行觀察。這些角度的定義基本上應該包括如下幾個方面：
- 目標需求：不同的干系人擔當着不同的角色及責任，其看問題的角度與擔當的任務也因此有着非常緊密的聯系。一般來講，目標需求大體可以分為：
- 設計層面：包括了用於指導和支持與設計決策相關的各種制品。例如架構師、開發人員以及業務流程建模人員等干系人經常會用到的UML圖、流程建模圖（例如BPMN圖）、以及用於描述數據的關系-實體圖等制品都屬於這一范疇。
- 決策層面：包括了用於支持高層決策的制品（例如，交叉引用表、情景圖、以及各種報告等制品），適用於企業中處於管理高層的各種決策人，例如CEO、CIO等。
- 告知層面：包括了用於為相關干系人進行解釋、說服以及獲得其承諾方面的制品（流程概述、圖表、宣講動畫等）。這些干系人可能會是一般職工、客戶，或者其他在企業中從業務到解決方案這條線上雖不占關鍵位置卻需要對企業架構進行了解的干系人。
- 抽象級別需求：上面一點描述了不同干系人由於其擔負任務的不同，因而對於企業的觀察也具有着不同的角度，從而對不同的制品產生興趣。然而，即使不同的干系人針對企業的相同側面有着共同的興趣，但是他們對於描述的抽象級別或詳細程度也可能有着不同的要求。例如，對於相同的業務流程來說，可能對於高層管理人員來說需要關注的僅是此流程的輸入、輸出，而對於其實現細節並不一定關心，而對於流程建模人員來說此業務流程恐怕就需要被細化為粒度更加細小的業務功能組合，而對於軟件開發人員來講，可能還要為某個具體業務行為而考慮其相關的數據結構和實現方案。
- 展示需求：上述兩點可以說是依據干系人所持的角度在內容方面所進行的分類，而除此之外，由於不同的干系人由於各自的偏好不同，他們可能會對視圖的展示也有着非常不同的要求。雖然在TOGAF中，架構制品的描述方式被定義為目錄、矩陣和圖形三種方式，但就其具體展示方式來說，不同的干系人還可能具有不同的要求和偏好。例如，對於組織結構的展示，有的干系人可能偏好於采用簡單的樹形結構的展示，而其他干系人則可能更加傾向於圖形化的結構圖。這種展示需求在圖形展示方面尤其突出，某些干系人（特別是來自於內部的干系人，例如領域專家等）可能習慣於采用某種標准的標注體系來對架構內容進行展示，而對於其他干系人來講（例如客戶或非專業的干系人）采用如此方式可能並不能取得很好的效果，而采用更加貼近現實的圖標來代替標准圖標（通常是若干簡單的形狀、連線和顏色的組合）則更加友好。雖然展示需求也是視角定義所需靠慮的元素之一，但是在大多數情況下這一層面的定義往往可以采用松耦合的方式來進行描述，即將視角的定義分為內容和展示兩個層面，並在兩者之間建立關聯（通常一個內容定義可以包含若干展示定義）。
上述關於視角分類的定義很容易讓人產生非此即彼的感覺，即視角是為干系人服務的，因而應該僅從屬於某種干系人。這樣的思想除了源於思想的慣性，最主要的還是由於忽視了企業架構的核心精神—在組織中創建無障礙的溝通信息流。作為企業架構的核心概念，如果只把視角看作為企業架構描述用的約束和定義，而忽視了溝通這一本質則是違反企業架構最終目標的。每種干系人對於視角的采用都要着自己的要求，但反過來講，視角卻不一定從屬於某種干系人，不同的干系人之間可以共享同樣的視角，也只有這樣才能保證不同干系人之間的順暢溝通。正像TOGAF中所舉的例子一樣，飛機的飛行員和航空管制員對於飛行的視角各具特點，並采用不同的語言和元素來對“飛行”進行描述，但是他們同時也采用一種通用的語言（高度、速度等）來進行溝通。在這個例子中，飛行員和航空管制員在自己的領域內分別采用了自己的視角來對“飛行”進行理解和描述，不過作為溝通用的通用語言卻形成了第三個，並且是他們所共享的視角。
企業架構開發過程的結果可以說是在架構資源庫中按照架構元模型定義而填充的各種實體元素，這也方便了在對企業架構的使用中按照各個干系人的視角為其提供相應的視圖。針對架構的使用需要自動化工具的支持，該工具需要支持視角的定義和管理，並能夠從企業架構資源庫中根據選定的視角生成相應的視圖。
視角、工具和架構內容
不同的企業架構開發框架對於架構制品、視角和視圖的定義，有着不同的描述。例如在Zachman框架中，每一個單元格所代表的是某一種干系人視角針對系統某個方面的描述，而在TOGAF中，The Open Group則采用了一種獨特的方式對視角進行了組織和定義（需要注意的是，在上一節所提到的視角分類定義只是筆者針對幾個框架理論所做的總結性描述，並不說每種框架理論都是通過這些方面來對視角進行分類和定義的）。與其他框架理論不同，TOGAF定義了一系列原子架構制品，並倡議在企業架構過程中根據不同干系人的需要對這些原子架構制品進行組合，從而生成對於視角的定義。這些原子架構制品業可被看為原子級的視角定義，實際上在TOGAF中也正是用視角（ViewPoint）這個詞來稱呼各個架構開發階段相關的原子架構制品。TOGAF並不強制其用戶遵循這些原子架構制品，用戶可以根據自己的需要增加新的原子架構制品，或對已經定義的原子架構制品進行修訂。根據架構制品的描述形式，TOGAF將這些原子架構制品分為以下三類：
- 目錄（Catalogs）：此種類型的原子架構制品（視角）以列表的形式對各種構建塊進行列舉。
- 矩陣（Matrices）：此種類型的原子架構制品（視角）用於展示特定構建塊之間的關系。
- 圖形（Diagrams）：此種類型的原子架構制品（視角）采用了一種具有豐富表現力的方式對構建塊以及他們之間的關系進行了展示。此種方式特別適合用於在干系人之間進行溝通的場合。
4.1 架構開發過程與架構制品
表面上架構制品並不像架構交付物那樣與架構開發方法的各個階段有着很強的契約性關聯，但是做為架構交付物的重要組成部分，架構制品與架構開發方法之間也有着非常緊密的聯系。在TOGAF中，針對架構制品的組織和描述也是以架構開發方法各階段為基礎的，它詳盡展示了在每個架構開發方法階段中所產生的各個原子架構制品，以及這些架構制品與架構內容元模型各擴展之間的關系。
| 架構開發方法階段 |
架構制品類型 |
架構制品 |
內容元模型擴展 |
| 預備階段 |
目錄 |
原則目錄 |
核心 |
| 矩陣 |
N/A |
|
|
| 圖形 |
N/A |
|
|
| 架構願景 |
目錄 |
N/A |
|
| 矩陣 |
干系人映射矩陣 |
Core |
|
| 圖形 |
價值鏈圖 |
Core |
|
| 解決方案概念圖 |
Core |
||
| 業務架構 |
目錄 |
組織/執行者目錄 |
Core |
| 驅動力/目標/階段目標目錄 |
Motivation |
||
| 角色目錄 |
Core |
||
| 業務服務/功能目錄 |
Core |
||
| 位置目錄 |
Infrastructure Consolidation |
||
| 流程/事件/控制/產品目錄 |
Process |
||
| 合同/評測目錄 |
Governance |
||
| 矩陣 |
業務/交互矩陣 |
Core |
|
| 執行者/角色矩陣 |
Core |
||
| 圖形 |
業務足跡圖 |
Core |
|
| 業務服務/信息圖 |
Core |
||
| 功能分解圖 |
Core |
||
| 產品生命周期圖 |
Core |
||
| 目標/階段目標/服務圖 |
Motivation |
||
| 用例圖 |
Service |
||
| 組織分解圖 |
Service |
||
| 流程圖 |
Process |
||
| 事件圖 |
Process |
||
| 信息系統架構 （數據） |
目錄 |
數據實體/數據組件目錄 |
Core |
| 矩陣 |
數據實體/業務功能矩陣 |
Core |
|
| 系統/數據矩陣 |
Core |
||
| 圖形 |
類圖 |
Core |
|
| 數據傳播圖 |
Core |
||
| 數據安全圖 |
Data |
||
| 類層次結構圖 |
Data |
||
| 數據遷移圖 |
Data |
||
| 數據生命周期圖 |
Data |
||
| 信息系統架構 （應用） |
目錄 |
應用組合目錄 |
Core |
| 接口目錄 |
Core |
||
| 矩陣 |
系統/組織矩陣 |
Core |
|
| 角色/系統矩陣 |
Core |
||
| 系統/功能矩陣 |
Core |
||
| 應用交互矩陣 |
Core |
||
| 圖形 |
應用通信圖 |
Core |
|
| 應用及用戶位置圖 |
Core |
||
| 系統用例圖 |
Core |
||
| 企業管理能力圖 |
Governance |
||
| 流程/系統實現圖 |
Infrastructure Consolidation |
||
| 軟件工程圖 |
Infrastructure Consolidation |
||
| 應用遷移圖 |
Infrastructure Consolidation |
||
| 軟件分布圖 |
Infrastructure Consolidation |
||
| 技術架構 |
目錄 |
技術標准目錄 |
Core |
| 技術組合目錄 |
Core |
||
| 矩陣 |
系統/技術矩陣 |
Core |
|
| 圖形 |
環境及位置圖 |
Core |
|
| 平台分解圖 |
Core |
||
| 處理圖 |
Infrastructure Consolidation |
||
| 網絡計算/硬件圖 |
Infrastructure Consolidation |
||
| 通信工程圖 |
Infrastructure Consolidation |
||
| 機會及解決方案 |
目錄 |
N/A |
|
| 矩陣 |
N/A |
|
|
| 圖形 |
項目背景圖 |
Core |
|
| 效益圖 |
Core |
||
| 需求管理 |
目錄 |
需求目錄 |
Core |
| 矩陣 |
N/A |
|
|
| 圖形 |
N/A |
|
4.2 架構制品定義
4.2.1 原則目錄（Principles catalog）
原則目標對各項業務原則及架構原則進行列舉，用以表明一個好的解決方案或架構看起來應該是什么樣子。原則用於對各架構決策點的輸出進行評估和認可。原則也可在針對變更舉措的架構治理中充當輔助工具。
4.2.2 干系人映射矩陣（Stakeholder Map Matrix）
干系人映射矩陣用於明確參與架構活動的各個干系人、他們的影響、他們的主要問題，以及架構框架所必須解答的關注點。通過對於干系人的識別，並對他們的需求進行理解，架構師可以將注意力集中在能夠滿足干系人需求的各個領域之中。此目錄所涉及到的內容元模型實體包括：
- 原則
4.2.3 價值鏈圖（Value Chain Diagram）
價值鏈表提供了一張面向高層的企業視圖，用於表示企業如何與外界環境交互。與在業務架構階段中開發出來的更加正式的功能解構圖相比較，價值鏈表更着重於表象上的影響。價值鏈表的目標是使一個特定的變更主張能夠快速地在干系人中獲得一致性認識，從而使得所有參與者能夠對架構所涉及到的高層次功能性和組織性環境進行理解。
4.2.4 解決方案概念圖（Solution Concept Diagram）
解決方案概念圖提供了一個解決方案的高層次方向，用於達成架構所涉及的各個目標。與后續架構開發方法階段開發出來的、更正式且更詳細的架構圖相比較，解決方案概念圖更像是在一開始階段關於期望解決方案的一張草圖。這張圖體現了關鍵的目標、需求和約束，並對將采用正式架構模型來進行更詳細描述的各個工作區域進行了標明。解決方案概念圖的目標是使一個特定的變更主張能夠快速地在干系人中獲得一致性認識，從而使所有的參與者能夠理解架構所需要的究竟是什么，以及一個特定的解決方案被期望以何種方式來滿足企業的需求。
4.2.5 組織/執行者目錄（Organization/Actor Catalog）
該目錄的目標是得到一份明確的包括用戶和IT系統所有者在內的所有與IT有互動的參與者列表。該列表可以在開發需求時作為完備性檢測的參考。例如，針對於一個對客戶進行服務支持的應用的需求，我們可以通過如下幾個方面對其進行完備性檢測：
- 需要對何種類型的客戶進行支持。
- 是否某種類型的用戶存在特定需求或約束。
此目錄所涉及到的內容元模型實體包括：
- 組織單位
- 執行者
- 位置（如果一個單獨的位置目錄並不存在，則關於位置的信息就需要在這個目錄中加以維護）
4.2.6 驅動力/目標/階段目標目錄（Driver/Goal/Objective Catalog）
該目錄的目標是描述組織如何通過目標、工作目標和評測（可選內容）來滿足其驅動力的需要，並為此提供一份跨越組織的參考。通過針對驅動力、目標和階段目標的層層分解，各個變更舉措可以采用一種跨越組織邊界的方式進行協同，並在隨后的活動中使得各個干系人得以被明確，此外，相關的變更舉措也能夠被整合或協調起來。此目錄所涉及到的內容元模型實體包括：
- 組織單元
- 驅動力
- 目標
- 階段目標
- 評測（可選內容）
4.2.7 角色目錄（Role Catalog）
角色目錄的目標是為企業中所有的授權級別或區域提供一份列表。一般情況下，應用的安全或行為應該按照其對授權概念的理解而分別進行定義，但在與用戶的計算機相綁定時卻造成了復雜且不被期望的后果。如果角色在整個組織和所有應用中都得到了定義、理解和共識，那么更加安全並能夠提供更加無縫的用戶體驗的應用將會出現，因為管理員無需通過迂回的解決方法來使用戶執行他們的工作。除了對企業的安全定義進行支持，角色目錄還可以是明確組織變更管理影響、定義工作職能，以及執行最終用戶培訓這些方面的關鍵輸入。
由於每個角色都暗含着關於一系列業務功能的訪問，如果這些功能被影響到，那么變更管理將必不可少，組織的職責也需要被重新定義，同時新的培訓可能也是需要的。此目錄所涉及到的內容元模型實體包括：
- 角色
4.2.8 業務服務/功能目錄（Business Service/Function Catalog）
業務服務功能目錄的目標是提供一份功能性的解構，使得各種功能可以被過濾、匯報和查詢，並能夠作為功能結構圖的一個有力補充。服務功能目錄可以被用來對組織中的各項能力進行明確，並對組織中施加到各種功能上的治理水平加以理解。通過功能解構，用於支持業務變化所需要的各種新能力能夠被識別出來，或者對變更措施、應用以及技術組件的范圍進行確定。此目錄所涉及到的內容元模型實體包括：
- 組織單位
- 業務功能
- 業務服務
- 信息系統服務（可選內容）
4.2.9 位置目錄（Location Catalog）
位置目錄為企業的業務運營或房屋建築相關的資產（例如數據中心或終端用戶計算設備）所處位置提供了一份列表。針對此位置列表的維護，各個變更舉措的位置范圍得以被快速地定義出來，並且針對當前情況和建議的目標解決方案進行評估時，完備性測試也得以被執行。例如，一個用於更新台式計算機操作系統的項目需要識別出這些系統所部署的位置。與此相似，當實施一個新的系統時，一張關於位置的圖形描述對於開發適當的部署策略是非常關鍵的，該部署策略被用於對用戶和應用的位置進行了解，並且各個與位置相關的問題（例如，國際化、本地化、針對可用性的時區影響、延時距離影響、網絡帶寬影響和訪問）也得以被明確。此目錄所涉及到的內容元模型實體包括：
- 位置
4.2.10 流程/事件/控制/產品目錄（Process/Event/Control/Product Catalog）
流程/事件/控制/產品目錄為流程、觸發流程的事件、流程的輸出和施加到流程執行之上的控制提供了一份層次結構，並可被用來作為流程圖（Process Flow diagram）的一個有力的補充，這些流程圖使得企業可以進行跨越組織和流程的過濾、匯報和查詢操作，從而對其范圍、通用性或影響進行明確。例如，流程/事件/控制/產品目錄使得企業可以查看流程與各子流程之間的關系，從而明確源自於一個高層流程的變更所能帶來的影響鏈。此目錄所涉及到的內容元模型實體包括：
- 流程
- 事件
- 控制
- 產品
4.2.11 合同/評測目錄（Contract/Measure Catalog）
此目錄提供了一份關於所有經過批准的服務合同以及與此相關的評測的列表，從而形成了在整個企業內獲得批准的服務水平的主列表。此目錄所涉及到的內容元模型實體包括：
- 業務服務
- 信息系統服務（可選內容）
- 合同
- 評測
4.2.12 業務交互矩陣（Business Interaction Matrix）
此矩陣用於描述企業中各組織與業務功能之間的交互關系。理解企業中的業務交互是很重要的，因為它有助於突出整個組織中的價值鏈以及相互依賴關系。此矩陣所涉及到的內容元模型實體包括：
- 組織
- 業務功能
- 業務服務
- 業務服務之間的通信關系
- 業務服務之間的依賴關系
4.2.13 執行者/角色矩陣（Actor/Role Matrix）
此矩陣用於展示哪些執行者扮演何種角色，並支持對安全性和技能需求的定義。理解執行者與角色之間的關系對定義培訓需求、用戶安全設置和組織變更管理具有關鍵性作用。此矩陣所涉及到的內容元模型實體包括：
- 執行者
- 角色
- 執行者與角色之間的擔當關系
4.2.14 業務足跡圖（Business Footprint Diagram）
業務足跡圖描述了業務目標、組織單元、業務功能和服務之間的關聯，並將這些功能映射到各個提供了所需能力的技術組件之上。它在從技術組件到業務目標的映射中提供了清晰的可追溯性，同時還對已經明確的服務的所有權進行了闡述。業務功能圖僅對聯系組織單元功能與交付服務的關鍵因素進行描述，並且還可被用來作為與高層次干系人（CIO、CEO等）進行溝通的平台。
4.2.15 業務服務/信息圖（Business Service/Information Diagram）
業務服務/信息圖展示了用於對一個或多個業務服務進行支持的信息，包括了由業務服務使用或者產生的數據及其信息源。服務/信息圖對信息在架構中的最初表現形式進行了展現，因此為數據架構階段的進一步描述打下了基礎。
4.2.16 功能分解圖（Functional Decomposition Diagram）
功能分解圖的目標是將組織中與架構相關的各項能力展現在一張圖紙之上。通過從功能的視角檢視組織的各項能力，企業可以快速針對組織所做的事情進行建模，而不用陷入針對組織如何做所進行的額外討論之中。
4.2.17 產品生命周期圖（Product Lifecycle Diagram）
產品生命周期圖的目標是對企業中關鍵實體的理解進行輔助。就關於產品從生產到撤銷過程中所必須遵守的環境的關注、立法和規章來說，理解產品生命周期變得越來越重要。與此相同，在為了保證在控制、流程和程序的設計嚴謹而進行的業務架構開發過程中，創建涉及個人或敏感信息產品的組織必須對產品生命周期具有一個詳盡的理解，例如信用卡、借記卡、智能卡以及用戶身份認證等信息。
4.2.18 目標/階段目標/服務圖（Goal/Objective/Ser viceDiagram）
此圖的目標是為服務對業務願景或策略的達成而定義方法。通過將服務與驅動力、目標、階段目標和相關的評測進行關聯，企業可以了解到哪些服務貢獻於相似的業務效能方面。此外，該圖還為針對某一特定服務所形成的高效能的認定提供了定性的輸入。
4.2.19 業務用例圖（Business Use-Case Diagram）
業務用例圖展示了業務服務的提供者和使用者之間的關系。業務服務被各個執行者或其他的業務服務所使用，而業務用例圖則通過針對業務能力在何時以及如何被使用的描述，為業務能力的描述方面提供了額外的價值。此圖形的目標是對各執行者和他們在各流程和功能中所擔當的角色之間的交互關系進行描述和驗證。隨着架構過程的演進，這些用例圖也將從業務級別發展至包括數據、應用和技術在內的更加詳盡的級別。除此之外，業務用例圖也可在系統設計工作中得到復用。
4.2.20 組織分解圖（Organization Decomposition Diagram）
組織分解圖描述了執行者、角色以及他們在組織樹中所處位置之間的關系。一份組織分解圖應提供了一條組織中決策者和業務擁有者的命令鏈。雖然組織分解圖並不打算將組織與其目標聯系在一起，但是在這張圖中為最終目標與干系人之間建立直觀的聯系也是可以的。
4.2.21 流程圖（Process Flow Diagram）
流程圖的目標是對流程元模型實體相關的所有模型和映射進行描述，它展示了位於各個活動之間的順序化控制流，並可借助於泳道技術來表達各個流程步驟的歸屬和實現。例如，用於支持一個流程步驟的應用就可以作為一條泳道來展示。除此之外，流程圖也可以被用來細化賦予在流程之上的控制、觸發某流程或產生於流程結束時的事件，以及由於流程執行所產生的各種輸出產物。流程圖在為主題專家描述架構時非常有用，它可以為這些專家描述一個特定功能的工作是如何被完成的。通過這樣一個過程，每個流程步驟可以被細化為更小粒度的功能塊，而且這些功能塊在以后亦可以被當作一個流程來進行進一步的闡述。
4.2.22 事件圖（Event Diagram）
事件圖的目標是描述事件與流程之間的關系。諸如某些特定信息的到來，或者是某個特定的時間點這樣的特定事件會致使業務中特定的工作和行為得以進行，同時也經常會有被稱為業務事件（或簡稱事件）的信息被當作某個流程的觸發者。
4.2.23 數據實體/數據組件目錄（Data Entity/Data Component Catalog）
數據實體/數據組件目錄的目標是明確和維護企業中使用的所有數據的列表，包括數據實體，以及用於存儲數據實體的數據組件。一個經過批准的數據實體/數據組件目錄支持對信息管理和數據治理策略的定義和應用，並且鼓勵對數據進行有效地共享和重用。此目錄所涉及到的內容元模型實體包括：
- 數據實體
- 邏輯數據組件
- 物理數據組件
4.2.24 數據實體/業務功能矩陣（Data Entity/Business Function Matrix）
此矩陣用來描述企業中數據實體和業務功能之間的關系。業務功能被具有明顯邊界的業務服務所支持，並通過業務流程加以實現。通過數據實體與業務功能之間的映射，企業可以得到：
- 將數據實體的所有權分配給各個組織。
- 理解業務服務的數據和信息交換需求。
- 支持差距分析，並決定是否有需要被創建的數據實體被遺漏。
- 為數據實體定義源系統、記錄系統和引用系統。
- 啟動企業的數據治理程序的開發（建立數據管家、開發與業務功能相關的數據標准等）。
此矩陣所涉及到的內容元模型實體包括：
- 數據實體
- 業務功能
- 數據實體與其所屬組織單位的“從屬”關系
4.2.25 系統/數據矩陣（System/Data Matrix）
此矩陣用於描述系統與系統所訪問和更新的數據實體之間的關系（一張兩維表，其中一個緯度對應邏輯應用組件，而另外一個則對應數據實體）。系統用於創建、讀取、更新和刪除與他們相關聯的特定數據實體。例如，一個客戶關系系統將創建、讀取、更新和刪除客戶實體信息。處在一個被封包好的服務環境中的數據實體可以被分為主數據、引用數據、事務數據、內容數據和歷史數據，而用於操作這些數據實體的應用則包括事務應用、信息管理應用和業務倉庫應用。針對應用組件和數據實體之間映射是一個非常重要的步驟，因為它可以使得：
- 針對數據的訪問能力被分配給組織中的具體應用。
- 了解在不同應用中數據重復的程度，以及數據生命周期的規模。
- 了解在何處相同的數據會被不同的應用所更新。
- 支持差距分析，並確定是否本應存在的應用被遺漏了。
4.2.26 類圖（Class Diagram）
類圖的主要目標是描述企業中重要數據實體（或類）之間的關系。此圖用於清晰地展示數據之間的關系，並幫助干系人理解企業下層數據模型。
4.2.27 數據傳播圖（Data Dissemination Diagram）
數據傳播圖的目標是展示數據實體、業務服務和應用組件之間關系。此圖展示了各個邏輯實體如何被應用組件所實現。它使得針對數據大小的調整得以被有效地執行，同時IT足跡也會得以改善。而且，通過為數據設置業務價值，應用組件的業務重要性的指標也能夠在同時被獲得。另外，此圖還可以展示針對數據復制和主引用的所有權，即它可以展示數據的兩個備份以及數據之間的主-備份關系。此圖還能夠包含服務，比如，封裝數據並且駐留在應用之內的服務，或者駐留在應用之上並能夠訪問封裝在應用中的數據的服務。
上面所說的IT footprint中，footprint，即足跡，的本意是由動物遺留下的包含了遺留者本身標識和信息的事物。在信息技術領域，根據哈佛商學院Andrew McAfee所述，技術足跡表示了其在地理、邏輯分區和/或功能方面所能延展到范圍，是針對一個信息技術所期望的覆蓋范圍的描述（A technology's footprint is its geographic, divisional, and/or functional reach. It's a description of how much territory a piece of IT is intended to cover）。在TOGAF中並沒有說明數據大小的調整與IT足跡改善之間的關系，也沒有說明所謂的IT足跡改善的具體含義。不過通過互聯網上的一個關於IT足跡改善的實例，即將原本有着十幾台計算機的教室用一台中心計算機和若干終端來代替，筆者有感而發，粗淺的認為這里IT足跡改善意思是說由於數據尺寸得到了很好的調整，那么不必需的冗余信息被削減，因而數據和應用的“足跡”，即其涉及到的范圍，將比冗余剔除前更加清晰有效
4.2.28 數據安全圖（Data Security Diagram）
數據可以看作是企業的一項資產，簡單的講，數據安全可被認為是確保企業數據不被損害，並且針對數據的訪問也要在適當的控制之下。數據安全圖的目標是描述何執行者可以訪問企業中的哪些數據。此外，此圖也可以被用來闡述與數據隱私法規以及其他應用性法規的符合度。此圖還需要考慮發生在企業合作伙伴或其他團體對企業系統進行訪問之處的信任含義，例如在外包的情形下，信息可能會被企業之外的其他人員（甚至身處國門之外）所管理。
4.2.29 類層次結構圖（Class HierarchyDiagram）
類層次結構圖的目標是為技術方面的干系人展示一個有關類層次的視圖。此圖的優點是干系人可以得到一份關於數據實體在技術層面上如何被使用的圖形描述，它使得干系人可以了解何人正在針對數據進行使用，以及他是在何時、如何以及為何進行這項活動。
4.2.30 數據遷移圖（Data Migration Diagram）
在實現一個以封包服務為基礎的解決方案時，數據遷移是非常重要的，特別是將現存的遺留系統替換為一個服務封包時，或者當企業將要遷移到一個更大的封包服務時。每個服務包都傾向於具有屬於他們自己的數據模型，並且在數據遷移過程中，遺留的應用數據可能需要在載入到服務封包之前需要進行某種轉化。數據遷移活動通常包含如下的步驟：
- 從原有應用中抽取出數據。
- 配置源數據
- 執行數據轉換，其中包括數據質量相關的各個過程：
- 對數據進行標准化、歸一化，並消除數據的重復性（數據清洗）。
- 針對不同來源的數據進行比對、合並和整合。
- 進行自源頭至目標的映射
- 將數據加載到目標應用之中。
數據遷移圖的目標是展示數據如何從源頭應用流入到目標應用之中。此圖為數據從源頭到目標過程的進行提供了一個可視化表達，並可在數據審計和追溯中作為輔助工具。此外，此圖所展示的細節程度可以按照需要進行調整。例如，數據遷移圖可以僅僅包含一個關於遷移情況的整體布置，也可以為單獨的應用提供元數據元素級別的詳細信息。