對于任何數據管理專業人員來說，實現數據管理的實用和務實的方法都是關鍵的挑戰之一。我的數據管理/治理經驗始于十多年前，我第一次設計并實現了數據管理框架。當時，這個問題似乎很簡單。但是，我在數據管理方面獲得的經驗越多，數據管理/治理角色的問題就變得越復雜。在最近的一年里，我發現了一些在設計角色時需要考慮的新挑戰。在本文中，我想分享對當前通用方法的看法，討論應該考慮到的關鍵因素，并分享在制定數據管理/治理角色的實踐。

一 、常見方法面臨的挑戰

在我看來有幾個挑戰與現有的角色設計相關，如下圖所示:

1、角色數量多

關于數據管理/治理角色在不同框架中介紹了非常多角色。即使是DAMA國際的出版物也呈現了大量的角色:準確地說，有120個!最大的挑戰是這些角色和過程、要交付的任務以及要產生的工件之間的一致性。同時，角色和企業規模之間不明確的關系也是一大挑戰。

2、沒有明確的影響因素

在與許多構建數據管理/治理角色的數據管理專業人員交談時，我經常得到這樣的印象:他們只是從眾所周知的來源復制角色，而沒有分析可能影響角色設計模式的因素。這種方法導致了角色和責任不一致的問題。

3、角色和需求不一致

有一次我聽到一位同事說:“我們已經制定了管家和保管人的角色。”從語言學上講，“管家”和“保管人”是同義詞。這也是盲目復制角色的一個例子。之所以會出現這種情況，是因為在如何設計符合公司需求和現實的角色方面，沒有明確的指導方針。

4、沒有明確的指導方針

例如，在DAMA-DMBOK2中引入了與管家相關的不同角色:“數據管家”、“數據托管人”、“首席數據管家”、“業務數據管家”、“協調數據管家”、“執行數據管家”、“數據管家協調人”、“技術數據管家”。公司可以遵循什么規則來選擇“剛剛好”的管理員角色，以及管理員的正確職責是什么。

下面讓我們看看數據管理專業人員在設計數據管理/治理角色時應該考慮的因素。

二 、影響數據管理/治理角色設計的關鍵因素

下面我們討論影響數據管理/治理角色的七個關鍵因素，如下圖所示。

1、數據管理員的類型

數據管理的概念源于數據所有權的概念。作為一個整體，該公司擁有數據。公司將與數據相關的任務委托給不同類型的數據專員。DAMA明確表明，數據管家和數據托管人是同義詞。DAMA指定一個或一組“代表所有利益相關者的利益，必須從企業角度確保企業數據的高質量和有效使用”的人作為數據管理員。DAMA還指定了不同類型的數據專員。

數據專員可以根據其專業背景分為三類:業務、數據、技術。使用這種方法，可以將這些角色分配給處理數據的每個員工。數據管理員角色可以是正式的，也可以是虛擬的。正式意味著在組織結構中創建實際角色，可以將虛擬角色分配給已經存在的角色。

2、數據管理能力結構

在企業中關鍵的數據管理能力，包括數據鏈、數據管理框架、數據質量、數據建模、數據架構。四個維度支持這些功能:過程、角色、數據和工具。下圖“橙色”部分提供了沿著這些維度劃分數據治理/管理角色的方法。

例如，“業務流程所有者”和“系統所有者”對應于“流程”和“工具”維度。“數據”維度將描述數據所有者/數據用戶角色的責任。“角色”維度將明確組織層次結構中的角色分配。這些角色的職責將同時取決于它們在數據鏈中的位置。

3、數據鏈條上的位置

數據鏈描述了原始數據轉化為有意義信息的路徑。在下圖中，可以看到我們剛才討論的角色之間的關系，以及它們在數據鏈中的位置。

數據鏈與一個或多個業務流程相關聯。因此，業務流程所有者將沿著屬于其責任的數據鏈對業務流程負責。數據處理可能涉及一個或多個系統和/或應用程序。每個應用程序都有一個應用程序所有者。數據所有者和數據使用者將對數據負責。我們稍后將討論他們的責任。上述所有角色都將分配給業務數據專員。不同的數據管理能力需要支持數據鏈。所有類型的數據管理員都將執行與這些功能相關的流程，并交付相應的工件。數據鏈的數據架構會有所不同，也會影響角色的設計。

4、數據架構體系風格

數據架構將影響與數據、業務流程和系統相關的角色。如下圖所示，規范化和大數據平臺架構之間有很大的區別。

（1）規范的體系結構

許多公司仍然采用這種形式的架構。不同的來源和消費應用程序之間有太多的關系。在專業術語中，他們通常稱這種類型的架構為“意大利面式架構”。

（2）大數據平臺

來自不同源系統的數據進入中央大數據平臺。這個平臺有不同的數據域。數據在平臺內被處理，然后分發給不同的用戶。這類平臺的關鍵問題是數據集成和轉換的位置。它是發生在平臺本身，還是發生在面向消費者的過程中?這種決策也將影響角色的設置。

（3）數據網格平臺

數據網格平臺也與大數據架構相關。在這種情況下，將組織兩種不同的數據域類型:來源和消費。每個領域都是數據源系統和大數據平臺或大數據平臺和數據源系統中的數據的組合。在每個域內，根據該域的業務需求處理數據。

不同的架構風格將影響數據所有者和數據消費者的責任分配。架構風格也會影響數據建模和解決方案設計的模式。

5、數據建模方案設計

在規范方法中，根據企業架構指南TOGAF 9.2，數據模型設計和解決方案設計屬于不同的連續體。企業架構包括四個相互關聯的架構:業務、數據、應用和技術。數據架構提供概念、邏輯和物理數據模型。解決方案架構應該將物理數據模型付諸實踐。相反，新方法將數據模型設計和解決方案設計結合起來。概念數據模型、邏輯數據模型和解決方案數據模型應該在一個流程中同時設計。這意味著，根據數據管理和技術數據管理人員的方法不同，他們的職責和可交付成果也不同。也會影響數據管理相關的流程。

6、業務和數據域定義

在DAMA-DMBOK 2中將數據管理員的審批權限分配給其域。這種挑戰就在于指定“域”的定義。至少有三種可能的方法來指定域，如下圖所示。

第一種方法基于新數據創建的概念。數據沿著數據鏈流動。在這個過程中，數據要么改變要么不變。第一個挑戰是指定數據更改的條件。通常，主數據和引用數據保持不變，而事務性數據將更改。元數據將確保數據的更改。根據數據類型的不同，可以以不同的方式指定數據所有者的責任。

第二種方法基于數據內容。例如，客戶數據是通常與概念模型相關聯的主題領域。公司可以基于數據主題域分配數據所有權。基于業務能力域分配數據所有權的業務體系結構方法也可能適用。

第三種方法不太常見，根據組織結構指定數據所有權。

實際上，在企業中這些方法可以組合使用。

7、企業范圍以及規模

當公司設計一組角色時，應該考慮數據管理計劃的范圍和公司的規模。它將影響數據管理組織結構中所表示的角色的復雜性。假設業務單元成為特定數據集的數據所有者。然后，在這個業務單元中，數據所有權的最終責任和相應責任將在業務單元經理和員工之間分割。

在你分析了所有與你的公司相關的因素之后，最后一步是設計角色。

三 、設計數據管理/治理角色集

我的建議是不要隨便復制已經存在的解決方案，讓一組角色盡可能簡單，以滿足公司的實際需求。

下面的模型將數據管理視為一種業務功能。四個維度的支持能力:過程、角色、數據和工具。建議在最后階段將角色與數據管理流程和交付物聯系起來，下圖是一個示例。