數據架構師視角：數據治理究竟在治理什麼？

前言：從機艙看艦橋的「數據治理」

我是資料庫工作者（精確說是 DB2 工作者），處於 IBM Information Management 軟體組合的底層。若說分析、主數據管理、數據整合等高層技術人員是數據巨輪艦橋上的高級船員，穿著金肩章白制服、舉著雙筒望遠鏡眺望遠方，那我就在輪機艙。艦橋下令加快數據流速時，我回應「已達極限，船長！」但仍須想盡辦法完成任務。你們談戰略與模式，我談比特位元組、速度與供給。歡迎來到我的世界。

「數據治理」聽起來像針對問題的解決方案

最近遇到個似是而非的概念：「數據治理」。對不起長官，這聽起來像某個問題的解決方案。告訴你個小秘密：數據沒有自主行動力，意味著它不需要「治理」。它需要操控，我和夥伴們能應付，謝謝。請找別的東西去「治理」吧！

你說治理數據實際上是治理別的什麼？好，現在我有興趣了，請繼續。

核心在於人：治理的是行為，而非數據

關於數據治理，沒人比 Steve Adler 更權威——IBM Information Governance Solutions 主管暨 IBM Information Governance Council 主席。他指出「數據治理」在修辭上的矛盾性實有深意：它提醒人們提問「『數據治理』究竟是什麼意思？」。真正目標是治理行為。

人與資料庫交互：引導數據流向、解釋處理請求。人也會犯錯——常因流程缺陷、依賴的應用系統有瑕疵——在信息管道引入錯誤，導致下游數據品質問題。Adler 指出，數據治理意圖是系統化地找到並解決可能引入錯誤的點。目標是形成決策者可信任的數據，並提供數據可信的證明。

IBM 自己的「垃圾食品」實驗

Adler 問我是否了解 IBM 產品目錄。我當然了解——畢竟服務 IBM 17 年。IBM 擁有海量信息，多達 1.2 億條記錄。顯然很大部分包含錯誤信息：錯誤、缺失、未及時發布。在 255 個產品公告中，只有 5 個完全無錯。這統計數字令人震撼。

為找出數據品質問題源頭，團隊在通往生產資料庫的數據流不同位置設置「捕捉器」，發現特定條件下可能發生的錯誤。找出原因後，設計並實施基於流程與技術的解決方案，消除不準確信息源頭。

不是我的問題（也許是？）

我想，只要消除導致數據品質問題的條件就行，由您負責。我不需圍著 DBA 照管的資料庫打轉——它們很可靠，精確度至少 99.9%。生產資料庫可能超過 10 億記錄，雖錯誤率極低，但絕對錯誤量仍可觀。好吧，在資料庫內外放些捕捉器或許是好主意。

Adler 說別止步於此，因為數據品質問題不僅是記錄不準。有時迫切問題是數據分類：組織透過併購擴大規模，最終通過多業務線服務大型企業客戶。客戶抱怨：同一問題向不同業務線代表詢問，得到不同答案。因為相同術語在不同業務線含義不同。這是數據定義問題——數據治理需透過有效主數據管理 (MDM) 消除。

六步走：從看到價值到獲得價值

Adler 偏好的六步法：

1. 確定目標：有些目標可變，有些固定（如處理數據品質問題）。出發前必須明確目的地。
2. 確定度量指標：想提高數據品質，如何知道有進步？或許檢查倉庫中一定比例文檔，記錄信息不正確或缺失情況。度量過程與條件對評估基線、追蹤進程至關重要。說服人需要數字。
3. 了解組織決策模型：專制、代表、民主？無論哪種，適合貴公司嗎？您開發的數據治理策略支援該模式嗎？「更好決策」含義何在？需要大量決策還是更快決策？改進數據品質時，總須評估數據如何在環境中驅動決策，可能發現需改進之處。
4. 有效傳播策略：如何讓相關人員知曉？郵件？通訊？不能只靠口耳相傳。
5. 度量結果：策略實際效果如何？若已制定進度度量計劃（步驟 2），獲取具體數字不難。解讀數字才有趣。
6. 審查整個工作：是否採用適當流程、技術、實現有效控制？「審查」讓我不舒服，但對策略不可或缺。不喜歡評判他人工作，但理解有時必須這樣做。

這是高層檢查項，具體計劃遠超六步。但面對複雜任務，適當拆解確有助聚焦。Adler 的方法是不錯的問題拆解方式，可作為基礎展開。

結語：輪機艙的聲音值得被聽見

我接受了。若信息管理大人物再到資料庫「輪機艙」談數據治理，好好聽他們說。最好考慮自己能在哪些方面發揮作用。宏大計劃若能參考實幹家意見，往往成果更好。也許咖啡機旁會遇見您，輕鬆聊聊數據治理。