書接上回，我們介紹了元數據的三大基礎：Business Glossary（業務定義）、Data Catalog（技術目錄）以及 Linkage（兩者連結）。這三者解決了「資料是什麼」以及「資料在哪裡」的問題。

但對於想要使用資料的人來說，光知道這些還不夠。他心裡一定還有這些疑問：
「這資料出了問題我該找誰？」
「這資料是哪個部門負責維護的？」
「我該怎麼申請？這資料敢用在財報上嗎？」
為了回答這些問題，我們必須引入元數據架構中剩下的三個關鍵實體：Ownership (權責)、Domain (領域) 以及最核心的 Data Product (資料產品)。

Ownership (權責) —— 告別「踢皮球」大賽

在過去沒有治理時，資料出錯往往是一場災難。業務說系統爛，IT 說業務亂輸入，最後大家在 Email 裡互踢皮球。為了終結這個窘境，我們在元數據中明確區分了兩種 Ownership：
業務負責人 (Business Owner)：
標定位置：掛載於 Business Glossary Term 上。
職責：負責解釋資料的業務含義、計算邏輯。例如 Employee 的業務負責人通常是 HR 部門的主管或資深專員。
技術負責人 (IT Owner)：
標定位置：掛載於 Data Catalog 上。
職責：負責資料庫的維運、ETL 的穩定性。例如 hrsysdb.dbo.employee_master 的負責人就是 HRIS 的系統工程師。
透過這種雙層標定，當資料發生問題時，我們可以精準定位：是邏輯定義有誤找 Business Owner，還是資料流中斷找 IT Owner。

Domain (領域) —— 邁向 Data Mesh 的第一步

隨著企業規模擴大，單靠一個中央集權的「資料治理部門」是不可能搞懂所有資料的。試問：資料治理團隊會比財務部更懂「財報數據」嗎？會比供應鏈更懂「安全庫存」嗎？顯然不會。
因此，我們引入了 Domain (領域) 的概念。我們將資料依照業務屬性劃分疆域（例如：HR 領域、財務領域、銷售領域）。
分權治理：Domain 標籤代表了公司內部最高層級的權責劃分。該領域內的資料定義、品質與隱私分級，應由該 Domain 的團隊負責。
KPI 追蹤：這也是我們評估治理進度的關鍵。我們不會問「全公司治理了多少資料？」，而是問「財務 Domain 的核心資料治理覆蓋率達到多少了？」。這讓治理責任真正回歸到業務源頭。

Data Product (資料產品) —— 賦予資料「服務」的靈魂

這是元數據治理中最高階、也是最抽象的概念。很多工程師會問：「我有 Data Catalog (目錄) 了，使用者直接查表不就好了，為什麼還要包裝成 Data Product？」
答案很簡單：Data Catalog & Buisness Glossary是「零件&使用說明書」，而 Data Product 是「貨架上的已經用包裝包好的商品」。
零件只有規格，沒有保固，沒有說明書，壞了你可能不知道找誰修。
但商品有包裝、有保存期限、有售後服務、有價格。
讓我們用 API 的世界來做個對比，你就能瞬間理解這三層架構的差異：

Data Product 的核心屬性拆解
一個合格的 Data Product，必須像一份「契約」。在我們的元數據平台中，一個 Data Product 必須包含以下，才能被允許上架：

• 內容物與介紹 > 對應到Data Catalog的Table與Business Glossary
• 商品背書>包含產品名稱、Owner、Domain。
• 存取與安全 > 誰可以獲取，獲取的流程，誰可以申請？（例如：僅限主管級）。
• 使用指引> 我要怎麼用這個產品，EX: Sample Queries：提供標準 SQL 範本。

總結：一張圖看懂資料的 3W 1H

最後，我們終於可以回答使用者對資料的所有疑問。
以下這張架構圖，總結了我們這兩篇文章的核心。你可以看到 Data Product 如何作為最上層的服務載體，封裝了底下的定義與實體，並由 Owner 與 Domain 進行支撐。同時，也展示了我們常遇到的「一張表對應兩個術語（工號 vs 系統碼）」的 Linkage 關係。

+---------------------------------------------+
| [How] Data Product (資料產品)                |
|---------------------------------------------|
| 1. 內容物與介紹    3. 存取與安全             |
| 2. 商品背書        4. 使用指引               |
+----------------------+----------------------+
                       |
                       v
+----------------------+  +-------------------+
| [What] Glossary      |  | [Where] Catalog   |
|----------------------|  |-------------------|
| 1. Emp Code (工號)   |=>| - badge_number    |
| 2. System ID (系統碼)|=>| - emp_uuid        |
+----------+-----------+  +---------+---------+
           ^                        ^
           | Owns                   | Owns
+----------+-----------+  +---------+---------+
| [Who] Biz Owner      |  | [Who] IT Owner    |
+----------+-----------+  +---------+---------+
           ^                        ^
           +------------+-----------+
                        |
                 [Who] Domain: HR

至此，我們的元數據治理基礎建設已經介紹完畢。
我們定義了資料是什麼 (Glossary)，在哪裡 (Catalog)，誰負責 (Owner/Domain)，以及如何作為一項服務被使用 (Data Product)。
有了這些數位資產的地基，接下來的篇章，我們將深入探討各個元數據的進階內容，包含業務詞彙的目錄結構，責任人的詳細R&R，以及資料產品的目錄